Varför agentbaserade AI-projekt läggs ned – och vad ett åtta veckor långt pilotprojekt gör rätt

En kund ber om en återbetalning, och agenten hittar beställningen i CRM-systemet, kontrollerar returpolicyn och skriver ett svar på under en minut. Sedan kör den fast, eftersom återbetalningen måste godkännas i ett ekonomisystem som den inte är ansluten till och kundens adress inte stämmer överens i två databaser. Sådana brister upptäcks sällan i en demo, men de avgör hur mycket det kostar att driva en agent och om någon kan lita på den. Därför ligger den större risken med agentbaserad AI i verksamheten där agenten sätts in, snarare än i modellen.

Gartner räknar med att mer än 40 % av projekten med agentbaserad AI kommer att läggas ned före utgången av 2027 och pekar på stigande kostnader, otydligt affärsvärde och bristfälliga riskkontroller. Läser man prognosen noga handlar den om hur sådana projekt godkänns på grundval av en demo, med liten insyn i vad arbetet kostar i dag eller vem som ansvarar för resultatet.

Frågan jag skulle ställa till varje ledningsgrupp är om verksamheten kan stödja att agenten utför arbetet varje dag, till en kostnad och med en risknivå som den kan acceptera. För att besvara den behöver man granska det jag kallar arbetet efter automatiseringen, det vill säga allt som människor fortfarande måste göra när agenten har utfört sin del. Ett åtta veckor långt pilotprojekt är ett praktiskt sätt att mäta detta innan man bestämmer sig för en fullskalig utrullning.

Problem som agenten ärver från företaget

En agent arbetar sällan på egen hand, eftersom även en uppgift som verkar enkel berör kundregister, ett par verksamhetssystem och vanligtvis ett godkännandesteg. Varje anslutning begränsar vad agenten kan se och göra. Om uppgifterna är inkonsekventa eller ingen riktigt vet vem som ska godkänna arbetet ärver agenten förvirringen tillsammans med uppgiften.

Det är sällan rutinärendena som är problemet, utan undantagen. Det är där driftskostnaderna hopar sig, och just den delen är en demo utformad för att undvika. Deloittes undersökning från 2026 visade att endast 5 % av organisationerna bedömer att deras affärsprocesser är väl förberedda för AI-agenter. Den siffran säger mer än något riktmärke för modeller, eftersom den antyder att AI:n är redo långt innan de flesta processerna är det.

I affärskalkylen måste arbetet efter automatiseringen räknas med

Att mäta hur snabbt en agent producerar ett resultat är det enklaste sättet att överdriva dess värde, eftersom det viktiga måttet är hur mycket arbete hela uppgiften kräver. Anta att det tar en anställd 20 minuter att hantera en begäran och att agenten kortar ned den första genomgången till två minuter. Det ser ut som en tidsbesparing på 18 minuter – ända tills någon lägger 15 minuter på att kontrollera resultatet och rätta till fel. En besparing på tre minuter ger en mager avkastning när kostnaden för att driva agenten räknas in på andra sidan i kalkylen.

McKinseys analys av en kundtjänstagent inom banksektorn visar samma mönster i större skala: token stod för 20–25 % av de rörliga driftskostnaderna och mänsklig tillsyn för 70–75 %, vilket innebär att den största delen av kostnaderna låg utanför modellen. Om det inte finns ett utgångsvärde innan någon börjar skriva kod kan ett pilotprojekt visa stora tekniska framsteg utan att investeringskalkylen har prövats. Som minst behöver verksamhetsansvarig ha ett tydligt svar på var och en av följande punkter:

• Volym: hur ofta processen körs och hur många personer som arbetar med den.
• Slutförandetid: hur lång tid hela uppgiften tar, inklusive kontroller och korrigeringar.
• Träffsäkerhet: hur ofta något går fel eller måste göras om.
• Kostnad per uppgift: vad det kostar att slutföra en uppgift framgångsrikt i dag.
• Verksamhetspåverkan: vad en faktisk förbättring skulle innebära för kunderna, personalen eller verksamheten.

Agenten måste förtjäna sin plats i arbetsflödet

Införandet brukar räknas till förändringsledning, men enligt min erfarenhet avgörs det långt tidigare, av var i arbetsflödet agenten finns. Ett globalt företag inom professionella tjänster hade byggt agenter för support- och regelefterlevnadsarbete. Supportagenten kunde hämta information från flera interna system, men medarbetarna var tvungna att öppna ett separat program för att använda den och gjorde det därför sällan. När samma arbetsflöde flyttades till den befintliga supportplattformen dök agenten upp direkt i ärendet som medarbetarna redan arbetade med. En agent för regelefterlevnadskontroller infördes på samma sätt, inbyggd i Salesforce så att den kördes varje gång ett ärende skapades.

