Nadzor po trženju Akta EU o UI (čl. 72): Obveznosti za ponudnike visokotveganostne UI

Skladnost se ne konča z vstopom na trg. Čl. 72 zahteva, da ponudniki visokotveganostnih sistemov UI vzpostavijo aktivni sistem nadzora po trženju, zbirajo podatke o zmogljivosti in poročajo o resnih incidentih. Tukaj je, kaj morate storiti — in kdaj.

Kaj je nadzor po trženju?

Ugotavljanje skladnosti in oznaka CE sta vstopna karta za trg EU za visokotveganostni sistem UI — ne ciljna črta. Člen 72 Akta EU o UI nalaga nadaljnjo obveznost: ponudniki morajo vzpostaviti in upravljati sistem nadzora po trženju (NPT), ki aktivno zbira, analizira in ukrepa na podlagi podatkov o resnični zmogljivosti skozi celotno operativno življenjsko dobo sistema.

Utemeljitev je enostavna. Sistem UI, validiran na fiksnem naboru podatkov, se morda zamakne, ko se resnični vhodi spremenijo, ko se populacija uporabnikov spremeni ali ko se okolje, v katerem deluje, razvija. Statični posnetki skladnosti tega ne morejo zajeti. NPT je mehanizem, ki skladnost pretvori v kontinuiran postopek namesto enkratnega dogodka.

Sistem NPT mora biti sorazmeren naravi in tveganjem zadevnega visokotveganostnega sistema UI. Model za kreditno točkovanje, uvajan v obsegu za milijone potrošnikov, bo zahteval intenzivnejši nadzor kot ozko orodje za razvrščanje dokumentov, ki ga interno uporablja reguliran subjekt.

Kdo mora vzpostaviti sistem NPT?

Obvezno za:

• Ponudnike samostojnih visokotveganostnih sistemov UI Annex III — sistemi, navedeni v Annex III, ki niso varnostne komponente produkta (npr. UI, ki se uporablja pri odločitvah o zaposlitvi, dostopu do izobraževanja, kazenskem pregledu, ocenjevanju kreditne sposobnosti, upravljanju kritične infrastrukture)
• Ponudnike sistemov UI, vgrajenih v produkte Annex I — varnostne komponente UI, integrirane v produkte, ki jih zajema obstoječa harmonizacijska zakonodaja EU (medicinski pripomočki, stroji, vozila)

Ni zahtevano za:

• Ponudnike sistemov UI z minimalnim tveganjem (ni formalne obveznosti NPT, čeprav se priporoča dobra praksa)
• Ponudnike sistemov UI samo s preglednostjo (obveznosti čl. 50 se ne razširijo na NPT)
• Ponudnike modelov GPAI — ti so zavezani ločenemu režimu po čl. 61–62, ki vključuje poročanje o incidentih za modele s sistemskim tveganjem, toda je strukturiran drugače od NPT čl. 72

Vloga izvajalca je podporna, toda ni neobvezna. Izvajalci morajo sistem UI upravljati v skladu z navodili ponudnika, aktivirati in ohraniti zmogljivost beleženja, ki je vgrajena v sistem, in — kar je ključno — poročati o vseh resnih incidentih, ki jih opazijo, ponudniku brez nepotrebnega odlašanja. Izvajalec, ki opazi resni incident in ne obvesti ponudnika, ni v skladu s predpisi.

Načrt nadzora po trženju (Annex IV, točka 12)

Načrt NPT je obvezna sestavina tehnične dokumentacije (Annex IV). Ne more biti splošen dokument: mora biti specifičen za sistem, njegov kontekst uvajanja in identificirana tveganja. Najmanj mora opredeliti:

1. Zbiranje podatkov — katere merila zmogljivosti se zajemajo (točnost, stopnje napak, rezultati odločitev), kako se podatki zbirajo (samodejno telemetrika, poročila izvajalcev, povratne informacije uporabnikov) in s kakšno pogostostjo
2. Povratne zanke — mehanizem, prek katerega izvajalci strukturirano in pravočasno poročajo o težavah z zmogljivostjo, anomalijah ali incidentih ponudniku
3. Nadzor točnosti — kako se zmogljivost sistema spremlja v primerjavi z referenčno vrednostjo, validiranim med ugotavljanjem skladnosti, vključno z morebitno metodologijo zaznavanja zamika
4. Nadzor pristranskosti — za sisteme, pri katerih so demografski rezultati bistvenega pomena (zaposlovanje, kredit, kazenski pregon), stalni nadzor statističnih razlik med zaščitenimi skupinami z določeno metodologijo in pragovi
5. Sprožilci posodobitve — specifični kvantitativni ali kvalitativni pragovi, ki sprožijo popravljalne ukrepe, vključno s ponovnim usposabljanjem modela, prilagoditvijo parametrov ali prenehanjem uvajanja
6. Urnik pregleda — kako pogosto se načrt NPT sam po sebi pregleduje in posodablja, kar zagotavlja, da ostane primeren za namen, ko se kontekst uvajanja razvija

Načrt NPT mora biti ažuriran. Zastareli načrt, ki ne odraža več dejanske metodologije nadzora, ne izpolni čl. 72.

Poročanje o resnih incidentih (čl. 73)

Kaj sestavlja resni incident?

Člen 73 opredeljuje resni incident kot kateri koli incident ali okvaro visokotveganostnega sistema UI, ki neposredno ali posredno vodi do:

• Smrti ali resne škode za zdravje (fizično ali psihološko)
• Resne in nepopravljive motnje pri upravljanju ali delovanju kritične infrastrukture
• Resne kršitve temeljnih pravic (zasebnost, nediskriminacija, pravičen postopek)
• Situacije, v kateri je oseba komaj ušla kateri koli od zgornjih

Pomembno je, da Akt o UI ne zahteva vzpostavitve vzročne zveze s sistemom UI pred poročanjem. Za sprožitev obveznosti zadostuje razumna domneva, da je sistem UI prispeval k škodi ali je ni preprečil. Ponudniki, ki pred poročanjem čakajo na gotovost, tvegajo neskladnost.

Roki poročanja

15-dnevna ura začne teči, ko se ponudnik zave incidenta — kar v praksi pomeni, ko ga obvesti izvajalec. Ponudniki bi morali postopke obvestila izvajalcev zasnovati tako, da informacije do njih pridejo dovolj hitro, da se izpolni navzdol rok poročanja.

Kaj mora vsebovati poročilo o incidentu

Skladno poročilo o incidentu nacionalnemu organu za nadzor trga mora vsebovati:

• Identifikacijo sistema: ime, različica, registracijska številka baze podatkov EU
• Opis incidenta: kaj se je zgodilo, kakšna škoda je nastala ali bila komaj preprečena, datum in kraj
• Prizadete osebe: število in kategorije prizadetih uporabnikov ali tretjih oseb (anonimizirani, kjer to zahteva GDPR)
• Predhodno vzročno analizo: trenutno razumevanje ponudnika, kako je incident nastal, jasno označeno kot predhodno
• Sprejete takojšnje popravljalne ali varnostne ukrepe: vsi koraki, ki so bili že sprejeti za omejitev nadaljnje škode ali tveganja (npr. prekinitev prizadete funkcionalnosti, obvestila izvajalcev)
• Kontaktna točka: oseba ali ekipa, odgovorna za nadaljnje dopisovanje z organom

Poročilo mora biti dejansko in sorazmerno. Predhodna poročila so morda dopolnjena z naknadno poročili, ko preiskava napreduje.

Obvezno beleženje (čl. 12)

Člen 12 zahteva, da so visokotveganostni sistemi UI zasnovani in zgrajeni z zmogljivostjo za samodejno ustvarjanje dnevnikov na ravni podrobnosti, ki zadostuje za:

• Nadzor po trženju v skladu s čl. 72
• Sledenje dogodkom, ki vodijo do resnega incidenta
• Preiskavo s strani nacionalnih organov

To je zahteva oblikovanja, ki je naložena ponudniku. Ponudnik mora zmogljivost beleženja vgraditi v sistem, preden ga da na trg.

Obveznost aktiviranja in ohranitve teh dnevnikov leži na izvajalcu. Izvajalci ne smejo onemogočiti funkcionalnosti beleženja in morajo dnevnike hraniti za obdobje, ki je navedeno v navodilih ponudnika in tehnični dokumentaciji. Kjer specifično obdobje hranjenja ni določeno, je treba dnevnike hraniti za obdobje, ki je sorazmerno z operativnim življenjskim ciklom sistema in morebitnimi sektorsko specifičnimi zahtevami (npr. pravili o hranjenju evidenc finančnih storitev po DORA ali MiFID II).

Bistvene modifikacije in ponovna ocena

Ne vsaka sprememba uvajana sistema UI sproži novo ugotavljanje skladnosti. Akt razlikuje med manjšimi posodobitvami in bistvenimi modifikacijami.

Modifikacija je bistvena — in zahteva novo ugotavljanje skladnosti in posodobljeno tehnično dokumentacijo — ko:

• Spremeni predvideni namen sistema (celo delno)
• Vključuje bistveno spremembo arhitekture ali metodologije usposabljanja
• Uporabi nove podatke za usposabljanje, ki bistveno vplivajo na zmogljivost sistema na načine, ki bi lahko vplivali na vedenje, relevantno za skladnost
• Poslabša zmogljivost pod pragovi, določenimi v dokumentaciji upravljanja tveganj, na načine, ki vplivajo na varnost ali temeljne pravice

Manjše posodobitve — varnostni popravki, popravki napak, ki popravljajo jasno identificirane napake brez spremembe vedenja, relevantnega za skladnost, kozmetične spremembe vmesnika — ne zahtevajo polne ponovne ocene. Toda dokumentirati jih je treba, in ponudnik mora hraniti pisno oceno, ki potrjuje, da modifikacija ne sestavlja bistvene modifikacije. Ta evidenca je predmet pregleda organov za nadzor trga.

Praktičen kontrolni seznam za implementacijo

Naslednji kontrolni seznam odraža minimalne operativne zahteve po čl. 72, čl. 73 in čl. 12. Ni nadomestilo za pravni nasvet, toda zagotavlja izhodišče za analizo vrzeli.

• [ ] Načrt NPT, dokumentiran v tehnični mapi (Annex IV, točka 12), specifičen za sistem in njegov kontekst uvajanja
• [ ] Zmogljivost samodejnega beleženja, zasnovana in vgrajena v sistem pred dajanjem na trg
• [ ] Navodila za izvajalca vključujejo jasen, pisni postopek poročanja o incidentih s kontaktom za stopnjevanje
• [ ] Interna kontaktna točka za poročanje o incidentih vzpostavljena in priglašena pristojnemu nacionalnemu organu za nadzor trga
• [ ] Procesi ali nadzornje plošče za nadzor pristranskosti in točnosti opredeljeni z dokumentirano metodologijo in pragovi
• [ ] Stopnjevalni pragovi za popravljalne ukrepe dokumentirani in povezani s sistemom upravljanja tveganj
• [ ] Postopek ocene bistvene modifikacije vzpostavljen s predlogo evidenc odločitev za vsako posodobitev
• [ ] Politika hranjenja dnevnikov opredeljena, sporočena izvajalcem in usklajena s sektorsko specifičnimi pravili hranjenja

Navzkrižne reference: Tehnična dokumentacija — Visokotveganostni sistemi UI Annex III — Ponudniki vs. Izvajalci