Automatización en seguros: pólizas y siniestros

En casi todas las aseguradoras y agencias con las que hablamos se repite el mismo cuadro. Un siniestro tiene toda la información necesaria para avanzar, pero está repartida en tres lugares que no se comunican. El sistema de pólizas sabe qué cubre el contrato. Las fotos del daño y el parte del asegurado llegaron por correo. El estado real de cada expediente está en una planilla que nadie reconoce como sistema oficial, aunque el equipo la usa como tal porque el sistema de pólizas se actualiza tarde.

Alguien pasa buena parte de su jornada copiando datos entre esos tres lugares. Ese traspaso es la parte que un robot hace mejor que una persona. Decidir si el siniestro se paga sigue siendo tarea del equipo.

El seguro trabaja con datos estructurados y plazos estrictos, con consecuencias legales si se incumplen, y por eso en teoría es un candidato natural para RPA. En la práctica llega tarde a la automatización, igual que otros sectores regulados. El sistema núcleo suele ser un sistema de administración de pólizas (policy admin system) o, en aseguradoras pequeñas, un ERP adaptado. Lleva años en uso, sin API o con integraciones caras, y nadie quiere intervenir el sistema del que depende toda la operación.

Emisión y renovación de pólizas

Entre la cotización y la póliza emitida casi siempre hay una reescritura manual. El sistema de cotización captura los datos del cliente y del riesgo y calcula la prima. Después alguien vuelve a ingresar esos mismos datos en el sistema de pólizas para emitir el contrato definitivo, porque los dos sistemas no comparten base de datos. En el camino se revisan las reglas de suscripción: sumas aseguradas máximas, exclusiones, edades límite y documentación mínima según el producto.

Un robot para este tramo toma la cotización aprobada y la traspasa al sistema de pólizas campo por campo. Antes de emitir aplica la misma matriz de reglas de suscripción que hoy revisa una persona con una lista impresa al lado, y la póliza sale solo si la cotización cumple todas. Las que fallan pasan a un reporte aparte con el motivo exacto por el que se detuvieron, para que las revise un suscriptor.

Los números de póliza y la fecha de vigencia no van escritos dentro del flujo. Quedan en el archivo de configuración del proyecto, junto con las rutas de las carpetas donde llegan las cotizaciones. Cada póliza emitida se registra en la base SQLite local del proyecto, así que si el robot reprocesa las cotizaciones del día no emite dos veces la misma.

Las renovaciones recorren el mismo camino en sentido inverso. El robot revisa la cartera según la fecha de vencimiento, arma la propuesta de renovación con la prima recalculada y la deja lista para que un agente la envíe. Nadie tiene que abrir una planilla el primer día de cada mes para saber qué pólizas vencen.

Recepción y validación de siniestros

Un siniestro llega por correo, por un portal o, en muchas agencias, todavía por WhatsApp. Alguien lo lee, arma el expediente, verifica que la póliza esté vigente y que el evento tenga cobertura, y confirma que llegó toda la documentación que exige ese tipo de siniestro. Solo entonces lo deriva a un ajustador.

Automatizamos primero ese tramo, el que determina si el expediente está completo, porque es el que más tiempo del plazo de respuesta consume y casi no requiere criterio experto. El robot toma el siniestro en cuanto entra, cruza el número de póliza con el sistema para confirmar vigencia y cobertura, y compara la documentación recibida con el checklist de ese tipo de evento. Si en un robo falta el parte policial, o en un choque falta el presupuesto del taller, genera el pedido al asegurado con el documento puntual que falta. Sin automatización, ese faltante lo descubre un analista tres días después, cuando por fin abre el expediente. El caso entra a la cola del ajustador solo cuando está completo, con todo cargado y ordenado.

Aprobar, rechazar o pedir una pericia adicional sigue siendo decisión de alguien con la formación para tomarla. El robot tampoco evalúa cobertura en casos límite ni estima el monto a pagar. Su tarea es entregar el expediente armado, para que quien decide no gaste tiempo en reunir papeles.

Documentos del siniestro y extracción de datos

Un expediente de siniestro reúne fotos del daño, parte policial, certificado médico si hubo lesiones, presupuesto del taller y factura de reparación. Cada documento llega en un formato distinto, muchos como foto tomada con el celular, y alguien los abre uno por uno para transcribir los datos que importan: número de parte, monto del presupuesto y fecha del evento.

Esto se resuelve con la misma lógica que explicamos en IDP: procesamiento inteligente de documentos. El modelo extrae los campos y el robot valida las cuentas: que la suma de los ítems del presupuesto coincida con el total y que la fecha del parte sea igual o posterior a la del evento. Si alguna validación falla, el documento queda marcado para revisión y el robot no sigue adelante con un valor supuesto.

En seguros hay una validación adicional que en facturación no existe, que es comparar contra los límites de la póliza. Si un presupuesto de taller supera el límite de cobertura del producto contratado, o un certificado médico menciona una condición preexistente excluida, el robot detiene el expediente y avisa a un analista antes de que avance hacia el pago.

Endosos sobre la base del robot de emisión

Un endoso (agregar un conductor, cambiar la dirección del riesgo, ajustar la suma asegurada) usa el mismo motor que la emisión. También comparte reglas de validación con siniestros, porque con frecuencia es un siniestro el que revela que la póliza tenía un dato desactualizado. Si ya tienes el robot de emisión, el de endosos es una extensión menor que se construye sobre él. Cuando ordenes tus candidatos con el criterio de reutilización al priorizar, súmale puntos a cualquier proceso que comparta sistema y reglas con un robot que ya existe, porque rinde más de lo que su impacto individual sugiere.

Cuándo no conviene automatizar

Con una cartera pequeña, donde los siniestros del mes se cuentan con los dedos de una mano, basta con un buen checklist en papel y alguien ordenado. Si un proveedor te propone un proyecto de RPA para ese volumen, desconfía. A esa escala, el robot tarda más en pagarse que en quedar obsoleto.

Siniestros tampoco es buen punto de partida si el criterio sobre qué documentación pedir cambia según quién atiende el caso. El robot automatiza un proceso que existe y está escrito. Cuando ese proceso depende de dos personas con criterios distintos, la aseguradora primero tiene que elegir una sola versión y documentarla.

Cuánto cuesta y por dónde empezar

Un desarrollo de este tipo cuesta en promedio unos USD 6.000, con la marcha blanca incluida (el detalle está en cuánto cuesta automatizar un proceso). El soporte posterior es opcional, desde USD 300 al mes.

Entre emisión y siniestros, la mayoría de las aseguradoras con las que trabajamos empieza por siniestros. Es el proceso donde el asegurado sufre el atraso directamente, porque es él quien espera mientras el expediente sigue incompleto, y una respuesta más rápida se traduce en menos reclamos y en mejores resultados en las encuestas de satisfacción. La emisión libera más horas internas, pero esa mejora rara vez se nota desde fuera de la aseguradora.

Preguntas frecuentes

Si tu aseguradora o agencia ya sabe dónde pierde más tiempo entre pólizas y siniestros, el orden para automatizar depende del tamaño de la cartera y del canal por donde entran los reclamos. Escríbenos con esos dos datos y te decimos qué tramo conviene abordar primero. El método para ordenar esa decisión está en cómo priorizar qué procesos automatizar, y los criterios para elegir a quién confiarle el proyecto, en el artículo sobre cómo elegir un partner de RPA en LatAm.