Praktiniai gidai sektoriams
ES DI aktas IT įmonėms ir DI kūrėjams
ES DI aktas IT įmonėms reiškia, kad jūsų prievolės priklauso nuo vaidmens: jei tik naudojate DI įrankius darbui, esate diegiantysis subjektas ir jums galioja paprastesnės taisyklės; jei kuriate ir teikiate DI funkcionalumą savo produkte, tampate DI tiekėju ir prisiimate gerokai platesnes DI kūrėjų prievoles. Daugumai Lietuvos programinės įrangos įmonių aktualūs abu vaidmenys vienu metu, todėl svarbu nepainioti, kuri taisyklių grupė kada įsijungia.
IT įmonei pirmas klausimas yra vaidmuo: ar DI tik naudojamas viduje, ar DI funkcija jau teikiama klientams kaip produkto dalis. Nuo šio atsakymo priklauso, ar kalbame apie diegėjo pareigas, ar apie platesnes DI tiekėjo prievoles pagal ES DI aktą (angl. AI Act, Reglamentas (ES) 2024/1689).
Ar ES DI aktas taikomas IT įmonei?
Taip, beveik visada - klausimas tik koks vaidmuo. ES DI aktas reguliuoja DI sistemas pagal tai, ką su jomis darote, o ne pagal jūsų įmonės dydį. IT įmonė tipiškai atsiduria viename iš dviejų (arba abiejuose) vaidmenų:
- Diegiantysis subjektas - kai naudojate DI savo profesinėje veikloje: programuotojai dirba su „Copilot“, komanda naudoja „ChatGPT“ dokumentacijai, dizaineriai generuoja vaizdus. Apie tai plačiau - kam taikomas ES DI aktas.
- DI tiekėjas - kai į savo produktą integruojate DI funkciją (pvz., pokalbių botą, rekomendacijų variklį, automatinį turinio generavimą) ir teikiate ją klientams savo vardu arba prekės ženklu.
Esminis principas: jei imate trečiosios šalies modelį (pvz., per API) ir įtraukiate jį į savo programinę įrangą, kurią parduodate, jūs galite tapti tos DI sistemos tiekėju ES rinkoje - net jei pamatinio modelio nesukūrėte patys. Tai dažna IT įmonės klaida: „mes tik naudojame OpenAI“ neatleidžia nuo tiekėjo pareigų, jei tą funkciją pateikiate galutiniam vartotojui kaip savo produkto dalį.
Kada įsigalioja prievolės?
Daugelis IT įmonių klaidingai mano, kad turi laiko iki 2026 m. Bazinės prievolės galioja jau nuo 2025 m. vasario 2 d.:
| Data | Kas įsigalioja | Aktualu IT įmonei |
|---|---|---|
| 2025-02-02 | DI raštingumas (4 str.) ir draudžiamos praktikos | Privaloma ugdyti komandos, naudojančios bet kokį DI įrankį, DI raštingumą |
| 2025-08-02 | Bendrosios paskirties DI modelių taisyklės | Taikoma modelių tiekėjams, atsižvelgiant į pereinamąsias nuostatas |
| 2026-08-02 | Bendras reglamento ir skaidrumo nuostatų taikymas | Taikoma, kai konkreti veikla patenka į atitinkamų nuostatų apimtį |
| 2027-12-02 | Didelės rizikos DI sistemų taisyklės (Annex III) | Taikomos sistemoms, patektoms į didelės rizikos kategoriją |
| 2028-08-02 | Didelės rizikos DI, įterptų į reguliuojamus Annex I produktus, taisyklės | Taikomos, kai DI yra įterpta į esamus reguliuojamus produktus |
Tai reiškia, kad DI raštingumo prievolė pagal 4 straipsnį jau galioja nuo 2025-02-02 ir taikoma kiekvienai IT įmonei, kurios darbuotojai naudoja DI. Bendrosios paskirties DI modelių taisyklės pradėtos taikyti 2025 m. rugpjūčio 2 d., atsižvelgiant į pereinamąsias nuostatas. 2026 m. rugpjūčio 2 d. pradėtos taikyti bendrosios ir skaidrumo nuostatos, o didelės rizikos sistemų taisyklės pradedamos taikyti nuo 2027 m. gruodžio 2 d. Jei kuriate produktą su didelės rizikos DI funkcionalumu, papildomos tiekėjo prievolės pradeda galioti nuo atitinkamų datų - bet pasiruošimas joms (architektūra, žurnalai, dokumentacija) turi prasidėti gerokai anksčiau, nes vėliau jų neįmanoma „prirašyti atgaline data“.
Kuo skiriasi DI tiekėjo pareigos nuo diegiančiojo subjekto prievolių?
Tai pagrindinis IT įmonei aktualus skirtumas. Diegiantysis subjektas turi palyginti lengvą naštą; tiekėjas - sunkią. Štai esminis palyginimas:
| Sritis | Diegiantysis subjektas (naudojate DI) | DI tiekėjas (kuriate ir teikiate DI) |
|---|---|---|
| DI raštingumas (4 str.) | Privaloma | Privaloma |
| Naudojimo politika ir vidaus tvarka | Priemonės priklauso nuo naudojimo ir rizikos | Pareigos priklauso nuo sistemos ir rizikos kategorijos |
| Skaidrumas vartotojui (kad bendrauja su DI) | Atitinkamos pareigos priklauso nuo naudojimo | Atitinkamos pareigos priklauso nuo sistemos ir naudojimo |
| Techninė dokumentacija apie sistemą | Duomenų saugojimo ir informavimo pareigos priklauso nuo naudojimo | Specialūs reikalavimai didelės rizikos sistemoms |
| Rizikos valdymo sistema | Atitinkamos naudojimo pareigos didelės rizikos atvejais | Privaloma didelės rizikos sistemoms |
| Veiklos žurnalai | Didelės rizikos naudojimui gali būti taikomos žurnalų saugojimo pareigos | Privaloma didelės rizikos sistemoms |
| Atitikties įvertinimas ir CE ženklinimas | Ne | Privaloma didelės rizikos sistemoms |
DI kūrėjų prievolės apima kur kas daugiau nei tik mokymus. Jei jūsų produktas patenka į didelės rizikos kategoriją, jūs privalote turėti dokumentuotą rizikos valdymo procesą, kokybės valdymo sistemą, techninę dokumentaciją, automatinį įvykių registravimą ir užtikrinti žmogaus priežiūrą. Tai - ne formalumas, o realus inžinerinis ir teisinis darbas, kurį reikia įtraukti į produkto planą nuo pat pradžių.
Kada IT produktas tampa „didelės rizikos“ DI sistema?
Daugumos įprastų SaaS produktų DI funkcijos nėra didelės rizikos - pokalbių botas klientų aptarnavimui, teksto santraukos, kodo asistentas viduje. Tačiau produktas pakliūva į didelės rizikos kategoriją, jei DI naudojamas jautriose srityse, pavyzdžiui:
- darbuotojų atrankai, įvertinimui ar atleidimui (HR tech);
- kredito skyrimui ar finansiniam vertinimui;
- prieigai prie švietimo ar egzaminų vertinimui;
- esminėms viešosioms paslaugoms ar tam tikrai kritinei infrastruktūrai;
- biometriniam identifikavimui.
Tikslų sąrašą ir logiką paaiškina straipsnis apie DI akto rizikos kategorijas. IT įmonei svarbiausia atlikti sąžiningą savęs vertinimą: jei kuriate, pavyzdžiui, įdarbinimo platformą su DI kandidatų reitingavimu, jūs greičiausiai esate didelės rizikos sistemos tiekėjas su visomis iš to kylančiomis pareigomis. Jei kuriate marketingo teksto generatorių, beveik tikrai - ne, bet skaidrumo prievolė (informuoti, kad turinį generuoja DI) vis tiek galioja.
Atskira pastaba apie atvirojo kodo komponentus ir kodo įrankius: jei jūsų programuotojai naudoja DI kodo asistentus, tai atskira tema su savo rizikomis - ją išsamiai aptaria straipsnis apie Copilot ir kitus kodo DI įrankius įmonėje.
Ką IT įmonei daryti praktiškai?
Nepriklausomai nuo to, ar esate vien diegiantysis subjektas, ar ir tiekėjas, minimalus veiksmų rinkinys smulkiai IT įmonei atrodo taip:
-
Nustatykite savo vaidmenį kiekvienai DI sistemai. Atskirai įvertinkite vidinius įrankius (kuriuos naudojate) ir produkto funkcijas (kurias teikiate). Vienai įmonei dažnai galioja abu vaidmenys.
-
Ugdykite komandą DI raštingumo. Tai jau privaloma prievolė nuo 2025-02-02. Pagal 4 straipsnį, įmonės privalo imtis priemonių, kad padėtų personalui ir kitiems jos vardu DI naudojantiems asmenims ugdyti DI raštingumą atsižvelgiant į jų žinias, patirtį, apmokymą, kontekstą ir asmenis, kurie gali būti paveikti. Tai nereiškia, kad kiekvienas individualus lygis turi būti garantuojamas. Žinių patikra ir įrašai gali padėti įvertinti bei paaiškinti mokymus; 4 straipsnis nenustato konkretaus testo ar dokumento.
-
Inventorizuokite naudojamus įrankius. Kiekvieną DI įrankį surašykite su paskirtimi, atsakingu asmeniu ir rizikos vertinimu.
-
Įveskite naudojimo politiką. Aiškiai apibrėžkite, kokius duomenis galima ir negalima paduoti DI įrankiams (kliento kodas, asmens duomenys, paslaptys).
-
Produkto pusėje - įvertinkite rizikos kategoriją anksti. Jei funkcija gali būti didelės rizikos, planuokite techninę dokumentaciją, žurnalus ir žmogaus priežiūrą nuo architektūros etapo.
-
Užtikrinkite skaidrumą vartotojui. Jei produkte vartotojas bendrauja su DI arba mato DI generuotą turinį, jis turi apie tai žinoti.
Geras orientyras: jei rytoj atvyktų klientas ar auditorius ir paklaustų „kaip jūs valdote DI riziką“, turėtumėte gebėti parodyti dokumentus, o ne aiškinti žodžiu. Būtent ši įrodomoji medžiaga ir yra atitikties esmė.
Kokie dokumentai gali padėti įmonei?
Diegiančiojo subjekto lygmeniu (kurį turi turėti praktiškai kiekviena IT įmonė) rekomenduojamas dokumentų rinkinys yra:
- DI naudojimo politika - kaip leidžiama naudoti DI įrankius ir kokie duomenys draudžiami.
- DI įrankių registras - su visais naudojamais įrankiais ir jų rizika.
- Atitikties įrašas pagal 4 straipsnį - įrodymas, kad darbuotojai apmokyti DI raštingumo (šis dokumentas nėra privalomas įstatymo, ir yra vienas iš galimų būdų užfiksuoti taikytas priemones).
- Darbuotojų DI vadovas - praktiškos kasdienės taisyklės komandai.
- DI raštingumo mokymai su žinių patikra ir pažymėjimais - dokumentuotas įrodymas.
Jei esate ir tiekėjas su didelės rizikos produktu, prie šio rinkinio prisideda atskira techninė dokumentacija, rizikos valdymo sistema ir atitikties įvertinimas - tai jau produkto inžinerinis darbas, kurio negalima nupirkti kaip šablono.
Bazinio diegiančiojo subjekto dokumentų rinkinio nereikia rašyti nuo nulio. nebedirbam.lt automatiškai parengia visą šį paketą už fiksuotą €149 + PVM (€299) kainą, pritaikytą jūsų įmonės atsakymams - nuo politikos iki mokymų su pažymėjimais (žr. pagrindinį puslapį). Jei pirmiausia norite išbandyti mokymus patys, yra ir nemokami DI raštingumo mokymai. Nemokamas kelias skirtas vienam prisijungusiam dalyviui; komandos mokymai įtraukti į mokamą dokumentų paketą.
Pastaba: ES DI aktas nereikalauja konkretaus sertifikato, dokumentų rinkinio, fiksuoto mokymų trukmės, išorinio auditoriaus ar atskiro AI atsakovo. Tai - praktinės rekomendacijos, o ne teisinės prievolės.
Dažniausiai užduodami klausimai
Ar mes tampame DI tiekėju, jei naudojame OpenAI API savo produkte? Galite tapti. Jei DI funkciją teikiate galutiniam vartotojui savo prekės ženklu, jūs esate tos sistemos tiekėjas ES rinkoje, net jei pamatinį modelį sukūrė kitas. Pareigų apimtis priklauso nuo to, ar sistema yra didelės rizikos.
Ar 4 straipsnio prievolė taikoma, jei dirba tik 3 žmonės? Taip. DI raštingumo prievolė neturi išimties pagal įmonės dydį ir galioja nuo 2025-02-02 nuo pirmo DI naudotojo.
Ar draudžiama naudoti DI įrankius su asmens duomenimis? ES DI aktas nedraudžia DI naudoti su asmens duomenimis, bet reikia atlikti BDAR atitikties vertinimą. Įmonėse dažnai draudžiama naudoti nepatvirtintus viešus įrankius su asmens duomenimis, bet tai priklauso nuo teisėto pagrindo, duomenų kiekio mažinimo principo, įrankio patikimumo ir apsaugos priemonių. Nėra bendro draudimo - kiekviena situacija vertinama atskirai.
Mūsų produktas tik generuoja tekstą - ar mums reikia daryti pilną didelės rizikos atitiktį? Greičiausiai ne. Teksto generavimas paprastai nėra didelės rizikos, tačiau galioja skaidrumo prievolė informuoti vartotoją, kad turinį sukūrė DI.
Daugiau praktinių straipsnių apie ES DI akto atitiktį rasite visų straipsnių sąraše.
Šiame straipsnyje pateikta informacija remiasi oficialiais ES DI akto (Reglamentas (ES) 2024/1689) šaltiniais: AI Act Service Desk - 4 straipsnis ir Europos Komisijos AI aktas. Norėdami patikrinti naujausią informaciją, apsilankykite šiuose puslapiuose.
ES DI akto dokumentai Jūsų įmonei per valandą
DI naudojimo politika, įrankių registras, atitikties įrašas ir darbuotojų vadovas, automatiškai pritaikyti Jūsų įmonei. Vienkartinis mokėjimas. Per 14 dienų galite susigrąžinti pinigus, jei dar neatsisiuntėte dokumentų.
€149€299+ PVMSusiję straipsniai
Copilot ir kiti kodo DI įrankiai: ką privalo žinoti įmonė
Copilot, Cursor ir kitų DI kodo įrankių naudojimas darbe: saugumas, licencijos, darbuotojų mokymai ir DI akto reikalavimai.
DI sistemų rizikos kategorijos pagal ES DI aktą
Nepriimtina, didelė, ribota ir minimali DI rizika: praktiniai pavyzdžiai ir įmonės naudojamiems įrankiams aktualios pareigos.
Kam taikomas ES DI aktas? Ar jis galioja Jūsų įmonei?
Kam taikomas ES DI aktas: įmonių vaidmenys, DI naudojimas, rizikos kategorijos, aktualios datos ir praktinės raštingumo ugdymo priemonės.
Atitikties įrašas pagal 4 straipsnį: kas tai ir kaip jį parengti
Kaip užfiksuoti įmonės DI raštingumo ugdymo priemones pagal 4 straipsnį: praktiška struktūra, įrodymai, peržiūra ir dažnos klaidos.
nebedirbam.lt yra automatizuoto dokumentų rengimo įrankis, ne teisinių paslaugų teikėjas. Šis straipsnis yra bendrojo pobūdžio informacija, ne teisinė konsultacija. Svarbiems sprendimams rekomenduojame pasitarti su teisininku.