Hvorfor prosjekter med agentisk KI avlyses, og hva en åtteukers pilot gjør riktig

En kunde ber om refusjon, og agenten finner bestillingen i CRM-systemet, sjekker returvilkårene og skriver et svarutkast på under ett minutt. Så stopper den opp fordi refusjonen må godkjennes i et økonomisystem den ikke er koblet til, og kundens adresse er ulik i to databaser. Slike mangler dukker sjelden opp i en demonstrasjon, men de avgjør hvor mye det koster å drifte en agent, og om noen kan stole på den. Dermed ligger den største risikoen ved agentisk KI i virksomheten agenten settes inn i, ikke i modellen.

Gartner venter at mer enn 40 % av prosjektene med agentisk KI blir avlyst innen utgangen av 2027, og viser til økende kostnader, uklar forretningsverdi og svake risikokontroller. Ser man nærmere på prognosen, handler den om hvordan disse prosjektene godkjennes på grunnlag av en demonstrasjon, uten særlig innsikt i hva arbeidet koster i dag, eller hvem som har ansvar for resultatet.

Spørsmålet jeg ville stilt ledergruppen, er om virksomheten kan støtte at denne agenten utfører arbeidet hver dag, til en kostnad og med et risikonivå den kan leve med. For å svare må man se nøye på det jeg kaller arbeidet etter automatisering – alt folk fortsatt må gjøre når agenten er ferdig med sin del. En åtteukers pilot er en praktisk måte å måle dette på før man forplikter seg til en full utrulling.

Problemene agenten arver fra virksomheten

En agent jobber sjelden alene. Selv en oppgave som virker enkel, berører kunderegistre, et par forretningsapplikasjoner og som regel et godkjenningstrinn, og hver tilkobling begrenser hva agenten kan se og gjøre. Hvis opplysningene er inkonsekvente eller ingen helt vet hvem som skal godkjenne, arver agenten forvirringen sammen med oppgaven.

Rutineoppgavene er sjelden problemet; det er unntakene, for det er der driftskostnadene hoper seg opp, og det er nettopp slike tilfeller en demonstrasjon er laget for å unngå. Deloittes forskning fra 2026 viste at bare 5 % av organisasjonene vurderer forretningsprosessene sine som svært godt forberedt på KI-agenter. Dette tallet sier mer enn noen modellreferanse, fordi det tyder på at KI-en er klar lenge før de fleste prosessene er det.

Forretningsgrunnlaget må omfatte arbeidet etter automatisering

Det er lettest å overdrive verdien av en agent ved å måle hvor raskt den produserer et resultat. Det som betyr noe, er hvor mye arbeid det tar å fullføre oppgaven. Si at det tar en ansatt 20 minutter å behandle en forespørsel, og at agenten reduserer tiden for første gjennomgang til to minutter. Det ser ut som en besparelse på 18 minutter – helt til noen bruker 15 minutter på å kontrollere resultatet og rette feil. En besparelse på tre minutter gir liten avkastning når kostnaden ved å drifte agenten også regnes med.

McKinseys analyse av en kundeserviceagent i banksektoren viser det samme mønsteret i stor skala: Tokenene utgjorde 20–25 % av de variable driftskostnadene, mens menneskelig tilsyn utgjorde 70–75 %. Dermed lå mesteparten av kostnadene utenfor modellen. Hvis man ikke fastsetter et utgangspunkt før noen skriver kode, kan en pilot vise betydelig teknisk fremgang uten at investeringsgrunnlaget blir prøvd. Som et minimum må den forretningsansvarlige ha et klart svar på hvert av disse punktene:

• Volum: hvor ofte prosessen kjøres, og hvor mange som er involvert.
• Gjennomføringstid: hvor lang tid hele oppgaven tar, inkludert kontroll og korrigeringer.
• Nøyaktighet: hvor ofte noe går galt eller må gjøres om.
• Kostnad per oppgave: hva det koster å fullføre en oppgave i dag.
• Forretningseffekt: hva en reell forbedring vil endre for kundene, de ansatte eller virksomheten.

Agenten må gjøre seg fortjent til plassen sin i arbeidsflyten

Adopsjon regnes vanligvis som en del av endringsledelse, men etter min erfaring avgjøres den mye tidligere, av hvor i arbeidsflyten agenten er plassert. Et globalt selskap som leverer profesjonelle tjenester, hadde utviklet agenter for kundestøtte og etterlevelse. Støtteagenten kunne hente informasjon fra flere interne systemer, men folk måtte åpne en separat applikasjon for å bruke den, og de fleste lot være. Da den samme arbeidsflyten ble flyttet inn i den eksisterende kundestøtteplattformen, ble agenten tilgjengelig i saken medarbeiderne allerede jobbet med. En agent for kontroll av etterlevelse ble tatt i bruk på samme måte: Den ble bygget inn i Salesforce, slik at den kjørte hver gang en sak ble opprettet.

