El detonante fue una carta formal del regulador financiero nacional. Un grupo asegurador de tamaño medio del Benelux, con alrededor de 2.000 empleados y una cartera significativa de seguros personales, llevaba tres años ejecutando el scoring de siniestros impulsado por IA en un hiperespecialista estadounidense. La carta les fijaba un plazo: demostrar que los datos de los asegurados procesados por esos modelos permanecían bajo jurisdicción legal europea, o enfrentarse a condiciones de remediación que suspenderían en la práctica las herramientas de scoring. Schrems II había invalidado la base legal en la que se apoyaba la organización, y el regulador ya no estaba dispuesto a aceptar las cláusulas contractuales estándar como cobertura suficiente cuando la infraestructura de procesamiento se encontraba en instalaciones de propiedad estadounidense sujetas a la legislación de vigilancia de ese país.

El desafío técnico y de cumplimiento era más complejo que una simple cuestión de residencia de datos. El pipeline de scoring de siniestros ingería notificaciones de siniestros en bruto, las enriquecía con datos de referencia de terceros, ejecutaba inferencia sobre un modelo de gradient boosting reentrenado mensualmente y escribía los resultados puntuados de vuelta al sistema de administración de pólizas. Cada etapa tocaba datos personales. El contrato con el hiperespecialista especificaba endpoints en región europea, pero el domicilio estadounidense de la empresa matriz significaba que las solicitudes bajo la CLOUD Act podían acceder a esos datos sin conocimiento ni consentimiento de la aseguradora. Demostrar ante los auditores que la inferencia de IA era soberanamente europea requería no solo trasladar el cómputo a suelo europeo, sino establecer una cadena contractual limpia: ninguna entidad matriz fuera de la jurisdicción europea y controles técnicos que impidieran la exfiltración incluso en teoría.

La organización también necesitaba preservar el rendimiento del modelo y la cadencia de reentrenamiento. El modelo de scoring existente corría sobre infraestructura acelerada con GPU; migrar a cómputo exclusivamente en CPU habría degradado la latencia de inferencia hasta un punto en que el triaje de siniestros en tiempo real se volvería impracticable. Cualquier solución debía igualar el perfil GPU del entorno existente, no aproximarlo.

Arquitectura: construcción de un pipeline de inferencia soberano

DIVERSITY planificó el proyecto en dos líneas paralelas: infraestructura GPU de inferencia para las cargas de trabajo de scoring, y cómputo cloud en la UE para los pipelines de datos circundantes. El despliegue AMS1 de la aseguradora en el datacenter de DIVERSITY en Ámsterdam les proporcionó un denso peering a través de los grandes puntos neutros europeos, conectividad de baja latencia con el sistema de administración de pólizas en los Países Bajos, y un ancla contractual íntegramente dentro de la jurisdicción legal europea. DIVERSITY tiene su sede en Europa, no opera ninguna entidad matriz en EE. UU. y responde ante la legislación europea, lo que abordó de inmediato el primer nivel de la preocupación del regulador.

Las cargas de trabajo de inferencia se trasladaron a la infraestructura GPU de DIVERSITY, aprovisionada en AMS1. El pipeline de reentrenamiento, que se ejecutaba mensualmente sobre una ventana móvil de 18 meses de siniestros, se reconstruyó como un job gestionado en cómputo cloud en la UE, con almacenamiento de objetos para los artefactos de entrenamiento. Los datos nunca abandonaron el entorno AMS1 durante el procesamiento. La etapa de enriquecimiento, que anteriormente llamaba a una API de datos de referencia de terceros alojada en una CDN estadounidense, fue redirigida a través de una capa de caché dentro del entorno DIVERSITY, de modo que los registros enriquecidos con datos personales se ensamblan y puntúan íntegramente dentro del perímetro soberano.

La arquitectura de red recibió la misma atención. El sistema de administración de pólizas on-premises de la aseguradora se conectó a AMS1 a través de un enlace privado dedicado en lugar de la internet pública, eliminando cualquier posibilidad de que los datos personales transitaran por infraestructura fuera del alcance contractual. La configuración de multihoming BGP de DIVERSITY en AMS1 garantizó que la ruta entre el datacenter de la aseguradora y el endpoint de inferencia fuera determinista y documentada, algo que importaba para el anexo técnico que requerían los auditores.

