Webinariesammanfattning: Så fick ett av Europas största försäkringsbolag AI-agenter i produktion

Försäkringskunder ringer sällan när allt går bra. De ringer efter en olycka, för att göra en skadeanmälan eller mitt i en verklig kris. Det samtalet präglar allt som följer, och är ofta kundens enda verkliga kontakt med sitt försäkringsbolag.

Admiral hanterar miljontals sådana samtal varje år i Storbritannien, Italien, Frankrike och Spanien. Nu använder de AI-agenter för att hjälpa till att hantera dem och samtidigt uppfylla regelkrav. 

I det här webbinariet berättade Admirals team hur de gjorde: valde sitt första användningsfall, tog in juridik- och compliancefunktionerna från dag noll och gick från en fungerande prototyp till ändringar i produktion som nu kan lanseras på timmar i stället för veckor.

Viktiga slutsatser

• Börja smalt, men på riktigt. Admirals första användningsfall i produktion, slutregleringsofferter inom den brittiska utlåningsverksamheten, var tillräckligt avgränsat för att kunna lanseras inom en realistisk tidsram men omfattade ändå telefoni och back-end-integrationer. Det räckte för att bevisa arkitekturen utan att försöka lösa allt på en gång.
• Höj ribban innan du skalar upp, sänk den inte. Admiral byggde för produktion från dag ett, gjorde om sina styrningsrutiner för att hålla jämna steg med tekniken och tog in juridik- och compliancefunktionerna från dag noll med ett tydligt avgränsat pilotprojekt.
• Regelverk är grunden, inte hela lösningen. Admiral lägger sina egna interna regler ovanpå regelkraven, använder deterministisk logik för allt som måste kunna bevisas och hänvisar sårbara eller utsatta kunder till mänskliga handläggare.
• Det verkliga arbetet börjar i produktion. Varje ändring av en agent testas mot en komplett simuleringssvit och rullas ut från 1 procent av trafiken till 100 procent – en cykel som har gått från veckor till timmar.

Börja smalt, men inte för smalt

Admirals första användningsfall i produktion var slutregleringsofferter inom den brittiska utlåningsverksamheten – en medvetet kontrollerad startpunkt i stället för det svåraste problemet på listan. Kampa beskrev metoden som att välja ett land och en verksamhetsgren att experimentera med innan man expanderar.

Neely sa att detta är mönstret som skiljer driftsättningar som når produktion från dem som stannar upp: användningsfallet måste vara tillräckligt avgränsat för att lösas inom en realistisk tidsram, men samtidigt komplext nog för att verkligen testa systemen runt omkring. Slutregleringsofferter fungerade eftersom samtalet har ett begränsat antal möjliga vägar, men ändå berör telefoni och back-end-integrationer. Det räckte för att bevisa arkitekturen utan att försöka lösa allt på en gång.

Några saker var viktiga i valet:

• Avgränsad omfattning, verklig komplexitet. Användningsfallet behöver tillräckligt mycket variation för att testa telefoni och back-end-integration, inte bara ett skriptat idealfall.
• Snabb väg till produktion. Ju längre en lösning stannar i utveckling, desto längre dröjer det innan verkliga samtal ger den återkoppling som faktiskt förbättrar agenten. Neely kallade detta ”de sista 20 procenten” – den del som först visar sig när riktiga kunder pratar med systemet.
• Volym och effekt tillsammans. Admiral började med enkla interaktioner i hög volym, där kortare väntetider och snabbare lösningar skulle ge en märkbar förbättring av kundupplevelsen.

Höj ribban, sänk den inte, innan du skalar upp

Admirals ledning var tydlig med att AI-agenter ska höja kraven på compliance och testning, inte sänka dem. Kampa uttryckte det direkt: valideringsstandarden måste vara striktare än tidigare, eftersom risken för att en agent avviker från manus eller bryter mot en regel skiljer sig från en mänsklig handläggares bedömning.

Den standarden märktes i tre åtaganden som teamet gjorde tidigt:

• Bygg för produktion, inte för ett proof of concept. Kampa bad sina team att från dag ett utforma lösningen med målet att gå live, i stället för att göra ett litet experiment som aldrig kan skalas upp.
• Styrning som håller jämna steg med tekniken. Kampa påpekade att en styrningsprocess som tar sex månader för att godkänna något riskerar att godkänna teknik som redan är föråldrad när den lanseras. Admiral byggde om sin granskningsprocess för att matcha hur snabbt de underliggande modellerna och verktygen förändrades.
• Juridik och compliance från dag noll. På frågan om när juridik- och compliancefunktionerna anslöt till projektet svarade både Kampa och Clark omedelbart: dag noll, med ett tydligt avgränsat pilotprojekt – ett bestämt antal samtal – i stället för en öppen begäran om godkännande.

Låt regelverket vara grunden, inte hela lösningen

Clark var tydlig med att regelkraven varierar mellan Storbritannien, Italien, Frankrike och Spanien, exempelvis kravet att berätta för kunden att hen talar med en AI och i vissa jurisdiktioner erbjuda möjlighet att kopplas till en människa. Admiral byggde sina agenter för att hantera dessa skillnader, utan att låta en enskild uppringare ”eskalera” sig ur ett samtal som går att lösa.