Det var ikke agentene selv som endret seg, men plasseringen deres i arbeidsflyten. Medarbeiderne hadde allerede en grunn til å åpne en sak eller opprette en sak, så det krevde ikke noe ekstra av dem å møte dem der. Plasseringen er derfor like mye en arkitekturbeslutning som en beslutning om adopsjon. Agenten trenger kontekst der arbeidet utføres, og resultatet må kunne føres videre til neste trinn uten at noen kopierer det manuelt.

Autonomi endrer sikkerhetsbildet

En agent som bare kan lese informasjon, innebærer én type risiko. En agent som kan endre opplysninger eller sende e-post til kunder, innebærer en helt annen. Kontrollene må derfor tilpasses det agenten faktisk har tillatelse til å gjøre. For omfattende tilgangsrettigheter og lekkasje av sensitive data er kjente risikoer, men man bør være mest oppmerksom på promptinjeksjon: instruksjoner som er skjult i et dokument eller en e-post agenten kommer over mens den utfører en helt legitim oppgave.

Gartners veiledning fra mai 2026 om styring av agenter deler autonomi inn i fire nivåer, noe som gir en praktisk måte å avgjøre hvor strenge kontrollene må være:

1. Observere: Agenten henter informasjon og oppdager mønstre, med skrivebeskyttet tilgang.
2. Gi råd: Agenten anbefaler en handling, og en ansatt tar beslutningen.
3. Handle med godkjenning: Agenten forbereder eller starter en handling som en person må godkjenne før den utføres.
4. Handle autonomt: Agenten utfører godkjente handlinger på egen hånd innenfor fastsatte grenser, med overvåking og eskalering av unntak.

På hvert nivå trenger en agent sin egen identitet, tillatelser som er begrenset til oppgaven, og en logg over hver handling den utfører. Organisasjoner trenger også regler for hvordan data håndteres og lagres, klarhet om hva som deles med eksterne modelltilbydere, og noen med myndighet til å sette agenten på pause og stenge tilgangen dens så snart noe virker galt.

Hver av disse kontrollene medfører løpende kostnader, siden bredere tillatelser, ekstra overvåking og hyppige godkjenninger samlet sett koster mer over tid. Riktig grad av autonomi er derfor både en økonomisk beslutning og et sikkerhetsspørsmål, og den ligger på det nivået der agenten gir et verdifullt resultat med en risiko virksomheten kan akseptere.

Velg en prosess som kan forsvare bruken av en agent

Mange team begynner med teknologien og leter deretter etter et problem. Et bedre utgangspunkt er en prosess der kostnadene eller forsinkelsene allerede er tydelige for dem som utfører arbeidet.

Et globalt selskap innen ekspertnettverk som vi samarbeidet med, var et slikt eksempel: Teamet måtte koble forespørsler om undersøkelser til eksperter på tvers av tre systemer som ikke kunne kommunisere med hverandre. For hver kobling kontrollerte de profiler, tidligere deltakelse og etterlevelse manuelt. Vi bygde en agent som kombinerte semantisk søk med historikk over deltakelse og etterlevelsesreglene. Etter at løsningen ble satt i produksjon, falt antallet saker om feiltreff med 80 %, treffsikkerheten i koblingene økte med 40 %, og teamet fikk tilbake 22 % av kapasiteten sin.

Prosjektet lyktes fordi problemet var konkret: Informasjonen var spredt, sammenstillingen ble gjort manuelt, og kvaliteten på koblingene kunne måles både før og etter. En konkret problemstilling gjør det også lettere å avgjøre om en prosess i det hele tatt trenger en agent. Arbeid som styres av faste regler, håndteres som regel billigere med konvensjonell automatisering. Arbeid som hovedsakelig består i å finne og oppsummere informasjon, egner seg ofte godt for en KI-assistent. Agenter forsvarer de ekstra kostnadene og risikoen når jobben innebærer å tolke kontekst, velge mellom tillatte handlinger og sette sammen flere trinn for å oppnå et resultat.

En åtteukers pilot med tydelige beslutningspunkter

Hele piloten dreier seg om ett forretningsmessig spørsmål: Kan denne agenten forbedre prosessen nok til at det forsvarer å ta den i bruk i stor skala? Åtte uker gir nok tid til å teste forretningsgrunnlaget, teknologien og organisasjonens evne til å håndtere det den bygger.