Qué necesitaba ver el regulador

Las revisiones regulatorias de este tipo no se satisfacen solo con diagramas de arquitectura. El equipo de cumplimiento de la aseguradora necesitaba elaborar un registro de actividades de tratamiento conforme al Artículo 30 del RGPD que reflejara con precisión el nuevo entorno, una evaluación de impacto relativa a la protección de datos actualizada para cubrir las decisiones de siniestros asistidas por IA, y una evaluación de DIVERSITY como proveedor frente a los requisitos técnicos y organizativos esperados de un encargado del tratamiento según el Artículo 28. El SLA contractual del 99,9% de disponibilidad se citó directamente en la evaluación del proveedor. La ausencia de cualquier entidad matriz no europea fue el factor más determinante para cerrar la brecha de Schrems II.

Schrems II no es un problema técnico con una solución técnica. Es un problema jurisdiccional, y la única respuesta fiable es un proveedor cloud que no tenga exposición legal ante las demandas de gobiernos no europeos. Todo lo demás es gestión del riesgo, no eliminación del riesgo.

El equipo de cumplimiento presentó el registro de tratamiento actualizado y la evaluación del proveedor cuatro meses después de completar la migración. El panel de revisión del regulador examinó el anexo técnico, la cadena contractual y la EIPD. No se impusieron condiciones de remediación. Las herramientas de scoring permanecieron en producción sin interrupción durante todo el período de revisión.

Resultados: aprobación regulatoria y reducción del gasto en cloud del 30%

Seis meses después de la carta inicial del regulador, el grupo asegurador había superado su revisión sin observaciones y había reducido su gasto mensual en cloud aproximadamente un 30% respecto al contrato anterior con el hiperespecialista. La reducción de costes se debió a una combinación de factores: infraestructura GPU con precios orientados al mercado medio europeo en lugar de contratos empresariales globales, eliminación de las tarifas de egreso que se habían acumulado al mover datos entre regiones en el hiperespecialista, y supresión de varios servicios gestionados que la organización pagaba sin aprovechar plenamente.

El rendimiento del modelo se mantuvo. La latencia de inferencia en la infraestructura GPU de AMS1 coincidió con la del entorno anterior dentro de una tolerancia aceptable, y el ciclo mensual de reentrenamiento continuó sin modificaciones en el código de entrenamiento. El equipo de ciencia de datos informó de que la migración había sido en gran medida transparente para su flujo de trabajo una vez actualizada la configuración del pipeline para apuntar a los nuevos endpoints.

El beneficio más amplio fue la confianza operativa. El delegado de protección de datos de la aseguradora dispone ahora de una respuesta sólida ante cualquier consulta regulatoria futura sobre el destino de los datos de los asegurados durante el procesamiento con IA: permanecen en Ámsterdam, en infraestructura regida por la legislación europea, con una cadena contractual que no contiene ninguna exposición a jurisdicciones de terceros países. Para una organización de servicios financieros sometida a un escrutinio regulatorio creciente sobre los sistemas de IA, esa claridad tiene un valor que va mucho más allá del ahorro en costes.

Capacidades relevantes

  • Infraestructura GPU de inferencia en AMS1 Ámsterdam, adecuada para cargas de trabajo de IA en producción que requieren jurisdicción europea
  • Cómputo cloud en la UE con almacenamiento de objetos, gestionado dentro de un único perímetro soberano
  • Acuerdos de encargado del tratamiento según el Artículo 28 que respaldan la documentación de cumplimiento en servicios financieros
  • Peering a través de los grandes puntos neutros europeos y conectividad privada para rutas de datos deterministas y auditables entre las instalaciones del cliente y la infraestructura cloud
  • Sin entidad matriz no europea, eliminando a nivel contractual la exposición a la CLOUD Act y a la vigilancia de gobiernos de terceros países