ES DI aktas: teikėjai vs. naudotojai — kas atsakingas už ką?

ES DI aktas skirsto įpareigojimus tarp teikėjų (kurie kuria DI sistemas) ir naudotojų (kurie jas taiko praktikoje). Supratimas, kokį vaidmenį jūs atliekate, nustato jūsų atitikties naštą — ir ar galite perkelti atsakomybę kitai šaliai.

Dviejų aktorių ES DI akto architektūra

ES DI aktas nesukuria vieno universalaus įsipareigojimo visiems DI suinteresuotajams. Jis sistemingai skiria du pagrindinius vaidmenis DI vertės grandinėje:

• Teikėjai — subjektai, kurie kuria, moko ar puoselėja DI sistemas ir jas pateikia rinkai
• Naudotojai — subjektai, eksploatuojantys DI sistemas profesiniame kontekste jų nesukūrę

Šis skirtumas nėra semantinis. Jis nustato, kokie įsipareigojimai taikomi, kas turi kokią dokumentaciją, kas registruojasi ES DI duomenų bazėje, kas atlieka atitikties vertinimą ir kas yra atsakingas, kai kažkas negerai. Teisingas savo vaidmens nustatymas yra pirmasis žingsnis bet kurioje ES DI akto atitikties programoje.

Trečias vaidmuo — įgaliotasis atstovas — taikomas teikėjams, įsteigtiems už ES ribų, kurie turi paskirti ES įsteigtą atstovą savo reguliacinių įpareigojimų vykdymui ES teritorijoje.

Teikėjo apibrėžimas (Art. 3(3))

Teikėjas yra bet koks fizinis ar juridinis asmuo, valdžios institucija, agentūra ar kitas subjektas, kuris:

1. Kuria DI sistemą arba ją kuria, ir
2. Pateikia ją rinkai arba pradeda naudoti savo vardu ar prekiniu ženklu — tiek už mokestį, tiek nemokamai

Pagrindiniai teikėjo statuso požymiai yra kūrimo atsakomybė ir rinkos pateikimas. DI laboratorija, kuri kuria ir licencijuoja kreditų vertinimo modelį, yra teikėja. Konsultacinė įmonė, kuri projektuoja ir kuria pasirinktinę įdarbinimo atrankos priemonę klientui, tada ją perduoda, taip pat yra teikėja (kol sistema pateikiama rinkai savo vardu; jei ji sukuriama pagal kliento prekės ženklą, klientas gali būti teikėjas).

Apibrėžimas apima:

• DI startuolius ir programinės įrangos pardavėjus, parduodančius supakuotus DI produktus
• Įmones, kuriančias DI sistemas vidiniam diegimui
• Mokslinių tyrimų institucijas, skelbiančias DI sistemas bendram naudojimui
• Debesų teikėjus, siūlančius DI kaip paslaugą savo prekės ženklu

Teikėjai prisiima didžiausią atitikties naštą pagal aktą. Didelės rizikos sistemoms tai apima atitikties vertinimų atlikimą, techninės dokumentacijos rengimą, registraciją ES DI duomenų bazėje, CE ženklinimo affixavimą ir stebėjimo po pateikimo rinkai sistemos palaikymą.

Naudotojo apibrėžimas (Art. 3(4))

Naudotojas yra bet koks fizinis ar juridinis asmuo, valdžios institucija, agentūra ar kitas subjektas, kuris naudoja DI sistemą savo valdžios žinioje profesiniam tikslui — išskyrus atvejus, kai naudojama asmeninei ne profesinei veiklai.

Naudotojai nekuria DI sistemų. Jie naudoja kitiems sukurtas sistemas — perkamas įpakuotu būdu, licencijuojamas per API ar integruotas į SaaS produktą. Didžioji dalis Europos organizacijų, kurios „naudoja DI", yra naudotojai: įmonės, naudojančios ChatGPT ar Claude per API, personalo departamentai, naudojantys DI varomus pretendentų stebėjimo įrankius, ligoninės, naudojančios DI pagalbinius diagnostikos įrankius, bankai, naudojantys pardavėjų teikiamus kreditų modelius.

Pagrindiniai naudotojų įsipareigojimai (didelės rizikos DI sistemoms):

• Naudoti sistemą tik pagal teikėjo pateiktas instrukcijas (Art. 26(1))
• Paskirti žmogų su kompetencija, valdžia ir ištekliais vykdyti žmogaus priežiūrą (Art. 26(2))
• Užtikrinti, kad įvesties duomenys būtų tinkami ir reprezentatyvūs numatytam tikslui (Art. 26(5))
• Stebėti sistemos veikimą ir aptikti anomalijas (Art. 26(5))
• Saugoti sistemos generuojamus žurnalus reikalaujamą laikotarpį (Art. 26(6))
• Pranešti teikėjui ir kompetentingai institucijai apie bet kokius rimtus incidentus (Art. 26(8))
• Atlikti duomenų apsaugos poveikio vertinimą, kai to reikalauja BDAR (Art. 26(9))

Emocijų atpažinimo ir biometrinio kategorizavimo sistemų naudotojai taip pat turi laikytis Art. 50 skaidrumo įpareigojimų neatsižvelgiant į rizikos klasifikavimą.

Teikėjo ir naudotojo riba praktikoje

Teikėjo ir naudotojo riba teorijoje yra aiški, tačiau praktikoje susilieja. Trys scenarijai iliustruoja dažniausias pilkąsias zonas:

