Incidenty a hlášení závažných problémů podle AI Actu: co musí firma udělat po chybě systému

Aktualizováno 10. srpna 2026. Incident u AI nemusí být jen výpadek služby nebo nepřesná odpověď chatbotu. Může jít o chybné rozhodnutí, únik osobních údajů, diskriminační výstup, selhání bezpečnostní funkce, nesprávné označení obsahu nebo situaci, kdy systém přestane respektovat své limity. U vysoce rizikové AI může taková událost spustit povinnost vyšetřovat, přijmout nápravná opatření a v určitých případech incident oznámit.

Článek 73 AI Actu stanoví pravidla pro hlášení závažných incidentů vysoce rizikových systémů. Primární povinnost má poskytovatel systému uvedeného na trh Unie. Provozovatel musí mít vlastní interní postup, okamžitě informovat poskytovatele, zachovat důkazy a spolupracovat. V některých sektorech se mohou uplatnit rovnocenné oznamovací režimy podle jiných předpisů, například pro zdravotnické prostředky nebo kybernetickou bezpečnost.

Tento článek je praktický průvodce pro české firmy, webové agentury, dodavatele software i provozovatele AI. Vysvětluje, co AI Act považuje za závažný incident, jak během prvních hodin omezit další škodu, jak sestavit hlášení a jak propojit AI Act s GDPR, bezpečností a smlouvami. Konkrétní příslušný úřad, lhůtu a formu podání vždy ověřte podle typu systému, místa incidentu a aktuálního národního procesu.

Krátká odpověď: ne každý chybný výstup je závažným incidentem podle AI Actu. Pokud však incident přímo nebo nepřímo vede k úmrtí nebo vážné újmě na zdraví, k závažnému a nevratnému narušení kritické infrastruktury, k porušení unijních povinností na ochranu základních práv nebo k vážné škodě na majetku či životním prostředí, je nutné jednat rychle. U běžného provozního problému může vzniknout povinnost podle GDPR, smlouvy, spotřebitelského práva nebo bezpečnostních předpisů i bez hlášení podle článku 73.

Co je závažný incident

Článek 3 bod 49 AI Actu definuje závažný incident jako incident nebo nefunkčnost systému AI, která přímo nebo nepřímo vede k některému z těchto následků:

• úmrtí osoby nebo vážná újma na zdraví;
• závažné a nevratné narušení řízení nebo provozu kritické infrastruktury;
• porušení povinností podle práva Unie, jejichž účelem je ochrana základních práv;
• vážná škoda na majetku nebo životním prostředí.

Důležité je slovo „vede“. Samotná chyba modelu ještě nemusí stačit. Firma musí posoudit vztah mezi událostí a skutečným nebo pravděpodobným dopadem. Chybná odpověď v interním experimentu je jiná situace než chybný výstup, podle kterého je člověku odmítnuta důležitá služba, aktivováno nebezpečné zařízení nebo porušeno právo chráněné unijními předpisy.

Na druhou stranu není bezpečné čekat na absolutní jistotu. Článek 73 počítá s oznámením po zjištění příčinné souvislosti nebo rozumné pravděpodobnosti takové souvislosti. Interní triage proto musí pracovat s fakty, hypotézami a mírou nejistoty odděleně.

Každá chyba není hlášení podle AI Actu

Provozní tým potřebuje rozlišit několik úrovní událostí:

ÚroveňPříkladPrvní reakce Běžná chybaChatbot odpoví nepřesně, ale člověk výsledek ověří a nikomu nevznikne významná újma.Oprava zdroje, záznam, test a kontrola opakování. Významný provozní incidentModel opakovaně špatně klasifikuje žádosti nebo uniká mimo určený účel.Omezení funkce, vyšetření rozsahu, kontrola dotčených případů a nápravný plán. Možný závažný incidentVýstup pravděpodobně zasáhl základní práva, bezpečnost, kritickou infrastrukturu, majetek nebo zdraví.Okamžité zajištění důkazů, eskalace, právní posouzení a ověření oznamovací povinnosti. Potvrzený závažný incidentJe doložený relevantní dopad a příčinná souvislost nebo její rozumná pravděpodobnost.Hlášení podle článku 73 nebo jiného režimu, vyšetření, náprava a spolupráce s úřadem.

