Situación del cliente
Aseguradora mediana española con ~1,2 millones de pólizas en ramos de hogar y autos. Tiempo medio de resolución: 22 días para siniestros de hogar, 18 días para autos. NPS en siniestros: −12. El problema no era la velocidad del perito, sino el tiempo muerto entre etapas: 3 días esperando asignación de perito, 4 días esperando revisión del tramitador, 2 días esperando validación del supervisor. El 34% del tiempo total del proceso era espera burocrática, no trabajo real.
El 18% de los siniestros presentaban fraude potencial, pero la detección era reactiva con reglas rígidas que generaban un 40% de falsos positivos, creando fricciones innecesarias con asegurados legítimos. La dirección solicitaba inicialmente un "chatbot para que el asegurado consulte el estado de su siniestro". Propusimos rechazar ese scope: un chatbot no resuelve el problema cuando el proceso real tarda 22 días.
Retos
- Estado persistente durante semanas: un expediente de siniestro puede estar activo durante semanas con múltiples actores (asegurado, perito, tramitador, supervisor) — requiere memoria de sesión que sobreviva entre interacciones
- Heterogeneidad de informes periciales: cada perito usaba su propio formato; el 23% de los campos clave no se extraían correctamente con procesamiento estándar
- Modelo de fraude no generalizable: entrenado con datos 2019-2023, rendía significativamente peor con patrones de 2025 (especialmente fraude organizado con talleres colaboradores)
- Bloqueo legal en pagos autónomos: el diseño original permitía aprobar pagos de hasta 1.500€ de forma autónoma; el departamento legal lo bloqueó por reglamento interno de poderes
- Latencias en producción a volumen: en el PoC las latencias eran aceptables; en producción real (400-600 siniestros diarios) el agente de tramitación superaba los 45 segundos por expediente
- Auditabilidad DGS: cumplimiento de los requisitos de la Dirección General de Seguros e ICEA para registro y trazabilidad de decisiones automatizadas
Solución implementada
- Amazon Bedrock AgentCore como runtime central: la memoria persistente de AgentCore permitió que cada siniestro = una sesión con estado completo accesible para todos los agentes durante semanas, sin construir esa infraestructura desde cero
- Workflow agéntico en tres fases con EventBridge: Agente de Apertura (12 min vs. 3 días para asignación de perito), Agente de Tramitación + Agente de Fraude en paralelo, y Agente de Cierre. EventBridge como bus de eventos con reintentos automáticos y historial auditable
- Análisis multimodal de informes periciales: Textract + análisis multimodal de Claude en Bedrock para interpretar PDFs e imágenes de daños simultáneamente. Tasa de error de extracción: del 23% al 3%
- Modelo de fraude con reentrenamiento mensual: fine-tune propio en PyTorch sobre DLC de SageMaker, con pipeline de reentrenamiento automático mensual y módulo de anomaly detection no supervisado para patrones nuevos. Los DLC garantizan que el procesamiento permanece dentro de la VPC del cliente
- Human-in-the-loop optimizado: para pagos, el agente prepara el expediente completo y lo pone en cola de "aprobación en un clic". El tramitador revisa en 15 minutos en lugar de 4 días — no es autonomía total, pero es el resultado que importa y cumple el reglamento interno
- Paralelización y caché: tool calls paralelos para fuentes sin dependencia de datos + caché en DynamoDB para condicionados de póliza. Latencia de >45s a 8-12 segundos en producción
Ventajas para el cliente
Patrón de arquitectura
Workflow agéntico end-to-end para tramitación de siniestros con Amazon Bedrock AgentCore como runtime de estado persistente (cada expediente = una sesión activa durante semanas), SageMaker DLC PyTorch para detección de fraude y EventBridge como bus de transiciones de estado auditable para la DGS.
- AgentCore Memory para workflows de larga duración — cada expediente es una sesión con estado persistente accesible para todos los agentes durante semanas, sin construir esa infraestructura de estado a mano.
- DLC PyTorch en SageMaker dentro de VPC — el modelo de fraude procesa datos de pólizas y clientes. La inferencia nunca sale al endpoint público; es un requisito no negociable con la DGS.
- Pipeline de reentrenamiento mensual automático — los modelos de fraude degradan con el tiempo. Configurar desde el inicio el pipeline con nuevos datos etiquetados y anomaly detection para patrones emergentes de fraude.
- EventBridge con reintentos backoff exponencial — cada transición de estado es un evento auditable. El historial de eventos es el log de auditoría para supervisores. Diseñarlo desde el día 1.
- Human-in-the-loop en pagos es obligatorio regulatoriamente — diseñar la aprobación de pago "en un clic" desde el inicio, no como concesión posterior. El regulador no acepta pagos 100% automatizados sin supervisión.
- Análisis multimodal para documentos no estructurados — combinar Textract + Bedrock multimodal reduce la tasa de error en extracción de datos de siniestros del 23% al 3%.