Decisiones de siniestros según llegan los informes
Un siniestro tarda semanas y cambia a medida que llegan informes. Decisimo aplica su política escrita al caso, con revisión de un tramitador.
La política de siniestros sigue la evidencia del caso
Siniestro como caso
Las tareas se ejecutan cuando consta la evidencia que necesitan
Revisión actualizada
Los cambios reejecutan tareas y asignan otra revisión al mismo rol
Base registrada
Las filas del equipo registran la base y el motivo en el caso
Cambios de política
El equipo edita reglas, tablas y scorecards
Alertas de fraude identificadas
Las reglas generan alertas con nombre para que las lea el tramitador
Riesgo estándar
El equipo de suscripción edita el flujo de decisiones para resolver riesgos estándar en una llamada
Siniestro de automóvil, del primer aviso a la carta de liquidación
Aviso del siniestro
Cobertura y valor
Informe pericial
Indicadores de fraude
Base de liquidación
Revisión del tramitador
Carta de liquidación
El siniestro como caso que sigue la evidencia
- Sin orden fijoCada tarea se ejecuta cuando se cumplen sus condiciones.
- Vista de flujoConecta la tarea que escribe un valor con todas las tareas que lo leen
- Seis tipos de tareaRevisión humana, nota, lógica de decisión, extracción con IA, lectura de documentos y llamada externa
Equipo de siniestros edita filas: reparar o pérdida total
- Dos condicionesLa relación entre reparación y valor y el dictamen pericial forman cuatro filas
- Pérdida totalMás de 0.7 implica pérdida total, igual que el dictamen pericial
- Motivos clarosCada fila registra su motivo en el caso para la revisión y la carta
Qué vuelve a ejecutarse cuando llega tarde un informe
- Dato actualizadoLa tarea que leyó el dato vuelve a ejecutarse por sí sola
- Lógica y cartaEl tipo de caso fija el presupuesto para llamadas, lectura documental y extracción con IA
- Nueva tarea de revisiónEl mismo rol recibe los datos actuales. La revisión y la decisión anteriores siguen en el caso.
Indicadores de fraude: alertas con nombre para el tramitador
- Plazo del siniestroAviso dentro de los 30 días del inicio o más de 14 días tras el incidente
- Historial de siniestrosTres o más siniestros en tres años, o sin tercero identificado
- Alertas para revisarLas reglas generan alertas para el tramitador. Ninguna rechaza un siniestro.
Suscripción edita el flujo: riesgo estándar, una llamada
- Edición en el portalEl equipo edita fuentes, reglas, tablas, scorecards y funciones
- Nombre del releaseLa respuesta del endpoint identifica el release. El endpoint puede exigir aprobación.
- Lógica compartidaUna tarea del caso puede usar las mismas reglas, tablas, scorecards y funciones
La obligación sigue siendo de la aseguradora
- Ley de IA de la UEEvaluar riesgos y fijar precios en vida y salud es de alto riesgo desde el 2 de diciembre de 2027
- Artículo 22 del RGPDSe aplica hoy a las decisiones automatizadas
- Registro de decisionesLas entradas y salidas pueden guardarse en el Postgres de la aseguradora
Lo que queda en manos de la aseguradora
- Caso de demostraciónLas capturas muestran valores de un caso de demostración
- Política de la aseguradoraLa política de la aseguradora se ejecuta sobre los datos que esta proporciona
- Decisión del tramitadorEl tramitador revisa las alertas y decide sobre el siniestro
Preguntas que nos hacen
¿Puede la política resolver parte del siniestro y enviar el resto al tramitador?
La tabla de base de liquidación registra en el caso la reparación o la pérdida total y su motivo. El tramitador revisa el caso en Decisimo.
¿Qué ocurre si un informe pericial cambia una reparación autorizada?
Las tareas que leyeron el valor modificado se ejecutan de nuevo. El mismo rol recibe una nueva tarea de revisión con los valores actuales, y la revisión anterior queda en el caso.
¿Dónde se guarda el registro de cada decisión?
Para el riesgo estándar, las entradas y salidas de cada decisión pueden guardarse en la base de datos Postgres de la aseguradora.