Evaluace zveřejněná na arXivu 6. července 2026 prohnala 302 kvalitativně prověřených Kubernetes incidentů modely s retrieval augmentací a hodnotila dvě schopnosti zvlášť. Pojmenovat službu, která byla příčinou: správně v 91,4 až 99,7 % případů. Vybrat platnou nápravnou akci pro incident, který právě sám diagnostikoval: 36,8 až 60,3 %. Mezi těmi dvěma sloupci leží čtyřicet až padesát pět bodů a ta vzdálenost je nejužitečnější číslo, které letos o AIOps vyšlo.
Je to tvrzení o druzích práce, ne o kvalitě modelu. Model dobře čte a špatně rozhoduje, a to rozděluje trh na dvě hromady. Část provozní práce selže viditelně, přímo před člověkem, který ji drží. Část selže tím, že se promění v akci proti produkci. AIOps si vydělá na tom prvním druhu a v tom druhém je dnes rizikem, a většina zklamání na tomhle trhu pochází z toho, že se kupuje na to druhé po demu toho prvního.
Korelace alertů, deduplikace a první verze příběhu
PagerDuty svůj AIOps produkt prodává jako snížení šumu v alertech až o 91 %. Přečtěte si to vedle průzkumu z února 2026 mezi 1 039 profesionály z SRE, DevOps a IT provozu, sponzorovaného firmou NeuBird, ve kterém 44 % uvedlo, že za poslední rok zažilo výpadek navázaný na potlačené nebo ignorované alerty. Korelace, která složí čtyřicet upozornění do jednoho incidentu, je skutečný přínos. Korelace, která potichu rozhoduje, která upozornění nikdy neuvidíte, je způsob, jak těch 44 % vzniká, a odlišuje je to, jestli jde do toho seskupení nahlédnout.
Nejsilnější případy jsou ty, které člověk zkontroluje během pár sekund. Model, který přečte historii nasazení, posun metriky a tři proudy logů a sepíše první verzi popisu incidentu, dělá práci, kterou jinak ve 3 hodiny ráno dělá někdo se špatnou pamětí - a když se splete, důkaz leží přímo v tom odstavci. Vysvětlit, proč se pohnula faktura, je úloha stejného druhu, plná korelací, kterých si člověk všimne o měsíc později, a State of FinOps 2026 od FinOps Foundation, vydaný 19. února 2026 mezi 1 192 respondenty spravujícími přes 83 miliard USD ročních výdajů, zjistil, že 98 % z nich už dnes řídí výdaje na AI, oproti 31 % o dva roky dřív. Udělat z uzavřeného incidentu napsaný runbook je ještě lepší: fakta jsou usazená a nejhorší možný výsledek je, že člověk opraví větu.
AI code review nad infrastrukturou chytá jednu třídu chyb a k jiné je slepý
Veracode GenAI Code Security Report 2026, vydaný 28. července 2026, otestoval přes 100 modelů a zjistil, že průměrná úspěšnost v bezpečnosti uvázla na 56 %, o bod výš než 55 %. Zhruba 44 % generovacích úloh zavleklo rizikovou zranitelnost ve chvíli, kdy nikdo v promptu bezpečnost výslovně nežádal. Nejlepší z nich, GPT-5.5, dosáhl 68 % a pořád neuspěl u každé třetí bezpečnostní úlohy.
Užitečná je právě ta nerovnoměrnost. Ty modely uspěly u úloh na SQL injection v 83 % případů a u kryptografie v 87 %, ale u cross-site scriptingu jen v 15 % a u log injection ve 12 %. AI recenzent je silný na to, co viděl tisíckrát oštítkované, jinde je skoro slepý a neřekne vám, ve kterém z těch dvou režimů zrovna je. Nad diffem infrastruktury jako kódu ho použijte jako druhého čtenáře na chyby, které jsou zpětně zjevné: security group otevřená na 0.0.0.0/0, změna, která je ve skutečnosti nahrazením, ne úpravou. Nedělejte z něj bránu: třídy, které míjí, jsou přesně ty, na které nikdo nenapsal pravidlo.
U autonomní nápravy přestávají důkazy podporovat prodejní řeč
Tatáž studie přináší nález, který by měl debatu o samoopravujících se systémech na další rok ukončit. I když model správně určil službu, která byla příčinou, i typ poruchy, vybral neplatnou nápravu u 39,5 až 62,0 % těch správně diagnostikovaných incidentů. Diagnóza se do akce nepřenáší. Predikce Gartneru z června 2025, že přes 40 % projektů s agentní AI bude do konce roku 2027 zrušeno, jmenovala vedle nákladů nedostatečné kontroly rizik - a tohle je přesně ta chybějící.
Kapacitní plánování selhává z příbuzného důvodu: model vyrobí sebejisté číslo z tenkých podkladů a sebejisté číslo je přesně to, co plánovací schůzka chce. Článek 14 aktu o umělé inteligenci míří přesně na tohle - vyžaduje, aby člověk vykonávající dohled mohl vysoce rizikový systém přerušit a zastavit ho v bezpečném stavu, a jmenuje automatizační zkreslení jako to, čemu má dohled odolávat.
Strop útraty musí ležet nad fakturační konzolí providera
V květnu 2026 dostal autonomní agent neomezené AWS credentials a zadání proskenovat porty na DN42, hobby síti. Naprovisionoval pět instancí m8g.12xlarge, každou se 48 vCPU, k tomu load balancery a Lambda funkce, a pak pořád dokola aplikoval tentýž CloudFormation template. Provozovatel se to dozvěděl zhruba o 24 hodin později z plateb kartou v celkové výši 6 531,30 USD - za workload, o kterém komunita usoudila, že by se vešel na VPS za 5 USD měsíčně. AWS pak fakturu snížilo na 1 894 USD. Ochranou, která zafungovala, byl kredit z dobré vůle.
Rozpočtové nástroje žádného z velkých providerů by to nezastavily a všichni tři to mají černé na bílém. Amazon dokumentuje AWS Budgets tak, že se obnovují až třikrát denně, přičemž každá aktualizace je typicky 8 až 12 hodin za tou předchozí - kadence stavěná pro lidi, kteří dělají drahé chyby po jedné. Microsoft uvádí, že překročený rozpočtový práh v Azure neovlivní zdroje ani nezastaví spotřebu, přičemž data o nákladech jsou typicky k dispozici do 8 až 24 hodin. Google Cloud uvádí, že rozpočet nastavený jen na upozornění automaticky nestropuje využití ani útratu. AWS dodává open source řešení Budget Controls, které zasáhne na 90 % rozpočtu, pokrývá čtyři služby v jednom regionu a samo přiznává, že úložiště a síť účtují dál. Tříčlenná agentura, o které se psalo v červenci 2026, dostala jednodenní účet od AWS na 14 000 USD proti běžné měsíční faktuře 10 až 15 USD poté, co útočníci stáhli z instance statické klíče a utratili je za volání modelů v Bedrocku.
Naše odpověď je dát limit tam, kde se vydávají credentials, ne tam, kde se skládá faktura. Výdaje se v Sencai sledují průběžně podle providera, projektu a prostředí, se stropy a rozpočty, které upozorňují už během narůstání, ne na fakturačním cyklu dlouhém 8 až 24 hodin. Automatický zásah při překročení stropu máme na roadmapě a není nasazený, takže dnes credential pořád vytahuje člověk. AI je jediný rozpočet, který umíme ohraničit dopředu: kupuje se v kreditech a kredit je pevná částka peněz, ne počet tokenů, takže změna ceny modelu posune, kolik tokenů za kredit dostanete, a nikdy ne to, jakou má kredit hodnotu. Každý placený osobní plán má měsíční příděl a tvrdý strop nastavený na jeho násobku, takže utržený skript nedokáže vyrobit neohraničenou fakturu. Runbooky jsou ze stejného důvodu schvalované: model navrhuje, jmenovitě určený člověk provádí.
Audit trail, který umí říct, jestli to udělal člověk, nebo model
Článek 12 odst. 1 aktu o umělé inteligenci vyžaduje, aby vysoce rizikové systémy technicky umožňovaly automatické zaznamenávání událostí po celou dobu své životnosti, a čl. 26 odst. 6 ukládá zavádějícím subjektům uchovávat ty logy nejméně šest měsíců, pokud jiný předpis nestanoví déle. Pokud máte v plánech napsané datum srpen 2026, opravte si ho. Nařízení (EU) 2026/1744, digitální omnibus k umělé inteligenci, účinné od 27. července 2026, odsunulo samostatné vysoce rizikové systémy z přílohy III na 2. prosince 2027 a systémy vestavěné do výrobků podle přílohy I na 2. srpna 2028. Posunula se data, ne povinnosti.
Provozní důvod, proč tohle stavět, nemá s termínem nic společného. Půl roku po incidentu je otázka, jestli tu změnu udělal člověk, nebo model, a řešení, které zapisuje akce AI do jednoho systému a lidské do jiného, na to neodpoví bez joinu, kterému nikdo nevěří. Odmítli jsme vést dva záznamy: akce modelů i akce lidí přistávají v jednom append-only trailu. Sencai ho exportuje jako CSV s entry_hash a prev_hash na každém řádku, takže čtenář, který nám to nebere na slovo, si řetěz přepočítá sám. Pole, které si tam své místo zaslouží, je to malé vedle actora - říká, jestli změna přišla od člověka, nebo od modelu utrácejícího příděl konkrétního člověka.
Pravidlo, které z těch důkazů vypadne, není nijak efektní a drží. Nechte model číst cokoliv, včetně věcí, které čte špatně, protože špatné čtení je vidět v odstavci, který napsal. Zapisovat ho nechte jen tam, kde změnu podepíše jmenovitě určený člověk a pod tím leží limit na credentialu pro případ, že se mýlí i on. Mezi upozorněním providera na cyklu 8 až 24 hodin a někým, kdo čte e-maily v pracovní dny, je hlásič kouře a žádné sprinklery. Provozovatel DN42 měl hlásič kouře.