Resumen del webinar: cómo una de las mayores aseguradoras de Europa llevó agentes de IA a producción

Clientes de seguros rara vez llaman cuando todo va bien. Llaman después de un accidente, para presentar una reclamación o en plena crisis. Esa conversación condiciona todo lo que viene después y, a menudo, es la única interacción real que un cliente tiene con su aseguradora.

Admiral gestiona millones de estas conversaciones cada año en Reino Unido, Italia, Francia y España. Ahora utiliza agentes de IA para ayudar a gestionarlas sin dejar de cumplir la normativa. 

En este webinar, el equipo de Admiral nos explicó cómo lo hizo: elegir un primer caso de uso, involucrar a los equipos legal y de cumplimiento normativo desde el día cero, y pasar de un prototipo funcional a implementar cambios en producción en horas, en lugar de semanas.

Conclusiones clave

• Empieza con algo acotado, pero real. El primer caso de uso en producción de Admiral, las ofertas de liquidación en su negocio de crédito en Reino Unido, tenía un alcance lo bastante acotado para implementarse en un plazo realista, pero incluía integraciones de telefonía y backend suficientes para demostrar la arquitectura sin intentar resolverlo todo de golpe.
• Eleva el nivel antes de escalar; no lo rebajes. Admiral diseñó para producción desde el primer día, reformuló el ritmo de su gobernanza para avanzar al ritmo de la tecnología e involucró a los equipos legal y de cumplimiento normativo desde el día cero con un piloto de alcance claro.
• La normativa es el mínimo, no todo el diseño. Admiral añade sus propias normas internas a las exigidas por la normativa, usa lógica determinista para todo lo que debe poder demostrarse y deriva a clientes vulnerables o en situación de angustia a agentes humanos.
• El verdadero trabajo empieza en producción. Cada cambio en un agente se somete a una batería completa de pruebas de simulación y se despliega del 1 % al 100 % del tráfico, un ciclo que ha pasado de semanas a horas.

Empieza con algo acotado, pero no demasiado

El primer caso de uso en producción de Admiral fueron las ofertas de liquidación en su negocio de crédito en Reino Unido: un punto de partida deliberadamente controlado, en lugar del problema más difícil de la lista. Kampa describió el enfoque como elegir un país y una línea de negocio para experimentar antes de ampliar.

Neely explicó que este es el patrón que distingue los despliegues que llegan a producción de los que se estancan: el caso de uso debe estar lo bastante acotado como para resolverse en un plazo realista, pero ser lo bastante complejo como para poner realmente a prueba los sistemas que lo rodean. Las ofertas de liquidación funcionaron porque la conversación tiene un número limitado de recorridos, aunque sigue implicando integraciones de telefonía y backend, suficientes para demostrar la arquitectura sin intentar resolverlo todo de golpe.

Hubo varios aspectos importantes en esa elección:

• Alcance acotado, complejidad real. El caso de uso necesita suficiente variedad para probar la telefonía y la integración con el backend, no solo un recorrido ideal predefinido.
• Llegar rápido a producción. Cuanto más tiempo permanece un desarrollo en fase de creación, más se tarda en obtener las conversaciones reales que generan el feedback que de verdad mejora al agente. Neely lo llamó «el último 20 %»: la parte que solo aparece cuando clientes reales hablan con el sistema.
• Volumen e impacto a la vez. Admiral empezó con interacciones sencillas y de gran volumen, en las que tiempos de espera más cortos y una resolución más rápida marcarían una diferencia visible en la experiencia del cliente.

Eleva el nivel, no lo rebajes, antes de escalar

La dirección de Admiral dejó claro que los agentes de IA debían elevar el nivel de cumplimiento normativo y pruebas, no rebajarlo. Kampa lo expresó directamente: el estándar de validación debe ser más estricto que el anterior, porque el riesgo de que un agente se salga del guion o incumpla una norma es sustancialmente distinto de que un agente humano tome una decisión.

Ese estándar se reflejó en tres compromisos que el equipo asumió desde el principio:

• Diseña para producción, no para una prueba de concepto. Kampa pidió a sus equipos que diseñaran desde el primer día pensando en poner el producto en marcha, en vez de hacer un pequeño experimento que nunca escale.
• Una gobernanza que avance al ritmo de la tecnología. Kampa señaló que un proceso de gobernanza que tarda seis meses en aprobar algo corre el riesgo de aprobar una tecnología que ya está desfasada cuando se implementa. Admiral rediseñó el ritmo de sus revisiones para adaptarlo a la velocidad con la que cambiaban los modelos y herramientas subyacentes.
• Equipos legal y de cumplimiento normativo desde el día cero. Al preguntar cuándo se unieron los equipos legal y de cumplimiento normativo al proyecto, tanto Kampa como Clark respondieron de inmediato: desde el día cero, con un piloto de alcance claramente definido —un número concreto de llamadas—, en lugar de una solicitud abierta de aprobación.

Deja que la normativa marque el mínimo, no todo el diseño

Clark dejó claro que los requisitos normativos —como informar a un cliente de que está hablando con una IA y, en algunas jurisdicciones, ofrecer la posibilidad de pasar a una persona— varían entre Reino Unido, Italia, Francia y España. Admiral diseñó sus agentes para gestionar estas diferencias sin permitir que una persona que llama use la «escalada» para salir de una conversación que puede resolverse.

