UNIQA / CHERRISK en 2026: qué haríamos diferente hoy

Una retrospectiva sobre una plataforma de seguros greenfield — y cómo la IA cambia la ecuación hoy.

Escrito por Olivér Haszpra, Gergely Pász

Qué construimos – y por qué funcionó

Cuando empezamos con CHERRISK para UNIQA, el proyecto era verdaderamente greenfield: sin restricciones legacy, un equipo que quería hacerlo bien y un negocio que necesitaba lanzar una plataforma de seguros completamente online en múltiples mercados. Elegimos Scala / Play, una arquitectura CQRS orientada a eventos, Kafka para el streaming de eventos, GraphQL / Sangria para la capa API y GitLab CI/CD con Docker Swarm para el despliegue.

Ese stack aguantó. La plataforma se lanzó, escaló, gestionó carga de producción real y apoyó el trabajo actuarial y de BI a través de su capa de datos event-sourced en ElasticSearch. Las decisiones fueron sólidas — y la mayoría las volveríamos a tomar hoy.

Qué ha cambiado desde entonces: IA en el flujo de trabajo de ingeniería

El mayor cambio individual entre entonces y ahora no es un framework ni un proveedor cloud — es la llegada de los asistentes de codificación con IA como herramienta de ingeniería del día a día. Desde finales de 2022, hemos integrado progresivamente ChatGPT, Claude, Cursor y herramientas relacionadas en cada fase de la entrega. El delta de productividad no es marginal; en ciertas clases de trabajo — boilerplate, scaffolding de tests, documentación, lógica de transformación de datos — se mide en horas ahorradas por desarrollador por día.

En un proyecto de la escala de CHERRISK, eso importa enormemente.

Qué haríamos diferente hoy

1. Equipo inicial más ágil, rampa más rápida

Una fracción significativa del esfuerzo en la fase inicial de grandes proyectos greenfield va en setup: scaffolding del proyecto, configuración de CI/CD, estandarización de entornos, escribir el primer 80% de la capa de servicio boilerplate. Con desarrollo asistido por IA, dos ingenieros senior hoy pueden producir en el mismo plazo lo que antes requería cuatro o cinco. Empezaríamos más ágiles, validaríamos el modelo de dominio más rápido y escalaríamos el equipo una vez probada la arquitectura en producción.

2. Cobertura de tests generada por IA desde el primer día

La cobertura de tests en un sistema CQRS/event-sourced no es trivial — escribir fixtures de comandos realistas, snapshots de eventos y escenarios de integración es trabajo tedioso que históricamente se ha deprioritizado bajo presión de entrega. Hoy usaríamos IA para generar continuamente el primer pase de scaffolding de tests, manteniendo la cobertura honesta sin ralentizar la entrega de funcionalidades.

3. Lazos de retroalimentación más estrechos entre expertos de dominio y código

Las reglas de dominio de seguros — pricing, elegibilidad, lógica de productos — se traducen lentamente a código cuando toda la traducción tiene que pasar por cabezas de desarrolladores. Exploraríamos usar IA para ayudar a analistas de negocio y actuarios a producir lógica estructurada que alimente directamente la base de código, acortando el bucle negocio-código.

4. Uso más agresivo de servicios gestionados para infraestructura no diferenciadora

Gestionamos nuestro propio Kafka, nuestro propio almacenamiento de objetos Ceph, nuestro propio Docker Swarm. En 2026, para la mayoría de esos componentes existe un equivalente cloud gestionado. Gastaríamos menos tiempo en operaciones de infraestructura y más en entrega de producto.

Qué mantendríamos exactamente igual

  • La arquitectura CQRS orientada a eventos. Para un dominio que requiere audit trail, soporta replay actuarial y necesita evolucionar reglas de producto sin downtime, esta sigue siendo la decisión correcta.
  • Scala / Play para el backend principal. El sistema de tipos previene clases enteras de bugs. El rendimiento es excelente. Las herramientas de IA se han vuelto sorprendentemente buenas en la generación de código Scala.
  • GitLab CI/CD con pipelines multi-entorno y quality gates. La entrega automatizada y auditable fue uno de los mayores logros del proyecto.

La conclusión para proyectos similares hoy

Si estás empezando un proyecto similar ahora — un dominio complejo, de alta corrección que requiere datos event-sourced y escalabilidad multi-mercado — la arquitectura fundamental sigue siendo válida. La diferencia está en la velocidad y el tamaño de equipo necesarios para ejecutarla. Un equipo senior más pequeño, aumentado con IA, puede hoy entregar lo que antes requería un equipo más grande durante un período más largo.

Si eso suena relevante para tu proyecto, hablemos.

Volver a las entradas de blog