Contratos inteligentes en seguros: automatización de reclamaciones y pólizas

Los seguros establecen qué cobertura recibe una persona o una empresa y en qué circunstancias corresponde una prestación. Algunas pólizas vinculan el pago a eventos medibles, como un retraso de vuelo o un determinado nivel de lluvia. En esos casos, los contratos inteligentes pueden automatizar una parte del proceso a partir de datos y reglas previamente definidos.

La relación entre la póliza, la fuente de datos y el código permite entender qué se automatiza y qué sigue bajo responsabilidad de la aseguradora. La regla ejecutada debe corresponder a la cobertura acordada, y el producto necesita prever cómo atender datos incorrectos, discrepancias y reclamaciones.

Qué parte del seguro puede ejecutar un smart contract

Un programa puede comprobar fechas, límites, estados y autorizaciones; calcular un importe según una fórmula y ordenar un pago disponible en la red. Necesita una transacción o llamada que active la operación. Un hecho externo, como la llegada de un vuelo, debe introducirse mediante un servicio de datos u oráculo.

La póliza define cobertura, exclusiones y obligaciones. El contrato inteligente implementa una parte de esas condiciones. Si hay una diferencia entre documento y código, publicarlo en una red blockchain no elimina el conflicto ni convierte automáticamente el resultado técnico en la solución jurídica.

Por eso conviene identificar qué decisiones son mecánicas y cuáles necesitan interpretación o revisión. Validar una fecha no equivale a valorar responsabilidad en un accidente. Automatizar ambas como si fueran el mismo problema produce una falsa sensación de certeza.

Seguro paramétrico y riesgo de base

El seguro paramétrico vincula el pago a un índice o evento definido, en lugar de calcular cada indemnización a partir del daño individual observado. Existe sin blockchain. Añadir un contrato inteligente cambia el modo de ejecutar o registrar el proceso, no la naturaleza de ese diseño.

El riesgo de base aparece cuando el pago determinado por el índice no coincide con la pérdida real. Puede haber daño sin que se alcance el umbral, o un pago superior al perjuicio. El Banco Mundial describe esta limitación en sus trabajos sobre seguros paramétricos. Un oráculo correcto no la elimina: puede transmitir exactamente un índice que representa de forma imperfecta la situación del asegurado.

Ejemplo de un flujo por retraso de vuelo

Imaginemos una cobertura ficticia que paga 100 € por un retraso de llegada de al menos tres horas. Antes de venderla, el diseño debe definir vuelo, aeropuerto, hora de referencia, zona horaria, fuente de datos y tratamiento de cancelaciones o desvíos. El importe y el umbral de este ejemplo no corresponden a una oferta comercial.

La aplicación registra la cobertura y su vigencia. Tras el vuelo, un servicio obtiene el dato previsto y envía una operación al contrato. Este comprueba que la póliza estaba activa, que no se pagó antes y que el umbral se cumple. Después registra el resultado y ejecuta el pago mediante el mecanismo definido.

La prueba importante incluye las excepciones: fuente sin respuesta, dato corregido, identificador duplicado y fondos insuficientes. También hay que decidir qué verá el usuario mientras espera y cómo podrá reclamar. «Pendiente de dato» y «sin cobertura» son estados diferentes y deben comunicarse como tales.

Oráculos, fondos y correcciones

El oráculo conecta una fuente externa con la regla del contrato. Su firma permite comprobar quién suministró el dato; no demuestra por sí sola que el dato sea verdadero. La arquitectura debe establecer antigüedad máxima, fuentes aceptadas, respuesta ante discrepancias y permisos para corregir errores.

La automatización tampoco crea capacidad de pago. Hay que diseñar dónde están los fondos, qué entidad responde por la obligación y cómo se concilia cada operación con sus sistemas. Un saldo visible en un contrato no acredita por sí solo la solvencia de todo un negocio asegurador.

Los permisos de pausa y actualización merecen revisión específica. Pueden facilitar la respuesta a un fallo y, a la vez, concentrar capacidad de intervención. Deben estar documentados, probados y vinculados a responsables. Su existencia no debe descubrirse durante una reclamación.

Privacidad y supervisión

Los datos médicos, informes y documentos de identidad necesitan controles de acceso y conservación. Publicarlos en una red abierta puede exponerlos de forma difícil de corregir. Mantener documentos fuera de la cadena y registrar referencias limitadas es una opción de diseño, pero incluso esas referencias pueden permitir identificar personas.

EIOPA examinó oportunidades y riesgos de blockchain en su documento de discusión de 2021: integración, seguridad, privacidad y gobierno forman parte de la evaluación. Es un análisis supervisor, no una autorización de cualquier producto basado en contratos inteligentes. La actividad y la distribución del seguro siguen requiriendo su propio encaje normativo.

Cómo comprobar si la automatización compensa

El piloto debería comparar el proceso actual con el propuesto: tiempo desde la disponibilidad del dato hasta el pago, operaciones que necesitan intervención, errores de conciliación y coste de mantenimiento. La referencia es el flujo completo, no solo el tiempo de ejecución de una transacción.

Antes de producción, prueba correspondencia entre póliza y código, pagos duplicados, límites, oráculos caídos y recuperación. Una auditoría de contratos inteligentes aporta evidencia sobre un alcance técnico concreto. La calidad del producto depende también de su diseño asegurador, sus datos y la atención de las incidencias.