Monitorování po uvedení na trh EU AI Act (čl. 72): povinnosti pro poskytovatele vysoce rizikových systémů AI

Soulad nekončí vstupem na trh. Čl. 72 vyžaduje, aby poskytovatelé vysoce rizikových systémů AI udržovali aktivní systém monitorování po uvedení na trh, shromažďovali data o výkonu a hlásili závažné incidenty. Zde je to, co musíte dělat — a kdy.

Co je monitorování po uvedení na trh?

Posouzení shody a označení CE jsou vstupní lístek na trh EU pro vysoce rizikový systém AI — nikoli cílová čára. Článek 72 EU AI Act ukládá přetrvávající povinnost: poskytovatelé musí zavést a provozovat systém monitorování po uvedení na trh (PMM), který aktivně shromažďuje, analyzuje a jedná na základě dat o výkonu v reálném světě po celou provozní dobu systému.

Zdůvodnění je přímočaré. Systém AI ověřený na pevné datové sadě může driftovat, jak se reálné vstupy mění, jak se mění populace uživatelů nebo jak se vyvíjí prostředí, ve kterém funguje. Statické snímky shody to nemohou zachytit. PMM je mechanismus, který mění soulad z jednorázové události na nepřetržitý proces.

Systém PMM musí být přiměřený povaze a rizikům dotčeného vysoce rizikového systému AI. Model úvěrového skórování nasazený ve velkém měřítku pro miliony spotřebitelů bude vyžadovat intenzivnější monitorování než úzký nástroj pro klasifikaci dokumentů používaný interně regulovanou firmou.

Kdo musí zavést systém PMM?

Povinné pro:

• Poskytovatele samostatných vysoce rizikových systémů AI Přílohy III — systémy uvedené v Příloze III, které nejsou bezpečnostními součástmi produktu (např. AI používaná při rozhodnutích o zaměstnání, přístupu ke vzdělávání, vymáhání práva, hodnocení úvěruschopnosti, řízení kritické infrastruktury)
• Poskytovatele systémů AI zabudovaných v produktech Přílohy I — bezpečnostní součásti AI integrované do produktů pokrytých stávající harmonizační legislativou EU (zdravotnické prostředky, stroje, vozidla)

Nevyžadováno pro:

• Poskytovatele systémů AI s minimálním rizikem (žádná formální povinnost PMM, i když platí osvědčená praxe)
• Poskytovatele systémů AI pouze s povinností transparentnosti (povinnosti čl. 50 se nevztahují na PMM)
• Poskytovatele modelů GPAI — ti podléhají samostatnému režimu podle čl. 61–62, který zahrnuje hlášení incidentů pro modely se systémovým rizikem, ale je strukturován odlišně od PMM podle čl. 72

Role provozovatele je podpůrná, ale nikoli volitelná. Provozovatelé musí provozovat systém AI v souladu s pokyny poskytovatele, aktivovat a uchovávat protokolovací funkci zabudovanou do systému a — kriticky — hlásit jakékoli závažné incidenty, o nichž se dozvědí, poskytovateli bez zbytečného prodlení. Provozovatel, který zaregistruje závažný incident a nevyrozumí poskytovatele, není v souladu.

Plán monitorování po uvedení na trh (Příloha IV, bod 12)

Plán PMM je povinnou součástí technické dokumentace (Příloha IV). Nemůže být obecným dokumentem: musí být specifický pro systém, jeho kontext nasazení a jeho identifikovaná rizika. Minimálně musí definovat:

1. Sběr dat — jaké metriky výkonu jsou zachycovány (přesnost, míry chyb, výsledky rozhodnutí), jak jsou data shromažďována (automatická telemetrie, zprávy provozovatelů, zpětná vazba uživatelů) a v jaké frekvenci
2. Zpětné vazební smyčky — mechanismus, prostřednictvím kterého mohou provozovatelé hlásit problémy s výkonem, anomálie nebo incidenty zpět poskytovateli strukturovaným a včasným způsobem
3. Monitorování přesnosti — jak je výkon systému sledován vůči ověřenému benchmarku použitému při posouzení shody, včetně jakékoli metodologie detekce driftu
4. Monitorování zkreslení — pro systémy, kde jsou demografické výsledky materiální (nábor, úvěr, vymáhání práva), průběžné monitorování statistických disparit napříč chráněnými skupinami s definovanou metodologií a prahy
5. Spouštěče aktualizace — konkrétní kvantitativní nebo kvalitativní prahy, které vyvolávají nápravné opatření, včetně přetrénování modelu, úpravy parametrů nebo pozastavení nasazení
6. Plán přezkumu — jak často je samotný plán PMM přezkoumáván a aktualizován, aby zůstal vhodný pro daný účel s vývojem kontextu nasazení

Plán PMM musí být průběžně aktualizován. Zastaralý plán, který již neodráží skutečnou metodologii monitorování, nesplňuje čl. 72.

Hlášení závažných incidentů (čl. 73)

Co tvoří závažný incident?

Článek 73 definuje závažný incident jako jakýkoli incident nebo poruchu vysoce rizikového systému AI, která přímo nebo nepřímo vede k:

• Úmrtí nebo závažné újmě na zdraví (fyzické nebo psychické)
• Závažnému a nenapravitelnému narušení řízení nebo provozu kritické infrastruktury
• Závažnému porušení základních práv (soukromí, nediskriminace, spravedlivý proces)
• Situaci, kdy osoba těsně unikla jakémukoli z výše uvedeného

