Hvorfor agentiske AI-projekter bliver aflyst, og hvad et otteugers pilotprojekt gør rigtigt

En kunde beder om at få pengene tilbage, og agenten finder ordren i CRM-systemet, tjekker returpolitikken og udarbejder et svar på under et minut. Så går den i stå, fordi godkendelsen af tilbagebetalingen ligger i et økonomisystem, den ikke er forbundet med, og kundens adresse ikke stemmer overens i to databaser. Den slags huller viser sig sjældent i en demo, men de afgør, hvor meget det koster at drive en agent, og om nogen kan stole på den. Det betyder, at den største risiko ved agentisk AI ligger i den virksomhed, agenten sættes ind i, snarere end i modellen.

Gartner forventer, at mere end 40 % af projekterne med agentisk AI bliver aflyst inden udgangen af 2027, med henvisning til stigende omkostninger, uklar forretningsværdi og utilstrækkelig risikostyring. Ser man nærmere på prognosen, handler den om, hvordan disse projekter godkendes på baggrund af en demo, uden nævneværdigt indblik i, hvad arbejdet koster i dag, eller hvem der har ansvaret for resultatet.

Det spørgsmål, jeg ville stille enhver ledelsesgruppe, er, om virksomheden kan understøtte, at agenten udfører arbejdet hver dag, til en pris og med et risikoniveau, den kan leve med. For at svare på det skal man se grundigt på det, jeg kalder arbejdet efter automatisering, altså alt det, folk stadig skal gøre, når agenten har udført sin del. Et pilotprojekt på otte uger er en praktisk måde at måle det på, før man forpligter sig til en fuld udrulning.

De problemer, agenten overtager fra virksomheden

En agent arbejder sjældent alene, for selv en opgave, der ser enkel ud, berører kunderegistre, et par forretningsapplikationer og som regel et godkendelsestrin. Hver forbindelse begrænser, hvad agenten kan se og gøre. Hvis registrene ikke stemmer overens, eller ingen helt ved, hvem der skal godkende, overtager agenten forvirringen sammen med opgaven.

Rutineopgaver er sjældent problemet; det er undtagelserne, for det er dér, driftsomkostningerne hober sig op, og netop den del forsøger en demo at undgå. Deloittes forskning fra 2026 viste, at kun 5 % af organisationerne vurderer, at deres forretningsprocesser er særdeles godt forberedt på AI-agenter. Det tal siger mere end nogen modelbenchmark, fordi det tyder på, at AI er klar længe før de fleste processer.

Forretningsgrundlaget skal omfatte arbejdet efter automatiseringen

Det er den nemmeste måde at overvurdere en agents værdi på at måle, hvor hurtigt den leverer et resultat. Det afgørende tal er nemlig, hvor meget arbejde den færdige opgave kræver. Lad os sige, at det tager en medarbejder 20 minutter at behandle en anmodning, og at agenten reducerer den første gennemgang til to minutter. Det ligner en besparelse på 18 minutter, lige indtil nogen bruger 15 minutter på at kontrollere resultatet og rette fejl. En besparelse på tre minutter giver et beskedent afkast, når omkostningerne ved at drive agenten også regnes med.

McKinseys analyse af en AI-agent til kundeservice i banksektoren viser det samme mønster i stor skala: Tokens udgjorde 20–25 % af de variable driftsomkostninger, mens menneskelig kontrol stod for 70–75 %. Det meste af udgiften lå altså uden for modellen. Hvis man ikke fastlægger et udgangspunkt, før nogen skriver kode, kan et pilotprojekt vise betydelige tekniske fremskridt uden at afprøve, om investeringen kan betale sig. Som minimum skal den forretningsansvarlige have et klart svar på hvert af disse punkter:

• Mængde: Hvor ofte processen udføres, og hvor mange mennesker der er involveret.
• Tidsforbrug: Hvor lang tid hele opgaven tager, inklusive kontrol og rettelser.
• Nøjagtighed: Hvor ofte noget går galt eller skal gøres om.
• Omkostning pr. opgave: Hvad det i dag koster at gennemføre en opgave.
• Forretningseffekt: Hvad en reel forbedring ville ændre for kunderne, medarbejderne eller virksomheden.

Agenten skal gøre sig fortjent til sin plads i arbejdsgangen

I organisationer bliver udbredelse som regel betragtet som et spørgsmål om forandringsledelse, men efter min erfaring afgøres den langt tidligere af, hvor agenten indgår i arbejdsgangen. En global virksomhed inden for professionelle tjenester havde udviklet agenter til support- og complianceopgaver. Supportagenten kunne hente oplysninger fra flere interne systemer, men medarbejderne skulle åbne en separat applikation for at bruge den, og de lod for det meste være. Da den samme arbejdsgang blev flyttet ind i den eksisterende supportplatform, dukkede agenten op i den sag, medarbejderne allerede arbejdede på. En agent til compliancekontrol blev integreret på samme måde i Salesforce, så den blev kørt, hver gang en sag blev oprettet.

