El regulador envía una carta
El delegado de protección de datos de una aseguradora de salud belga de tamaño mediano llevaba dos años observando las consecuencias del caso Schrems II cuando la Autoridad de Servicios y Mercados Financieros de Bélgica (FSMA) hizo imposible seguir en esa posición. Llegó una consulta formal por escrito en la que se pedía a la aseguradora que demostrara que su tratamiento de datos sensibles de reclamaciones de afiliados cumplía los requisitos del artículo 46 del RGPD y que ningún dato de salud personal estaba expuesto a riesgo de transferencia a terceros países. La aseguradora ejecutaba sus cargas de trabajo analíticas principales en un proveedor hiperscaler con sede en Estados Unidos. No tenía ninguna respuesta adecuada preparada.
La organización cubría a aproximadamente 800.000 asegurados. Su plataforma analítica procesaba reclamaciones, puntuaciones de riesgo y datos de costos médicos de forma continua. Bajo los términos estándar del hiperscaler, los datos podían atravesar infraestructura regida por la ley estadounidense, incluida la CLOUD Act. El delegado de protección de datos había señalado esto internamente meses antes; la consulta de la FSMA convirtió esa alerta interna en una prioridad a nivel de consejo directivo con un plazo definido.
La brecha de cumplimiento en términos concretos
El cumplimiento normativo de Schrems II para datos de salud no es un problema de papeleo. El Tribunal de Justicia de la Unión Europea invalidó el marco Privacy Shield precisamente porque la legislación de vigilancia estadounidense crea derechos de acceso estructurales que ninguna cláusula contractual puede neutralizar. Las Cláusulas Contractuales Tipo siguen siendo válidas en principio, pero solo cuando una evaluación de impacto de la transferencia confirma que el marco jurídico del país de destino no las socava. Para datos de salud procesados en la infraestructura de un hiperscaler estadounidense, esa evaluación falla sistemáticamente: la CLOUD Act otorga a las autoridades estadounidenses acceso a los datos en poder de entidades constituidas en EE. UU., independientemente de dónde estén ubicados los servidores.
El equipo legal de la aseguradora completó una evaluación de impacto de la transferencia y llegó a la misma conclusión. Las cargas de trabajo analíticas tenían que trasladarse a una infraestructura donde el operador estuviera constituido en la UE, los servidores estuvieran físicamente ubicados en la UE y los términos contractuales prohibieran explícitamente cualquier flujo de datos a terceros países. Las expectativas de la FSMA en materia de residencia de datos reforzaron esto: el regulador quería garantías contractuales escritas, no diagramas de arquitectura y buenas intenciones.
Qué construyó DIVERSITY y cómo
DIVERSITY propuso una migración a bare metal soberano de la UE alojado en su instalación AMS1 en Ámsterdam, con términos contractuales de residencia de datos vinculantes bajo la legislación belga y de la UE y sin subencargados fuera del Espacio Económico Europeo. El bare metal era la opción adecuada por dos razones: las cargas de trabajo analíticas eran suficientemente intensivas en CPU y memoria como para que la virtualización compartida añadiera costo sin aportar flexibilidad, y el bare metal ofrecía a la aseguradora hardware dedicado sin capa de hipervisor a la que una autoridad extranjera pudiera acceder teóricamente a través de un plano de gestión en la nube.
La migración se realizó en tres fases a lo largo de once semanas. En la primera fase, DIVERSITY aprovisionó nodos de bare metal dedicados dimensionados para la carga máxima de procesamiento de reclamaciones de la aseguradora, con almacenamiento respaldado por NVMe para el nivel de base de datos analítica y enlaces de 25 Gbps hacia AMS-IX para la conectividad con las oficinas belgas existentes de la aseguradora y sus socios externos de reclamaciones. La segunda fase ejecutó la plataforma analítica en paralelo en ambos entornos, con el equipo de ingeniería de la aseguradora validando el rendimiento de las consultas y la consistencia de los resultados frente a una matriz de aceptación definida. La tercera fase realizó el traspaso del tráfico de producción, desmanteló el entorno del hiperscaler y emitió el certificado final de residencia de datos contractual que el delegado de protección de datos necesitaba para responder a la FSMA.
El contrato de DIVERSITY incluía prohibiciones explícitas de transferencia de datos fuera de la UE, un listado de subencargados nombrados con solo entidades del EEE y una cláusula que comprometía a notificar a la aseguradora en un plazo de 24 horas ante cualquier solicitud de acceso gubernamental. Estos términos se redactaron para responder directamente a la consulta escrita de la FSMA, de modo que el delegado de protección de datos pudiera adjuntar el contrato como documento principal en lugar de redactar un extenso memorando explicativo.
Detalles de la arquitectura
El entorno de producción comprendía seis nodos de bare metal en un clúster de alta disponibilidad: cuatro nodos de cómputo que ejecutaban la capa de procesamiento analítico y dos dedicados al nivel de base de datos con replicación síncrona entre ellos. DIVERSITY configuró multihoming BGP en AMS1 para que el tráfico de la aseguradora tuviera redundancia de rutas sin depender de un único proveedor upstream. El almacenamiento de objetos para datos de reclamaciones en archivo se ubicó en el servicio de almacenamiento de objetos soberano de la UE de DIVERSITY, cifrado en reposo con claves gestionadas exclusivamente dentro del EEE.
Para la recuperación ante desastres, DIVERSITY replicó el nivel de base de datos en un conjunto de nodos secundario en MUC1 Múnich bajo los mismos términos contractuales de residencia de datos, satisfaciendo la política interna de continuidad de negocio de la aseguradora sin introducir ningún flujo de datos transatlántico. El objetivo de punto de recuperación se fijó en 15 minutos y el objetivo de tiempo de recuperación en dos horas; ambos quedaron documentados en el acuerdo de servicio y se verificaron durante la fase de ejecución en paralelo.
La nube soberana no es una etiqueta de marketing. Es un compromiso jurídico y técnico específico: el operador está constituido en la UE, el hardware está en la UE y el contrato lo dice en un lenguaje que un regulador puede leer.
Qué cambió tras la migración
La aseguradora presentó su respuesta a la consulta escrita de la FSMA dentro del mismo ciclo de auditoría en que llegó la consulta. El paquete de respuesta incluía el contrato con DIVERSITY, la evaluación de impacto de la transferencia que confirmaba la ausencia de flujos a terceros países y un resumen técnico de la arquitectura. La FSMA cerró la consulta sin adoptar medidas adicionales. El delegado de protección de datos documentó el resultado como el primer cierre regulatorio sin incidencias de la organización en una cuestión de transferencia de datos en tres años.
El resultado financiero fue igualmente claro. El contrato anterior con el hiperscaler incluía compromisos de instancias reservadas, tarifas de egreso por datos que se movían entre regiones y cargos por nivel de soporte que se acumulaban de forma independiente al uso real. El contrato de bare metal con DIVERSITY reemplazó todo eso con una tarifa mensual fija que cubría cómputo, almacenamiento, conectividad y un SLA de soporte definido. El gasto mensual en infraestructura cayó un 34% sobre una base de carga de trabajo equivalente. El ahorro cubrió el costo del proyecto de migración en cuatro meses.
El rendimiento de las consultas analíticas mejoró como efecto secundario del traslado a bare metal dedicado. El equipo de ingeniería de la aseguradora informó que los trabajos de procesamiento por lotes de reclamaciones que anteriormente se ejecutaban durante la noche en infraestructura de nube compartida se completaban en menos de tres horas en nodos dedicados, lo que permitió al equipo analítico realizar actualizaciones intradía por primera vez. Esa capacidad llevaba dos años en la hoja de ruta, pero había estado bloqueada por restricciones de costo en el hiperscaler.
La lección más amplia para las aseguradoras de salud
Las decisiones de migración a la nube de las aseguradoras de salud tomadas antes de Schrems II no quedan automáticamente exentas. Los reguladores de toda Europa, incluida la FSMA, están revisando activamente si las organizaciones que tratan datos de salud sensibles han completado evaluaciones de impacto de la transferencia y si sus contratos de infraestructura respaldan las conclusiones de esas evaluaciones. La designación de región europea de un hiperscaler no resuelve el problema estructural: la entidad jurídica que opera la infraestructura sigue estando sujeta a la legislación estadounidense.
El alojamiento en bare metal soberano de la UE resuelve el problema estructural porque cambia simultáneamente la entidad jurídica, los términos contractuales y la infraestructura física. Para organizaciones con cargas de trabajo concentradas y predecibles, como el análisis de reclamaciones, el bare metal también elimina las capas de costo que el modelo de precios de los hiperscalers incorpora por defecto. La aseguradora belga no tuvo que elegir entre cumplimiento normativo y eficiencia de costos. Migrar a infraestructura soberana le proporcionó ambas cosas.
