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 anmäla en skada eller mitt i en verklig kris. Det samtalet formar allt som kommer efteråt, 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 följa reglerna. 

I det här webbinariet berättade Admirals team hur de gjorde: hur de valde ett första användningsfall, tog med juridik- och compliance-teamen från dag ett och gick från en fungerande prototyp till produktionsändringar som nu levereras på timmar i stället för veckor.

Viktiga insikter

• Börja smalt, men på riktigt. Admirals första användningsfall i produktion, slutregleringsofferter i den brittiska utlåningsverksamheten, var tillräckligt avgränsat för att kunna lanseras inom en realistisk tidsram, men berörde ändå telefoni och back-end-integrationer. Det räckte för att bevisa arkitekturen utan att 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, anpassade sin styrning till teknikens takt och involverade juridik och compliance från dag ett genom ett tydligt avgränsat pilotprojekt.
• Regleringen är grunden, inte hela utformningen. Admiral lägger sina egna interna regler ovanpå lagkraven, använder deterministisk logik för allt som måste kunna bevisas och kopplar sårbara eller utsatta kunder till mänskliga handläggare.
• Det verkliga arbetet börjar i produktion. Varje agentändring testas mot en komplett svit av simuleringstester 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 i 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 affärslinje att experimentera med innan man expanderar.

Neely menade att detta är mönstret som skiljer implementationer som når produktion från dem som fastnar: användningsfallet måste vara tillräckligt smalt för att lösas inom en realistisk tidsram, men tillräckligt komplext för att faktiskt 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 det valet:

• Avgränsad omfattning, verklig komplexitet. Användningsfallet behöver tillräckligt med variation för att testa telefoni och backend-integration, inte bara ett skriptat idealt scenario.
• 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 verkliga kunder pratar med systemet.
• Volym och effekt tillsammans. Admiral började med enkla interaktioner med hög volym, där kortare väntetider och snabbare lösningar skulle göra märkbar skillnad för kundupplevelsen.

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

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

Den standarden syntes i tre åtaganden som teamet gjorde tidigt:

• Bygg för produktion, inte för ett proof of concept. Kampa uppmanade sina team att från dag ett utforma lösningen med målet att gå live, i stället för att genomföra ett litet experiment som aldrig kan skalas upp.
• Styrning som följer teknikens takt. Kampa påpekade att en styrningsprocess som tar sex månader att godkänna något riskerar att godkänna teknik som redan är föråldrad när den lanseras. Admiral anpassade sina granskningscykler efter hur snabbt de underliggande modellerna och verktygen förändrades.
• Juridik och compliance från dag ett. När Kampa och Clark fick frågan om när juridik och compliance anslöt till projektet svarade båda direkt: dag ett, 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 regleringen sätta grunden, inte hela utformningen

Clark var tydlig med att regelkrav – exempelvis att berätta för en kund att de talar med en AI och att i vissa jurisdiktioner erbjuda möjlighet att kopplas till en människa – skiljer sig mellan Storbritannien, Italien, Frankrike och Spanien. Admiral byggde sina agenter för att hantera dessa skillnader utan att låta en enskild uppringare ”eskalera” sig ur ett samtal som kan lösas.

Vissa samtal hanteras inte av agenten alls: Admiral kopplar sårbara eller utsatta kunder till mänskliga handläggare, och AI:n är tränad att upptäcka signalerna som utlöser överlämningen.

Kampa beskrev den övergripande strategin som lager på lager: ”Regleringen är bara grunden”, med Admirals egna interna regler och kulturstandarder ovanpå, som ibland går längre än vad regleringen kräver.

Denna lagerindelning styrde 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å uppringarens avsikt eller upptäcka utsatthet, medan allt som verksamheten måste kunna bevisa, ett obligatoriskt regulatoriskt uttalande eller en väg kunden måste ledas igenom, måste köras deterministiskt – utan någon tolerans för att agenten improviserar.

Neely beskrev hur ElevenLabs workflow-struktur stöder detta i praktiken: agenter byggs som en uppsättning specialiserade underagenter, med deterministiska grindar som autentisering. De låser upp eller begränsar funktionalitet beroende på om ett villkor uppfylls, 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 affärskrav och utveckling höll Admiral och ElevenLabs workshops på plats som samlade dem som kände till användningsfallet, utvecklingsteamet och telefoniteamet i samma rum. Neely berättade att den första workshopen tog fram en fungerande v0 av agenten, ansluten till backend 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 något helt nytt och obekant. Kampa kopplade detta till förändringsledning i stort: att tidigt involvera ledare, mellanchefer och medarbetare i kundnära roller, så att tekniken blir en del av hur verksamheten faktiskt fungerar, inte ett sidoprojekt.

Det verkliga arbetet börjar i produktion

När lösningen 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 svit av simuleringstester innan den når kunderna. Clark beskrev hur en utrullning startar med 1 procent av trafiken, medan kundnöjdhets- och lösningsmått följs i realtid, och utökas till 100 procent när siffrorna håller. Cykeln har gått från veckor till timmar.

Två lärdomar stack ut från den här iterationsprocessen:

• Lokalanpassa språket, inte bara orden. Admiral skrev först alla prompts och workflows på engelska och märkte att resultaten i Frankrike, Spanien och Italien inte motsvarade dem i Storbritannien. När de skrev om promptarna direkt på varje marknads språk, i stället för att översätta från engelska, blev svaren mer anpassade till lokala kundförväntningar och kultur.
• Simuleringstestning måste tas på allvar, inte behandlas som en formalitet. Neely sa att det verkar enkelt att skriva en prompt som klarar en handfull simulerade tester, men att det svårare och viktigare arbetet är att bygga testsviter som verkligen stressar agenten och att definiera tydliga framgångskriterier från början. Admiral kör nu hundratals till tusentals simulerade samtal mot varje ändring innan den lanseras.

När det gäller resultaten lyfte Kampa fram handläggningstid som det främsta måttet: AI-ledda samtal når ofta samma lösning snabbare än samtal som hanteras av människor, delvis eftersom det inte uppstår några tysta pauser medan ett system laddar. Hon beskrev också hur CSAT och lösningsgrader har ökat stegvis, marknad för marknad, genom upprepade omgångar av tester och justeringar snarare än ett enda stort språng.

Vad du kan ta med dig om du ska börja

Neelys råd till team som börjar med detta arbete är att välja ett väl avgränsat användningsfall, få det i produktion snabbt och låta verkliga kundsamtal – inte fler tester före lansering – identifiera specialfall. Clark tillade att när integrationerna i båda ändar, telefoni och interna system, har bevisats går det successivt snabbare att skala till fler användningsfall, eftersom teamet redan vet vilka utvärderingar och mått 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 ge direkt stöd till mänskliga handläggare, genom live-transkriberingar, 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 reglering 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 vidare till en människa i åtanke blev Admirals agenter mer disciplinerade, inte mindre.

Se hela sessionen

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