Post-market monitoring nariadenia EÚ o AI (čl. 72): Povinnosti pre poskytovateľov vysokorizikových systémov AI

Súlad nekončí vstupom na trh. Čl. 72 vyžaduje, aby poskytovatelia vysokorizikových systémov AI udržiavali aktívny systém post-market monitoringu, zbierali údaje o výkone a hlásili závažné incidenty. Tu je to, čo musíte urobiť — a kedy.

Čo je post-market monitoring?

Posúdenie zhody a označenie CE sú vstupnou vstupenkou na trh EÚ pre vysokorizikový systém AI — nie cieľovou čiarou. Článok 72 nariadenia EÚ o AI ukladá pokračujúcu povinnosť: poskytovatelia musia zriadiť a prevádzkovať systém post-market monitoringu (PMM), ktorý aktívne zbiera, analyzuje a koná na základe reálnych výkonnostných údajov počas celej operačnej životnosti systému.

Odôvodnenie je priamočiare. Systém AI validovaný na pevnom datasete môže driftovať, keď sa menia reálne vstupy, keď sa mení populácia používateľov alebo keď sa vyvíja prostredie, v ktorom pôsobí. Statické snímky súladu to nemôžu zachytiť. PMM je mechanizmus, ktorý mení súlad na nepretržitý proces a nie jednorazovú udalosť.

Systém PMM musí byť primeraný povahe a rizikám dotknutého vysokorizikového systému AI. Model kreditného skórovania nasadený vo veľkom rozsahu naprieč miliónmi spotrebiteľov bude vyžadovať intenzívnejší monitoring ako úzky nástroj klasifikácie dokumentov používaný interne regulovanou firmou.

Kto musí zriadiť systém PMM?

Povinné pre:

• Poskytovateľov samostatných vysokorizikových systémov AI Prílohy III — systémy uvedené v Prílohe III, ktoré nie sú bezpečnostnými komponentmi výrobku (napr. AI používaná pri rozhodnutiach o zamestnaní, prístupe k vzdelávaniu, presadzovaní práva, hodnotení úverovej spôsobilosti, správe kritickej infraštruktúry)
• Poskytovateľov systémov AI zabudovaných do výrobkov Prílohy I — bezpečnostné komponenty AI integrované do výrobkov pokrytých existujúcou harmonizačnou legislatívou EÚ (zdravotnícke pomôcky, strojové zariadenia, vozidlá)

Nevyžaduje sa pre:

• Poskytovateľov systémov AI s minimálnym rizikom (žiadna formálna povinnosť PMM, hoci platí osvedčená prax)
• Poskytovateľov systémov AI iba s transparentnosťou (povinnosti čl. 50 sa nerozširujú na PMM)
• Poskytovatelia modelov GPAI — tieto podliehajú samostatnému režimu podľa čl. 61–62, ktorý zahŕňa hlásenie incidentov pre modely so systémovým rizikom, ale je štruktúrovaný odlišne od PMM čl. 72

Úloha nasadzujúceho subjektu je podporná, ale nie nepovinná. Nasadzujúce subjekty musia prevádzkovať systém AI v súlade s pokynmi poskytovateľa, aktivovať a uchovávať funkciu protokolovania zabudovanú do systému a — kriticky — hlásiť akékoľvek závažné incidenty, o ktorých sa dozvedia, poskytovateľovi bez zbytočného odkladu. Nasadzujúci subjekt, ktorý pozoruje závažný incident a neinformuje poskytovateľa, nie je v súlade.

Plán post-market monitoringu (Príloha IV, bod 12)

Plán PMM je povinnou súčasťou technickej dokumentácie (Príloha IV). Nemôže byť všeobecným dokumentom: musí byť špecifický pre systém, jeho kontext nasadenia a identifikované riziká. Minimálne musí definovať:

1. Zber údajov — aké metriky výkonu sú zachytávané (presnosť, miery chýb, výsledky rozhodnutí), ako sú zbierané údaje (automatická telemetria, hlásenia nasadzujúcich subjektov, spätná väzba používateľov) a v akej frekvencii
2. Spätné väzby — mechanizmus, prostredníctvom ktorého môžu nasadzujúce subjekty hlásiť problémy s výkonom, anomálie alebo incidenty späť poskytovateľovi štruktúrovaným a včasným spôsobom
3. Monitorovanie presnosti — spôsob sledovania výkonu systému voči validovanej referenčnej hodnote použitej počas posúdenia zhody vrátane akejkoľvek metodológie detekcie driftu
4. Monitorovanie zaujatosti — pre systémy, kde sú demografické výsledky materiálne (nábor, úver, presadzovanie práva), priebežné monitorovanie štatistických disparít naprieč chránenými skupinami so zdokumentovanou metodológiou a hranicami
5. Spúšťače aktualizácií — konkrétne kvantitatívne alebo kvalitatívne hranice, ktoré vyzývajú na nápravné opatrenia vrátane preškolovania modelu, úpravy parametrov alebo pozastavenia nasadenia
6. Harmonogram preskúmania — ako často je samotný plán PMM preskúmavaný a aktualizovaný, čo zabezpečuje, že zostáva vhodný na daný účel, keď sa vyvíja kontext nasadenia

Plán PMM musí byť udržiavaný aktuálny. Zastaraný plán, ktorý už nereflektuje skutočnú metodológiu monitorovania, nespĺňa čl. 72.

Hlásenie závažných incidentov (čl. 73)

Čo tvorí závažný incident?

Článok 73 definuje závažný incident ako akýkoľvek incident alebo poruchu vysokorizikového systému AI, ktorá priamo alebo nepriamo vedie k:

• Smrti alebo závažnému poškodeniu zdravia (fyzickému alebo psychologickému)
• Závažnému a nezvratnému narušeniu správy alebo prevádzky kritickej infraštruktúry
• Závažnému porušeniu základných práv (súkromie, nediskriminácia, spravodlivý proces)
• Situácii, v ktorej osoba takmer unikla ktorémukoľvek z vyššie uvedeného

Nariadenie o AI nevyžaduje, aby bol kauzálny súvis so systémom AI stanovený pred hlásením. Primeraná domienka, že systém AI prispel alebo nepodarilo sa mu zabrániť škode, postačuje na spustenie povinnosti. Poskytovatelia, ktorí čakajú na istotu pred hlásením, riskujú nedodržanie.

Termíny hlásenia

15-dňové hodinky začínajú, keď sa poskytovateľ dozvie o incidente — čo v praxi znamená, keď ho notifikuje nasadzujúci subjekt. Poskytovatelia by mali navrhnúť postupy oznamovania nasadzujúcich subjektov tak, aby sa informácie dostali k nim dostatočne rýchlo na splnenie downstream termínu hlásenia.

Čo musí správa o incidente obsahovať

Vyhovujúca správa o incidente národnému orgánu trhového dohľadu by mala obsahovať:

• Identifikáciu systému: názov, verzia, registračné číslo databázy EÚ AI
• Popis incidentu: čo sa stalo, aká škoda nastala alebo sa takmer nestala, dátum a miesto
• Dotknuté osoby: počet a kategórie dotknutých používateľov alebo tretích strán (anonymizované, kde to vyžaduje GDPR)
• Predbežná príčinná analýza: aktuálne chápanie poskytovateľa, ako k incidentu došlo, jasne označené ako predbežné
• Okamžité nápravné alebo bezpečnostné opatrenia prijaté: akékoľvek kroky už podniknuté na obmedzenie ďalšej škody alebo rizika (napr. pozastavenie dotknutej funkcionality, oznámenia nasadzujúcim subjektom)
• Kontaktný bod: osoba alebo tím zodpovedný za následné korešpondencia s orgánom

Správa by mala byť faktická a primeraná. Predbežné správy môžu byť doplnené následnými správami, keď vyšetrovanie pokračuje.

Povinné protokolovanie (čl. 12)

