Pilotprojekt med AI-agenter: så lägger ni upp det steg för steg

De flesta företag som provar AI-agenter gör det i någon form av pilot. Det är ett bra grepp, men en pilot utan struktur blir lätt ett lekprojekt som ingen vågar stänga eller skala upp. Här är en arbetsmodell som fungerar för företag där ingen har ett eget AI-team, med uppgifter som ofta går att hantera i en vanlig vecka mellan övriga jobb.

Poängen med en pilot är att lära sig något avgörande för ett beslut: fungerar det här hos oss, med våra ärenden och våra system, och är det värt att fortsätta? Allt som inte hjälper den frågan ska skalas bort.

Välj ett avgränsat användningsfall

Det vanligaste misstaget är att börja för stort. "AI i hela kundtjänsten" är inte en pilot. "Agenten tar emot felanmälningar på kvällar och helger" är det.

Ett bra första användningsfall har några gemensamma drag:

• Det återkommer ofta, så att ni får underlag snabbt.
• Reglerna är ganska tydliga, även om de inte är nedskrivna ännu.
• Ett fel går att rätta utan stora konsekvenser för kunden eller affären.
• Det finns en person i verksamheten som äger processen och vill ha hjälp.

Exempel från svenska vardagen: en bilhandlare som vill att förfrågningar från webben kvalificeras och bokas in till provkörning, en redovisningsbyrå som vill sortera och besvara klienternas återkommande frågor, eller en fastighetsförvaltare som vill ta emot och kategorisera felanmälningar. Fler idéer finns i genomgången av användningsfall för AI-agenter i små och medelstora företag.

Lika viktigt är att veta vad som inte passar i en första pilot. Undvik uppgifter där agenten ska fatta beslut om kredit, anställning eller vård, uppgifter med mycket sällsynta undantag och processer som ingen i dag kan beskriva. En agent kan inte automatisera något som ingen vet hur det går till.

Vilka som bör ingå i pilotgruppen

Håll gruppen liten. En beslutsfattare som kan säga ja eller nej, en processägare som kan arbetet på djupet, en eller två medarbetare som använder agenten dagligen och någon med koll på system och behörigheter räcker långt. Är gruppen större går mycket tid åt till avstämningar i stället för till att lära sig något.

Definiera vad som är ett lyckat utfall

Skriv ner före start vad piloten ska visa. Annars kommer slutmötet att handla om känslor, och den som är mest skeptisk eller mest entusiastisk vinner diskussionen.

Använd en handfull mått som går att följa upp utan avancerad analys:

• Andel ärenden som agenten klarar själv utan att en människa behöver gå in.
• Kvalitet: hur ofta en medarbetare behöver rätta eller komplettera agentens arbete.
• Tid: hur mycket handläggningstid eller väntetid som minskar.
• Upplevelse: vad kunder och medarbetare tycker, helst med några enkla frågor.
• Risk: antal fall där agenten gjorde något den inte skulle.

Sätt också en nivå som innebär "gå vidare" och en som innebär "stoppa eller bygg om". Ni behöver inte hitta på tal, men ni behöver bestämma vilka mått som avgör. Mät gärna nuläget redan innan piloten startar, annars saknas jämförelsen.

Underlag och data

En agent är aldrig bättre än det den får veta. Samla underlaget tidigt, eftersom det ofta är det som drar ut på tiden:

• Vanliga frågor och de svar ni faktiskt vill ge, med aktuella villkor, öppettider och undantag.
• Exempel på riktiga ärenden, avidentifierade där det behövs.
• Regler för vad agenten får lova och vad som alltid ska till en människa.
• Åtkomst till de system agenten ska läsa från eller skriva till, med så snäva behörigheter som möjligt.

Passa på att städa. Gamla prislistor, motstridiga instruktioner och information som bara finns i någons huvud blir synligt direkt när en agent ska använda den. Det är ofta en av pilotens mest värdefulla biverkningar. Dataskydd hör hit, och ni hittar en genomgång i artikeln om AI-agenter, GDPR och AI-förordningen.

Bygg eller köp

Frågan avgörs av hur vanlig processen är och hur nära era egna system agenten behöver komma.

Utgångspunkt	Köpa en färdig lösning	Bygga skräddarsytt
Passar när	Användningsfallet är vanligt, som telefonsvar, chatt eller ärendeintag	Processen är unik eller agenten är en del av er produkt
Tid till första test	Kort, ofta några veckor	Längre, kräver mer specifikation
Anpassning	Begränsad till det plattformen stödjer	Full frihet mot era system och regler
Underhåll	Ligger främst hos leverantören	Ligger hos er eller er utvecklingspartner
Risk	Inlåsning i en leverantör	Beroende av få personer som kan systemet

