Španělský dozorový úřad pro ochranu osobních údajů dostal první ohlášení incidentu, který podle postižené organizace provedl agent postavený na běžném jazykovém modelu. Titulky z toho po Evropě udělaly „AI provedla kybernetický útok". V samotném textu úřadu je ale jedna věta, která je pro vaši firmu důležitější než celý ten příběh: agent se do systému přihlásil správně. Zranitelnost začal hledat až potom — uvnitř.
Co se stalo
- Kdo a kdy: Španělská Agencia Española de Protección de Datos (AEPD, obdoba našeho ÚOOÚ) zveřejnila 14. září 2026 na svém blogu text Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA. Autorem je Francisco Pérez Bes. Všechna tvrzení a citace níže beru z tohoto textu úřadu, ne z převzatých článků.
- Co úřad dostal: první ohlášení porušení zabezpečení osobních údajů, u něhož měl být incident „proveden prostřednictvím agenta umělé inteligence, který použil známý jazykový model" (un agente de inteligencia artificial que utilizó un conocido modelo de lenguaje).
- Průběh podle úřadu — a tady je ten detail: „Útočící agent začal hledáním zranitelností v obecných souborech a provedl správné přihlášení. Jakmile se dostal do systému, začal samostatně hledat zranitelnosti v aplikaci, což mu po úspěchu umožnilo pozměnit osobní údaje a získat přístup k fakturám." Vstup do systému tedy nebyl prolomením zabezpečení — bylo to funkční přihlášení. Autonomní část přišla až za ním.
- Co úřad výslovně netvrdí: AEPD před jakýmkoli závěrem upozorňuje, že dostupné informace „pocházejí z ohlášení podaného postiženou organizací a budou muset být předmětem odpovídající analýzy". A dodává varování, které v převzatých článcích většinou chybí: použití konkrétního modelu AI „neznamená, že model nebo infrastruktura jeho poskytovatele byly kompromitovány, ani že nástroj byl navržen k provádění škodlivé činnosti".
- Ani úřad z toho nedělá trend: „Toto první ohlášení neumožňuje tvrdit, že jde o statistický trend" — je to podle AEPD ale významný signál, že útoky opřené o AI „přestaly být teoretickým rizikem a začínají se projevovat v incidentech, které se dotýkají reálného zpracování osobních údajů".
- Co v textu není: AEPD neuvádí jméno organizace, neuvádí, který model to byl, ani počet dotčených osob či záznamů. Kdo v článcích jinde viděl konkrétní firmu nebo konkrétní model, viděl dohad, ne zdroj.
- Druhý primární dokument: AEPD odkazuje na příručku španělského Národního kryptologického centra (CCN, součást zpravodajské služby CNI) CCN-CERT BP/36 Buenas prácticas frente al modelo de IA ofensiva, publikovanou 23. června 2026. Ta konstatuje, že ofenzivní AI „přestala být vznikající hrozbou a stala se operační schopností integrovanou do reálných kampaní" kriminálních i státních aktérů. Doporučení uzavírá desatero: posílit základní kontroly, zrychlit správu zranitelností, zabezpečit identity a přístupy, řídit používání AI, chránit dodavatelský řetězec a udržet lidský dohled nad automatizací.
- Jedna věta, která stojí za zapamatování: AEPD píše, že „AI nevytváří nové hrozby. Zvyšuje ale rychlost, rozsah a schopnost adaptace už známých škodlivých technik a zkracuje čas, který máte na jejich odhalení a zastavení."
Proč se to týká i vás
Španělský případ není zajímavý tím, že „AI útočí". Je zajímavý tím, že ho někdo musel ohlásit dozorovému úřadu — a že stejná povinnost platí i pro vás, se stejnými lhůtami a stejnou dokumentací. U nás to vede k ÚOOÚ.
- Vstupem bylo přihlášení, ne průlom. To je pro obranu dobrá i zlá zpráva zároveň. Dobrá: nemusíte se bát exotické AI zranitelnosti, tohle zastavíte běžnými věcmi — dvoufaktorem, omezením oprávnění, hlídáním přihlášení z neobvyklých míst. Zlá: pokud vám někde leží funkční heslo, API klíč nebo servisní účet s širšími právy, než potřebuje, je útok „s AI" jen rychlejší verze toho, co u vás šlo i dosud. AEPD to říká napřímo: agent, který získá účet, API klíč nebo token s nadbytečnými oprávněními, „může operovat rychlostí stroje a dostat se k různým službám dřív, než organizace zaznamená anomální chování".
- Obecná zmínka o „malwaru a phishingu" v analýze rizik už nestačí. První bod, který AEPD z případu vyvozuje, je povinnost výslovně zahrnout útoky prováděné nebo podpořené AI do analýz rizik zpracování. Cituji: „nestačí zahrnout obecný odkaz na malware, phishing nebo neoprávněný přístup, protože tato automatizace může podstatně změnit pravděpodobnost, rychlost a rozsah incidentu." Pokud máte analýzu rizik nebo DPIA napsanou před dvěma lety, právě jste dostali konkrétní důvod ji otevřít — a konkrétní citaci od dozorového úřadu, kterou do ní můžete napsat.
- Vaše postupy reakce jsou navržené na člověka. Druhý bod AEPD: postupy pro ručně prováděné útoky „mohou být nedostatečné, když agent analyzuje současně více aktiv, zkouší různé cesty přístupu a rychle mění své chování". Když váš plán incidentu předpokládá, že ráno někdo zkontroluje logy, počítáte s útočníkem, který si dá pauzu na spaní.
- Lhůta se nepočítá od útoku, ale od okamžiku, kdy se to dozvíte. Podle návodu ÚOOÚ Porušení zabezpečení osobních údajů ohlašuje správce případ bez zbytečného odkladu, „pokud možno do 72 hodin od okamžiku, kdy se o něm dověděl"; při pozdějším ohlášení musí zároveň uvést důvody zpoždění. To je citlivé právě u agentního útoku — čím později si ho všimnete, tím víc toho musíte v ohlášení vysvětlovat.
- Dokumentovat musíte i to, co nehlásíte. Tentýž návod ÚOOÚ: veškeré případy porušení zabezpečení „(tj. i ty, které nepodléhají povinnosti ohlášení) včetně přijatých nápravných opatření je však správce povinen dokumentovat". Firmy tenhle řádek pravidelně přehlížejí — a je to přitom ta část, kterou úřad umí zkontrolovat kdykoli, bez incidentu.
- Posuzuje se i to, co jste udělali předem. ÚOOÚ v návodu píše, že pro posouzení ohlášení a další postup je „stěžejní, zdali a jaká opatření k zabezpečení osobních údajů správce přijal před vznikem incidentu". Jinými slovy: výsledek řízení se neláme na tom, jak jste incident popsali, ale na tom, co jste měli nasazené, než přišel.
Co s tím
Nic z následujícího nevyžaduje nový nástroj ani rozpočet. Je to práce na jedno až dvě odpoledne.
- 1. Projděte účty, které nepatří člověku. Servisní účty, API klíče, CI tokeny, integrace, které kdysi někdo nastavil. U každého odpovězte na dvě otázky: potřebuje tohle oprávnění, které má? A poznáme, když se přihlásí odjinud než obvykle? Tohle je přesně ta vrstva, kterou španělský agent použil ke vstupu.
- 2. Dopište do analýzy rizik jeden odstavec o AI útocích. Ne obecně, ale podle vodítka AEPD: u kterých zpracování by automatizovaný útočník výrazně zkrátil čas na reakci, a co konkrétně by tam stihl udělat. Odkaz na blog AEPD si k tomu přiložte — dozorové úřady mezi sebou čtou a argument „změnila se povaha hrozby" je teď doložitelný.
- 3. Zjistěte, za jak dlouho byste si to všimli. Ne kolik máte nástrojů, ale jedno číslo: kolik hodin uplyne mezi podezřelým přihlášením a tím, než na něj někdo kouká. Pokud je odpověď „až když si někdo stěžuje", 72hodinová lhůta je pro vás teoretická.
- 4. Připravte ohlášení dřív, než ho budete potřebovat. ÚOOÚ vyžaduje popis povahy případu včetně kategorií a přibližného počtu dotčených osob a záznamů, kontakt na pověřence nebo jiné kontaktní místo, popis pravděpodobných důsledků a popis přijatých opatření. Sepsat si tuhle strukturu předem do jednoho dokumentu s vyplněnými kontakty zabere půl hodiny v klidu — a v krizi to jsou hodiny, které nemáte.
- 5. Založte si evidenci i pro drobnosti. Jeden sdílený soubor, kam jde datum, co se stalo, co jste udělali a proč to (ne)bylo ohlášeno. Splníte tím dokumentační povinnost a zároveň si po půl roce sami uvidíte, kde vám to teče opakovaně.
A teď proti vlastnímu byznysu: jestli je vaše firma malá, osobní údaje zpracovává v jednom účetním systému a v e-mailu, a žádného vlastního AI agenta nikde nemáte, pak z tohoto případu neplyne, že potřebujete AI governance. Plyne z něj, že potřebujete dvoufaktor a úklid v oprávněních — a to není projekt, to je odpoledne s IT. Pořadí je důležité: agentní útok se zastavuje na základních kontrolách, ne na dokumentu o AI. Kdo si koupí audit AI a nechá si přitom sdílený admin účet bez druhého faktoru, zaplatil za špatnou věc.
Kde to řeším s klienty
U firem, kde už agenti pracují s reálnými systémy, je tohle v rámci AI Agent Governance Checkupu první blok: jaké neosobní účty existují, co s nimi jde udělat, za jak dlouho se pozná neobvyklé přihlášení a jak vypadá cesta od zjištění k ohlášení na ÚOOÚ. Když si nejste jistí, jestli se vás to vůbec týká, začněte AI Risk Scanem zdarma — u části firem z něj vyjde, že audit nepotřebují. Na tohle téma tu píšu opakovaně: viz dřívější text o tom, jak útočník použil agenty jako sběrače klíčů, a rozbor hlášení zneužité zranitelnosti do 24 hodin. Vzorec je pořád stejný: oprávnění, o kterém si někdo myslel, že je dočasné, a lhůta, která běží dřív, než si jí kdokoli všimne.