Riepilogo del webinar: come una delle più grandi compagnie assicurative europee ha portato gli agenti IA in produzione

I clienti assicurativi chiamano raramente quando tutto va bene. Chiamano dopo un incidente, per presentare una richiesta di risarcimento o nel mezzo di una vera crisi. Quella conversazione condiziona tutto ciò che segue e spesso è l'unica interazione reale che un cliente ha con la propria compagnia assicurativa.

Admiral gestisce milioni di queste conversazioni ogni anno nel Regno Unito, in Italia, Francia e Spagna. Ora utilizza agenti IA per gestirle mantenendo la conformità normativa. 

In questo webinar, il team di Admiral ci ha illustrato come ha fatto: dalla scelta del primo caso d'uso al coinvolgimento dei team legale e conformità normativa fin dal primo giorno, fino al passaggio da un prototipo funzionante a modifiche in produzione che ora vengono rilasciate in ore anziché settimane.

Punti chiave

• Inizia con un ambito ristretto, ma concreto. Il primo caso d'uso di Admiral in produzione, i preventivi di estinzione per il suo business di prestiti nel Regno Unito, aveva un ambito sufficientemente delimitato da poter essere rilasciato in tempi realistici, pur coinvolgendo la telefonia e le integrazioni backend: abbastanza da dimostrare l'architettura senza risolvere tutto insieme.
• Alza l'asticella prima di scalare, non abbassarla. Admiral ha progettato per la produzione fin dal primo giorno, ha rivisto la cadenza della governance per tenere il passo con la tecnologia e ha coinvolto i team legale e conformità normativa fin dal primo giorno con un progetto pilota dall'ambito ben definito.
• La normativa è il punto di partenza, non l'intero progetto. Admiral aggiunge alle prescrizioni normative le proprie regole interne, usa una logica deterministica per tutto ciò che deve essere dimostrabile e indirizza i clienti vulnerabili o in difficoltà verso operatori umani.
• Il vero lavoro inizia in produzione. Ogni modifica agli agenti viene testata con una suite completa di simulazioni e viene distribuita dall'1% al 100% del traffico: un ciclo passato da settimane a ore.

Inizia con un ambito ristretto, ma non troppo

Il primo caso d'uso di Admiral in produzione sono stati i preventivi di estinzione per il suo business di prestiti nel Regno Unito: un punto di partenza volutamente controllato, anziché il problema più difficile della lista. Kampa ha descritto l'approccio come la scelta di un Paese e di una linea di business su cui sperimentare prima di espandersi.

Secondo Neely, è questo il modello che distingue le implementazioni che arrivano in produzione da quelle che si bloccano: il caso d'uso deve essere abbastanza circoscritto da poter essere risolto in tempi realistici, ma sufficientemente complesso da mettere davvero alla prova i sistemi circostanti. I preventivi di estinzione hanno funzionato perché la conversazione segue un numero limitato di percorsi, pur coinvolgendo telefonia e integrazioni backend: abbastanza da dimostrare l'architettura senza cercare di risolvere tutto in una volta.

In quella scelta sono stati importanti alcuni aspetti:

• Ambito delimitato, complessità reale. Il caso d'uso deve avere abbastanza varianti da testare la telefonia e l'integrazione backend, non solo un percorso ideale predefinito.
• Rapido passaggio alla produzione. Più a lungo una build resta in sviluppo, più tempo passa prima che le conversazioni reali generino il feedback che migliora davvero l'agente. Neely lo ha definito «l'ultimo 20%», la parte che emerge solo quando i clienti reali parlano con il sistema.
• Volume e impatto insieme. Admiral ha iniziato con interazioni semplici e ad alto volume, in cui tempi di attesa più brevi e una risoluzione più rapida avrebbero migliorato visibilmente l'esperienza del cliente.

Alza l'asticella prima di scalare, non abbassarla

La leadership di Admiral ha dichiarato esplicitamente che gli agenti IA dovrebbero alzare l'asticella della conformità normativa e dei test, non abbassarla. Kampa lo ha espresso chiaramente: lo standard di validazione deve essere più rigoroso di quello precedente, perché il rischio che un agente esca dal copione o violi una regola è sostanzialmente diverso dal caso di un operatore umano che esprime un giudizio.

Questo standard si è tradotto in tre impegni che il team ha assunto fin dall'inizio:

• Progetta per la produzione, non per una proof of concept. Kampa ha chiesto ai suoi team di progettare fin dal primo giorno con l'obiettivo di andare live, anziché condurre un piccolo esperimento che non scala mai.
• Una governance al passo con la tecnologia. Kampa ha osservato che un processo di governance che impiega sei mesi per approvare qualcosa rischia di approvare una tecnologia già obsoleta al momento del rilascio. Admiral ha ridefinito la cadenza delle revisioni per allinearla alla velocità con cui cambiavano i modelli e gli strumenti sottostanti.
• Team legale e conformità normativa fin dal primo giorno. Alla domanda su quando i team legale e conformità normativa si fossero uniti al progetto, sia Kampa sia Clark hanno risposto subito: dal primo giorno, con un progetto pilota dall'ambito chiaramente definito (un numero stabilito di chiamate), anziché una richiesta di approvazione senza limiti definiti.

Lascia che la normativa definisca il punto di partenza, non l'intero progetto

Clark ha chiarito che i requisiti normativi, come informare un cliente che sta parlando con un'IA e offrire il passaggio a un operatore umano in alcune giurisdizioni, variano tra Regno Unito, Italia, Francia e Spagna. Admiral ha quindi progettato i suoi agenti per gestire queste differenze senza consentire a un singolo chiamante di «escalare» una conversazione che può essere risolta.

