En utvärdering som lades upp på arXiv den 6 juli 2026 körde 302 kvalitetsgranskade Kubernetes-incidenter genom retrieval-augmenterade modeller och betygsatte två förmågor var för sig. Att namnge tjänsten som är grundorsak: rätt mellan 91,4 % och 99,7 % av gångerna. Att välja en giltig återställningsåtgärd för incidenten den just hade diagnostiserat: 36,8 % till 60,3 %. Fyrtio till femtiofem punkter ligger mellan de två kolumnerna, och det avståndet är den mest användbara siffra som publicerats om AIOps i år.
Det är ett påstående om sorters arbete, inte om modellkvalitet. Modellen läser bra och beslutar dåligt, och det sorterar marknaden i två högar. En del driftarbete misslyckas synligt, framför personen som håller i det. En del misslyckas genom att bli en åtgärd mot produktion. AIOps tjänar sina pengar på den första sorten och är för närvarande en risk i den andra, och det mesta av besvikelsen på den här marknaden kommer av att man köpt det för den andra efter en demo av den första.
Korrelering av larm, deduplicering och den första versionen av berättelsen
PagerDuty marknadsför sin AIOps-produkt som att den skär ner larmbruset med upp till 91 %. Läs det bredvid en undersökning från februari 2026 bland 1 039 yrkesverksamma inom SRE, DevOps och IT-drift, sponsrad av NeuBird, där 44 % rapporterade ett driftstopp det senaste året kopplat till larm som undertryckts eller ignorerats. Korrelering som slår ihop fyrtio utkallningar till en incident är en verklig vinst. Korrelering som i tysthet avgör vilka utkallningar du aldrig får se är hur de 44 procenten uppstår, och det som skiljer dem åt är om grupperingen går att granska.
De starkaste fallen är de en människa kan kontrollera på några sekunder. En modell som läser deployhistoriken, mätvärdesförändringen och tre loggströmmar och skriver ett utkast till incidentberättelsen gör arbete som annars görs klockan 3 på natten av någon med dåligt minne, och när den har fel ligger bevisen i stycket den skrev. Att förklara varför en faktura rörde sig är samma sorts uppgift, full av samband en människa upptäcker en månad för sent, och FinOps Foundations State of FinOps 2026, släppt den 19 februari 2026 med 1 192 svarande som hanterar över 83 miljarder dollar i årliga utgifter, fann att 98 % av dem numera hanterar AI-utgifter, upp från 31 % två år tidigare. Att göra en avslutad incident till en skriven runbook är ännu bättre: fakta är fastställda, och det värsta utfallet är att en människa rättar en mening.
AI-kodgranskning av infrastruktur fångar en sorts misstag och är blind för en annan
Veracodes 2026 GenAI Code Security Report, publicerad den 28 juli 2026, testade över 100 modeller och fann att den genomsnittliga andelen godkända säkerhetsuppgifter stannade på 56 %, upp en punkt från 55 %. Ungefär 44 % av genereringsuppgifterna förde in en riskabel sårbarhet när ingen uttryckligen bad om säkerhet i prompten. Bäst i test, GPT-5.5, nådde 68 %, och missade fortfarande en säkerhetsuppgift av tre.
Det ojämna är det användbara. De modellerna klarade uppgifter om SQL-injektion 83 % av gångerna och kryptografi 87 %, men cross-site scripting bara 15 % och logginjektion 12 %. En AI-granskare är stark på det den har sett etiketterat tusen gånger, nästan blind i övrigt, och den talar inte om för dig vilket läge den är i. På en infrastructure-as-code-diff, använd den som en andra läsare för de misstag som är uppenbara i efterhand: säkerhetsgruppen som öppnats mot 0.0.0.0/0, ändringen som i själva verket är en ersättning och inte en uppdatering. Gör den inte till spärren: de klasser den missar är de som ingen skrev en regel för.
Autonomt åtgärdande är där bevisen slutar stödja säljsnacket
Samma studie innehåller fyndet som borde avsluta samtalet om självläkning i ytterligare ett år. Även när modellen korrekt identifierade både tjänsten som var grundorsak och feltypen valde den en ogiltig åtgärd i 39,5 % till 62,0 % av just de korrekt diagnostiserade incidenterna. Diagnos bär inte över i handling. Gartners prognos från juni 2025 om att över 40 % av projekten inom agentisk AI skulle läggas ner före utgången av 2027 nämnde otillräckliga riskkontroller vid sidan av kostnad, och det är den som saknas.
Kapacitetsplanering misslyckas av ett besläktat skäl: modellen producerar en självsäker siffra ur tunt underlag, och en självsäker siffra är precis vad ett planeringsmöte vill ha. Artikel 14 i AI-förordningen är skriven mot exakt det, och kräver att en mänsklig kontrollant kan avbryta ett högrisksystem och stoppa det i ett säkert tillstånd, och pekar ut automationsbias som det tillsynen måste stå emot.
Utgiftstaket måste sitta ovanför leverantörens faktureringskonsol
I maj 2026 fick en autonom agent obegränsade AWS-autentiseringsuppgifter och uppdraget att portskanna DN42, ett hobbynätverk. Den provisionerade fem m8g.12xlarge-instanser med 48 vCPU:er var, plus lastbalanserare och Lambda-funktioner, och fortsatte sedan applicera om samma CloudFormation-mall. Operatören fick veta det ungefär 24 timmar senare av kortdragningar på totalt 6 531,30 dollar, för en arbetsbelastning som communityt bedömde skulle rymmas på en VPS för 5 dollar i månaden. AWS sänkte senare räkningen till 1 894 dollar. Skyddet som fungerade var en goodwill-kredit.
Ingen stor leverantörs budgetverktyg hade stoppat det, och alla tre säger det i skrift. Amazon dokumenterar att AWS Budgets uppdateras upp till tre gånger om dagen, där varje uppdatering typiskt ligger 8 till 12 timmar efter den förra, en takt byggd för människor som gör dyra misstag ett i taget. Microsoft anger att ett överskridet budgettröskelvärde i Azure inte påverkar resurser eller stoppar förbrukning, och att kostnadsdata typiskt finns tillgängliga inom 8 till 24 timmar. Google Cloud anger att en budget med enbart aviseringar inte automatiskt sätter tak för användning eller utgifter. AWS levererar en Budget Controls-lösning med öppen källkod som agerar vid 90 % av en budget, täcker fyra tjänster i en region, och medger att lagring och nätverk fortsätter dra kostnader. En byrå med tre anställda, omskriven i juli 2026, drog på sig en AWS-kostnad på 14 000 dollar under en enda dag mot en normal månadsräkning på 10 till 15 dollar, efter att angripare plockat statiska nycklar från en instans och gjort av med dem på Bedrock-modellanrop.
Vårt svar är att lägga gränsen där autentiseringsuppgifterna utfärdas, inte där fakturan sätts ihop. Utgifter i Sencai spåras medan de sker, per leverantör, projekt och miljö, med tak och budgetar som larmar medan kostnaden byggs upp snarare än på en faktureringscykel på 8 till 24 timmar. Att agera automatiskt på ett överskridet tak ligger på vår färdplan och är inte levererat, så idag är det fortfarande en människa som drar in autentiseringsuppgiften. AI är den enda budget vi kan begränsa i förväg: den köps i krediter, och en kredit är ett fast belopp pengar snarare än ett antal tokens, så en prisändring på en modell flyttar hur många tokens en kredit räcker till och aldrig vad den är värd. Varje betald personlig plan har en månatlig tilldelning och ett hårt tak satt till en multipel av den, så ett skript som skenar kan inte producera en obegränsad räkning. Runbooks kräver godkännande av samma skäl: modellen föreslår, en namngiven människa utför.
Ett granskningsspår som kan säga om det var en människa eller en modell
Artikel 12(1) i AI-förordningen kräver att högrisksystem tekniskt tillåter automatisk registrering av händelser under systemets livstid, och artikel 26(6) kräver att tillhandahållare sparar de loggarna i minst sex månader om inte annan lag säger längre. Om du planerar mot ett datum i augusti 2026, korrigera det. Förordning (EU) 2026/1744, det digitala omnibuspaketet om AI, i kraft från den 27 juli 2026, flyttade fristående högrisksystem enligt bilaga III till den 2 december 2027 och produktinbyggda system enligt bilaga I till den 2 augusti 2028. Datumen flyttades; skyldigheterna gjorde det inte.
Det operativa skälet att bygga det här har inget med tidsfristen att göra. Sex månader efter en incident är frågan om det var en människa eller en modell som gjorde ändringen, och en uppsättning som registrerar AI:ns åtgärder i ett system och människans i ett annat kan inte svara på det utan en sammanslagning ingen litar på. Vi vägrade hålla två journaler: modellens åtgärder och människans hamnar i ett och samma append-only-spår. Sencai exporterar det som CSV med entry_hash och prev_hash på varje rad, så att en läsare som inte tar vårt ord för det kan räkna om kedjan. Fältet som förtjänar sin plats är det lilla bredvid aktören, som säger om ändringen kom från en människa eller från en modell som gör av med en människas tilldelning.
Regeln som faller ut ur bevisen är oglamorös och håller. Låt en modell läsa vad som helst, inklusive det den läser dåligt, för en dålig läsning syns i stycket den skrev. Låt den bara skriva där en namngiven person signerar ändringen och en gräns på autentiseringsuppgiften ligger under den, ifall den personen också har fel. Mellan en leverantörsavisering på en cykel om 8 till 24 timmar och någon som läser e-post på vardagar finns en brandvarnare och inget sprinklersystem. DN42-operatören hade en brandvarnare.