Atitiktis ES dirbtinio intelekto aktui: techninė dokumentacija, įvykių registravimas, žmogaus priežiūra ir duomenų valdymas

Didžioji dalis to, kas parašyta apie ES dirbtinio intelekto aktą, yra apie taikymo sritį: kuriai rizikos kategorijai priskiriama jūsų sistema, ar esate tiekėjas, ar diegėjas, ar jūsų sistemai taikomas III priedas. Į šiuos klausimus atsako jūsų teisininkai.

Beveik niekas nekalba apie tai, kas vyksta gavus atsakymą. Jei jūsų sistema yra didelės rizikos, reglamentas reikalauja rizikos valdymo sistemos, veikiančios per visą gyvavimo ciklą, duomenų valdymo, kurį galite įrodyti, automatinio įvykių registravimo su nustatytu saugojimo laikotarpiu, techninės dokumentacijos nustatyta struktūra, žmogaus priežiūros, kuri yra suprojektuota, o ne tik deklaruota, ir stebėsenos po pateikimo rinkai, kuri iš tikrųjų kažką renka. Tai inžineriniai rezultatai. Būtent šią dalį mes ir kuriame.

Kur dabar yra terminai

Dirbtinio intelekto aktas (Reglamentas (ES) 2024/1689) įsigaliojo 2024 m. rugpjūtį ir taikomas etapais. 2026 m. etapai pasikeitė, todėl verta būti tiksliems: pakeitimas perkėlė ir pinigus, ir dėmesį.

• 2025 m. vasario 2 d.: pradėti taikyti draudžiamos praktikos ir DI raštingumo įpareigojimai.
• 2025 m. rugpjūčio 2 d.: pradėti taikyti bendrosios paskirties DI modelių įpareigojimai.
• 2026 m. rugpjūčio 2 d.: pradėti taikyti 50 straipsnio skaidrumo įpareigojimai: informavimas, kad naudotojas bendrauja su DI sistema, sintetinio turinio žymėjimas, informavimas apie emocijų atpažinimą ir biometrinį kategorizavimą bei giliųjų klastočių ženklinimas.
• 2027 m. gruodžio 2 d.: didelės rizikos įpareigojimai savarankiškoms sistemoms, po skaitmeninio omnibuso (Digital Omnibus). Taryba ir Parlamentas dėl atidėjimo susitarė 2026 m. gegužę, o galutinai jis patvirtintas 2026 m. birželį.
• 2028 m. rugpjūčio 2 d.: didelės rizikos įpareigojimai DI sistemoms, įdiegtoms į reguliuojamus produktus.

Jei esate didelės rizikos sistemos tiekėjas, atidėjimas suteikė maždaug šešiolika mėnesių. Jis nesumažino darbo ir nepakeitė dviejų jau galiojančių įpareigojimų: 50 straipsnio skaidrumo reikalavimų ir DI raštingumo darbuotojams, kurie naudoja šias sistemas.

Ką kuriame

Techninė dokumentacija kaip generuojamas artefaktas

IV priede nustatyta, ką turi apimti techninė dokumentacija: sistemos aprašymą, projektavimo sprendimus, architektūrą, duomenų reikalavimus, mokymo metodiką, kai ji taikoma, patvirtinimo ir testavimo procedūras, metrikas, rizikos valdymo priemones ir per gyvavimo ciklą atliktus pakeitimus.

Rankomis parašytas toks dokumentas pasensta jau kitą savaitę po pasirašymo. Mes jį kuriame kaip jūsų konvejerio produktą: modelių kortelės ir duomenų lapai generuojami iš mokymo ir vertinimo vykdymų, architektūros ir duomenų srautų aprašai prižiūrimi kartu su kodu, vertinimo rezultatai pridedami prie versijos, kurią jie aprašo, o pakeitimų istorija ateina iš jūsų versijų kontrolės sistemos, o ne iš kažkieno atminties. Dokumentas tampa kūrimo proceso rezultatu.