Toto rozdělení je interní pomůcka, nikoli právní definice. Událost může začít jako běžná chyba a později se změnit na závažný incident, pokud se zjistí větší rozsah nebo dopad.

Kdo incident hlásí

U vysoce rizikových systémů článek 73 ukládá povinnost hlásit závažné incidenty poskytovateli systému. Hlášení se posílá orgánům dozoru nad trhem členských států, ve kterých k incidentu došlo. Poskytovatel musí také bezodkladně provést vyšetření, posouzení rizik a přijmout nápravné opatření.

Provozovatel, který systém používá, nesmí čekat, až problém někdo objeví. V praxi má:

• mít dostupný kontakt pro incidenty u poskytovatele;
• bez zbytečného odkladu předat ověřené informace a zachovat důkazy;
• omezit nebo zastavit používání, pokud pokračování zvyšuje riziko;
• spolupracovat na posouzení dopadu a kontrole dotčených případů;
• ověřit vlastní povinnosti podle GDPR, smlouvy, bezpečnostních nebo sektorových pravidel;
• zaznamenat, kdo rozhodl o dalším provozu, omezení nebo návratu k ručnímu procesu.

Smlouva může určit, že provozovatel musí incident dodavateli oznámit například do několika hodin. Taková smluvní lhůta nenahrazuje zákonnou oznamovací lhůtu a nesmí být důvodem, proč firma nejprve čeká na schválení dodavatele, když hrozí další újma.

Lhůty podle článku 73

Článek 73 pracuje s několika časovými režimy. Rozhodující není až okamžik, kdy je vyšetření dokončené, ale kdy se poskytovatel nebo případně provozovatel o závažném incidentu dozví a kdy je potvrzena nebo rozumně předpokládána příčinná souvislost.

• Běžný režim: oznámit okamžitě po zjištění příčinné souvislosti nebo rozumné pravděpodobnosti, nejpozději do 15 dnů od okamžiku, kdy se poskytovatel nebo případně provozovatel o incidentu dozví.
• Rozšířené porušení nebo závažné a nevratné narušení kritické infrastruktury: oznámit okamžitě, nejpozději do 2 dnů od zjištění incidentu.
• Úmrtí osoby: oznámit okamžitě po zjištění nebo podezření na příčinnou souvislost, nejpozději do 10 dnů od okamžiku, kdy se o incidentu poskytovatel nebo případně provozovatel dozví.

Jestliže nejsou všechny informace včas k dispozici, článek 73 umožňuje podat nejprve neúplné hlášení a následně ho doplnit. To není povolení k mlčení. První zpráva musí obsahovat ověřená fakta, stav vyšetření, předběžné vymezení dopadu a kontakt na odpovědnou osobu.

Lhůty výše jsou shrnutím čl. 73 AI Actu, nikoli náhradou za kontrolu aktuálního právního textu a sektorových pravidel. U zdravotnických prostředků, kritické infrastruktury, kybernetických incidentů nebo dalších regulovaných oblastí může platit zvláštní oznamovací cesta.

Prvních 15 minut

Incidentní postup má být použitelný i v noci, o víkendu a pro člověka, který systém nevyvíjel. První krok není dlouhá analýza. Je to zastavení dalšího dopadu.

1. Potvrďte událost: zapište čas, systém, verzi, zdroj hlášení a stručný popis.
2. Omezte riziko: vypněte dotčenou funkci, odpojte automatickou akci, snižte dosah nebo přepněte na ruční režim.
3. Zachovejte stav: pořiďte bezpečnou kopii logů, konfigurace, vstupů, výstupů a relevantní komunikace.
4. Informujte vlastníka: zapojte incident managera, techniku, bezpečnost, právní roli, DPO a procesního vlastníka podle dopadu.
5. Označte nejistotu: oddělte doložená fakta od předběžného odhadu a hypotézy o příčině.

