Ny IBM-benchmark: AI-agenter bommer på halve IT-feilene

IBM Research og Artificial Analysis har lagt ut ITBench-AA, en ny benchmark for agentiske enterprise-IT-oppgaver. Første del måler hvor godt modeller klarer Site Reliability Engineering: feilsøking i Kubernetes-miljøer med logger, metrics, traces, events og topologi.

Resultatet er et kaldt bad for AI-agent-hypen. Beste modell i testen, Claude Opus 4.7 med maksimal resonneringsinnsats, scorer 47 prosent. GPT-5.5 xhigh følger på 46 prosent. Qwen3.7 Max ligger på 42 prosent. Ingen av frontmodellene passerer 50 prosent.

Det er ikke en test av om modellene kan skrive fine forklaringer. Oppgavene krever at en agent finner den minimale listen over Kubernetes-objekter som faktisk er rotårsaken til en hendelse. Bommer modellen på én av rotårsakene, får den null for den runden. Treffer den alle, men legger til falske forklaringer, trekkes den for presisjon.

Det er omtrent slik produksjonsdrift oppleves i praksis. Et system kan ha mange symptomer samtidig. En rollout-feil, en nettverkspolicy, en kvotegrense eller en connection pool kan se ut som flere ting på en gang. Feil svar er ikke bare akademisk svakt. Det sender vaktlaget til feil sted.

Hva testen faktisk måler

ITBench-AA SRE består av 59 oppgaver. 40 er offentlige, 19 er holdt tilbake. Hver oppgave gir modellen et øyeblikksbilde av en Kubernetes-hendelse. Agenten får shell-tilgang til en sandbox med relevante filer, men ikke til et levende produksjonsmiljø. Den kan kjøre kommandoer, lese logger og følge spor, og må levere en strukturert JSON-diagnose med rotårsakene.

IBM leverer underliggende ITBench-datasett og ground truth. Artificial Analysis har bygget benchmark-implementasjonen for frontier-evaluering. Harnesset, kalt Stirrup, holdes likt på tvers av modellene. Det gjør testen mer nyttig enn mange demo-benchmarks der hvert system får sitt eget oppsett og sin egen dramaturgi.

Det mest interessante funnet er ikke bare at modellene scorer lavt. Det er at mer arbeid ikke nødvendigvis hjelper. GPT-5.5 xhigh bruker i snitt 31 turer per oppgave og scorer 46 prosent. Gemini 3.1 Pro Preview bruker 83 turer og scorer 30 prosent. Lengre agentløp kan gi mer støy, flere sidespor og flere falske positive rotårsaker.

Det bør treffe alle som planlegger å slippe agenter løs i drift, sikkerhet eller økonomifunksjoner. En agent som undersøker mer, er ikke automatisk tryggere. Den kan bare produsere flere plausible blindspor.

Åpne modeller presser kostnadssiden

Benchmarken gir også en kostnadsvinkel. Claude Opus 4.7 leder på score, men er dyrest i testen med 5,38 dollar per oppgave. Gemma 4 31B Reasoning scorer 37 prosent til 0,14 dollar per oppgave. GLM-5.1 Reasoning scorer 40 prosent til 1,23 dollar.

Det betyr ikke at åpne modeller plutselig er gode nok til autonom IT-drift. Men det viser at modellvalg i agentiske systemer ikke kan reduseres til én toppliste. For mange virksomheter blir spørsmålet hvilket presisjonsnivå som er godt nok for triage, hvilken risiko feil svar gir, og hvor mange oppgaver som skal kjøres hver dag.

En dyr modell med litt bedre score kan være riktig i en høyrisiko-hendelse. En billigere modell kan være riktig for første sortering, dokumentasjon eller forslag som alltid må godkjennes av mennesker. Den arkitekturen må bestemmes før innkjøp, ikke etter første alvorlige incident.

Konsekvensen for norske CIO-er og CISO-er

For norske ledere er hovedpoenget enkelt: Agentisk IT-drift må styres som et produksjonssystem, ikke som et eksperiment i et hjørne av utviklingsavdelingen. Benchmarken viser at dagens modeller kan være nyttige, men at de fortsatt er svake på presis rotårsaksanalyse i komplekse miljøer.

Det bør påvirke tre beslutninger.

Først må virksomheter bygge egne evals på egne driftsscenarioer. En generell benchmark er nyttig som temperaturmåler, men den sier ikke om agenten klarer virksomhetens faktiske skyløsning, nettverksoppsett, overvåking, datakilder og navngivning.

Deretter må agentene ha klare sperrer. De kan foreslå diagnose, hente kontekst og lage runbook-forslag. Å endre produksjon, rotere hemmeligheter, skalere ned tjenester eller lukke varsler bør kreve policy, logging og menneskelig godkjenning.

Til slutt må innkjøp og risikostyring stille hardere spørsmål til leverandørene. Hva er modellens presisjon på relevante oppgaver? Hvordan måles falske positive? Hvor mange turer får agenten bruke? Hva koster en normal hendelse? Hvilke handlinger er eksplisitt forbudt? Hvordan lagres og revideres agentens spor?

Dette er ikke bare teknisk hygiene. Det blir vendor risk, internkontroll og beredskap. Når AI-agenter flytter fra kodeforslag til IT-operasjoner, flytter de også risikoen nærmere kjerneinfrastrukturen.

Nøktern lesning

ITBench-AA er fortsatt en benchmark, ikke en fasit for alle driftsmiljøer. Den bruker snapshots, ikke levende systemer med stress, mennesker, endringsvinduer og telefoner som ringer. Men nettopp derfor er resultatet ubehagelig. Selv i et avgrenset oppsett med riktig informasjon tilgjengelig klarer ikke frontmodellene å levere stabil rotårsaksanalyse.

Den riktige konklusjonen er ikke å droppe AI-agenter i IT. Den er å bruke dem der de faktisk tåler feil: som observasjons- og beslutningsstøtte før automatisering. Virksomheter som hopper rett til selvhelbredende infrastruktur uten målinger, bygger ny risiko på toppen av gammel kompleksitet.

Det er fristende å kjøpe agentplattformen først og governance etterpå. ITBench-AA er et godt argument for motsatt rekkefølge. Lag evals, logging, kostnadsrammer og stoppunkter først. Deretter kan agentene få mer ansvar når de beviser at de treffer i virksomhetens egne feilbilder.

Kilder og medier

Primærkilde: IBM Research / Artificial Analysis via Hugging Face, «ITBench-AA: Frontier Models Score Below 50% on the First Benchmark for Agentic Enterprise IT Tasks», publisert 27. mai 2026: https://huggingface.co/blog/ibm-research/itbench-aa

Kildekreditering: IBM Research / Artificial Analysis.

Thumbnail: OpenAI Image 2 / hogby.ai