Automatinis įvykių registravimas, atitinkantis 12 straipsnį

Didelės rizikos sistemos turi automatiškai registruoti įvykius per visą savo gyvavimo laiką tokiu lygiu, kuris leidžia atsekti veikimą ir vykdyti stebėseną po pateikimo rinkai, o įrašai turi būti saugomi tikslui tinkamą laiką, kai kuriais atvejais ne trumpiau kaip šešis mėnesius.

Praktiškai tai reiškia nuspręsti, kas jūsų sistemai yra „įvykis“, fiksuoti įvestis, išvestis, modelio versiją, sprendimo kelią ir dalyvavusio žmogaus tapatybę, saugoti tai forma, kurioje po kelerių metų būtų galima atlikti užklausas, ir daryti tai nekaupiant asmens duomenų, kurių neturite pagrindo saugoti. Ši įtampa (registruoti pakankamai DI aktui, bet saugoti pakankamai mažai BDAR) yra tikroji projektavimo problema, ir ją aiškiai sprendžiame kartu su jūsų duomenų apsaugos specialistais.

Duomenų valdymas pagal 10 straipsnį

Mokymo, patvirtinimo ir testavimo duomenų rinkiniai turi būti tinkami, pakankamai reprezentatyvūs ir kiek įmanoma be klaidų bei išsamūs, patikrinti dėl šališkumo. Kad tai būtų įvykdyta, reikia duomenų kilmės sekos, kurią galite parodyti, dokumentuoto šaltinio, šališkumo vertinimo metodikos su rezultatais ir galimybės atkurti, kurie duomenys sukūrė kurią modelio versiją.

Kuriame konvejerį, dėl kurio šie teiginiai tampa patikrinami, o ne tik siekiami: versijuoti duomenų rinkiniai, atkuriami duomenų padalijimai, automatiniai duomenų kokybės patikrinimai ir šališkumo vertinimas pagal jūsų atvejui aktualias saugomas savybes.

Žmogaus priežiūra, sukurta, o ne deklaruota

14 straipsnis reikalauja, kad didelės rizikos sistemos būtų suprojektuotos taip, jog žmogus galėtų suprasti išvestį, žinotų apie polinkį per daug pasitikėti automatizacija, teisingai interpretuotų rezultatą, galėtų nuspręsti jo nenaudoti ir įsikištų arba sustabdytų sistemą.

Tai naudotojo sąsajos specifikacija. Priežiūrą įdiegiame į produktą: sąžiningai rodomas pasitikėjimo ir neapibrėžtumo lygis, matomi išvestį lėmę veiksniai, rezultatą atmesti taip pat paprasta kaip jį priimti, sustabdymo valdiklis tikrai veikia, o kiekvienas atmetimas registruojamas, kad stebėsena po pateikimo rinkai turėtų iš ko mokytis.

Stebėsena po pateikimo rinkai ir pranešimai apie incidentus

Reikalingas stebėsenos planas, taip pat būtina pranešti apie rimtus incidentus atitinkamai institucijai. Kuriame telemetriją, kuri tam teikia duomenis: veikimas stebimas pagal jūsų dokumentacijoje nurodytas metrikas, aptinkamas įvesčių ir išvesčių nuokrypis, naudotojų pranešimai apie problemas pasiekia inžinierius, o incidentų darbo eigoje terminų reikalavimai įdiegti iš anksto, o ne atrandami incidento metu.

Skaidrumo įpareigojimai pagal 50 straipsnį

Jau galioja. Informavimas, kad naudotojas bendrauja su DI sistema, mašininiu būdu nuskaitomas sintetinio garso, vaizdų, vaizdo įrašų ir teksto žymėjimas, giliųjų klastočių ženklinimas ir informavimas apie emocijų atpažinimą. Įdiegiame informavimo vietas ir turinio kilmės žymėjimą (C2PA turinio kredencialus, kai tai tinkamas mechanizmas) ir užtikriname, kad jie išliktų eksportuojant ir perkoduojant, kai paprastai prarandami.