1 scenarijus: Įpakuotas SaaS be jokio tinkinimo

Įmonė prenumeruoja pardavėjo DI varomą personalo atrankos platformą be jokio modifikavimo. Pardavėjas yra teikėjas. Įmonė yra naudotoja. Pardavėjas skolingas įmonei naudojimo instrukcijas, atitikties dokumentaciją ir registravimo galimybę. Įmonė skolinga savo darbuotojams skaidrumą ir žmogaus priežiūrą.

2 scenarijus: API integracija su dideliu klausimu inžinerizavimu

Įmonė integruoja GPAI modelį per API, prideda pasirinktinį sistemos klausimą, kuria naudotojo sąsają ir leidžia programą klientams. Pagrindiniam GPAI modeliui pirminis kūrėjas yra teikėjas. Ant jo sukurtai programai įmonė yra teikėja — ji sukūrė DI sistemą ir pateikė ją rinkai savo prekės ženklu. Tiek teikėjo, tiek GPAI įsipareigojimai taikomi skirtingais sluoksniais.

3 scenarijus: Pasirinktinis vidinis kūrimas

Bankas sukuria savo kreditingumo vertinimo modelį, moko jį nuosavomis duomenų bazėmis ir diegia viduje paskolų sprendimams. Bankas yra vienu metu teikėjas (jis sukūrė ir naudoja sistemą) ir naudotojas (jis eksploatuoja sistemą savo tikslams). Visi teikėjo įsipareigojimai pagal aktą taikomi — įskaitant atitikties vertinimą šiam Annex III didelės rizikos naudojimo atvejui — taip pat visi naudotojo įsipareigojimai.

Kada naudotojai tampa teikėjais (Art. 25)

Art. 25 nustato aiškius suktus, kuriais naudotojas prisiima teikėjo statusą ir paveldi visus teikėjo įpareigojimus:

1. Esminis modifikavimas — naudotojas iš esmės modifikuoja didelės rizikos DI sistemą, viršijant tai, ką numatė pirminis teikėjas
2. Tikslo keitimas, sukeliantis didelės rizikos klasifikavimą — naudotojas naudoja ne didelės rizikos sistemą taip, kad tai atitinka Annex III didelės rizikos kriterijus
3. Pateikimas savo vardu — naudotojas pateikia DI sistemą rinkai arba pradeda naudoti savo vardu ar prekiniu ženklu
4. GPAI modelio modifikavimas — naudotojas, kuris atlieka didelius GPAI modelio pakeitimus, keičiančius jo bendrosios paskirties naudojimo atvejį

Kai Art. 25 suaktyvinamas, pirminių teikėjų įsipareigojimai perkeliami naujam teikėjui. Pirminis teikėjas atleidžiamas nuo įpareigojimų modifikuotai ar perpanaudotai sistemai. Tai svarbus atsakomybės paskirstymo mechanizmas: organizacijos, tik tinkinančios sistemą, turi suprasti, kur tinkinimas baigiasi ir prasideda esminis modifikavimas.

Įpareigojimų palyginimo lentelė

Kaip nustatyti savo vaidmenį

Trys klausimai nustato jūsų vaidmenį pagal ES DI aktą:

1. Ar jūs kūrėte DI sistemą arba ją kūrėte savo vadovavimo? Jei taip — ir ją pateikėte rinkai arba pradėjote naudoti — esate teikėjas.

2. Ar naudojate DI sistemą, kurią sukūrė kitas, profesiniam tikslui? Jei taip, esate naudotojas.

3. Ar iš esmės modifikavote, perpanaudojote ar perkainojote DI sistemą? Jei taip, galite tapti tos modifikuotos sistemos teikėju pagal Art. 25.

Organizacijoms, kurios yra ir viena, ir kita — vidinis kūrimas vidiniam naudojimui — visi įsipareigojimai kaupiasi. Integruotoms operacijoms jokio mažinimo nėra.

Sutartinis atsakomybių paskirstymas

Aktas leidžia teikėjams ir naudotojams sutartinai paskirstyti konkrečius įpareigojimus. Art. 25(1) tai aiškiai leidžia tam tikrais įpareigojimais. Tačiau taikomi du apribojimai:

• Reguliacinė atsakomybė negali būti sutartinai perduota. Jei naudotojas eksploatuoja didelės rizikos sistemą, jis lieka atsakingas už naudotojo įpareigojimus, neatsižvelgiant į tai, ką nurodo sutartis. Sutartys gali nustatyti vidinį regresą, tačiau negali perkelti reguliacinės atskaitomybės kitai šaliai.
• Informacijos srautas turi būti išsaugota. Bet koks paskirstymas turi užtikrinti, kad naudotojas turėtų informaciją, reikalingą savo įpareigojimams vykdyti — naudojimo instrukcijas, prieigą prie registravimo, incidentų pranešimų kanalus. Sutartys, nutraukiančios šį informacijos srautą, kelia problemų atitikčiai, ne tik komerciškai.

Pirkimų komandos turėtų naudoti DI pardavėjų sutartis siekiant užtikrinti, kad teikėjai pateiks tai, ko naudotojams reikia: instrukcijas, atitikties dokumentaciją, incidentų pranešimų kanalus, atnaujinimų įsipareigojimus ir duomenų valdymo sąlygas dėl duomenų, kuriomis dalijamasi puoselėjimui.