Blog de Amazon Web Services (AWS)
Autoevaluación Inteligente de Siniestros: cómo Consorcio digitalizó la inspección vehicular con Amazon Bedrock
Por Izabela Rubens, Innovation Specialist Lead for SOLA.
El proceso de reportar un daño vehicular leve no debería tomar 49 días. Pero eso era exactamente lo que ocurría: el asegurado coordinaba una cita, trasladaba el vehículo y esperaba al liquidador. Luego aguardaba 72 horas para recibir un presupuesto y repetía el ciclo si algo salía mal. En la Región Metropolitana de Chile, ese número llegaba a 53 días, con 28 solo para ingresar al taller y dos visitas presenciales por siniestro como mínimo. El 65% de los asegurados describía el proceso como tedioso.
El primer día que revisamos las métricas de ciclo de siniestros en una reunión de operaciones, el número de 53 días en la Región Metropolitana quedó colgado en el aire un momento más de lo normal. No era nuevo — todos lo conocíamos — pero verlo junto al costo por visita y el volumen mensual lo hizo tangible. Ahí quedó claro que el problema no era de personas ni de procesos: era estructural.
El punto de inflexión llegó con el programa AWS InnoQuest / Shark Tank en Santiago, junio de 2026. Consorcio, uno de los principales conglomerados financieros y aseguradores de Chile, participó junto al partner Strata Analytics para evaluar si la inteligencia artificial generativa podía transformar ese proceso. La respuesta fue sí — con números que respaldan la afirmación.
El equipo llegó al programa con una hipótesis clara. Al trabajar en el diseño inicial, lo que más sorprendió fue la magnitud del problema de datos subyacente: antes de pensar en IA, había que resolver el catálogo. Eso redefinió completamente la secuencia del proyecto.
El problema que hacía inviable escalar el modelo presencial
El proceso de inspección manual tenía un problema de raíz que iba más allá del tiempo: el catálogo de autopartes con el que trabajaban los liquidadores contenía más de 2.743 nombres inconsistentes para las mismas piezas. Un parachoques delantero, un «bumper frontal» y un «paragolpes delantero» podían referirse exactamente al mismo componente según quién llenara el formulario. Esa inconsistencia hacía imposible comparar presupuestos entre talleres, detectar anomalías de costo y, especialmente, entrenar cualquier modelo de IA con datos históricos confiables.
El segundo problema era de escalabilidad. En siniestros leves — donde el vehículo aún circula y el daño es estético o mecánico menor — la inspección presencial consumía los mismos recursos que un siniestro grave. Dos visitas, un liquidador, una ventana de 72 horas: todo eso para daños que en muchos casos eran predecibles y categorizables.
Antes de buscar una solución de IA, el equipo trabajó en el prerrequisito más importante: depurar ese catálogo de autopartes hasta llegar a 786 ítems únicos, normalizados y categorizados. Sin ese trabajo de datos, ningún modelo hubiera podido operar con precisión útil.
Selección del modelo: por qué el benchmarking importa más que el marketing
Amazon Bedrock permite acceder a múltiples modelos fundacionales a través de una sola API (interfaz de programación de aplicaciones), sin gestionar infraestructura. Esa característica fue determinante para la metodología del proyecto: en lugar de comprometerse con un modelo por intuición o popularidad, el equipo evaluó cuatro modelos de inteligencia artificial generativa disponibles en Amazon Bedrock sobre el mismo conjunto de casos reales.
El criterio principal era precisión en visión multimodal — la capacidad de analizar imágenes de vehículos dañados, identificar correctamente qué autoparte estaba afectada y qué acción correspondía aplicar. Los modelos se evaluaron sobre siniestros reales con ground truth conocido.
Arquitectura de la solución: el flujo de 30 segundos
La «Autoevaluación Inteligente de Siniestros» opera en un flujo lineal diseñado para minimizar la fricción del asegurado y maximizar la calidad de los datos que recibe el modelo.
El asegurado inicia el reporte desde su celular y recibe instrucciones para capturar nueve fotos guiadas del vehículo. Cada captura pasa por un proceso de validación de calidad en tiempo real: detección de desenfoque, verificación de iluminación mínima, confirmación de que el encuadre corresponde al ángulo solicitado. Si una foto no cumple los criterios, la aplicación solicita una nueva captura antes de avanzar. Ese paso de validación es fundamental — la calidad del input determina directamente la calidad del output del modelo.
Primero, detecta qué autopartes del catálogo presentan daños visibles en las imágenes. Segundo, descarta daños preexistentes aplicando lógica basada en características visuales de oxidación, desgaste y patrones de impacto que no corresponden a un evento reciente. Tercero, clasifica cada autoparte dañada en una de dos acciones: sustituir o reparar, con base en la extensión y tipo del daño detectado.
Con esa información, el sistema genera un presupuesto interno preliminar consultando los precios asociados a cada autoparte en el catálogo. Todo el proceso, desde que las fotos se cargan hasta que el presupuesto está disponible, toma aproximadamente 30 segundos.
Resultados de la validación: 53 siniestros reales
El equipo validó la solución sobre 53 siniestros reales con ground truth conocido — casos donde el resultado correcto estaba documentado por la inspección presencial previa.
En el período de validación trabajamos con un subconjunto de siniestros leves elegibles — daños estéticos y mecánicos menores en vehículos que aún circulaban. El volumen mensual total de esa categoría en Consorcio es significativamente mayor. Los números exactos son confidenciales, pero la dirección es clara: a escala, la diferencia justifica con amplitud el costo de desarrollo e integración.
El criterio de elegibilidad también es parte del diseño: no todos los siniestros pasan por el flujo automatizado. Los siniestros con daños que superan un umbral de costo estimado, o donde el análisis de la IA detecta ambigüedad alta, se marcan para revisión humana. El sistema no reemplaza al liquidador — le cambia el tipo de trabajo: de visitas de rutina para siniestros simples, a revisión de casos complejos o ambiguos.
Lecciones del programa AWS InnoQuest
El marco del programa Shark Tank de AWS InnoQuest fue relevante por una razón práctica: obligó a definir métricas de éxito antes de construir. El equipo entró con una hipótesis (la IA puede reemplazar la inspección presencial en siniestros leves elegibles), definió cómo la mediría (precisión en acción recomendada, costo por caso, tiempo de respuesta) y ejecutó la validación sobre datos reales antes de escalar.
Presentar ante el jurado del programa fue más útil de lo que esperaba. Las preguntas más difíciles no fueron técnicas — fueron sobre el plan de escalamiento y sobre qué pasaría con los liquidadores en el nuevo modelo operativo. Responder esas preguntas en ese contexto obligó a afinar el mensaje antes de llevarlo a la dirección de Consorcio. Si otros equipos en LATAM están considerando participar en programas similares, ese ejercicio de preparación para el jurado vale por sí solo, independientemente del resultado.
La colaboración con Strata Analytics como partner también fue parte del modelo: combinar el conocimiento de dominio del negocio asegurador con experiencia técnica en IA generativa acortó el tiempo de iteración en el diseño del prompt y en la evaluación comparativa de modelos.
Autora
![]() |
Izabela Rubens es Innovation Specialist Lead for SOLA. Este post describe la solución desarrollada por Consorcio con el apoyo de Strata Analytics en el programa AWS InnoQuest / Shark Tank, Santiago, junio 2026. |
