Desarrollo Insurtech en 2026: Construir, Comprar o Extender

Desarrollo insurtech significa construir el software sobre el que opera una aseguradora o MGA: cotización y tarificación, administración de pólizas, suscripción, siniestros, portales de distribución y las APIs que integran la cobertura en otros productos. En 2026, la respuesta práctica para la mayoría de las aseguradoras es híbrida: comprar o mantener un core system para pólizas y registros financieros, y construir módulos a medida a su alrededor donde el negocio se diferencia. Esta guía explica qué son esos sistemas, cómo decidir entre construir, comprar y extender, con qué hay que integrarse, qué normas europeas y británicas condicionan la arquitectura y cómo acotar un proyecto que llegue a producción.

Qué contiene realmente un sistema insurtech

El "software de seguros" no es una sola aplicación. Es un conjunto de sistemas con ritmos de cambio distintos, y la mayoría de los proyectos fracasa cuando el equipo los trata como uno solo.

Sistema de administración de pólizas (PAS). El sistema de registro de pólizas, endosos, renovaciones, cancelaciones, facturación y comisiones. Guarda la verdad del contrato y alimenta finanzas y el reporte regulatorio. Cambia despacio y equivocarse sale caro.

Motor de cotización y tarificación. Recibe los datos de riesgo (vehículo, inmueble, actividad de la empresa, declaraciones de salud) y devuelve un precio a partir de tablas de tarificación, factores y reglas. Aquí es donde los product managers cambian algo cada mes: nuevos factores, nuevos descuentos, ajustes regionales. Necesita más versionado y auditabilidad que velocidad bruta.

Workbench de suscripción. La herramienta que usan los suscriptores para revisar riesgos derivados: la solicitud, datos de terceros, reglas de apetito, siniestros previos, notas y una decisión. El procesamiento automático (straight-through) resuelve los casos simples; el workbench se ocupa del resto.

Gestión de siniestros. Aviso de siniestro (FNOL), triaje, reservas, asignación de peritos, gestión de documentos y fotos, redes de reparación, pagos, subrogación y comprobaciones de fraude. Siniestros es el dominio con más workflow y por el que los clientes te juzgan.

Portales de corredores y agentes. Front-ends de distribución para intermediarios: cotizar, contratar, modificaciones a mitad de vigencia, renovaciones, documentos, extractos de comisiones. Suele ser la primera construcción a medida, porque los portales de los proveedores son genéricos y los corredores votan con los pies.

APIs de seguro embebido. Endpoints de cotización-contratación-emisión consumidos por un retailer, una plataforma de viajes, una app de car sharing o un prestamista. El producto es el contrato de la API: idempotencia, latencia, sandbox, versionado y semántica de errores clara.

Alrededor de todo esto están los documentos, la firma electrónica, los pagos, KYC/AML, el enriquecimiento de datos y las apps orientadas al cliente.

Construir, comprar o extender un core system

La decisión no es "proveedor o a medida", sino qué capacidad va en qué cesta. Las plataformas core de la clase Guidewire, Duck Creek y Sapiens cubren PAS, facturación y siniestros con productos configurables. Son fuertes en registro y reporte regulatorio, y débiles o caras en cualquier cosa específica del cliente, del canal o de cambio rápido.

Criterio	Comprar el core (clase Guidewire / Duck Creek / Sapiens)	Extender el core (módulos propios alrededor de un PAS de proveedor)	Construir a medida de extremo a extremo
Ideal para	Registros de pólizas, facturación y siniestros; aseguradoras multirramo	Portales, APIs embebidas, flujos de cotización, entrada de siniestros, productos de datos	MGAs de nicho, startups de un solo ramo, productos paramétricos o por uso
Tiempo hasta la primera versión	Largo: los programas de implantación del proveedor duran trimestres	Meses por módulo	Meses para un producto acotado; largo si además reconstruyes el ledger
Velocidad de cambio en productos	Basada en configuración, pero limitada por los ciclos de release del proveedor	Rápida donde el código es tuyo; aún limitada por las APIs del core	La más rápida, con responsabilidad total
Reporte regulatorio	Incluido, maduro	Heredado del core	Lo construyes tú, y la auditoría es tuya
Perfil de coste total	Licencia e implantación caras, coste de operación predecible	Moderado; el esfuerzo de integración es el coste principal	Licencia barata, ingeniería y operación caras
Lock-in del proveedor	Alto	Medio: el core queda atado, tus módulos son portables	Bajo
Talento necesario	Configuradores certificados por el proveedor más ingenieros de integración	Ingenieros de producto con conocimiento del dominio asegurador	Equipos full-stack más experiencia actuarial y financiera
Riesgo típico	Scope creep y personalización dentro del stack del proveedor	Deuda de integración si los contratos no son tuyos	Reconstruir contabilidad y compliance que no necesitabas