Der blev ikke ændret noget ved selve agenterne; det gjorde der derimod ved deres placering i arbejdsgangen. Medarbejderne havde allerede en grund til at åbne en supportsag eller oprette en sag, så det krævede ikke noget ekstra af dem at møde dem dér. Placeringen er derfor lige så meget en arkitekturbeslutning som en beslutning om udbredelse, for agenten har brug for kontekst dér, hvor arbejdet udføres, og dens output skal kunne føres videre til næste trin, uden at nogen skal kopiere det over manuelt.

Autonomi ændrer sikkerhedsbilledet

En agent, der kun kan læse oplysninger, indebærer én type risiko, mens en agent, der kan ændre registreringer eller sende kunder e-mails, indebærer en helt anden. Derfor skal kontrollerne afspejle, hvad agenten faktisk har tilladelse til at gøre. For mange tilladelser og læk af følsomme data er velkendte risici, men prompt-injektion kræver størst opmærksomhed: instruktioner, der er skjult i et dokument eller en e-mail, som agenten opfanger, mens den udfører en helt legitim opgave.

Gartners retningslinjer fra maj 2026 for styring af agenter opdeler graden af autonomi i fire niveauer, hvilket giver en praktisk måde at afgøre, hvor stramme kontrolforanstaltningerne skal være:

1. Observere: Agenten henter oplysninger og identificerer mønstre med skrivebeskyttet adgang.
2. Rådgive: Agenten anbefaler en handling, og en medarbejder træffer beslutningen.
3. Handle med godkendelse: Agenten forbereder eller igangsætter en handling, som en person skal godkende, før den udføres.
4. Handle autonomt: Agenten udfører godkendte handlinger på egen hånd inden for fastsatte grænser, med overvågning og eskalering af undtagelser.

På alle niveauer skal en agent have sin egen identitet, tilladelser begrænset til dens opgave og en log over hver handling, den udfører. Organisationer har også brug for regler for, hvordan data håndteres og opbevares, klarhed over, hvilke oplysninger der når frem til eksterne modeludbydere, og en person med beføjelse til at sætte agenten på pause og tilbagekalde dens adgang, så snart noget ser forkert ud.

Alle disse kontrolforanstaltninger medfører løbende omkostninger, fordi bredere tilladelser, ekstra overvågning og hyppige godkendelser løber op over tid. Det rette niveau af autonomi er derfor både en økonomisk beslutning og et sikkerhedsspørgsmål, og det er det niveau, hvor agenten skaber et værdifuldt resultat med en risiko, virksomheden kan acceptere.

Vælg en proces, der kan retfærdiggøre en agent

Mange teams begynder med teknologien og leder derefter efter et problem, selv om det bedre udgangspunkt er en proces, hvor omkostningerne eller forsinkelserne allerede er tydelige for dem, der udfører arbejdet.

En global virksomhed inden for ekspertnetværk, som vi arbejdede sammen med, passede på den beskrivelse: Teamet skulle matche forespørgsler på undersøgelser med eksperter på tværs af tre systemer, der ikke kunne kommunikere med hinanden, og manuelt kontrollere profiler, tidligere deltagelse og overholdelse af regler for hvert match. Vi byggede en agent, der kombinerede semantisk søgning med historikken over deltagelse og reglerne for overholdelse, og i produktion faldt antallet af sager om fejlmatch med 80 %, matchningsnøjagtigheden steg med 40 %, og teamet fik 22 % af sin kapacitet tilbage.

Projektet lykkedes, fordi problemet var konkret: Oplysningerne var spredt, de skulle sammenstilles manuelt, og matchningskvaliteten kunne måles før og efter. En præcis problemformulering gør det også lettere at afgøre, om en proces overhovedet har brug for en agent. Arbejde, der følger faste regler, er som regel billigere at håndtere med traditionel automatisering, og arbejde, der hovedsageligt består i at finde og opsummere oplysninger, egner sig ofte godt til en AI-assistent. Agenter kan derimod retfærdiggøre deres ekstra omkostninger og risici, når opgaven kræver, at man læser konteksten, vælger mellem tilladte handlinger og kæder flere trin sammen for at nå et resultat.

Et otteugers pilotprojekt med klare beslutningspunkter

Hele pilotprojektet afhænger af ét kommercielt spørgsmål: Kan denne agent forbedre processen nok til, at det kan betale sig at drive den i stor skala? Otte uger giver tilstrækkelig tid til at afprøve forretningsgrundlaget, teknologien og organisationens evne til at håndtere det, den bygger.

