En evaluering lagt ut på arXiv 6. juli 2026 kjørte 302 kvalitetsreviderte Kubernetes-hendelser gjennom retrieval-augmenterte modeller og målte to evner hver for seg. Å navngi tjenesten som er rotårsak: riktig mellom 91,4 % og 99,7 % av gangene. Å velge en gyldig gjenopprettingshandling for hendelsen den nettopp hadde diagnostisert: 36,8 % til 60,3 %. Førti til femtifem poeng ligger mellom de to kolonnene, og den avstanden er det mest nyttige tallet som er publisert om AIOps i år.
Det er en påstand om typer arbeid, ikke om modellkvalitet. Modellen leser godt og bestemmer dårlig, og det sorterer markedet i to hauger. Noe driftsarbeid feiler synlig, rett foran den som holder i det. Noe feiler ved å bli til en handling mot produksjon. AIOps tjener inn pengene sine på den første typen og er foreløpig en risiko på den andre, og det meste av skuffelsen i dette markedet kommer av å kjøpe det til den andre etter en demo av den første.
Varselkorrelering, deduplisering og første utkast til historien
PagerDuty markedsfører AIOps-produktet sitt som noe som kutter varselstøy med opptil 91 %. Les det ved siden av en undersøkelse fra februar 2026 blant 1 039 fagfolk innen SRE, DevOps og IT-drift, finansiert av NeuBird, der 44 % rapporterte et avbrudd det siste året knyttet til undertrykte eller ignorerte varsler. Korrelering som folder førti utkall sammen til én hendelse er en reell gevinst. Korrelering som stille bestemmer hvilke utkall du aldri ser, er slik de 44 % oppstår, og det som skiller dem er om grupperingen kan inspiseres.
De sterkeste tilfellene er de et menneske kan sjekke på sekunder. En modell som leser deploy-historikken, metrikkendringen og tre loggstrømmer og skriver utkastet til hendelsesfortellingen, gjør arbeid som ellers gjøres klokken 3 om natten av noen med dårlig hukommelse, og når den tar feil, ligger beviset i avsnittet den skrev. Å forklare hvorfor en regning har flyttet på seg er den samme typen oppgave, full av sammenhenger et menneske ser en måned for sent, og FinOps Foundations State of FinOps 2026, sluppet 19. februar 2026 med 1 192 respondenter som forvalter over 83 milliarder dollar i årlig forbruk, fant at 98 % av dem nå styrer KI-forbruk, opp fra 31 % to år tidligere. Å gjøre en lukket hendelse om til en skrevet runbook er enda bedre: fakta er avklart, og det verste utfallet er at et menneske retter en setning.
KI-kodegjennomgang på infrastruktur fanger én type feil og er blind for en annen
Veracodes 2026 GenAI Code Security Report, publisert 28. juli 2026, testet mer enn 100 modeller og fant at gjennomsnittlig andel beståtte sikkerhetsoppgaver hadde stanset på 56 %, opp ett poeng fra 55 %. Rundt 44 % av genereringsoppgavene introduserte en risikabel sårbarhet når ingen ba spesifikt om sikkerhet. Den beste, GPT-5.5, nådde 68 %, og feilet fortsatt på én sikkerhetsoppgave av tre.
Den ujevne delen er den nyttige delen. De modellene besto oppgaver om SQL-injeksjon 83 % av gangene og kryptografi 87 %, men cross-site scripting bare 15 % og logginjeksjon 12 %. En KI som går gjennom kode er sterk på det den har sett merket tusen ganger, nesten blind ellers, og den vil ikke fortelle deg hvilken modus den er i. På en diff av infrastruktur som kode bruker du den som andreleser for feilene som er åpenbare i etterpåklokskap: sikkerhetsgruppen åpnet mot 0.0.0.0/0, endringen som er en utskifting fremfor en oppdatering. Ikke gjør den til porten: klassene den bommer på er de ingen skrev en regel for.
Autonom utbedring er der bevisene slutter å støtte salgsargumentet
Den samme studien inneholder funnet som burde avslutte samtalen om selvhelbredende systemer for enda et år. Selv når modellen korrekt identifiserte både tjenesten som var rotårsak og feiltypen, valgte den en ugyldig utbedring i 39,5 % til 62,0 % av de korrekt diagnostiserte hendelsene. Diagnose bærer ikke over i handling. Gartners spådom fra juni 2025 om at over 40 % av agentiske KI-prosjekter ville bli avlyst innen utgangen av 2027, pekte på utilstrekkelige risikokontroller ved siden av kostnad, og det er den som mangler.
Kapasitetsplanlegging feiler av en beslektet grunn: modellen produserer et selvsikkert tall fra tynt grunnlag, og et selvsikkert tall er nettopp det et planleggingsmøte vil ha. Artikkel 14 i KI-forordningen er skrevet mot akkurat det, og krever at en menneskelig tilsynsperson kan avbryte et høyrisikosystem og stanse det i en trygg tilstand, og peker ut automatiseringsskjevhet som det tilsynet må stå imot.
Forbrukstaket må ligge over leverandørens faktureringskonsoll
I mai 2026 fikk en autonom agent ubegrensede AWS-credentials og beskjed om å portskanne DN42, et hobbynettverk. Den provisjonerte fem m8g.12xlarge-instanser med 48 vCPU-er hver, pluss lastbalanserere og Lambda-funksjoner, og fortsatte deretter å kjøre den samme CloudFormation-malen på nytt. Operatøren fant det ut omtrent 24 timer senere gjennom kortbelastninger på til sammen 6 531,30 dollar, for en arbeidslast fellesskapet regnet med ville få plass på en VPS til 5 dollar i måneden. AWS satte senere regningen ned til 1 894 dollar. Beskyttelsen som fungerte var en kreditt gitt av velvilje.
Ingen stor leverandørs budsjettverktøy ville stoppet det, og alle tre sier det skriftlig. Amazon dokumenterer at AWS Budgets oppdateres opptil tre ganger om dagen, der hver oppdatering typisk ligger 8 til 12 timer bak den forrige, en takt bygget for mennesker som gjør dyre feil én om gangen. Microsoft opplyser at en overskredet budsjetterskel i Azure ikke påvirker ressurser eller stopper forbruk, med kostnadsdata typisk tilgjengelig innen 8 til 24 timer. Google Cloud opplyser at et budsjett som bare varsler, ikke automatisk setter tak på bruk eller forbruk. AWS leverer en løsning med åpen kildekode, Budget Controls, som slår inn ved 90 % av et budsjett, dekker fire tjenester i én region, og innrømmer at lagring og nettverk fortsetter å påløpe kostnader. Et byrå med tre ansatte, omtalt i juli 2026, fikk en AWS-belastning på 14 000 dollar på én dag mot en normal månedsregning på 10 til 15 dollar etter at angripere hentet statiske nøkler fra en instans og brukte dem på Bedrock-modellkall.
Vårt svar er å legge grensen der credentials utstedes, ikke der fakturaen settes sammen. Forbruk i Sencai spores mens det skjer, per leverandør, prosjekt og miljø, med tak og budsjetter som varsler mens det påløper fremfor på en faktureringssyklus på 8 til 24 timer. Å handle automatisk på et brutt tak står på veikartet vårt og er ikke levert, så i dag er det fortsatt et menneske som trekker credential-en. KI er det ene budsjettet vi kan avgrense på forhånd: det kjøpes i kreditter, og en kreditt er et fast pengebeløp fremfor et antall tokens, så en endring i modellprisen flytter hvor mange tokens en kreditt kjøper og aldri hva den er verdt. Hver betalt personlig plan har en månedlig kvote og et hardt tak satt til et multiplum av den, slik at et skript som løper løpsk ikke kan produsere en ubegrenset regning. Runbooks er godkjenningsstyrte av samme grunn: modellen foreslår, et navngitt menneske utfører.
Et revisjonsspor som kan si om et menneske eller en modell gjorde det
Artikkel 12(1) i KI-forordningen krever at høyrisikosystemer teknisk tillater automatisk registrering av hendelser gjennom systemets levetid, og artikkel 26(6) krever at ibruktakere oppbevarer de loggene i minst seks måneder med mindre annen rett sier lenger. Hvis du planlegger mot en dato i august 2026, må du korrigere den. Forordning (EU) 2026/1744, Digital Omnibus om KI, i kraft fra 27. juli 2026, flyttet frittstående høyrisikosystemer i vedlegg III til 2. desember 2027 og produktinnbygde systemer i vedlegg I til 2. august 2028. Datoene flyttet seg; forpliktelsene gjorde det ikke.
Den driftsmessige grunnen til å bygge dette har ingenting med fristen å gjøre. Seks måneder etter en hendelse er spørsmålet om det var et menneske eller en modell som gjorde endringen, og et oppsett som journalfører KI-handlinger i ett system og menneskelige i et annet, kan ikke svare på det uten en sammenstilling ingen stoler på. Vi nektet å føre to journaler: modellhandlinger og menneskelige handlinger lander i det samme append-only-sporet. Sencai eksporterer det som CSV med entry_hash og prev_hash på hver linje, slik at en leser som ikke tar oss på ordet kan regne ut kjeden på nytt. Feltet som fortjener plassen sin er det lille ved siden av aktøren, som sier om endringen kom fra et menneske eller fra en modell som bruker av et menneskes kvote.
Regelen som faller ut av bevisene er lite glamorøs og holder. La en modell lese hva som helst, inkludert det den leser dårlig, fordi en dårlig lesning er synlig i avsnittet den skrev. La den skrive bare der et navngitt menneske signerer endringen og en credential-grense ligger under i tilfelle det mennesket også tar feil. Mellom et leverandørvarsel på en syklus på 8 til 24 timer og noen som leser e-post på hverdager er det en røykvarsler og ingen sprinkler. DN42-operatøren hadde en røykvarsler.