Ingenting med själva agenterna förändrades; det var deras placering i arbetsflödet som ändrades. Medarbetarna hade redan anledning att öppna ett supportärende eller skapa ett ärende, så att möta dem där och då krävde inget extra av dem. Placeringen är därför lika mycket ett arkitekturbeslut som ett beslut om införande, eftersom agenten behöver sammanhanget där arbetet utförs och resultatet måste kunna föras vidare till nästa steg utan att någon kopierar över det för hand.

Autonomi förändrar säkerhetsbilden

En agent som bara kan läsa information innebär en sorts risk, medan en agent som kan ändra uppgifter eller skicka e-post till kunder innebär en helt annan. Kontrollerna måste därför anpassas efter vad agenten faktiskt får göra. Överdrivna behörigheter och läckage av känsliga uppgifter är välkända risker, men promptinjektion kräver särskilt stor uppmärksamhet: instruktioner som döljs i ett dokument eller ett e-postmeddelande som agenten läser in medan den utför en i övrigt helt legitim uppgift.

Gartners vägledning från maj 2026 om styrning av agenter delar in autonomi i fyra nivåer, vilket ger ett praktiskt sätt att avgöra hur strikta kontrollerna behöver vara:

1. Observera: agenten hämtar information och upptäcker mönster, med skrivskyddad åtkomst.
2. Ge råd: agenten rekommenderar en åtgärd och en anställd fattar beslutet.
3. Agera efter godkännande: agenten förbereder eller påbörjar en åtgärd som en person måste godkänna innan den genomförs.
4. Agera autonomt: agenten utför godkända åtgärder på egen hand inom fastställda gränser, med övervakning och eskalering av undantag.

På varje nivå behöver en agent en egen identitet, behörigheter som begränsas till dess uppgift och en logg över varje åtgärd den vidtar. Organisationer behöver också regler för hur data hanteras och lagras, tydlighet kring vilken information som når externa modellleverantörer och någon med befogenhet att pausa agenten och återkalla dess åtkomst så snart något verkar fel.

Var och en av dessa kontroller medför löpande kostnader, eftersom bredare behörigheter, extra övervakning och frekventa godkännanden alla blir kostsamma med tiden. Rätt nivå av autonomi är därför både ett ekonomiskt beslut och ett säkerhetsbeslut, och den ligger där agenten ger ett värdefullt resultat till en risknivå som verksamheten kan acceptera.

Välj en process som motiverar en agent

Många team börjar med tekniken och letar sedan efter ett problem, trots att en bättre utgångspunkt är en process där kostnaderna eller förseningarna redan är uppenbara för dem som utför arbetet.

Ett globalt företag inom expertförmedling som vi arbetade med passade in på den beskrivningen: teamet matchade enkätförfrågningar med experter i tre system som inte kommunicerade med varandra och kontrollerade manuellt profiler, tidigare deltagande och efterlevnad för varje matchning. Vi byggde en agent som kombinerade semantisk sökning med historik över deltagande och efterlevnadsreglerna. I produktion minskade antalet ärenden om felmatchningar med 80 %, träffsäkerheten i matchningarna ökade med 40 % och teamet fick tillbaka 22 % av sin kapacitet.

Projektet lyckades eftersom problemet var tydligt avgränsat, med information utspridd på flera ställen, manuell sammanställning och en matchningskvalitet som gick att mäta både före och efter. En tydligt avgränsad uppgift hjälper också till att avgöra om en process över huvud taget behöver en agent. Arbete som styrs av fasta regler är vanligtvis billigare att hantera med traditionell automatisering, och arbete som främst går ut på att hitta och sammanfatta information lämpar sig ofta väl för en AI-assistent. Agenter motiverar sin extra kostnad och risk när uppgiften innebär att tolka sammanhang, välja mellan tillåtna åtgärder och länka samman flera steg för att nå ett resultat.

Ett åttaveckors pilotprojekt med tydliga beslutspunkter

Hela pilotprojektet kretsar kring en kommersiell fråga: kan den här agenten förbättra processen tillräckligt mycket för att det ska vara motiverat att driva den i stor skala? Åtta veckor ger tillräckligt med tid för att pröva affärsnyttan, tekniken och organisationens förmåga att hantera det den bygger.

