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 jurídico y de cumplimiento normativo desde el primer día 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 de Admiral en producción, las ofertas de liquidación en su negocio de préstamos en Reino Unido, tenía un alcance suficientemente delimitado para implementarse en un plazo realista, pero implicaba telefonía e integraciones de backend, lo bastante como para demostrar la arquitectura sin resolverlo todo de una vez.
• Eleva el listón antes de escalar, no lo bajes. Admiral diseñó para producción desde el primer día, replanteó el ritmo de su gobernanza para avanzar al ritmo de la tecnología e involucró a los equipos jurídico y de cumplimiento normativo desde el primer día con un piloto de alcance claramente definido.
• La normativa es el mínimo, no todo el diseño. Admiral añade sus propias normas internas a lo que exige la normativa, utiliza lógica determinista para todo aquello que debe poder demostrarse y deriva a clientes vulnerables o en situaciones de angustia a agentes humanos.
• El trabajo de verdad empieza en producción. Cada cambio en un agente se prueba con una completa suite 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 de Admiral en producción fueron las ofertas de liquidación en su negocio de préstamos en Reino Unido: un punto de partida controlado de forma deliberada, 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 con los que experimentar antes de expandirse.

Neely explicó que este patrón distingue los despliegues que llegan a producción de los que se estancan: el caso de uso debe estar lo bastante acotado para resolverse en un plazo realista, pero ser lo bastante complejo 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, pero aun así implica telefonía e integraciones de backend, lo suficiente para demostrar la arquitectura sin intentar resolverlo todo de una vez.

Hubo varios aspectos importantes en esa elección:

• Alcance delimitado, 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 conversaciones reales que generen el feedback que realmente mejora el 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, donde unos tiempos de espera más cortos y una resolución más rápida supondrían una diferencia visible en la experiencia del cliente.

Eleva el listón antes de escalar, no lo bajes

La dirección de Admiral dejó claro que los agentes de IA debían elevar el listón en materia de cumplimiento normativo y pruebas, no bajarlo. Kampa lo expresó directamente: el estándar de validación debe ser más estricto que antes, porque el riesgo de que un agente se salga del guion o incumpla una norma es de una naturaleza distinta al de un agente humano que toma 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 el objetivo de lanzar la solución, en lugar de realizar 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á obsoleta cuando se implementa. Admiral replanteó el ritmo de sus revisiones para ajustarlo a la velocidad a la que cambiaban los modelos y las herramientas subyacentes.
• Equipos jurídico y de cumplimiento normativo desde el primer día. Al preguntar cuándo se unieron los equipos jurídico y de cumplimiento normativo al proyecto, tanto Kampa como Clark respondieron de inmediato: desde el primer día, con un piloto de alcance claramente definido —un número determinado 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 regulatorios, como informar a un cliente de que está hablando con una IA y ofrecer la posibilidad de derivar la conversación a una persona en algunas jurisdicciones, varían entre Reino Unido, Italia, Francia y España. Admiral diseñó sus agentes para gestionar esas diferencias sin permitir que una persona que llama use la «derivación» para evitar una conversación que puede resolverse.

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

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

Este sistema de capas también determinó dónde utilizaba Admiral lógica determinista y no determinista. Clark explicó que el razonamiento no determinista resulta adecuado para comprender la intención de quien llama o detectar angustia, mientras que todo aquello que la empresa necesite poder demostrar, una declaración reglamentaria obligatoria o un recorrido por el que deba pasar el cliente, debe ejecutarse de forma determinista, sin tolerancia alguna a que el agente improvise.

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

Cocrear con quienes gestionan el proceso

En lugar de realizar el traspaso tradicional entre los requisitos de negocio y el desarrollo de ingeniería, Admiral y ElevenLabs organizaron 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 v0 funcional del agente, conectada al backend y a la telefonía, en cuatro o cinco horas. Kampa y Clark pudieron entonces mostrarla internamente para conseguir la aprobación necesaria para seguir desarrollando.

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

El trabajo de verdad empieza en producción

Una vez en marcha, Admiral trata cada cambio en un agente, grande o pequeño, de la misma manera: como una rama que se somete a una completa suite de pruebas de simulación antes de llegar a clientes. Clark describió cómo inician un despliegue con el 1 % del tráfico, supervisan 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, en un ciclo que ha pasado de semanas a horas.

Dos lecciones destacaron en ese proceso de iteración:

• Localiza el idioma, no solo las palabras. Al principio, Admiral redactó todos los prompts y workflows en inglés y descubrió 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 del inglés, generó respuestas más acordes con las expectativas y la cultura locales de clientes.
• Las pruebas de simulación deben tomarse en serio, no tratarse como una formalidad. Neely afirmó que escribir un prompt que supere unas cuantas pruebas simuladas parece fácil, pero crear suites de pruebas que realmente pongan al agente bajo presión y definir criterios de éxito claros desde el principio es el trabajo más difícil e importante. Admiral realiza ahora entre cientos y miles de conversaciones simuladas para cada cambio antes de implementarlo.

En cuanto a los resultados, Kampa destacó el tiempo de gestión como la métrica más relevante: las conversaciones dirigidas por IA suelen alcanzar la misma resolución más rápido que las dirigidas por personas, en parte porque no hay silencios mientras se carga un sistema. También describió cómo las puntuaciones de CSAT y las tasas de resolución aumentaban progresivamente, mercado a mercado, a través de rondas repetidas de pruebas y ajustes, en lugar de dar un único gran salto.

Qué puedes extraer de esto si estás empezando

El consejo de Neely para equipos que empiezan este trabajo: elige un caso de uso bien definido, llévalo a producción rápidamente y deja 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 punto final de Kampa fue más allá: la ambición no se limita a automatizar conversaciones, sino que busca utilizar la misma capa de IA para apoyar directamente a agentes humanos mediante transcripciones en directo, indicaciones sobre la mejor acción siguiente y simulaciones de formación.

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

Ver la sesión completa

Mira la sesión completa aquí, incluido el desarrollo en directo y la sesión de preguntas y respuestas con la audiencia.