Regla práctica para 2026: compra o mantén el ledger, construye la experiencia y los datos. La contabilidad y el reporte regulatorio a medida son difíciles de justificar, salvo que el producto no encaje en ningún modelo de proveedor, lo que ocurre con algunos ramos paramétricos y por uso.

El patrón que más falla es personalizar el core del proveedor hasta que parece una construcción propia; cada personalización profunda bloquea la siguiente actualización. La lógica escrita dentro del PAS para servir a un portal o una API pertenece a un módulo tuyo, que habla con el core a través de un contrato tuyo. Es el mismo razonamiento que al migrar sistemas heredados: estrangula los bordes, no reescribas el centro.

El panorama de integraciones

Cualquier aplicación de seguros es un hub de integraciones. Mapéalo antes del primer sprint; cada conector tiene su propio contrato, modo de fallo e implicación de compliance.

Integración	Qué hace	Modo de fallo típico	Nota de diseño
PAS / sistema de siniestros del core	Sistema de registro de pólizas y siniestros	APIs lentas o solo por lotes; SDKs de proveedor frágiles	Envuélvelo en una capa anticorrupción; nunca expongas modelos del proveedor a los portales
Proveedor de pagos (tarjetas, SEPA, domiciliación)	Cobro de primas, devoluciones, pago de siniestros	Mandatos fallidos, contracargos, huecos de conciliación	Intenciones de pago idempotentes; concilia a diario contra el ledger
KYC / AML y cribado de sanciones	Comprobaciones de identidad, PEP y sanciones en el alta y en el pago	Falsos positivos que bloquean la contratación; listas desactualizadas	Cribado asíncrono con estado de espera, no una puerta síncrona en la cotización
Generación de documentos	Condiciones particulares, IPIDs, certificados, cartas de siniestro	Deriva de plantillas entre idiomas y productos	Versiona las plantillas con la versión de tarificación; renderiza desde datos estructurados
Firma electrónica	Declaraciones de contratación y mandatos	Validez legal entre jurisdicciones; sobres caducados	Guarda paquetes de evidencia con la póliza, no solo un PDF firmado
Proveedores de datos	Datos de vehículos, inmuebles, crédito, clima, telemática, historial de siniestros	Coste por llamada; no disponible en el momento de cotizar	Caché con un TTL acorde al uso legal del dato; fallback a derivación
Redes de reparación y proveedores	Talleres, contratistas, proveedores de reposición	Workflows manuales por email	Asignación basada en eventos con callbacks de estado

Dos decisiones importan aquí más que el resto. Mantén los modelos canónicos de cliente, riesgo, cotización, póliza y siniestro en tus propios servicios; los modelos de proveedores y partners cambian, los tuyos no deberían tener que hacerlo. Y trata cada llamada externa como no fiable: un flujo de cotización debe degradarse cuando un proveedor de datos se cae (deriva el caso, conserva el lead), y un flujo de siniestros debe sobrevivir a una caída del pago sin perder la instrucción.

Regulación en Europa y el Reino Unido: qué significa cada norma para el código

La regulación fija requisitos de arquitectura. Cuatro marcos aparecen en casi cualquier alcance europeo o británico.

RGPD. Datos personales en cotización, póliza y siniestros. En la práctica: base legal y retención por categoría de dato, minimización en los formularios de cotización, acceso y supresión del interesado que alcancen todos los sistemas integrados, y DPIAs para perfilado y decisiones automatizadas. Los datos de salud en vida, salud y algunos ramos de viaje son datos de categoría especial. Nuestra guía de RGPD para equipos de software cubre la parte de ingeniería.

Solvencia II. El régimen prudencial de la UE: requisitos de capital, gestión de riesgos y reporte al supervisor. Los equipos de software rara vez implementan el modelo de capital, pero son dueños de los datos que lo alimentan. La implicación es el linaje de datos: primas, reservas y cifras de siniestros necesitan origen trazable, historial inmutable y totales conciliados entre los sistemas operativos y la capa de reporte. El Reino Unido aplica su propia versión adaptada del régimen.

DORA (Digital Operational Resilience Act). El marco de la UE para el riesgo TIC en entidades financieras, aseguradoras incluidas: gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia y supervisión de proveedores terceros de TIC. Para un equipo de desarrollo: servicios críticos y dependencias documentados, recuperación probada, clasificación y vías de notificación de incidentes, y controles sobre cada SaaS y proveedor cloud de la cadena. Un PAS alojado en la nube, un proveedor de pagos y una API de datos son todos riesgo TIC de terceros bajo DORA.

