Pålitelighet er den virkelige prøven for agentbasert AI

De siste to årene har bransjen stilt ett spørsmål: Er AI-agenter dyktige nok til å håndtere reelt arbeid? Vi kan slutte å spørre. Vi vet at de er det, men vi må konsentrere oss om hvorvidt vi kan oppdage når en agent er i ferd med å gjøre en kostbar feil, og om vi kan stoppe den før det skjer.

De verste feilene i produksjon ser vanligvis ikke ut som en tydelig modellfeil. En agent kan fullføre hvert API-kall uten feil og likevel arbeide ut fra utdatert kontekst, prøve et verktøy som svikter på nytt eller bevege seg mot en handling som bryter en regel. Pålitelighet avgjør om et program med agentbasert AI kommer seg ut av pilotfasen.

Ifølge “The state of AI in 2025: Agents, innovation, and transformation”, en undersøkelse fra McKinsey, eksperimenterer 62% av organisasjonene med AI-agenter, men bare rundt ti prosent skalerer ikke innen noen av disse funksjonene. Det er enkelt å vise kolleger at en agent fungerer. Det er ikke enkelt å drive den trygt på tvers av virkelige data og tilkoblede systemer.

Hvorfor agentbasert AI forsterker risiko

Agenter kombinerer sannsynlighetsbasert resonnering, bruk av verktøy og en viss grad av selvstendighet. Dette gjør dem nyttige, men utsetter også selskaper for feil som forsterkes raskere enn de ville gjort i en mer tradisjonell applikasjon.

Kontekst

Agenter kan bare arbeide ut fra konteksten de får. Hvis denne konteksten er ufullstendig, utdatert eller feil, følger derfor en dårlig tidlig tolkning med videre til hvert påfølgende trinn. Et feil svar fra en chatbot er irriterende. En feil tolkning som endrer en tilgangstillatelse eller berører infrastruktur, er en hendelse. Hvis noe går galt, er det viktig å vite om agenten brukte riktig dokumentasjon, fulgte retningslinjene og holdt seg innenfor en akseptabel skaderadius.

Kunnskapsbaser

Agenter kobles også til kunnskapsbaser, supportsystemer og betalingsplattformer; hver tilkobling utvider angrepsflaten. En agent kan kalle feil verktøy, kalle riktig verktøy i feil rekkefølge eller handle etter instruksjoner som er skjult i hentet innhold. Dette er kjente feilmoduser, og de omfatter konfabulering og sikkerhetssårbarheter som oppstår gjennom måten agenter kjeder sammen verktøy og kontekst på.

Et grønt kontrollpanel kan lure deg: Infrastrukturen ser ut til å fungere mens en agent i stillhet spør det samme verktøyet om og om igjen. Dette er et tidlig tegn på avdrift snarere enn et vanlig driftsavbrudd.

Ikke-determinisme

Ikke-determinisme gjør også hendelseshåndtering vanskeligere. En tradisjonell tjenestefeil kan vanligvis gjenskapes med en forespørsels-ID og en kjent programvareversjon. En agentkjøring avhenger av modellversjonen, dokumentene agenten hentet, verktøyresultatene den fikk tilbake og en kjede av mellomliggende beslutninger. Uten en oversikt over hva agenten mottok og forsøkte, blir både rotårsaksanalyse og styring mye vanskeligere.

Kostnad og ventetid

Kostnad og ventetid forteller den samme historien fra en annen vinkel. En plutselig økning i tokenbruk eller gjentatte forsøk kan signalisere en dårlig plan eller en løkke, selv om brukeren til slutt får et svar. Kostnadene ved inferens har falt kraftig de siste årene, og billigere inferens gjør det enklere å overse ineffektiv atferd frem til den gjentas i tusenvis av arbeidsflyter. Behandle kostnad, ventetid og gjentatte forsøk som signaler om pålitelighet, ikke bare som økonomiske måltall.

Desentralisert AI trenger fortsatt sentral synlighet