Nemažte původní výstup jen proto, že je chybný. Pokud obsahuje osobní údaje, zabezpečte ho a omezte přístup. Cílem je zachovat důkaz v minimálním potřebném rozsahu, ne vytvořit další kopie bez kontroly.

Vyšetření a příčinná souvislost

Vyšetření má odpovědět na pět různých otázek:

• Co se stalo? Konkrétní událost, dotčená funkce a časový průběh.
• Komu se to stalo? Počet případů, skupiny osob, zákazníci, zaměstnanci, majetek nebo infrastruktura.
• Jaký je dopad? Skutečná újma, potenciální újma, vratnost, rozsah a možnost nápravy.
• Jak k tomu došlo? Model, data, konfigurace, integrace, lidské rozhodnutí, útok nebo organizační selhání.
• Co zabrání opakování? Technická oprava, změna procesu, lidská kontrola, omezení účelu nebo ukončení funkce.

Vztah mezi AI a následkem může být přímý i nepřímý. Systém nemusí sám rozhodnutí učinit. Může vytvořit skóre, které pracovník nekriticky převezme, nebo může nesprávně vyplnit podklad, který ovlivní další automatizaci. Do reportu proto popište také zásahy lidí a navazujících systémů.

Jak připravit hlášení

Komise zveřejnila návrh metodiky a šablony pro hlášení závažných incidentů u vysoce rizikových systémů. I když se právní požadavky nebo formulář mohou dále upřesňovat, firma si může interní šablonu připravit už nyní.

Doporučený obsah interního reportu

1. Identifikace: název systému, poskytovatel, provozovatel, verze, účel a kontaktní osoby.
2. Událost: datum, místo, způsob zjištění a časová osa.
3. Dopad: dotčené osoby, zdraví, základní práva, majetek, životní prostředí nebo kritická infrastruktura.
4. Rozsah: počet případů, období, regiony, skupiny a stav pokračování.
5. Příčinná souvislost: potvrzená, pravděpodobná nebo dosud nejasná, včetně podkladů.
6. Okamžitá opatření: vypnutí, omezení, lidský přezkum, komunikace a zajištění dat.
7. Vyšetření: použité metody, zapojené osoby, známé limity a další kroky.
8. Náprava: oprava systému, změna procesu, opakování rozhodnutí a kontrola účinnosti.
9. Oznamovací mapa: AI Act, GDPR, kyberbezpečnost, sektorová pravidla, smlouvy a pojištění.

Report má být srozumitelný pro člověka, který systém nezná. Technické přílohy připojte podle potřeby, ale hlavní část vysvětlete běžným jazykem. Nezaměňujte první hlášení s kompletní forenzní zprávou. První hlášení může být neúplné a následně doplněné.

Druhý proud: GDPR a únik osobních údajů

Pokud incident zahrnuje osobní údaje, samostatně posuďte porušení zabezpečení osobních údajů podle GDPR. Správce musí v příslušných případech oznámit porušení dozorovému úřadu bez zbytečného odkladu, pokud možno do 72 hodin od okamžiku, kdy se o něm dozvěděl. Oznámení podle GDPR a hlášení podle AI Actu se mohou týkat stejné události, ale mají jiný právní základ, příjemce, obsah a test rizika.

Prakticky si ve formuláři položte dvě oddělené otázky:

• Došlo k porušení zabezpečení osobních údajů a vzniká oznamovací povinnost podle GDPR?
• Splňuje událost definici závažného incidentu podle AI Actu nebo se na ni vztahuje jiný režim?

Jedna odpověď nenahrazuje druhou. U některých incidentů bude odpověď „ano“ pouze na GDPR, u jiných pouze na AI Act a u závažných případů na oba režimy současně.

GPAI modely se systémovým rizikem

U obecného modelu AI se systémovým rizikem platí odlišný režim. Poskytovatel musí podle článku 55 sledovat, dokumentovat a bez zbytečného odkladu hlásit AI Office relevantní informace o závažných incidentech a možných nápravných opatřeních. Podle okolností může být potřeba informovat také národní kompetentní orgány.