Consumer Duty de la FCA (Reino Unido). Un estándar de conducta que exige buenos resultados para los clientes minoristas en productos, precio y valor, comprensión y soporte. En términos de software: información de producto clara en el punto de venta, sin dark patterns en los recorridos de cotización y renovación, soporte accesible y evidencia de resultados, lo que implica instrumentar los recorridos y conservar los datos. Los flujos de renovación y renovación automática reciben especial atención.

Según el ramo y el país, también aplican IDD, PSD2, normas nacionales de documentación y requisitos del defensor del cliente. Lleva el compliance al alcance, no al UAT.

Datos e IA en suscripción y siniestros: qué funciona y qué no

Las aplicaciones útiles de la IA son más estrechas de lo que sugieren los pitch decks.

Qué funciona en producción.

• Extracción de documentos: leer formularios de siniestro, facturas, informes médicos y condiciones de pólizas anteriores hacia campos estructurados, con una puntuación de confianza y una cola de revisión.
• Triaje de siniestros: enrutar los siniestros simples y de bajo importe al tratamiento automático y los complejos a peritos, según tipo, importe y señales de inconsistencia.
• Señales de fraude: detección de anomalías y análisis de redes que marcan casos para investigación. La salida es una lista de motivos para un humano, no una decisión.
• Insumos de pricing: modelos que producen factores de riesgo consumidos por el motor de tarificación como features versionadas y explicables.
• Asistentes de soporte sobre documentos de póliza, con retrieval anclado en la póliza del propio cliente.

Dónde están los límites.

• Las decisiones automatizadas con efectos jurídicos o similarmente significativos caen bajo las reglas del RGPD sobre decisiones automatizadas: explicación y una vía de revisión humana. Rechazar una cobertura o un siniestro solo por una puntuación es un problema legal y de conducta.
• El drift de modelo es real: un modelo de pricing entrenado antes de un cambio en la inflación de siniestros o de un nuevo patrón de fraude se degrada en silencio. La monitorización entra en el alcance desde el primer día; ver MLOps en producción.
• Sesgo y discriminación por proxy: las features correlacionadas con características protegidas requieren revisión, y algunos mercados prohíben directamente ciertos factores.
• Los modelos generativos alucinan. Nunca dejes que uno produzca una declaración de cobertura sin anclarla en el condicionado de la póliza y marcarla como orientación.

El contrato de ingeniería es simple: cada salida de modelo almacenada con su versión, snapshot de entrada y explicación; cada resultado automatizado reversible por un humano; cada modelo con una línea base monitorizada.

Patrones de arquitectura que aguantan en seguros

Tres patrones aparecen en casi toda construcción bien llevada.

Siniestros basados en eventos. Un siniestro es un proceso de larga duración con muchos actores: cliente, perito, taller, proveedor médico, sistema de pagos, equipo de fraude. Modelarlo como eventos de dominio (ClaimRegistered, DocumentsReceived, ReserveSet, AssessmentCompleted, PaymentInstructed, ClaimClosed) permite que cada servicio reaccione de forma independiente, da un log de auditoría natural y hace trivial la medición de SLA. Usa un outbox para que los eventos nunca se pierdan entre la escritura en la base de datos y el broker. Los trade-offs están en arquitectura basada en eventos.

Motores de reglas con reglas propias. Las reglas de apetito, derivación, elegibilidad y compliance cambian a menudo y deben ser explicables. Mantenlas como datos (tablas de decisión o un DSL) con versionado, tests y fechas de vigencia, no como if dispersos. Que el motor sea de mercado o un evaluador propio importa menos que tres propiedades: un usuario de negocio puede leer la regla, un test la demuestra y un log muestra qué versión se disparó para una cotización dada.

Tablas de tarificación versionadas. Un precio debe ser reproducible meses después ante una reclamación, una auditoría o un regulador. Eso significa que el motor de tarificación recibe una versión explícita y devuelve un desglose, y las versiones antiguas nunca se editan en su sitio.

{
  "product": "motor-private",
  "ratingVersion": "2026.08.1",
  "effectiveFrom": "2026-09-01",
  "basePremium": 412.00,
  "factors": [
    { "name": "vehicleGroup", "value": "14", "multiplier": 1.12 },
    { "name": "ncdYears", "value": "5", "multiplier": 0.68 },
    { "name": "postcodeZone", "value": "C", "multiplier": 1.05 }
  ],
  "rules": [
    { "id": "REF-017", "version": 3, "outcome": "refer", "reason": "prior-claims >= 2" }
  ],
  "premium": 329.61
}

Guarda este desglose junto con la cotización. Cuando alguien pregunte por qué un cliente pagó ese importe en marzo, respondes con datos.

También merece la pena adoptar: una capa anticorrupción alrededor del core del proveedor, un identificador único de cliente que sea tuyo, APIs idempotentes para cada endpoint embebido y read models separados para portales y dashboards, de modo que el reporte nunca compita con el tráfico transaccional.

