Kai pirmą kartą išgirdau apie ES dirbtinio intelekto reglamentą, pagalvojau — na, dar vienas biurokratinis dokumentas, kurį teisininkai skaitys, o programuotojai ignoruos. Realybė pasirodė kitokia. AI Act (oficialiai — Reglamentas (ES) 2024/1689) jau dabar keičia tai, kaip įmonės projektuoja, testuoja ir diegia dirbtinio intelekto sprendimus, o pasekmės palies ne tik didžiuosius technologijų gigantus, bet ir vidutinio dydžio IT komandas, kurios naudoja trečiųjų šalių AI įrankius savo produktuose.
Straipsnyje pabandysiu paaiškinti, kas iš tikrųjų slypi po šiuo reglamentu, kodėl jis sukonstruotas būtent taip, kaip sukonstruotas, ir ką konkrečiai reikia daryti, jei jūsų komanda kuria ar naudoja AI sprendimus Europos rinkai.
Kodėl apskritai reikėjo tokio reglamento
ES jau seniai turi GDPR duomenų apsaugai, turi kibernetinio saugumo direktyvas, turi produktų saugos taisykles. AI Act atsirado todėl, kad dirbtinis intelektas nepakliūva tvarkingai nė į vieną iš šių kategorijų. Modelis gali priimti sprendimą dėl paskolos, atrinkti CV kandidatus ar valdyti pramoninį įrenginį — ir jokia esama teisinė sistema tam nebuvo pritaikyta.
Reglamentas priimtas remiantis rizikos principu — panašiai kaip medicinos prietaisų reguliavime. Idėja paprasta: kuo didesnė žala, kurią sistema gali padaryti žmogui, tuo griežtesni reikalavimai jai taikomi. Tai skiriasi nuo, tarkime, JAV požiūrio, kur reguliavimas labiau sektorinis ir fragmentiškas. Europa pasirinko horizontalų modelį — vienas įstatymas visoms sritims, bet su skirtingais reikalavimų lygiais.
Svarbu suprasti: AI Act taikomas ne tik ES įsikūrusioms įmonėms. Jei jūsų sistema naudojama ES rinkoje arba jos rezultatai turi poveikį ES gyventojams, reglamentas galioja jums, nesvarbu, kur fiziškai yra jūsų serveriai ar biuras. Tai tas pats ekstrateritorialumo principas, kurį jau matėme su GDPR.
Keturi rizikos lygiai — kaip tai veikia praktiškai
Visa sistema sukasi apie keturias kategorijas, ir verta jas įsiminti, nes būtent nuo jų priklauso, kiek popierizmo ir techninio darbo laukia jūsų projekto.
- Nepriimtina rizika (unacceptable risk) — tokios sistemos tiesiog draudžiamos ES rinkoje. Jokių išimčių, jokių sertifikatų, kurie leistų jas legalizuoti.
- Didelė rizika (high-risk) — čia didžiausias reguliavimo svoris. Sistemos, susijusios su darbo įdarbinimu, kreditingumo vertinimu, teisėsauga, švietimu, medicina, kritine infrastruktūra.
- Ribota rizika (limited risk) — daugiausia skaidrumo reikalavimai. Pavyzdžiui, jei bendraujate su chatbotu, jums turi būti aišku, kad tai ne žmogus.
- Minimali rizika (minimal risk) — didžioji dauguma šiandien naudojamų AI sistemų, pavyzdžiui, spam filtrai ar žaidimų AI. Praktiškai jokių papildomų įsipareigojimų.
Įdomu tai, kad dauguma šiandien rinkoje esančių AI produktų patenka į paskutinę kategoriją. Bet jei jūsų startuolis planuoja plėstis į HR technologijas, finansų sektorių ar sveikatos priežiūrą — geriau iš karto pradėti galvoti apie „high-risk” reikalavimus, nes vėliau juos „prilipdyti” prie jau veikiančio produkto bus daug brangiau.
Kas visiškai uždrausta
Draudžiamų praktikų sąrašas nėra ilgas, bet kiekvienas punktas ten atsidūrė neatsitiktinai — dažniausiai po realių incidentų ar viešų skandalų. Trumpai:
- Subliminalios ar manipuliacinės technikos, kurios iškreipia žmogaus elgesį taip, kad jam pačiam nesuvokiant padaroma žala.
- Pažeidžiamumų (amžiaus, negalios, socialinės ar ekonominės situacijos) išnaudojimas siekiant manipuliuoti elgesiu.
- Socialinio kredito reitingavimo sistemos, panašios į tas, apie kurias kalbama Kinijos kontekste.
- Biometrinis atpažinimas realiu laiku viešose vietose teisėsaugos tikslais — su labai siaurai apibrėžtomis išimtimis, pavyzdžiui, dingusių vaikų paieškai ar teroro aktų prevencijai.
- Emocijų atpažinimo sistemos darbo vietoje ir švietimo įstaigose (išskyrus medicinos ar saugumo tikslus).
- Veidų duomenų bazių kūrimas per neselektyvų atvaizdų nuskaitymą iš interneto ar CCTV kamerų (aiški nuoroda į Clearview AI atvejį).
Šis sąrašas galioja jau nuo 2025 metų vasario — tai buvo pirmoji reglamento dalis, kuri įsigaliojo praktiškai iš karto po priėmimo. Jei jūsų produktas artimas kuriai nors iš šių kategorijų, verta konsultuotis su teisininku dar prieš rašant pirmą kodo eilutę, nes čia nėra pereinamojo laikotarpio ar „minkštos” adaptacijos.
Didelės rizikos sistemos — kur slypi tikrasis darbas
Jei dirbate su high-risk sistema, reikalavimų sąrašas primena ISO standartą, tik su teisine galia. Reikės:
- Rizikos valdymo sistemos, kuri veikia visą gyvavimo ciklą, o ne tik prieš paleidimą.
- Duomenų valdymo — mokymo, validavimo ir testavimo duomenų rinkiniai turi būti aktualūs, reprezentatyvūs, be klaidų, kiek įmanoma laisvi nuo šališkumo.
- Techninės dokumentacijos, panašios į medicinos prietaisų bylas — turi būti galima atsekti, kaip sistema priima sprendimus.
- Žurnalų kaupimo (logging) automatinio veiklos fiksavimo viso gyvavimo ciklo metu.
- Skaidrumo naudotojams — jie turi suprasti, ką sistema daro ir kokie jos apribojimai.
- Žmogaus priežiūros (human oversight) — turi būti realus mechanizmas, leidžiantis žmogui įsikišti ar sustabdyti sistemą.
- Tikslumo, patikimumo ir kibernetinio saugumo reikalavimų.
Iš IT komandos perspektyvos tai reiškia, kad MLOps procesai turi keistis iš esmės. Nebeužtenka turėti modelio versijos ir metrikų dashboard’o Grafanoje. Reikia audituojamo pipeline’o, kuris parodytų reguliatoriui, kokie duomenys naudoti, kaip modelis buvo testuojamas ir kokie yra jo apribojimai realiomis sąlygomis. Daug komandų šiuo metu tiesiog perkelia dalis šio darbo į esamus DevOps procesus, papildydamos juos compliance sluoksniu — tai realistiškiausias kelias, nei kurti atskirą procesą nuo nulio.
Bendros paskirties AI ir didieji kalbos modeliai
Čia įdomiausia dalis, nes reglamentas buvo rašomas dar prieš ChatGPT sprogimą, o vėliau teko skubiai pridėti atskirą skyrių apie General Purpose AI (GPAI) modelius. Kalbame apie GPT, Claude, Gemini, Llama ir panašius pagrindinius modelius (foundation models).
Visiems GPAI tiekėjams taikomi baziniai reikalavimai: techninė dokumentacija, informacija apie mokymo duomenis (bent jau suminis aprašymas, ne visas duomenų rinkinys), autorių teisių politikos laikymasis.
Modeliams, kurie laikomi turintys „sisteminę riziką” (systemic risk) — tai apibrėžiama pagal skaičiavimo galią, naudotą mokymui (10^25 FLOPs riba), taikomi papildomi reikalavimai: adversarial testavimas, incidentų raportavimas Komisijai, kibernetinio saugumo priemonės. Praktiškai tai reiškia, kad OpenAI, Google ir Meta turės žymiai daugiau popierizmo nei vidutinis startuolis, kuris tiesiog naudoja jų API per wrapper’į.
Čia svarbu suprasti vieną niuansą, kuris daug kam kelia painiavą: jei jūs tik naudojate GPT-4 API savo produkte, jūs nesate GPAI tiekėjas — tą naštą neša OpenAI. Bet jei jūsų produktas, sukurtas ant šio modelio, patenka į high-risk kategoriją (pvz., naudojamas CV atrankai), tuomet jūs kaip „deployer” turite savo atskirus įsipareigojimus, nepriklausomai nuo to, ką daro pagrindinio modelio tiekėjas.
Terminai, baudos ir kas jau galioja
Reglamentas įsigalioja etapais, ir tai svarbu prisiminti planuojant produkto kūrimo grafiką:
- 2025 m. vasaris — draudžiamos praktikos ir AI raštingumo reikalavimai darbuotojams.
- 2025 m. rugpjūtis — GPAI modelių taisyklės, valdymo struktūros nacionaliniu lygiu.
- 2026 m. rugpjūtis — dauguma high-risk sistemų reikalavimų, skaidrumo taisyklės.
- 2027 m. rugpjūtis — likusios high-risk kategorijos, susijusios su produktų sauga (pvz., medicinos prietaisai, kur AI yra sudėtinė dalis).
Baudos primena GDPR logiką, tik dar didesnės. Už draudžiamų praktikų naudojimą — iki 35 milijonų eurų arba 7% pasaulinės metinės apyvartos, priklausomai nuo to, kas didesnė. Už kitus pažeidimus — iki 15 milijonų eurų arba 3% apyvartos. Mažesnės įmonės ir startuoliai turi šiek tiek švelnesnius koeficientus, bet principas išlieka tas pats — bauda skaičiuojama nuo apyvartos, ne nuo fiksuoto skaičiaus, todėl didelėms korporacijoms tai gali reikšti milijardus.
Ką realiai daryti, jei jūs — IT žmogus, o ne teisininkas
Baigiant norisi ne tiek apibendrinti, kiek duoti konkretų veiksmų sąrašą, nes būtent to trūksta daugumoje straipsnių apie šią temą.
Pirma — padarykite savo AI sistemų inventorizaciją. Nustebsite, kiek „paslėpto” AI naudoja jūsų organizacija — nuo rekomendacijų variklių iki paprastų anomalijų aptikimo skriptų. Kiekvienam reikia priskirti rizikos kategoriją, net jei atsakymas bus „minimali”.
Antra — jei kuriate ar integruojate high-risk sistemą, pradėkite dokumentaciją nuo pirmos dienos, ne tada, kai produktas jau veikia. Daug lengviau rašyti techninę bylą lygiagrečiai su kūrimu, nei bandyti rekonstruoti sprendimų logiką po metų.
Trečia — investuokite į duomenų valdymo (data governance) procesus jau dabar, net jei jūsų sistema nepatenka į high-risk kategoriją. Švarūs, dokumentuoti, atsekami duomenų rinkiniai vis tiek pravers, kai (ne jei) reguliavimas prisiveks jūsų sritį.
Ketvirta — jei naudojate trečiųjų šalių API (OpenAI, Anthropic, Google), pasitikrinkite jų atitikties dokumentaciją. Didieji tiekėjai jau dabar skelbia „EU AI Act compliance” puslapius — tai jums palengvins jūsų pačių atitikties įrodinėjimą.
Penkta — neignoruokite AI raštingumo (AI literacy) reikalavimo, nors jis atrodo formalus. Reglamentas reikalauja, kad darbuotojai, dirbantys su AI sistemomis, suprastų bent bazinius jų veikimo principus ir apribojimus. Tai lengviausiai įgyvendinamas reikalavimas, bet jį dažniausiai pamiršta.
Vietoj išvadų: kompasas, o ne žemėlapis
AI Act nėra tobulas dokumentas — jame yra neaiškių formuluočių, techninių standartų dar trūksta (juos ruošia CEN-CENELEC ir kitos organizacijos), o kai kurie terminai keičiasi net priėmus reglamentą. Bet tai nereiškia, kad galima laukti, kol viskas „nusistovės”. Reguliavimo logika aiški, o kryptis nepasikeis — daugiau skaidrumo, daugiau atsekamumo, daugiau atsakomybės už automatizuotus sprendimus.
Praktiškai vertėtų šį reglamentą traktuoti ne kaip biurokratinę kliūtį, o kaip kompasą: jis nesako tiksliai, kaip kiekvieną komponentą sukoduoti, bet aiškiai nurodo, kokia kryptimi turi judėti atsakingas AI kūrimas. Komandos, kurios šiandien investuoja į skaidrią dokumentaciją, atsekamus duomenų procesus ir žmogaus priežiūros mechanizmus, rytoj turės ne tik atitiktį įstatymui, bet ir geresnį, patikimesnį produktą — o tai retai kada būna blogas kompromisas.