Článok 12 vyžaduje, aby vysokorizikové systémy AI boli navrhnuté a vybudované so schopnosťou automaticky generovať protokoly na úrovni granularity dostatočnej na umožnenie:

• Post-market monitoringu v súlade s čl. 72
• Sledovania udalostí vedúcich k závažnému incidentu
• Vyšetrovania národnými orgánmi

Toto je požiadavka na dizajn uložená na poskytovateľa. Poskytovateľ musí zabudovať schopnosť protokolovania do systému pred umiestnením na trh.

Povinnosť aktivovať a uchovávať tieto protokoly padá na nasadzujúceho subjektu. Nasadzujúce subjekty nesmú vypínať funkcie protokolovania a musia uchovávať protokoly po dobu uvedenú v pokynoch a technickej dokumentácii poskytovateľa. Kde nie je definované konkrétne obdobie uchovávania, protokoly by mali byť uchovávané po dobu primeranu prevádzkovému životnému cyklu systému a akýmkoľvek sektorovo špecifickým požiadavkám (napr. pravidlá uchovávanie záznamov vo finančných službách podľa DORA alebo MiFID II).

Podstatné modifikácie a opätovné hodnotenie

Nie každá zmena nasadeného systému AI spúšťa nové posúdenie zhody. Zákon rozlišuje medzi menšími aktualizáciami a podstatnými modifikáciami.

Modifikácia je podstatná — a vyžaduje nové posúdenie zhody a aktualizovanú technickú dokumentáciu — keď:

• Mení zamýšľaný účel systému (aj čiastočne)
• Zahŕňa výraznú zmenu architektúry alebo metodológie trénovania
• Používa nové trénovacie údaje, ktoré materálne ovplyvňujú výkon systému spôsobmi, ktoré môžu ovplyvniť správanie relevantné pre súlad
• Zhoršuje výkon nad hranice definované v dokumentácii riadenia rizík spôsobmi, ktoré ovplyvňujú bezpečnosť alebo základné práva

Menšie aktualizácie — bezpečnostné záplaty, opravy chýb, ktoré opravujú jasne identifikované defekty bez zmeny správania relevantného pre súlad, kozmetické zmeny rozhrania — nevyžadujú úplné opätovné hodnotenie. Musia však byť zdokumentované a poskytovateľ musí uchovávať písomné hodnotenie potvrdzujúce, že modifikácia nepredstavuje podstatnú modifikáciu. Tento záznam podlieha kontrole orgánov trhového dohľadu.

Praktický implementačný kontrolný zoznam

Nasledujúci kontrolný zoznam odráža minimálne prevádzkové požiadavky podľa čl. 72, čl. 73 a čl. 12. Nie je náhradou za právne poradenstvo, ale poskytuje východiskový bod pre analýzu medzier.

• [ ] Plán PMM zdokumentovaný v technickom spise (Príloha IV, bod 12), špecifický pre systém a jeho kontext nasadenia
• [ ] Schopnosť automatického protokolovania navrhnutá a zabudovaná do systému pred umiestnením na trh
• [ ] Pokyny pre nasadzujúce subjekty zahŕňajú jasný písomný postup hlásenia incidentov s eskalačným kontaktom
• [ ] Interne zriadený kontaktný bod hlásenia incidentov a oznámený príslušnému národnému orgánu trhového dohľadu
• [ ] Definované procesy alebo dashboardy monitorovania zaujatosti a presnosti so zdokumentovanou metodológiou a hranicami
• [ ] Eskalačné hranice pre nápravné opatrenia zdokumentované a prepojené so systémom riadenia rizík
• [ ] Zavedený postup hodnotenia podstatnej modifikácie so šablónou záznamu rozhodnutia pre každú aktualizáciu
• [ ] Definovaná politika uchovávania protokolov, komunikovaná nasadzujúcim subjektom a zosúladená so sektorovo špecifickými pravidlami uchovávania

Krížové referencie: Technická dokumentácia — Vysokorizikové systémy AI Prílohy III — Poskytovatelia vs. nasadzujúce subjekty