Registracija ir atitikties vertinimo parama

III priedo sričių didelės rizikos sistemos turi būti užregistruotos ES duomenų bazėje prieš pateikiant jas rinkai, o tiekėjai turi atlikti atitikties vertinimą. Parengiame techninius duomenis (dokumentaciją, įrodymų paketą, kokybės valdymo sistemos artefaktus inžinerinėje pusėje) ir dirbame kartu su jūsų notifikuotąja įstaiga ar vidaus vertinimo procesu.

Ko nedarome

Neteikiame teisinių konsultacijų ir nesakome, kuriai rizikos kategorijai priklauso jūsų sistema. Šis sprendimas yra teisinis, turintis realių pasekmių, ir jį turi priimti teisininkai arba kvalifikuotas atitikties konsultantas.

Taip pat neparduodame DI valdysenos platformos. Tokių yra daug, ir jei jums reikia DI sistemų registro bei politikų darbo eigos, viena iš jų jums tiks geriau nei mes. Mes atliekame inžinerinį darbą pačiose sistemose.

Kam tai skirta

Didelės rizikos DI sistemų tiekėjams pagal III priedą (darbuotojų atranka ir valdymas, kreditingumo vertinimas, draudimo kainodara, švietimo vertinimas, teisės į esmines paslaugas nustatymas, biometrinės sistemos), kurie dabar turi laiko iki 2027 m. gruodžio ir daug ką sukurti.

Gamintojams, diegiantiems DI į reguliuojamus produktus (medicinos priemones, mašinas, transporto priemones), kai DI aktas taikomas papildomai prie esamos atitikties tvarkos ir abu dokumentacijos rinkiniai turi derėti tarpusavyje.

Įmonėms, diegiančioms iš kitų įsigytas didelės rizikos sistemas, kurioms tenka savi įpareigojimai: žmogaus priežiūra, įvesties duomenų tinkamumas, stebėsena ir įvykių žurnalų saugojimas.

Visiems, kurie ES naudotojams teikia generatyvines funkcijas, nes 50 straipsnio skaidrumo reikalavimai jau taikomi šiandien, nepriklausomai nuo rizikos kategorijos.

Kaip vyksta bendradarbiavimas

Techninių spragų vertinimas, nuo dviejų iki keturių savaičių. Remiamės jūsų teisininkų atliktu klasifikavimu ir įvertiname jūsų sistemas pagal iš jo kylančius inžinerinius įpareigojimus. Rezultatas yra spragų registras (įpareigojimas, dabartinė būklė, ką reikia sukurti, darbo apimtis), pagal kurį gali dirbti ir jūsų atitikties, ir inžinerijos vadovai.

Kūrimas, etapais, paprastai pradedant nuo įvykių registravimo ir dokumentacijos generavimo, nes visa kita sukuria įrodymus, kurie turi kažkur patekti.

Pasirengimo peržiūra prieš atitikties vertinimą, su surinktu įrodymų paketu ir sąžiningai įvardytomis likusiomis spragomis.

Standartai ir sistemos

Reglamentas (ES) 2024/1689 ir jo III bei IV priedai; CEN/CENELEC JTC 21 rengiami darnieji standartai; ISO/IEC 42001 DI valdymo sistemoms ir ISO/IEC 23894 DI rizikos valdymui; NIST AI Risk Management Framework, kai to reikia patronuojančiajai bendrovei JAV; ir BDAR, kuris niekur nedingsta ir riboja daugumą įvykių registravimo sprendimų.

Dažniausiai užduodami klausimai

Ar DI akto taikymas atidėtas?