Uge 1–2: Fastslå, hvad der skal forbedres

Begynd med at dokumentere, hvordan processen foregår i dag, fra omfang og gennemførelsestid til fejlprocenter, omarbejde og omkostninger. Notér, hvilke systemer der indgår, hvem der har ansvaret for hvert trin, og hvilke undtagelser der kræver menneskelig indgriben. Få derefter den forretningsansvarlige og det tekniske team til at blive enige om det ene resultat, agenten skal forbedre. Beslutningspunkt: Gå videre, når problemet, udgangspunktet, den ansvarlige og målene for succes står klart.

Uge 3: Fastlæg agentens grænser

Her fastlægges agentens grænser, herunder dens identitet, tilladelser, dataadgang, godkendte værktøjer og grad af autonomi. Afprøv den mod prompt-injektion, uautoriseret adgang, eksponering af følsomme data og misbrug af værktøjer, og indfør logføring og procedurer for håndtering af hændelser samt en måde at suspendere agenten eller tilbagekalde dens adgang på. Beslutningspunkt: Gå videre, når kontrolforanstaltningerne og indgrebsprocedurerne er blevet afprøvet i praksis, og alle ved, hvad agenten har tilladelse til at gøre.

Uge 4–6: Afprøv de forhold, der får demoen til at bryde sammen

Lad den nu håndtere realistiske opgaver, herunder ufuldstændige registre, modstridende oplysninger, usædvanlige forespørgsler og lejlighedsvise systemfejl. Følg med i, hvor mange opgaver den løser, hvor præcis den er, og hvor meget medarbejderne skal rette, og beregn derefter, hvad en gennemført opgave reelt koster, når forbruget af modeller, integrationer, overvågning og kontrol alle tælles med. Beslutningspunkt: Gå videre til liveafprøvning, når agenten opfylder de aftalte tærskelværdier, og teamet forstår både driftsomkostningerne og de måder, agenten fejler på.

Uge 7–8: Lad rigtige brugere prøve den

Giv en lille gruppe medarbejdere adgang til agenten, og lad den håndtere en afgrænset del af det reelle arbejde, mens den gamle proces stadig er til rådighed for alt det, agenten ikke kan håndtere. Hold øje med, om medarbejderne rent faktisk bruger den, om den sparer dem for arbejde, og om de har tillid til dens resultater.

Til sidst sammenlignes resultaterne med udgangspunktet fra uge ét, og man ser på produktivitet, nøjagtighed, anvendelse, hvor ofte medarbejderne måtte gribe ind, de samlede driftsomkostninger og eventuelle uløste sikkerhedsrisici. Derefter skal man beslutte, om løsningen skal skaleres, om konkrete mangler skal udbedres og afprøves igen, eller om projektet skal stoppes. Et pilotprojekt, der viser, at agenten er for dyr eller for upålidelig til opgaven, har stadig gjort nytte, fordi det har forhindret en langt større investering baseret på gætterier.

Mål resultaterne, og beslut derefter, hvor stor autonomi der skal gives

At tælle, hvor mange opgaver en agent behandler, siger meget lidt, eftersom et system kan behandle tusindvis af anmodninger og stadig efterlade medarbejderne med at kontrollere, rette eller færdiggøre de fleste af dem. Omkostningen pr. gennemført opgave, set i sammenhæng med nøjagtigheden og andelen af undtagelser, giver et langt bedre billede af, om processen er blevet forbedret fra start til slut.

De samme målinger bliver grundlaget for at give en agent større råderum. En agent, der pålideligt håndterer rutineanmodninger inden for aftalte grænser, kan få lov til at handle på egen hånd, mens en agent, der gentagne gange støder på tvetydige tilfælde, fortsat får et menneske til at godkende beslutningerne. Tilladelserne gennemgås, efterhånden som dokumentationen vokser.

Skalér, når virksomheden kan understøtte agenten

En agent, der fungerer godt for ét team, skal før eller siden også håndtere andre afdelinger, applikationer og godkendelsesforløb. Skalering kræver klart ejerskab, ensartede adgangskontroller og en måde at håndtere undtagelser på samt et budget til at holde agenten opdateret, efterhånden som de omkringliggende processer ændrer sig.

Det grundlæggende spørgsmål er, hvor stort et ansvar organisationen er klar til at overdrage, og beslutningen skal bygge på dokumentation fra det faktiske arbejde – ikke på en vellykket demonstration. Efter de otte uger bør ledelsen vide, hvad agenten kan håndtere, hvor medarbejderne stadig skal træde til, og hvad det vil koste at drive den. De virksomheder, der fører an med agentisk AI, vil være dem, der allerede fra den første uge planlægger arbejdet efter automatiseringen og investerer i agenter på baggrund af de opgaver, de faktisk løser.