För en första pilot är köp eller en lätt konfigurerad plattform oftast rätt väg. Om ni senare ser att processen kräver mer kan ni bygga vidare på det ni lärt er. Kostnadsbilden går vi igenom i vad AI-agenter kostar.

Bygg med människan i loopen och testa med riktiga ärenden

Människa i loopen i början

Låt agenten förbereda, inte avgöra. I första skedet föreslår den svar, sammanfattar ärenden eller fyller i bokningar, och en medarbetare godkänner, ändrar eller avvisar. Då ser ni var agenten är pålitlig innan en kund märker något.

Allteftersom förtroendet byggs kan ni släppa fram agenten i de delar där den visat sig träffsäker, till exempel enkla frågor, och behålla granskning där det är känsligare. Definiera också en tydlig överlämning: vad som ska till en människa, hur och med vilken information med sig, så att kunden inte behöver börja om.

Testa med riktiga ärenden

Konstruerade testfall visar att tekniken fungerar. Riktiga ärenden visar om verksamheten fungerar. Kör agenten parallellt med den ordinarie hanteringen en period, där den föreslår och människan utför. Jämför sedan utfallen ärende för ärende och samla fallen där agenten missade, eftersom de säger mest om vad som behöver förbättras.

Ta med dem som faktiskt gör jobbet i dag. Deras invändningar är oftast sakliga och pekar på verkliga undantag. Medarbetare som själva fått påverka agenten blir dessutom ofta dess bästa försvarare.

Mät och besluta om skalning

Vid slutet av piloten samlar ni mätvärdena mot de mål ni satte i början. Tre utfall är rimliga:

• Gå vidare: målen nåddes. Bestäm vilket nästa steg är, till exempel fler ärendetyper, fler kanaler eller mindre granskning.
• Justera och förläng: resultatet är lovande men inte tillräckligt. Peka ut exakt vad som ska förbättras och sätt en kort förlängning.
• Stoppa: målen nåddes inte och orsaken går inte att åtgärda rimligt. Det är också ett lyckat resultat, eftersom ni lärt er det billigt.

Inför skalning behöver ni mer än tekniken: en ägare, en rutin för uppföljning, en plan för att hålla underlaget aktuellt och en bedömning av vad det kostar att driva. Det är här många går vilse, eftersom pilotens engagemang inte räcker för vardagsdrift.

Skriv ner vad ni lärt er, även om det blev ett nej. Vilka frågor klarade agenten, var behövdes en människa och vilka delar av underlaget var sämst? Den kunskapen gör nästa försök snabbare, vare sig det gäller samma agent i större skala eller ett helt nytt användningsfall.

Tidsplan för en pilot

En pilot tar normalt sex till tolv veckor från beslut till utvärdering. Som rekommendation kan ni lägga upp den så här:

1. Vecka 1–2: förarbete. Välj användningsfall, utse ägare, sätt mål och mät nuläget.
2. Vecka 2–4: underlag och upplägg. Samla kunskap, ordna behörigheter, avgör bygg eller köp och välj leverantör.
3. Vecka 4–6: bygg och intern testning. Konfigurera agenten, definiera överlämning och testa internt.
4. Vecka 6–9: skarp drift med granskning. Kör med riktiga ärenden, med människa i loopen, och justera varje vecka.
5. Vecka 9–10: mätning. Sammanställ resultat mot målen och samla synpunkter.
6. Vecka 10–12: beslut. Gå vidare, justera eller stoppa, och planera driften.

Är användningsfallet enkelt kan det gå snabbare, och fler system eller strängare krav drar ut på tiden. Viktigast är att planen har ett slutdatum och ett beslutstillfälle.

Därför dör piloter

I efterhand brukar misslyckade piloter ha samma orsaker:

• Otydligt mål. Ingen vet vad lyckat betyder, så ingen kan säga att det lyckades.
• För stort användningsfall. Piloten försöker lösa allt och löser inget.
• Dåligt underlag. Agenten svarar fel eftersom informationen den får är gammal eller motsägelsefull.
• Ingen ägare i verksamheten. IT driver projektet, men ingen som arbetar med ärendena känner att det är deras.
• Medarbetarna förbigås. De som ska använda lösningen får höra om den först när den är klar.
• Ingen plan för efteråt. Piloten går bra, sedan saknas budget, ansvar och tid för driften.
• Orealistiska förväntningar. Någon trodde att agenten skulle klara allt från dag ett.

Nästan alla går att undvika med det som redan beskrivits: ett smalt fall, ett nedskrivet mål, en ägare, riktiga ärenden och ett utsatt beslutsdatum. Behöver ni en sparringpartner i upplägget kan ni höra av er till Techgruppen.