Vissa samtal hålls helt borta från agenten: Admiral hänvisar sårbara eller utsatta kunder till mänskliga handläggare, och AI:n är tränad att upptäcka de signaler som ska utlösa överlämningen.

Kampa beskrev den bredare metoden som skiktad: ”Regelverket är bara grunden.” Ovanpå det ligger Admirals egna interna regler och kulturstandarder, som ibland går längre än regelverket kräver.

Den skiktningen påverkade också var Admiral använde deterministisk respektive icke-deterministisk logik. Clark förklarade att icke-deterministiskt resonemang lämpar sig väl för att förstå den som ringer eller upptäcka utsatthet, medan allt som verksamheten måste kunna bevisa, ett obligatoriskt regulatoriskt uttalande eller en process kunden måste ledas igenom, måste köras deterministiskt. Agenten får inte improvisera alls.

Neely beskrev hur ElevenLabs workflow-struktur stöder detta i praktiken: agenter byggs som en uppsättning specialiserade underagenter med deterministiska spärrar, exempelvis autentisering, som ger eller begränsar funktionalitet beroende på om ett villkor är uppfyllt, i stället för att låta modellen avgöra vad den får göra.

Bygg tillsammans med dem som äger processen

I stället för en traditionell överlämning mellan verksamhetskrav och utveckling höll Admiral och ElevenLabs workshoppar på plats där personerna som kände till användningsfallet, utvecklingsteamet och telefoniteamet samlades i samma rum. Neely berättade att den första workshopen gav en fungerande v0 av agenten, ansluten till back-end och telefoni, inom fyra eller fem timmar. Kampa och Clark kunde sedan demonstrera den internt för att få godkännande att fortsätta bygga.

Clark sa att denna närhet var viktig även efter den första prototypen: verksamhetsansvariga står nu tillräckligt nära tekniken för att själva kunna göra vissa ändringar, eftersom workshopen behandlade plattformen som ett sätt att överföra en befintlig affärsprocess snarare än att införa en obekant ny process. Kampa kopplade detta till förändringsledning i stort: att involvera ledare, mellanchefer och medarbetare i frontlinjen tidigt, så att tekniken blir en del av hur verksamheten faktiskt drivs och inte ett sidoprojekt.

Det verkliga arbetet börjar i produktion

När systemet väl är live behandlar Admiral varje agentändring, stor som liten, på samma sätt: som en gren som körs mot en komplett simuleringssvit innan den når kunderna. Clark beskrev hur en utrullning startar med 1 procent av trafiken, medan kundnöjdhet och lösningsgrad övervakas i realtid, och sedan utökas till 100 procent när siffrorna håller. Cykeln har gått från veckor till timmar.

Två lärdomar från iterationsprocessen stack ut:

• Anpassa språket, inte bara orden. Admiral skrev först alla promptar och workflows på engelska och upptäckte att resultatet i Frankrike, Spanien och Italien inte motsvarade resultatet i Storbritannien. När de i stället skrev om promptarna direkt på respektive marknads språk, i stället för att översätta från engelska, fick de svar som bättre motsvarade lokala kundförväntningar och lokal kultur.
• Simuleringstester måste tas på allvar, inte behandlas som en formalitet. Neely sa att det kan verka enkelt att skriva en prompt som klarar en handfull simulerade tester, men att bygga testsviter som verkligen pressar agenten och att definiera tydliga framgångskriterier i förväg är det svårare och viktigare arbetet. Admiral kör nu hundratals till tusentals simulerade samtal mot varje ändring innan den lanseras.

När det gäller resultat pekade Kampa på handläggningstid som det främsta måttet: AI-ledda samtal når ofta samma lösning snabbare än samtal med mänskliga handläggare, delvis eftersom det inte uppstår några tysta pauser medan ett system laddar. Hon beskrev också hur CSAT och lösningsgrader steg gradvis, marknad för marknad, genom upprepade omgångar av testning och justeringar snarare än genom ett enda stort lyft.

Det här kan du ta med dig om du just har börjat

Neelys råd till team som börjar med detta: välj ett väl avgränsat användningsfall, få snabbt ut det i produktion och låt verkliga kundsamtal – inte fler tester före lansering – hitta specialfallen. Clark tillade att när integrationerna i båda ändar, telefoni och interna system, är bevisade går det successivt snabbare att skala till fler användningsfall, eftersom teamet redan vet vilka utvärderingar och mätvärden som är viktiga.

Kampas avslutande poäng blickade längre fram: ambitionen sträcker sig bortom att automatisera samtal till att använda samma AI-lager för att direkt stödja mänskliga handläggare, med transkribering i realtid, förslag på nästa bästa åtgärd och träningssimuleringar.

Som vår värd sammanfattade det är den röda tråden i samtalet att regelverk och AI inte står i konflikt med varandra. Genom att från dag ett bygga med spårbarhet, konsekvens och möjlighet att koppla över till en människa i åtanke blev Admirals agenter mer disciplinerade, inte mindre.

Se hela sessionen

Se hela sessionen här, inklusive livebygget och publikens frågor och svar.