Pro firmu, která pouze používá hotový model v aplikaci, je důležité vědět, kam incident eskalovat a jaké informace poskytovatel požaduje. Pro tým, který model významně upravuje nebo poskytuje vlastní systém založený na GPAI, je nutné znovu posoudit roli v hodnotovém řetězci a povinnosti pro downstream systém.

Nezasahujte do důkazů bez kontroly

Článek 73 vyžaduje, aby poskytovatel po oznámení incidentu provedl vyšetření, posouzení rizik a nápravné kroky. Zároveň nemá před informováním příslušných orgánů provést vyšetřovací zásah, který by změnil systém tak, že by ovlivnil pozdější vyhodnocení příčiny.

Praktický kompromis v produkci:

1. zastavte nebo omezte funkci, pokud by pokračování mohlo působit další škodu;
2. před změnou vytvořte bezpečnou kopii relevantní konfigurace a logů;
3. zapište čas, důvod a osobu, která změnu schválila;
4. analýzu provádějte nad kopií, pokud to bezpečnost a ochrana údajů umožní;
5. do hlášení uveďte, co bylo změněno a co zůstalo zachované.

Příklady z praxe

Chatbot zveřejní osobní údaje

Chatbot v odpovědi zobrazí část cizího požadavku včetně e-mailu a interní poznámky. Nejdříve se vypne dotčený zdroj nebo funkce, zachová se log a určí se rozsah. DPO posoudí GDPR, technický tým hledá příčinu a vlastník služby ověří, zda chatbot pokračuje v podobném chování. Samotné vypnutí nestačí: je potřeba posoudit dotčené osoby, informování, nápravu a prevenci opakování.

HR systém systematicky vyřazuje skupinu kandidátů

Firma zjistí, že verze klasifikačního modelu dává jedné skupině výrazně horší výstupy. Dočasně zastaví automatické vyřazení, zachová verzi dat a modelu, zkontroluje dotčené kandidáty a zapojí právní a HR roli. Pokud je dopad kvalifikován jako porušení povinností chránících základní práva, může jít o závažný incident podle AI Actu. Přesnou kvalifikaci je nutné posoudit podle faktů a právního rámce.

AI ovládá bezpečnostní funkci

Model nesprávně vyhodnotí stav zařízení a navazující systém přestane reagovat na varovný signál. Firma přepne na bezpečný režim, zachová telemetrii, ověří dotčený hardware a posoudí, zda incident zasáhl kritickou infrastrukturu, zdraví nebo majetek. U regulovaných výrobků se současně kontroluje speciální oznamovací režim.

Nepřesná marketingová ilustrace

Generátor vytvoří realistický obrázek, který zákazníci pochopí jako fotografii skutečné události. Pokud nevznikla závažná újma, nemusí jít o incident podle článku 73, ale může vzniknout problém transparentnosti, klamavé komunikace, autorských práv nebo reputace. Firma výstup stáhne, doplní označení, zkontroluje další použití a upraví redakční schvalování.

Jak nastavit role ve firmě

RoleOdpovědnost při incidentu Vlastník systémuRozhodne o omezení, zapojí tým, potvrdí účel a schválí návrat do provozu. Incident managerVede časovou osu, úkoly, důkazy a komunikaci mezi rolemi. IT a bezpečnostZajistí logy, izolaci, technické vyšetření, obnovu a nápravnou změnu. DPO a právní rolePosoudí GDPR, AI Act, základní práva, smlouvy a oznamovací povinnosti. Procesní vlastníkUrčí dotčené případy, ruční alternativu, nápravu a komunikaci se zákazníky nebo zaměstnanci. DodavatelDodá technické podklady, vyšetří vlastní komponentu a provede sjednanou opravu.

U malé firmy nemusí jít o šest lidí. Jedna osoba může mít více rolí, ale musí být jasné, kdo je zastupuje a kdo může systém skutečně vypnout.

Plán 30/60/90 dní

Prvních 30 dní: připravit kontakt a důkazy

• určete vlastníka každého AI systému a incidentní kontakt;
• zaveďte jednoduchý formulář pro záznam události;
• ověřte, zda lze exportovat logy, konfiguraci a verzi modelu;
• sepište pravidlo pro okamžité omezení nebo přechod na ruční režim;
• přidejte dodavatele, DPO, právní a bezpečnostní eskalaci.