Uke 1–2: Kartlegg hva som må forbedres

Begynn med å dokumentere hvordan prosessen fungerer i dag, fra omfang og gjennomføringstid til feilprosent, omarbeid og kostnader. Noter hvilke systemer som inngår, hvem som har ansvar for hvert trinn, og hvilke unntak som krever menneskelig medvirkning. Sørg deretter for at den forretningsansvarlige og det tekniske teamet blir enige om det ene resultatet agenten skal forbedre. Beslutningspunkt: Gå videre når problemet, utgangspunktet, den ansvarlige og målene for suksess er tydelige.

Uke 3: Fastsett agentens grenser

Her fastsettes agentens grenser: identitet, tillatelser, datatilgang, godkjente verktøy og grad av autonomi. Test den for instruksjonsinjeksjon, uautorisert tilgang, eksponering av sensitive data og misbruk av verktøy. Sørg også for logging og beredskap for hendelser, og etabler en måte å stanse agenten på eller trekke tilbake tilgangen dens. Beslutningspunkt: Gå videre når kontrollene og tiltakene for å gripe inn er grundig testet, og alle vet hva agenten har lov til å gjøre.

Uke 4–6: Test forholdene som får demonstrasjonen til å slå feil

Sett den nå til realistiske oppgaver, inkludert ufullstendige oppføringer, motstridende informasjon, uvanlige forespørsler og sporadiske systemfeil. Følg med på hvor mange oppgaver den fullfører, hvor nøyaktig den er, og hvor mye korrigeringsarbeid folk må gjøre. Regn deretter ut hva en fullført oppgave faktisk koster når bruk av modeller, integrasjoner, overvåking og gjennomgang er tatt med. Beslutningspunkt: Gå videre til testing i drift når agenten når de avtalte terskelverdiene, og teamet forstår både driftskostnadene og hvordan agenten feiler.

Uke 7–8: La reelle brukere prøve agenten

La en liten gruppe ansatte bruke agenten på en avgrenset del av det reelle arbeidet, samtidig som den gamle prosessen fortsatt er tilgjengelig for oppgaver agenten ikke kan håndtere. Følg med på om folk faktisk bruker den, om den sparer dem for arbeid, og om de stoler på resultatene den gir.

Til slutt sammenligner du resultatene med utgangspunktet fra den første uken og vurderer produktivitet, nøyaktighet, bruk, hvor ofte folk måtte gripe inn, samlede driftskostnader og eventuelle uløste sikkerhetsrisikoer. Deretter må dere avgjøre om dere skal skalere opp, rette konkrete mangler og teste på nytt, eller avslutte. En pilot som viser at agenten er for dyr eller for upålitelig for oppgaven, har likevel gjort nytte for seg, fordi den har hindret en langt større investering basert på gjetninger.

Mål resultatene, og avgjør deretter hvor mye autonomi agenten skal få

Det sier lite å telle hvor mange oppgaver en agent behandler, for et system kan tygge seg gjennom tusenvis av forespørsler og likevel la de ansatte stå for det meste av kontrollen, korrigeringen eller ferdigstillingen. Kostnaden per oppgave som fullføres, sett i sammenheng med nøyaktighet og antall unntak, gir et langt bedre bilde av om prosessen er blitt bedre fra start til slutt.

De samme målene danner grunnlaget for å gi agenten større handlingsrom. En agent som pålitelig håndterer rutineforespørsler innenfor avtalte grenser, kan få tillit til å behandle dem på egen hånd. Når den stadig støter på tvetydige saker, må et menneske fortsatt godkjenne avgjørelsene, og tilgangene bør vurderes på nytt etter hvert som kunnskapsgrunnlaget vokser.

Skaler når virksomheten har forutsetninger for å støtte agenten

Før eller siden må en agent som fungerer godt for ett team, også håndtere andre avdelinger, applikasjoner og godkjenningsprosesser. Skalering krever tydelig eierskap, konsekvent tilgangskontroll og en måte å håndtere unntak på, i tillegg til et budsjett for å holde agenten oppdatert når prosessene rundt den endres.

Den underliggende beslutningen handler om hvor mye ansvar organisasjonen er klar til å overlate, og den må bygge på erfaringer fra reelt arbeid, ikke en god demonstrasjon. Etter de åtte ukene bør ledelsen vite hva agenten kan håndtere, når folk fortsatt må gripe inn, og hva det vil koste å drifte den. Virksomhetene som lykkes best med agentisk KI, vil være de som fra første uke planlegger for arbeidet etter automatiseringen og finansierer agenter for oppgavene de faktisk fullfører.