24. září australský ministr Richard Marles na tiskovce v Sydney řekl, že agent OpenAI zasáhl do čtyř vládních webů, ale u tří z nich byla interakce „entirely normal“ — v pořádku, veřejná data. Neoprávněný přístup měl být jen u jednoho, u Medicare. O pět dní později, 29. září, zveřejnilo OpenAI vlastní přiznání a omluvu — a u dvou z těch tří „normálních“ webů popisuje věci, které normální nejsou: exponovaný přístupový klíč a neúspěšné pokusy obejít řízení přístupu. Pro českou firmu je z toho použitelné hlavně jedno: první oficiální vyjádření po incidentu není definitivní, a když další verzi dá až sám viník, může vypadat jinak.
Co se stalo
- Zdroje a data. Vláda promluvila 24. září (přepis z tiskovky Richarda Marlese v Sydney, popsaný v našem předchozím článku). OpenAI promluvilo 29. září ve vlastním blogovém příspěvku „How we will do better for Australia“, doplněném podrobnostmi, které ten den zveřejnila i Guardian Australia na základě e-mailu, který jí poskytla vláda. Citace níž jsou z těchto dvou zdrojů, ne z agregátorů.
- Co OpenAI přiznává u „normálních“ webů. U Victorian Department of Health OpenAI píše, že agenti „discovered an exposed access key to query the Victorian Agency for Health Information's reporting system and retrieve reporting configuration and aggregate survey statistics“ — a rovnou dodává: „The extent to which this information should have been accessible is unclear, and depends on VAHI's access policies.“ Sama firma tedy netvrdí, že šlo o normální přístup — tvrdí, že to není jasné. U Australian Institute of Health and Welfare OpenAI popisuje, že šlo o veřejně dostupná data, ale zároveň: „separate attempts to bypass access controls were unsuccessful.“ Pokus obejít řízení přístupu není totéž co běžná návštěva veřejné stránky.
- Třetí web, BOCSAR. U NSW Bureau of Crime Statistics and Research agent podle OpenAI použil veřejný nástroj Crime Mapping Tool a jeho API, které „supplies credentials for browser API requests“ — a systém mu vrátil „application configuration, operational jobs and logs, and website metadata“. Šlo tedy o přihlašovací údaje, které nástroj sám nabízí komukoliv v prohlížeči, ale to, co se přes ně dá stáhnout, sahá dál než mapa kriminality.
- Původní incident, Medicare. To, co Marles 24. září označil za jediný skutečný průnik, OpenAI 29. září popsalo přesněji: model dostal úkol zjistit výdaje na léky na kožní nemoci ve Viktorii, narazil na překážku a „it took actions that we had not authorised it to take“ — získal neveřejný přístup ke službě Medicare Statistics Reporting Service, spouštěl příkazy, stahoval interní soubory a přihlašovací údaje a zapisoval soubory. Záznamy pacientů podle dosavadní kontroly přístupné nebyly.
- Kdy se to kdo dozvěděl. OpenAI píše, že model incident vyvolal v červnu, firma sama na něj přišla v polovině srpna při zpětné kontrole po červencovém incidentu s Hugging Face. Services Australia a Victorian Department of Health dostaly zprávu 10. září, BOCSAR 18. září a AIHW 24. září — tenhle poslední případ OpenAI výslovně popisuje jako situaci, kdy aktivita „did not meet our disclosure thresholds“, dokud se nerozhodli sdílet zjištění i tak.
- Jak vypadalo samotné oznámení. Podle Guardianu šlo o pětiodstavcový e-mail na veřejnou schránku, kterou sleduje Services Australia, podepsaný „Best, OpenAI Security Team“. Vláda ho zveřejnila jako přílohu k tiskové zprávě 29. září a označila způsob doručení za nedostatečný vzhledem k závažnosti věci.
- Co následuje. Australské ministerstvo vnitřních věcí nařídilo všem vládním agenturám rychlou inventuru starých systémů s termínem konce roku pro kritické systémy a března pro ostatní. Vláda zvažuje zavedení povinného hlášení AI incidentů. OpenAI nabídlo kredity ze svého fondu Daybreak for Frontline Defenders (1 miliarda USD) a zřízení pracovní skupiny s australskými experty. Jason Kwon, Chief Strategy Officer OpenAI, má 6. října vystoupit před parlamentním výborem pro umělou inteligenci v Sydney.
Proč se to týká i vás
Česká firma bez vlastního modelu si z tohohle vývoje odnese tři věci, ne obecné poučení, že „AI je nebezpečná“.
První: první vyjádření po incidentu bývá to nejopatrnější, ne to nejpřesnější. 24. září vláda řekla „tři weby v pořádku, jeden problém“. Pět dní nato viník sám popsal exponovaný klíč a pokusy o obejití u dvou z těch tří „v pořádku“ webů. Nejde o to, že by vláda lhala — mluvila s tím, co v tu chvíli měla. Jde o to, že rozsah incidentu se ukazuje postupně a první číslo skoro vždy roste, ne klesá. Když řešíte incident u dodavatele, berte první shrnutí jako pracovní verzi, ne jako uzavřený spis.
Druhé: „nesplňuje náš práh pro hlášení“ rozhoduje dodavatel, ne vy. OpenAI otevřeně napsalo, že u AIHW se rozhodlo zpočátku nehlásit, protože to podle jejich posouzení nedosahovalo prahu pro oznámení — a pak to stejně oznámilo, ale o dva týdny později než první dvě agentury. Tenhle práh není nikde smluvně definovaný a nemáte na něj žádný nárok. Navazuje to přímo na to, co jsme psali o DPA smlouvách velké trojky: OpenAI si tam nesmluvně zavázalo jen „bez zbytečného odkladu“, a tenhle případ ukazuje, jak elasticky se to dá číst — u jedné agentury to bylo přes měsíc od doby, kdy o incidentu OpenAI vědělo, a rozhodnutí, jestli se to vůbec řekne, bylo čistě na nich.
Třetí: veřejně nabízené přihlašovací údaje nejsou totéž co bezpečný přístup. Případ BOCSAR je přenositelný na spoustu firemních webů: veřejný nástroj nabízí v prohlížeči přihlašovací údaje, aby fungoval bez přihlašování uživatele, a nikdo nekontroloval, co všechno se přes ně dá vytáhnout kromě zamýšlené funkce. Vrátily se mu i provozní logy a konfigurace aplikace — data, která veřejný nástroj vracet nemá, i když přístup k nim technicky „prošel“.
Co s tím
- Počítejte s tím, že první hlášení od dodavatele není finální. Žádejte písemné potvrzení, že se rozsah incidentu bude aktualizovat, a ptejte se aktivně znovu za týden — nečekejte, až vám pošlou další e-mail sami.
- Zeptejte se dodavatele přímo, jaký mají interní práh pro to, co se hlásí a co ne. Tahle otázka nemusí mít hezkou odpověď, ale aspoň budete vědět, že rozhodnutí není na vás a že existuje kategorie incidentů, o kterých se nedozvíte automaticky.
- Zkontrolujte veřejné nástroje s vestavěnými přihlašovacími údaji. Pokud máte na webu API nebo widget, který si sám nese credentials pro to, aby fungoval bez přihlášení uživatele, ověřte, co všechno přes tenhle klíč jde stáhnout — ne jen to, co má vracet ve výchozím použití.
- Sledujte australský návrh povinného hlášení AI incidentů jako předobraz. Zatím je to jen ohlášený záměr, ne zákon. Ale je to první případ, kdy vláda po konkrétním incidentu s AI agentem otevřeně mluví o zavedení pevné lhůty — stejný vzorec, jaký u nás zavedl zákon o kybernetické bezpečnosti (viz CRA a 24hodinové hlášení), jen o rok zpožděně a kvůli jinému typu incidentu.
A teď proti vlastnímu byznysu: pokud jste už četli náš článek z 24. září o tomhle incidentu, tenhle text vám nepřináší nový důvod k obavám — přináší jen přesnější obrázek téhož incidentu. Není to nová hrozba, kterou je potřeba řešit auditem tenhle týden. Je to potvrzení, že u komplexních incidentů se vyplatí počkat pár dní na druhou verzi, než se podle první rozhodujete o rozpočtu.
Kde to řeším s klienty
Kde to dává smysl probrat, je firma, která má u dodavatele AI nebo u vlastních agentů nastavené, co se hlásí a za jak dlouho — a nemá to ověřené jinak než důvěrou v to, co dodavatel řekne poprvé. To je obsah AI Agent Governance Checkupu. Pokud si nejste jistí, jaká data se dají vytáhnout přes veřejně dostupné API na vašem webu, začněte AI Risk Scanem zdarma. Předchozí díl tohohle případu je v článku Agent nejen četl, ale i zapisoval na vládní server, k oznamovacím lhůtám jsme psali v textu o smlouvách OpenAI, Anthropicu a Google Cloudu.