Iš dalies. Skaitmeninis omnibusas atidėjo didelės rizikos įpareigojimus savarankiškoms sistemoms iki 2027 m. gruodžio 2 d., o į reguliuojamus produktus įdiegtam DI iki 2028 m. rugpjūčio 2 d. Draudžiama praktika, DI raštingumas, bendrosios paskirties DI modelių įpareigojimai ir 50 straipsnio skaidrumo taisyklės nebuvo atidėti ir galioja jau dabar.

Naudojame tik kitų sukurtas DI sistemas. Ar turime įpareigojimų?

Taip, kaip diegėjas. Tarp jų: naudoti sistemą pagal jos naudojimo instrukcijas, žmogaus priežiūrą pavesti asmenims, turintiems tam reikalingos kompetencijos ir įgaliojimų, užtikrinti, kad įvesties duomenys atitiktų numatytąją paskirtį, stebėti veikimą ir saugoti įvykių žurnalus. Tai lengvesni įpareigojimai nei tiekėjo, bet realūs. Be to, atkreipkite dėmesį, kad iš esmės pakeitę sistemą arba pažymėję ją savo vardu galite tapti tiekėju.

Mūsų sistema nėra didelės rizikos. Ar reikia ką nors daryti?

Tikriausiai du dalykus. 50 straipsnio skaidrumo reikalavimai tam tikroms sistemoms taikomi nepriklausomai nuo rizikos kategorijos, įskaitant pokalbių robotus ir sintetinio turinio generavimą. O 4 straipsnio DI raštingumo reikalavimas apskritai taikomas tiekėjams ir diegėjams. Be to, verta turėti galimybę pagrįsti klasifikavimo sprendimą, jei kada nors to paklaustų priežiūros institucija.

Ar techninę dokumentaciją tikrai galima generuoti?

Didžiąją jos dalį, taip. Architektūra, duomenų rinkinių aprašai, vertinimo rezultatai, metrikos, modelių versijos ir pakeitimų istorija jau yra jūsų sistemose; darbas yra užfiksuoti juos stabilia struktūra kūrimo metu. Tikrai pasakojamąsias dalis (numatytąją paskirtį, rizikos analizę, projektavimo pagrindimą) rašo žmonės, o tada jos laikomos toje pačioje saugykloje, kad būtų versijuojamos kartu su visa kita.

Kaip DI aktas susijęs su BDAR?

Jie persidengia ir kartais traukia priešingomis kryptimis, ypač dėl įvykių registravimo. DI aktas nori atsekamumo; BDAR nori duomenų kiekio mažinimo ir ištrynimo. Sprendimas paprastai yra pseudonimizavimas, kruopščiai apibrėžta registruojamų duomenų apimtis ir nustatytas saugojimo laikotarpis, susietas su dokumentuotu tikslu. Tai projektavimo sprendimas, priimamas vieną kartą ir sąmoningai.

Ar naudodami trečiosios šalies modelį tampame to modelio tiekėju?

Ne, tačiau ant jo sukūrę DI sistemą galite tapti tos sistemos tiekėju su visais jai taikomais įpareigojimais. Kur eina riba, priklauso nuo to, ką kuriate ir kaip tai pateikiate; tai teisinis klausimas, tačiau inžinerinė išvada yra tokia: bet kuriuo atveju turėtumėte manyti, kad jums reikės savos sistemos dokumentacijos.

Pradėkite

Papasakokite, ką daro jūsų sistemos ir kokią klasifikaciją nustatė jūsų teisininkai. Įvertinsime, ką įpareigojimai reiškia kode, ir pateiksime spragų registrą su darbo apimtimi kiekvienai eilutei.

Susisiekite su mumis ir užsisakykite techninių spragų vertinimą pagal DI aktą.

Susijusios paslaugos

• DI agentų kūrimas ir MCP integracija: sistemų, kurias reguliuoja šis režimas, kūrimas
• Programinės įrangos kūrimas patekimui į ES rinką: platesnis ES skaitmeninės atitikties sprendimų rinkinys
• Interneto svetainių prieinamumo taisymas: kitas ES įpareigojimas, kuris pasirodo esąs inžinerinis projektas