Do 60 dní: nacvičit třídění

• vytvořte klasifikační matici pro běžnou chybu, významný incident a závažný incident;
• propojte AI Act s GDPR, NIS2 nebo sektorovými oznamovacími režimy;
• připravte šablonu prvního hlášení a seznam příloh;
• proveďte cvičení s únikem dat, chybným rozhodnutím a výpadkem;
• ověřte, že lidé rozumějí rozdílu mezi interní a zákonnou lhůtou.

Do 90 dní: měřit a zlepšovat

• změřte čas od zjištění po eskalaci a zajištění logů;
• zkontrolujte, zda je možné rekonstruovat rozhodnutí bez nadbytečných osobních údajů;
• vyhodnoťte nápravná opatření a opakování podobných chyb;
• aktualizujte smlouvy s dodavateli o spolupráci a hlášení;
• naplánujte pravidelný test incidentního postupu.

Kontrolní seznam

• Máme seznam AI systémů a jejich poskytovatelů?
• Víme, které systémy mohou být vysoce rizikové nebo jsou součástí regulovaného výrobku?
• Je určený člověk, který může systém omezit nebo vypnout?
• Umíme do několika hodin získat logy, konfiguraci a verzi modelu?
• Máme interně definované závažné dopady na zdraví, základní práva, majetek a infrastrukturu?
• Rozlišujeme příčinnou souvislost, pravděpodobnost a pouhou možnost?
• Známe kontakty a smluvní lhůty dodavatele?
• Umíme současně posoudit GDPR a další oznamovací povinnosti?
• Máme šablonu pro neúplné první hlášení a následné doplnění?
• Dokumentujeme nápravu, kontrolu dotčených případů a návrat do provozu?
• Je jasné, kdo schvaluje změnu, která může ovlivnit následné vyšetření?

Závěr

Nejlepší incidentní plán není ten, který slibuje, že se chyba nikdy nestane. Je to plán, který rychle oddělí další škodu od vyšetřování, uchová důkazy, zapojí správné role a umožní pravdivě rozhodnout, zda a komu incident oznámit.

Začněte jednoduchým formulářem, kontaktem, možností vypnout rizikovou funkci a exportem logů. Potom přidejte klasifikační matici, šablonu hlášení, vazbu na GDPR a pravidelný nácvik. U vysoce rizikových systémů si předem ověřte také sektorové režimy, protože jeden incident může mít více oznamovacích cest.

Potřebujete připravit incidentní postup, logování nebo bezpečné napojení AI do firemního systému? Popište nám svůj projekt. Pomůžeme vám navrhnout technické i procesní kroky tak, aby šlo systém nejen spustit, ale také bezpečně kontrolovat, omezit a obnovit. Prohlédnout si můžete také naše služby, reference a způsob spolupráce.

Ověřené zdroje a další čtení

• AI Act Service Desk: článek 3 – Definice – definice závažného incidentu v bodě 49 a dalších důležitých rolí.
• AI Act Service Desk: článek 73 – Hlášení závažných incidentů – povinnost poskytovatele, lhůty, neúplné první hlášení, vyšetření a náprava.
• Evropská komise: návrh pokynů a šablony pro hlášení závažných incidentů – praktická příprava a vztah k dalším oznamovacím režimům.
• Evropská komise: Supporting the implementation of the AI Act – pokyny a nástroje pro implementaci, včetně hlášení incidentů a monitoringu.
• GDPR, nařízení (EU) 2016/679 – zejména pravidla pro porušení zabezpečení osobních údajů.
• Nařízení Evropského parlamentu a Rady (EU) 2024/1689 – AI Act – právní základ definic, hlášení a povinností poskytovatelů a provozovatelů.

Právní informace v tomto článku odpovídají ověřeným oficiálním zdrojům dostupným k 10. srpnu 2026. Národní kontakty, formuláře, pokyny a sektorové oznamovací režimy se mohou měnit. Před podáním hlášení ověřte aktuální příslušný orgán, právní režim a konkrétní lhůtu.