Vecka 1–2: Fastställ vad som behöver förbättras

Börja med att dokumentera hur processen fungerar i dag, från volymer och genomloppstid till felfrekvens, omarbete och kostnader. Notera vilka system som ingår, vem som ansvarar för varje steg och vilka undantag som kräver mänsklig hantering. Se sedan till att verksamhetsansvarig och teknikteamet enas om det enda resultat som agenten ska förbättra. Beslutspunkt: gå vidare när problemet, utgångsläget, ansvarig person och framgångsmått är tydliga.

Vecka 3: Fastställ agentens gränser

Här fastställs agentens begränsningar, bland annat dess identitet, behörigheter, dataåtkomst, godkända verktyg och grad av autonomi. Testa den mot promptinjektion, obehörig åtkomst, exponering av känsliga uppgifter och missbruk av verktyg. Inför loggning och rutiner för incidenthantering samt ett sätt att stänga av agenten eller återkalla dess åtkomst. Beslutspunkt: gå vidare när kontrollerna och åtgärderna vid ingripanden faktiskt har testats och alla vet vad agenten får göra.

Vecka 4–6: Testa förhållanden som får demon att fallera

Ge den nu realistiska arbetsuppgifter, inklusive ofullständiga poster, motstridig information, ovanliga förfrågningar och enstaka systemfel. Följ upp hur många uppgifter den slutför, hur träffsäker den är och hur mycket människor behöver rätta till. Beräkna sedan den verkliga kostnaden för varje slutförd uppgift när användning av modeller, integrationer, övervakning och granskning räknas in. Beslutspunkt: gå vidare till tester i skarp drift när agenten når de överenskomna tröskelvärdena och teamet förstår både driftskostnaden och hur den fallerar.

Vecka 7–8: Låt riktiga användare prova agenten

Låt en liten grupp anställda använda den för en avgränsad del av det verkliga arbetet, samtidigt som den gamla processen finns kvar för sådant agenten inte kan hantera. Se om människor faktiskt använder den, om den minskar deras arbetsinsats och om de litar på det den producerar.

I slutet jämför du resultaten med utgångsläget från den första veckan och granskar produktivitet, träffsäkerhet, användning, hur ofta människor behövde ingripa, de totala driftskostnaderna och eventuella kvarstående säkerhetsrisker. Därefter fattar ni beslut om att skala upp, åtgärda specifika brister och testa igen eller avbryta. Även ett pilotprojekt som visar att agenten är för dyr eller opålitlig för uppgiften har fyllt sin funktion, eftersom det har förhindrat en mycket större investering grundad på gissningar.

Mät resultatet och avgör sedan hur stor självständighet agenten ska få

Att räkna hur många uppgifter en agent hanterar säger inte särskilt mycket, eftersom ett system kan beta av tusentals förfrågningar samtidigt som medarbetarna ändå måste verifiera, korrigera eller slutföra de flesta av dem. Kostnaden per framgångsrikt slutförd uppgift, bedömd tillsammans med träffsäkerheten och andelen undantag, ger en betydligt bättre bild av om processen har förbättrats från början till slut.

Samma mätvärden blir också underlaget för att ge agenten större handlingsutrymme. En agent som tillförlitligt hanterar rutinmässiga förfrågningar inom överenskomna gränser kan få agera på egen hand, medan en agent som gång på gång stöter på tvetydiga situationer bör låta en människa godkänna besluten. Behörigheterna kan ses över i takt med att underlaget växer.

Skala upp när verksamheten kan stödja agenten

Förr eller senare måste en agent som fungerar väl för ett team hantera andra avdelningar, applikationer och godkännandekedjor. För att skala upp den krävs tydligt ägarskap, enhetliga åtkomstkontroller och ett sätt att hantera undantag, liksom en budget för att hålla agenten uppdaterad när processerna runt omkring förändras.

Den grundläggande frågan är hur mycket ansvar organisationen är beredd att lämna över, och beslutet måste bygga på erfarenheter från verkligt arbete snarare än en lyckad demonstration. Efter de åtta veckorna bör ledningen veta vad agenten klarar av, när människor fortfarande behöver ingripa och vad det kostar att driva den. De företag som drar ifrån med agentisk AI kommer att vara de som redan från första veckan planerar för arbetet efter automatiseringen och finansierar agenter för de uppgifter de faktiskt slutför.