Desentralisering mislykkes uten tydelige sikkerhetsrammer. Legg ansvaret for arbeidsflyt og eskalering hos teamene i førstelinjen, men behold identitet, tilgang og hendelseshåndtering på virksomhetsnivå. Et økonomiteam kan skille mellom et legitimt fakturaavvik og en uriktig betalingsbeslutning på en måte en generell referansemåling aldri kan. I den samme undersøkelsen fant McKinsey at organisasjoner som rapporterte reell effekt av AI, hadde nesten tre ganger større sannsynlighet for å ha utformet arbeidsflytene sine på nytt i stedet for bare å legge AI oppå det som allerede fantes.

Avveiningen er likevel reell: Ansvaret blir raskt uklart når en hendelse krysser systemer. Løsningen er et felles operativt bilde av hver agent, verktøyene den bruker, datatilgangen og hendelseshistorikken.

Distribuerte arkitekturer gjør det lett å miste helhetsbildet når noe svikter. Mange team kan se tokenvolum og kostnad, men de kan ikke se om en agent faktisk oppnådde det tiltenkte resultatet på en trygg måte. Når registreringer fra en arbeidsflyt ligger på forskjellige steder, ender team med å jage symptomer i stedet for årsaker.

Standardiserte telemetrisignaler, som modellidentitet og verktøykall, kan hjelpe. Atferdsmessige referanseverdier, som det normale antallet trinn i en arbeidsflyt, er også nødvendige for å skille nyttig utholdenhet fra et system som har satt seg fast. Evaluering er ikke en engangskontroll før lansering. Det er en kontinuerlig sirkel.

Slik ser pålitelig AI faktisk ut i produksjon

Pålitelig AI handler om å håndtere feil, ikke om å unngå dem. Team trenger innsyn i atferd, varsler når ytelsen avviker, og en plan for inneslutning når noe går galt. Aller viktigst trenger hver agent tydelige sikkerhetsrammer for tilgang og selvstendige handlinger. De trenger også menneskelig godkjenning.

Begynn med handlinger med lav risiko som kan reverseres. Hold handlinger med store konsekvenser, som produksjonsendringer og finansielle transaksjoner, bak reelle kontroller. Arbeidsflyter med store konsekvenser bør kunne rekonstrueres i ettertid, inkludert konteksten agenten hentet, verktøyene den kalte, godkjenningene den fikk og om resultatet faktisk var riktig.

Tradisjonelle tjenestenivåmål må også utvides til å dekke agentkvalitet og sikkerhet. De omfatter validert oppgavesuksess, grad av etterlevelse av retningslinjer, grad av menneskelig eskalering, kostnad per vellykket oppgave og hvor ofte uønskede utfall oppstår. Tersklene bør variere etter bruksområde. En intern kunnskapsassistent kan tåle en annen feilprofil enn en agent som berører regulerte data.

De mest nyttige pålitelighetssystemene lærer å oppdage forholdene som gjerne oppstår før en feil, som en unormal økning i gjentatte forsøk eller en vei som tidligere har ført til menneskelig overstyring. En arbeidsflyt med lav risiko kan utløse en automatisk rettelse. En arbeidsflyt med høyere risiko bør stoppe og sende beslutningen til en autorisert person. Målet er ikke selvstendig handling for selvstendighetens egen skyld. Målet er raskere og tryggere handling når dokumentasjonen støtter den.

AI SRE lukker kretsløpet

Det er her AI SRE kommer inn. En AI SRE-agent kan sette sammen en tidslinje for en hendelse, sammenligne gjeldende atferd med tidligere hendelser og utarbeide en anbefalt handling, mens organisasjonen beholder kontrollert utbedring for oppgaver som kan reverseres, og menneskelig godkjenning for alt med store konsekvenser.

Innføringen av AI går raskt. Men innføring er ikke det samme som operativ modenhet. Virksomhetene som lykkes med å skalere agentbasert AI, er ikke nødvendigvis de som kjører den mest kapable modellen isolert. Det vil være de som kan se hvordan agentene oppfører seg på tvers av virksomheten, fange opp tidlige tegn på avdrift og gripe inn før en liten feil blir til en kunde-, sikkerhets- eller etterlevelseshendelse.

Det er rollen AI SRE fyller: å knytte desentralisert innovasjon til sentral synlighet og gjøre agentbasert AI til et system virksomheten kan stole på.