Důležité je, že AI Act nevyžaduje, aby byl prokázán příčinný vztah k systému AI před hlášením. K vyvolání povinnosti postačuje rozumné podezření, že systém AI přispěl k újmě nebo ji nepředešel. Poskytovatelé, kteří čekají na jistotu před hlášením, riskují nesoulad.

Lhůty pro hlášení

15denní lhůta začíná běžet, kdy se poskytovatel dozví o incidentu — což v praxi znamená, kdy jej provozovatel informuje. Poskytovatelé by měli navrhnout postupy pro oznamování provozovateli tak, aby informace k nim dorazily dostatečně rychle pro splnění lhůty pro hlášení dále v řetězci.

Co musí zpráva o incidentu obsahovat

Vyhovující zpráva o incidentu vnitrostátnímu orgánu dozoru nad trhem by měla zahrnovat:

• Identifikace systému: název, verze, číslo registrace v databázi AI EU
• Popis incidentu: co se stalo, jaká újma nastala nebo bylo těsně odvrácena, datum a místo
• Postižené osoby: počet a kategorie postižených uživatelů nebo třetích stran (anonymizováno tam, kde to vyžaduje GDPR)
• Předběžná kauzální analýza: aktuální porozumění poskytovatele tomu, jak incident vznikl, jasně označené jako předběžné
• Okamžitá nápravná nebo bezpečnostní opatření přijatá: jakékoli kroky již přijaté k omezení další újmy nebo rizika (např. pozastavení postižené funkce, oznámení provozovatelům)
• Kontaktní místo: osoba nebo tým zodpovědný za další korespondenci s orgánem

Zpráva by měla být věcná a přiměřená. Předběžné zprávy mohou být doplněny následujícími zprávami s pokročilostí vyšetřování.

Povinné protokolování (čl. 12)

Článek 12 vyžaduje, aby byly vysoce rizikové systémy AI navrženy a budovány se schopností automaticky generovat protokoly na úrovni granularity dostatečné k umožnění:

• Monitorování po uvedení na trh v souladu s čl. 72
• Sledování událostí vedoucích k závažnému incidentu
• Vyšetřování vnitrostátními orgány

Jde o požadavek na návrh uložený poskytovateli. Poskytovatel musí zabudovat schopnost protokolování do systému před jeho uvedením na trh.

Povinnost aktivovat a uchovávat tyto protokoly leží na provozovateli. Provozovatelé nesmí deaktivovat funkci protokolování a musí uchovávat protokoly po dobu stanovenou v pokynech poskytovatele a technické dokumentaci. Kde není definována žádná konkrétní lhůta uchovávání, by protokoly měly být uchovávány po dobu přiměřenou provoznímu životnímu cyklu systému a jakýmkoli odvětvově specifickým požadavkům (např. pravidla uchovávání záznamů finančních služeb podle DORA nebo MiFID II).

Podstatné modifikace a nové hodnocení

Ne každá změna nasazeného systému AI spouští nové posouzení shody. Zákon rozlišuje mezi drobnými aktualizacemi a podstatnými modifikacemi.

Modifikace je podstatná — a vyžaduje nové posouzení shody a aktualizovanou technickou dokumentaci — když:

• Mění zamýšlený účel systému (i částečně)
• Zahrnuje výraznou změnu architektury nebo metodologie trénování
• Používá nová trénovací data, která materiálně ovlivňují výkon systému způsoby, které mohou ovlivnit chování relevantní pro soulad
• Snižuje výkon nad prahy definované v dokumentaci řízení rizik způsoby, které ovlivňují bezpečnost nebo základní práva

Drobné aktualizace — bezpečnostní záplaty, opravy chyb, které opravují jasně identifikované vady bez změny chování relevantního pro soulad, kosmetické změny rozhraní — nevyžadují plné nové hodnocení. Musí však být zdokumentovány a poskytovatel musí uchovávat písemné posouzení potvrzující, že modifikace není podstatnou modifikací. Tento záznam podléhá inspekci orgánů dozoru nad trhem.

Praktický implementační kontrolní seznam

Následující kontrolní seznam odráží minimální provozní požadavky podle čl. 72, čl. 73 a čl. 12. Není náhradou právního poradenství, ale poskytuje výchozí bod pro analýzu mezer.

• [ ] Plán PMM zdokumentován v technickém spisu (Příloha IV, bod 12), specifický pro systém a jeho kontext nasazení
• [ ] Schopnost automatického protokolování navržena a zabudována do systému před uvedením na trh
• [ ] Pokyny pro provozovatele zahrnují jasný, písemný postup hlášení incidentů s eskalačním kontaktem
• [ ] Kontaktní místo pro hlášení incidentů zřízeno interně a oznámeno příslušnému vnitrostátnímu orgánu dozoru nad trhem
• [ ] Procesy nebo dashboardy pro monitorování zkreslení a přesnosti definovány s dokumentovanou metodologií a prahy
• [ ] Eskalační prahy pro nápravná opatření zdokumentovány a propojeny se systémem řízení rizik
• [ ] Postup posouzení podstatné modifikace zaveden se šablonou rozhodovacího záznamu pro každou aktualizaci
• [ ] Politika uchovávání protokolů definována, sdělena provozovatelům a sladěna s odvětvově specifickými pravidly uchovávání

Křížové reference: Technická dokumentace — Vysoce rizikové systémy AI Přílohy III — Poskytovatelé vs. provozovatelé