Checklist de entrega para proyectos de software de seguros

Una definición de hecho a nivel de programa.

• Modelo de dominio propio: cliente, riesgo, cotización, póliza, siniestro y pago definidos en tus servicios, mapeados a cada modelo de proveedor y partner.
• Tarificación y reglas versionadas: cada versión inmutable, probada, con fechas de vigencia y un desglose almacenado por cotización.
• Pista de auditoría: quién cambió qué, cuándo, desde qué sistema, para pólizas, siniestros, reservas y pagos. Inmutable y consultable.
• Protección de datos integrada: retención por categoría de dato, supresión que se propaga a todos los sistemas integrados, DPIA para perfilado y decisiones automatizadas, tratamiento de categoría especial donde aplique.
• Evidencia de resiliencia: servicios críticos documentados, dependencias mapeadas, recuperación probada, clasificación de incidentes y vía de notificación definidas (preparado para DORA).
• Controles de terceros: contratos, controles de acceso y monitorización para cada proveedor externo, incluidos el proveedor del core y la nube.
• Evidencia de resultados para el consumidor: instrumentación de recorridos, documentos en lenguaje claro, soporte accesible, flujos de renovación y cancelación sin fricción (preparado para Consumer Duty).
• Contratos de integración: esquemas, idempotencia, políticas de reintento y timeout, sandbox para partners, estrategia de versionado.
• Matriz de pruebas: suites de regresión de tarificación contra cotizaciones de referencia, tests de contrato para cada integración, end-to-end para cotización-contratación-emisión y de FNOL a pago.
• Observabilidad: métricas de negocio (tasa de cotización a contratación, tiempo de ciclo de siniestros, tasa de derivación) junto a las técnicas, con alertas a cargo de personas con nombre.
• Seguridad de release: feature flags para cambios de producto, canary releases para cambios de precio, rollback probado.
• Línea base de seguridad: autenticación para clientes, corredores y personal con roles distintos, cifrado en reposo y en tránsito, gestión de secretos, escaneo de dependencias en CI.

Cómo acotar un proyecto insurtech

La mayoría de los sobrecostes vienen del alcance, no de la tecnología. Responde seis preguntas.

1. ¿Qué ramo y qué canal? Un ramo, un canal para la primera versión: auto a través de un comparador, mascotas directo al consumidor, o un paquete de empresas a través de cinco corredores. Multirramo y multicanal desde el primer día es un programa, no un proyecto.
2. ¿Dónde vive el registro de la verdad? Si existe un PAS core, sigue siendo el ledger y el proyecto se construye a su alrededor. Si no existe, decide ahora si lo correcto es un core de proveedor o un ledger propio ligero, porque eso define el trabajo de integración.
3. ¿Qué debe ser reproducible? Precios, decisiones, documentos y pagos. Esto define los requisitos de versionado y auditoría, y es donde fallan la mayoría de las estimaciones.
4. ¿Qué integraciones están en la ruta crítica? Pagos y generación de documentos siempre lo están. KYC, enriquecimiento de datos y firma electrónica a menudo pueden ir por fases.
5. ¿Cuáles son las puertas regulatorias? Aprobación de producto, DPIA, evaluaciones de externalización y resiliencia, y cualquier aprobación de conducta. Ponlas en el plan con responsables y fechas, porque no se comprimen.
6. ¿Cómo se ve el éxito en números? Conversión de cotización a contratación, tasa de procesamiento automático, tiempo de ciclo de siniestros, coste por póliza. Mide la línea base antes de construir.

Una primera fase sensata para una aseguradora con core existente: un portal de corredores para un producto, una API embebida de cotización-contratación para un partner, o un módulo de entrada y triaje de siniestros para un ramo. Cada uno son unos meses de trabajo para un equipo enfocado, produce un resultado medible y establece la capa de integración que todo módulo posterior reutiliza. Los equipos que dimensionan este tipo de alcance suelen incorporar un partner de desarrollo de software a medida con experiencia en el dominio asegurador, en lugar de formar el equipo desde cero.

Recomendación

Mantén o compra el core para registros de pólizas, facturación y reporte regulatorio. Construye las capas que tocan clientes, corredores y partners, además de los datos y las reglas que hacen que tus productos sean tuyos. Sé dueño del modelo de dominio y de los contratos de integración para que el core siga siendo reemplazable. Versiona todo lo que produce un precio, una decisión o un documento, y diseña los siniestros como eventos desde el principio. Lleva el RGPD, el linaje de Solvencia II, la resiliencia de DORA y la evidencia de Consumer Duty al alcance antes del primer sprint. En Arvucore solemos recomendar un primer módulo que llegue a producción en meses y demuestre la capa de integración, y después escalar ramo a ramo en lugar de intentar un programa de plataforma desde el inicio.