ES DI akto stebėjimas po pateikimo rinkai (Art. 72): didelės rizikos DI teikėjų įsipareigojimai

Atitiktis nesibaigia pateikus rinkai. Art. 72 reikalauja, kad didelės rizikos DI sistemų teikėjai išlaikytų aktyvią stebėjimo po pateikimo rinkai sistemą, rinktų veiklos duomenis ir praneštų apie rimtus incidentus. Štai ką turite daryti — ir kada.

Kas yra stebėjimas po pateikimo rinkai?

Atitikties vertinimas ir CE ženklinimas yra įėjimo bilietas į ES rinką didelės rizikos DI sistemai — ne finišo linija. ES DI akto 72 straipsnis nustato tęstinį įpareigojimą: teikėjai turi sukurti ir valdyti stebėjimo po pateikimo rinkai (SPR) sistemą, kuri aktyviai renka, analizuoja ir veikia pagal realaus pasaulio veiklos duomenis per visą sistemos veiklos laikotarpį.

Pagrindimas yra aiškus. DI sistema, patvirtinta fiksuotame duomenų rinkinyje, gali nukristi, kai realiojo pasaulio įvestys keičiasi, kai kinta naudotojų populiacija arba kai keičiasi joje veikianti aplinka. Statiniai atitikties momentiniai vaizdai negali to užfiksuoti. SPR yra mechanizmas, kuris paverčia atitiktį nuolatiniu procesu, o ne vienkartinis įvykis.

SPR sistema turi būti proporcinga atitinkamos didelės rizikos DI sistemos pobūdžiui ir rizikoms. Kreditų vertinimo modelis, diegiamas dideliu mastu milijonams vartotojų, reikalaus intensyvesnio stebėjimo nei siauras dokumentų klasifikavimo įrankis, naudojamas viduje reguliuojamos įmonės.

Kas turi sukurti SPR sistemą?

Privaloma:

• Annex III savarankiškų didelės rizikos DI sistemų teikėjai — sistemos, išvardytos Annex III, kurios nėra gaminio saugos komponentai (pvz., DI, naudojama sprendimams dėl užimtumo, prieigai prie švietimo, teisėsaugai, kreditingumo vertinimui, ypatingos svarbos infrastruktūros valdymui)
• Annex I į gaminį įterptų DI sistemų teikėjai — DI saugos komponentai, integruoti į gaminius, apimtus esamų ES harmonizuotų teisės aktų (medicinos prietaisai, mašinos, transporto priemonės)

Nereikalinga:

• Minimalios rizikos DI sistemų teikėjams (jokio formalaus SPR įsipareigojimo, nors gera praktika taikoma)
• Tik skaidrumo DI sistemų teikėjams (Art. 50 įsipareigojimai neapima SPR)
• GPAI modelių teikėjai — jie priklauso atskiram režimui pagal Art. 61–62, kuris apima sisteminės rizikos modelių incidentų pranešimą, tačiau struktūrizuotas kitaip nei Art. 72 SPR

Naudotojo vaidmuo yra palaikantis, bet ne neprivalomas. Naudotojai turi eksploatuoti DI sistemą pagal teikėjo instrukcijas, aktyvuoti ir saugoti sistemoje integruotą registravimo funkcionalumą ir — svarbiausia — pranešti apie bet kokius rimtus incidentus, apie kuriuos sužino, teikėjui be nepagrįsto delsimo. Naudotojas, matantis rimtą incidentą ir nepraneša teikėjui, neatitinka reikalavimų.

Stebėjimo po pateikimo rinkai planas (Annex IV, 12 punktas)

SPR planas yra privalomas techninės dokumentacijos komponentas (Annex IV). Jis negali būti generinis dokumentas: jis turi būti specifinis sistemai, jos diegimo kontekstui ir nustatytoms rizikoms. Minimaliai jis turi apibrėžti:

1. Duomenų rinkimas — kokie veiklos rodikliai fiksuojami (tikslumas, klaidų rodikliai, sprendimų rezultatai), kaip duomenys renkami (automatinė telemetrija, naudotojų ataskaitos, naudotojų grįžtamasis ryšys) ir kokiu dažnumu
2. Grįžtamojo ryšio kilpai — mechanizmas, kuriuo naudotojai gali struktūrizuotai ir laiku pranešti teikėjui apie veiklos problemas, anomalijas ar incidentus
3. Tikslumo stebėjimas — kaip sistemos veikimas stebimas pagal patvirtintą lyginamąjį testą, naudotą per atitikties vertinimą, įskaitant bet kokią nukrypimo aptikimo metodiką
4. Šališkumo stebėjimas — sistemoms, kur demografiniai rezultatai yra reikšmingi (įdarbinimas, kreditai, teisėsauga), nuolatinis statistinių skirtumų stebėjimas tarp saugomų grupių su apibrėžta metodika ir slenkstiais
5. Atnaujinimo suaktyvintojai — konkretūs kiekybiniai ar kokybiniai slenkstiai, sukeliantys taisomąjį veiksmą, įskaitant modelio perkvalifikavimą, parametrų koregavimą ar diegimo sustabdymą
6. Peržiūros grafikas — kaip dažnai pats SPR planas yra peržiūrimas ir atnaujinamas, užtikrinant, kad jis lieka tinkamas diegimo konteksto pokyčiams

SPR planas turi būti atnaujinamas. Pasenęs planas, kuris nebeatspindi faktinės stebėjimo metodikos, netenkina Art. 72.

Rimtų incidentų pranešimas (Art. 73)

Kas sudaro rimtą incidentą?

73 straipsnis apibrėžia rimtą incidentą kaip bet kokį didelės rizikos DI sistemos incidentą ar gedimą, kuris tiesiogiai ar netiesiogiai lemia:

• Mirtį arba rimtą žalą sveikatai (fizinę ar psichologinę)
• Rimtą ir neatitaisomą sutrikimą ypatingos svarbos infrastruktūros valdymui ar veikimui
• Rimtą pagrindinių teisių pažeidimą (privatumas, nediskriminavimas, deramas procesas)
• Situaciją, kai asmuo vos išvengė bet kurio iš minėtų

Svarbiai pažymėtina, kad DI aktas nereikalauja, kad būtų nustatyta priežastinis ryšys su DI sistema prieš pranešimą. Pakankamas pagrįstas įtarimas, kad DI sistema prisidėjo prie žalos ar nesugebėjo jos užkirsti kelio, siekiant suaktyvinti įsipareigojimą. Teikėjai, laukiantys tikrumo prieš pranešimą, rizikuoja nesilaikyti.

Pranešimų terminai

15 dienų laikrodis pradeda bėgti, kai teikėjas sužino apie incidentą — kuris praktikoje reiškia, kai naudotojas jiems praneša. Teikėjai turėtų suprojektuoti savo naudotojų pranešimų procedūras taip, kad informacija pasiektų juos pakankamai greitai, kad atitiktų tolimesnio pranešimo terminą.

Ką turi apimti incidento ataskaita

Atitinkama incidento ataskaita nacionalinei rinkos priežiūros institucijai turėtų apimti:

• Sistemos identifikavimas: pavadinimas, versija, ES duomenų bazės registracijos numeris
• Incidento aprašymas: kas nutiko, kokia žala įvyko ar buvo vos išvengta, data ir vieta
• Paveikti asmenys: paveiktų naudotojų ar trečiųjų šalių skaičius ir kategorijos (anonimintos, kur reikalaujama pagal BDAR)
• Preliminari priežastinė analizė: dabartinis teikėjo supratimas, kaip incidentas atsirado, aiškiai pažymėtas kaip preliminarus
• Iš karto imtasi taisomosios ar saugumo priemonės: bet kokie jau imtasi veiksmai, siekiant apriboti tolesnę žalą ar riziką (pvz., paveikto funkcionalumo sustabdymas, naudotojų pranešimai)
• Kontaktinis punktas: asmuo ar komanda, atsakinga už tolesnę korespondenciją su institucija

Ataskaita turėtų būti faktinė ir proporcinga. Preliminarios ataskaitos gali būti papildytos tolesnėmis ataskaitomis tyrimui progresuojant.

Privalomas registravimas (Art. 12)

12 straipsnis reikalauja, kad didelės rizikos DI sistemos būtų suprojektuotos ir sukurtos taip, kad galėtų automatiškai generuoti žurnalus tokiu detalumo lygiu, leidžiančiu:

• Stebėjimą po pateikimo rinkai pagal Art. 72
• Rimtam incidentui vedančių įvykių atsekamumą
• Tyrimą nacionalinių institucijų

Tai yra projektavimo reikalavimas, nustatytas teikėjui. Teikėjas turi integruoti registravimo galimybę į sistemą prieš ją pateikiant rinkai.

Įsipareigojimas aktyvuoti ir saugoti tuos žurnalus tenka naudotojui. Naudotojai negali išjungti registravimo funkcionalumo ir turi saugoti žurnalus teikėjo instrukcijose ir techninėje dokumentacijoje nurodytą laikotarpį. Kur nėra nustatyta konkretaus saugojimo laikotarpio, žurnalai turėtų būti saugomi laikotarpiu, atitinkančiu sistemos veiklos gyvavimo ciklą ir bet kokius taikytinus sektoriaus konkrečius reikalavimus (pvz., finansinių paslaugų įrašų saugojimo taisyklės pagal DORA ar MiFID II).

Esminiai modifikavimų ir pakartotinio vertinimo

Ne kiekvienas diegtosios DI sistemos pakeitimas suaktyvina naują atitikties vertinimą. Aktas skiria nedidelius atnaujinimus ir esminius modifikavimus.

Modifikavimas yra esminis — ir reikalauja naujo atitikties vertinimo bei atnaujintos techninės dokumentacijos — kai jis:

• Keičia sistemos numatytą tikslą (net iš dalies)
• Apima reikšmingą architektūros ar mokymo metodologijos pakeitimą
• Naudoja naujus mokymo duomenis, kurie iš esmės daro poveikį sistemos veikimui taip, kad tai gali paveikti su atitiktimi susijusį elgesį
• Pablogina veikimą virš rizikos valdymo dokumentacijoje nustatytų slenkstių taip, kad tai daro poveikį saugai ar pagrindinėms teisėms

Nedideli atnaujinimai — saugumo patchimai, klaidų pataisymai, taisantys aiškiai nustatytus trūkumus, nekeičiant su atitiktimi susijusio elgesio, kosmetiniai sąsajos pakeitimai — nereikalauja visiško pakartotinio vertinimo. Tačiau jie turi būti dokumentuoti, ir teikėjas turi saugoti rašytinį vertinimą, patvirtinantį, kad modifikavimas nesudaro esminio modifikavimo. Tas įrašas yra pavaldus rinkos priežiūros institucijų patikrinimui.

Praktinis įgyvendinimo kontrolinis sąrašas

Šis kontrolinis sąrašas atspindi minimalius veiklos reikalavimus pagal Art. 72, Art. 73 ir Art. 12. Jis nėra teisinės konsultacijos pakaitalas, tačiau suteikia pradinį tašką spragų analizei.

• [ ] SPR planas dokumentuotas techninėje byloje (Annex IV, 12 punktas), specifinis sistemai ir jos diegimo kontekstui
• [ ] Automatinio registravimo galimybė suprojektuota ir integruota į sistemą prieš pateikiant rinkai
• [ ] Naudotojų instrukcijose pateikta aiški, rašytinė incidentų pranešimo procedūra su eskalavimo kontaktu
• [ ] Incidentų pranešimo kontaktinis punktas sukurtas viduje ir praneštas atitinkamai nacionalinei rinkos priežiūros institucijai
• [ ] Šališkumo ir tikslumo stebėjimo procesai ar prietaisų skydeliai apibrėžti su dokumentuota metodika ir slenkstiais
• [ ] Eskalavimo slenkstiai taisomajam veiksmui dokumentuoti ir susieti su rizikos valdymo sistema
• [ ] Esminio modifikavimo vertinimo procedūra įdiegta su sprendimo įrašų šablonu kiekvienam atnaujinimui
• [ ] Žurnalų saugojimo politika apibrėžta, pranešta naudotojams ir suderinta su sektoriaus konkrečiomis saugojimo taisyklėmis

Kryžmines nuorodos: Techninė dokumentacija — Annex III didelės rizikos DI sistemos — Teikėjai vs. naudotojai