Algunas conversaciones se mantienen completamente fuera del alcance del agente: Admiral deriva a clientes vulnerables o en situación de angustia a agentes humanos, y ha entrenado la IA para detectar las señales que activan esa derivación.

Kampa describió el enfoque general como un modelo por capas: «La normativa es solo el mínimo», sobre el que se asientan las propias normas internas y estándares culturales de Admiral, que en ocasiones van más allá de lo que exige la normativa.

Este enfoque por capas también determinó dónde utilizaba Admiral lógica determinista y no determinista. Clark explicó que el razonamiento no determinista es adecuado para entender la intención de quien llama o detectar angustia, mientras que todo lo que la empresa necesite poder demostrar, una declaración normativa obligatoria o un recorrido por el que deba guiarse al cliente, debe ejecutarse de forma determinista, sin ningún margen para que el agente improvise.

Neely explicó cómo la estructura de workflow de ElevenLabs lo facilita en la práctica: los agentes se crean como un conjunto de subagentes especializados, con puertas deterministas —como la autenticación— que habilitan o restringen funciones según se cumpla una condición, en lugar de dejar que el modelo infiera qué puede hacer.

Crea conjuntamente con quienes gestionan el proceso

En lugar de un traspaso tradicional entre los requisitos de negocio y el desarrollo de ingeniería, Admiral y ElevenLabs realizaron talleres presenciales que reunieron en una misma sala a quienes conocían el caso de uso, al equipo de ingeniería y al equipo de telefonía. Neely explicó que el primer taller produjo una versión 0 funcional del agente, conectada al backend y a la telefonía, en cuatro o cinco horas; después, Kampa y Clark pudieron hacer una demostración interna para conseguir la aprobación y seguir desarrollándolo.

Clark afirmó que esta cercanía fue importante más allá del primer prototipo: quienes gestionan el negocio están ahora lo bastante cerca de la tecnología como para realizar algunos cambios por su cuenta, porque el taller planteó la plataforma como una forma de trasladar un proceso de negocio existente, no de introducir uno nuevo y desconocido. Kampa lo relacionó con la gestión del cambio en general: involucrar desde el principio a responsables, mandos intermedios y personal de primera línea para que la tecnología forme parte de cómo funciona realmente el negocio, y no sea un proyecto paralelo.

El verdadero trabajo empieza en producción

Una vez en marcha, Admiral trata todos los cambios en un agente, grandes o pequeños, de la misma forma: como una rama que se somete a una batería completa de pruebas de simulación antes de llegar a clientes. Clark describió cómo comienzan un despliegue con el 1 % del tráfico, observan en tiempo real las métricas de satisfacción y resolución de clientes, y lo amplían al 100 % cuando los resultados se mantienen; un ciclo que ha pasado de semanas a horas.

De ese proceso de iteración destacaron dos lecciones:

• Localiza el idioma, no solo las palabras. Al principio, Admiral redactó todos los prompts y workflows en inglés y comprobó que el rendimiento en Francia, España e Italia no igualaba al de Reino Unido. Reescribir los prompts directamente en el idioma de cada mercado, en lugar de traducirlos desde el inglés, generó respuestas acordes con las expectativas y la cultura locales de clientes.
• Hay que tomarse en serio las pruebas de simulación, no tratarlas como un trámite. Neely señaló que redactar un prompt que supere unas pocas pruebas simuladas parece fácil, pero crear baterías de pruebas que realmente pongan al límite al agente y definir criterios de éxito claros desde el principio es el trabajo más difícil e importante. Admiral ejecuta ahora entre cientos y miles de conversaciones simuladas para cada cambio antes de implementarlo.

En cuanto a resultados, Kampa destacó el tiempo de gestión como la métrica más reveladora: las conversaciones lideradas por IA suelen llegar a la misma resolución más rápido que las gestionadas por personas, en parte porque no hay silencios mientras carga un sistema. También describió cómo el CSAT y las tasas de resolución aumentaban gradualmente, mercado a mercado, mediante rondas repetidas de pruebas y ajustes, en lugar de con un único salto.

Qué aprender de esto si estás empezando

El consejo de Neely para los equipos que empiezan este trabajo es elegir un caso de uso bien definido, llevarlo rápidamente a producción y dejar que las conversaciones reales con clientes —no más pruebas previas al lanzamiento— se encarguen de encontrar los casos límite. Clark añadió que, una vez probadas las integraciones en ambos extremos —telefonía y sistemas internos—, escalar a otros casos de uso es cada vez más rápido, porque el equipo ya sabe qué evaluaciones y métricas importan.

El mensaje final de Kampa miraba más allá: la ambición no se limita a automatizar conversaciones, sino que busca usar la misma capa de IA para ayudar directamente a agentes humanos, mediante transcripciones en directo, sugerencias de la siguiente mejor acción y simulaciones de formación.

Como resumió nuestro anfitrión, el hilo conductor de esta conversación es que la normativa y la IA no están enfrentadas. Diseñar desde el día cero pensando en la auditabilidad, la coherencia y la derivación a personas hizo que los agentes de Admiral fueran más disciplinados, no menos.

Ver la sesión completa

Mira la sesión completa aquí, incluida la creación en directo y la ronda de preguntas y respuestas del público.