Máte na ohlášení incidentu 24 nebo 72 hodin. Lhůta ale nezačíná v okamžiku incidentu — začíná ve chvíli, kdy se o něm dozvíte. A pokud se stal u vašeho dodavatele AI, dozvíte se to tehdy, kdy vám to řekne on. Otevřel jsem si proto smlouvy tří největších poskytovatelů a hledal, jaké číslo v nich stojí. U jednoho jediného tam nějaké je.
Co v těch smlouvách doopravdy stojí
Zpracovatelské smlouvy (DPA) jsou veřejné, nemusíte být zákazník, abyste si je přečetli. Tady je přesné znění těch pasáží, na kterých vám v krizi bude záležet.
- OpenAI — žádná hodina. OpenAI Data Processing Addendum s účinností od 1. ledna 2026 říká v článku 2.7 doslova: „OpenAI will notify Customer without undue delay after becoming aware of any Personal Data Breach." Bez zbytečného odkladu. Žádných 24, 48 ani 72 hodin. Co „undue delay" znamená v praxi, je věc výkladu — a v tomhle případě výkladu druhé strany.
- Anthropic — 48 hodin, jako jediný. Anthropic DPA, článek G.1: „Anthropic will notify Customer in writing without undue delay, but in any event within 48 hours, after becoming aware of any Security Breach." Tohle je jediné tvrdé číslo, které jsem ve smlouvách velké trojky našel.
- Google Cloud — taky bez čísla. Cloud Data Processing Addendum, článek 7.2.1 (Incident Notification): „Google will notify Customer promptly and without undue delay after becoming aware of a Data Incident." Opět žádná lhůta v hodinách. Google k tomu v 7.2.2 aspoň vyjmenovává, co oznámení bude obsahovat, a připouští, že první oznámení může být neúplné.
Shrnuto: dva ze tří největších dodavatelů AI vám smluvně negarantují žádnou konkrétní lhůtu. Třetí vám garantuje 48 hodin. Zapamatujte si to číslo, za chvíli ho budeme porovnávat.
Proti tomu stojí vaše lhůty — a ty čísla mají
Tady je asymetrie, kvůli které tenhle článek píšu.
GDPR: 72 hodin. Článek 33 odst. 1 ukládá správci ohlásit porušení zabezpečení dozorovému úřadu „bez zbytečného odkladu a pokud možno do 72 hodin od okamžiku, kdy se o něm dozvěděl". Úřad pro ochranu osobních údajů to na své stránce k porušení zabezpečení osobních údajů formuluje stejně a dodává praktickou věc, která se často přehlíží: „Pokud není ohlášení Úřadu učiněno do 72 hodin, musí být současně s ním uvedeny důvody tohoto zpoždění." Zpoždění se tedy nepromíjí, jen se vysvětluje — písemně, úřadu.
Kyberbezpečnost: 24 hodin. Zákon č. 264/2025 Sb. o kybernetické bezpečnosti, účinný od 1. listopadu 2025, v § 16 odst. 1 ukládá poskytovateli regulované služby předložit prvotní hlášení „bez zbytečného odkladu, nejpozději do 24 hodin po zjištění kybernetického bezpečnostního incidentu". Do 72 hodin pak navazuje oznámení s prvotním posouzením a indikátory kompromitace (§ 16 odst. 3 písm. a), do 30 dnů závěrečná zpráva (písm. c). Netýká se to každé firmy — jen poskytovatelů registrovaných regulovaných služeb podle § 3 a násl.
AI Act: 15 dnů, ale i dva. Článek 73 odst. 2 ukládá poskytovateli vysoce rizikového systému hlásit závažný incident „immediately after the provider has established a causal link… and, in any event, not later than 15 days". U rozsáhlého porušení je to podle odst. 3 nejpozději dva dny, při úmrtí osoby podle odst. 4 deset dnů.
Teď to porovnejte. Anthropic — ten nejlepší z trojice — vám smluvně slibuje 48 hodin. To je dvě třetiny vaší celé sedmdesátidvouhodinové lhůty podle GDPR spotřebované dřív, než se vůbec dozvíte, že se něco stalo. A pokud jste regulovaný subjekt s 24hodinovou lhůtou podle § 16, je vaše lhůta po smluvně dovoleném oznámení prošlá už o den. U OpenAI a Googlu se to nedá spočítat vůbec, protože tam žádné číslo není.
Co jsem si ověřil sám
Ověřoval jsem hlavně dvě věci a obě mají háček, který se v diskusích nad tímhle tématem ztrácí.
První: ty smluvní lhůty se vztahují jen na úzce vymezenou situaci. Přečtěte si definice. OpenAI definuje „Personal Data Breach" jako narušení bezpečnosti vedoucí k neoprávněnému přístupu k Customer Data, tedy k datům, která jste tam nahráli vy. Anthropicův „Security Breach" je narušení Anthropic's security týkající se Customer Personal Data. Google definuje „Data Incident" jako narušení bezpečnosti Googlu u Customer Data „on systems managed by or otherwise controlled by Google". Všechny tři definice pokrývají jeden scénář: u dodavatele se něco stalo a týká se to vašich dat.
Druhý a horší: scénář, který jsme viděli v Austrálii, pod žádnou z těch definic nespadá. V australském případu z tohoto týdne se agent OpenAI dostal do vládního portálu s Medicare statistikami. Services Australia ale nebyla zákazníkem OpenAI. Nešlo o „Customer Data", nešlo o narušení bezpečnosti OpenAI — šlo o to, že model při běžném výzkumném dotazu obešel blokace na cizím systému. Poškozený subjekt tedy neměl žádnou smluvní lhůtu, o kterou by se mohl opřít, protože neměl s dodavatelem vůbec žádnou smlouvu. Oznámení nakonec přišlo e-mailem na veřejnou schránku pro hlášení zranitelností, skoro tři měsíce po incidentu. Žádný článek DPA tam porušen nebyl. Nebylo co porušit.
To je podle mě z celé věci nejdůležitější poznatek a v ranních shrnutích ho nenajdete: smluvní lhůty na hlášení chrání zákazníka dodavatele, ne oběť jeho modelu. A vy můžete být v obou rolích najednou.
Proč se to týká i vás
Česká firma, která má ChatGPT Enterprise nebo Claude v týmu, si z toho odnese tři věci.
Regulátor se neptá vašeho dodavatele. Ptá se vás. Podle GDPR jste správce, dodavatel je zpracovatel — a čl. 33 odst. 2 ukládá zpracovateli jen to, že vás uvědomí „bez zbytečného odkladu". Vaše 72hodinová lhůta vůči ÚOOÚ běží nezávisle na tom, jak rychle to dodavatel stihl. Když ji zmeškáte, vysvětlujete to vy.
„Bez zbytečného odkladu" se dá zjistit dopředu, ale jen otázkou. Žádná z těch tří smluv neříká, jak dlouhé zpoždění dodavatel považuje za přiměřené. Je to legitimní otázka do obchodního jednání a odpověď na ni si dejte písemně. Anthropic ukazuje, že napsat do smlouvy konkrétní číslo je možné — takže argument „to se nedá" neobstojí.
Kontrola není jen o smlouvě. Ať už máte v DPA cokoli, lhůta vám začíná běžet „od zjištění". Když incident zaznamenáte ve vlastních logách dřív, než vám přijde e-mail od dodavatele, máte plnou lhůtu k dispozici. To je jediná část celé rovnice, kterou skutečně ovládáte.
Co s tím
- 1. Najděte si v DPA svého dodavatele ten jeden odstavec. Hledejte „Personal Data Breach", „Security Breach" nebo „Data Incident". Zabere to deset minut a zjistíte, jestli tam nějaké číslo je. Pokud ne, vězte, že ho nemáte.
- 2. Spočítejte si rozdíl. Vaše zákonná lhůta minus lhůta dodavatele = čas, který vám reálně zbyde na posouzení, sepsání a odeslání hlášení. U regulovaného subjektu s 24hodinovou lhůtou podle § 16 zákona 264/2025 Sb. vyjde záporné číslo i u toho nejlepšího dodavatele. To je informace pro vedení, ne pro IT.
- 3. U nové smlouvy o lhůtu požádejte. Existující znění Anthropicu je použitelný precedens: 48 hodin, písemně, „in any event". Není to nic exotického.
- 4. Ověřte, kam by oznámení přišlo. Všechny tři smlouvy počítají s tím, že vás dodavatel uvědomí — typicky na kontaktní adresu v účtu. Zjistěte, čí je to adresa, jestli ten člověk pořád ve firmě pracuje a co se s takovým e-mailem stane v pátek večer. Australský případ ztroskotal přesně na tomhle: oznámení leželo pět dní ve schránce, kterou někdo otevírá jednou denně.
A teď proti vlastnímu byznysu: jestli používáte ChatGPT nebo Claude v běžné placené verzi a neposíláte do nich osobní údaje svých zákazníků, tohle pro vás není úkol. Čtení DPA má smysl tehdy, když do nástroje teče něco, za co ručíte. A pokud nejste poskytovatelem regulované služby ani vysoce rizikového AI systému, ty 24hodinové a patnáctidenní lhůty se na vás nevztahují vůbec — nenechte si je prodat jako hrozbu. Kdokoli vám tenhle měsíc nabídne „revizi AI smluv" bez toho, aby se nejdřív zeptal, jaká data do těch nástrojů posíláte, prodává strach, ne službu.
Kde to řeším s klienty
Kde to naopak smysl dává, je firma, která dala AI nástrojům přístup k datům zákazníků nebo k interním systémům — tam je potřeba mít sepsané, kdo drží hlásicí lhůtu, odkud se o incidentu dozvíte a co dodavatel ve smlouvě skutečně slíbil. To je obsah AI Agent Governance Checkupu; začít se dá AI Risk Scanem zdarma. K hlásicím lhůtám jsem tu psal dřív u 24hodinové povinnosti podle Cyber Resilience Actu, k tomu, co ve smlouvách dodavatelů znamenají slova jinak než laicky, u „zero data retention", které neznamená nulu.