Alcune conversazioni non vengono affidate affatto all'agente: Admiral indirizza i clienti vulnerabili o in difficoltà verso operatori umani e ha addestrato l'IA a rilevare i segnali che attivano questo passaggio.

Kampa ha descritto l'approccio più ampio come stratificato: «La normativa è solo il punto di partenza», a cui si aggiungono le regole interne e gli standard culturali di Admiral, che talvolta vanno oltre quanto richiesto dalla normativa.

Questa stratificazione ha definito anche dove Admiral usa una logica deterministica anziché non deterministica. Clark ha spiegato che il ragionamento non deterministico è adatto a comprendere l'intento di chi chiama o a rilevarne il disagio, mentre tutto ciò che l'azienda deve poter dimostrare, una dichiarazione normativa obbligatoria o un percorso che il cliente deve seguire, deve essere gestito in modo deterministico, senza alcuna tolleranza per l'improvvisazione dell'agente.

Neely ha spiegato come la struttura dei workflow di ElevenLabs supporti questo approccio nella pratica: gli agenti sono costruiti come un insieme di sotto-agenti specializzati, con gate deterministici, come l'autenticazione, che abilitano o limitano le funzionalità in base al soddisfacimento di una condizione, anziché lasciare che il modello deduca ciò che può fare.

Crea insieme alle persone responsabili del processo

Invece di un tradizionale passaggio di consegne tra requisiti aziendali e sviluppo ingegneristico, Admiral ed ElevenLabs hanno organizzato workshop in sede riunendo in una sola stanza le persone che conoscevano il caso d'uso, il team di ingegneria e il team di telefonia. Neely ha raccontato che il primo workshop ha prodotto, in quattro o cinque ore, una v0 funzionante dell'agente, collegata al backend e alla telefonia, che Kampa e Clark hanno poi potuto mostrare internamente per ottenere l'approvazione a proseguire lo sviluppo.

Clark ha affermato che questa vicinanza è stata importante anche oltre il primo prototipo: oggi i responsabili di business sono abbastanza vicini alla tecnologia da poter apportare autonomamente alcune modifiche, perché il workshop ha trattato la piattaforma come uno strumento per trasferire un processo aziendale esistente, anziché introdurne uno nuovo e sconosciuto. Kampa ha collegato questo aspetto alla gestione del cambiamento più in generale, coinvolgendo fin da subito dirigenti, quadri intermedi e personale in prima linea, affinché la tecnologia diventi parte del funzionamento effettivo dell'azienda e non un progetto parallelo.

Il vero lavoro inizia in produzione

Una volta live, Admiral tratta allo stesso modo ogni modifica agli agenti, grande o piccola: come un branch che viene eseguito su una suite completa di test di simulazione prima di raggiungere i clienti. Clark ha descritto un rollout che parte dall'1% del traffico, monitora in tempo reale le metriche di soddisfazione e risoluzione dei clienti e si espande al 100% quando i dati si confermano positivi: un ciclo passato da settimane a ore.

Da questo processo iterativo sono emerse due lezioni:

• Localizza la lingua, non solo le parole. Inizialmente Admiral ha scritto tutti i prompt e i workflow in inglese, scoprendo che le prestazioni in Francia, Spagna e Italia non eguagliavano quelle nel Regno Unito. Riscrivere i prompt direttamente nella lingua di ciascun mercato, anziché tradurli dall'inglese, ha prodotto risposte in linea con le aspettative e la cultura dei clienti locali.
• I test di simulazione devono essere presi sul serio, non trattati come una formalità. Neely ha detto che scrivere un prompt che supera una manciata di test simulati può sembrare facile, ma il lavoro più difficile e importante è creare suite di test che mettano davvero sotto pressione l'agente e definire in anticipo criteri di successo chiari. Oggi Admiral esegue da centinaia a migliaia di conversazioni simulate per ogni modifica prima di rilasciarla.

Quanto ai risultati, Kampa ha indicato il tempo di gestione come la metrica più significativa: le conversazioni gestite dall'IA raggiungono spesso la stessa risoluzione più rapidamente di quelle gestite da persone, anche perché non ci sono silenzi mentre un sistema si carica. Ha inoltre descritto un incremento graduale dei punteggi CSAT e dei tassi di risoluzione, mercato dopo mercato, attraverso cicli ripetuti di test e ottimizzazione anziché un unico grande salto.

Cosa imparare se stai iniziando

Il consiglio di Neely ai team che iniziano questo lavoro è: scegli un caso d'uso dall'ambito ben definito, portalo rapidamente in produzione e lascia che siano le conversazioni reali con i clienti, non ulteriori test prima del lancio, a individuare i casi limite. Clark ha aggiunto che, una volta convalidate le integrazioni a entrambe le estremità, telefonia e sistemi interni, scalare verso altri casi d'uso diventa progressivamente più veloce, perché il team sa già quali valutazioni e metriche contano.

Nella sua conclusione, Kampa ha guardato oltre: l'ambizione va oltre l'automazione delle conversazioni e punta a usare lo stesso livello di IA per supportare direttamente gli operatori umani, attraverso trascrizioni in tempo reale, suggerimenti sulla prossima azione migliore e simulazioni di formazione.

Come ha riassunto il nostro host, il filo conduttore della conversazione è che normativa e IA non sono in conflitto. Progettare fin dal primo giorno tenendo conto di verificabilità, coerenza ed escalation verso una persona ha reso gli agenti di Admiral più disciplinati, non meno.

Guarda la sessione completa

Guarda la sessione completa qui, incluso lo sviluppo dal vivo e le domande e risposte del pubblico.