La auditoría que obligó a actuar
El detonante no fue una brecha. Fue una carta. La Agencia de Energía danesa completó una auditoría rutinaria del stack de tecnología operacional de la empresa y descubrió que la telemetría SCADA en tiempo real, el pulso continuo de lecturas de sensores, eventos de conmutación y señales de equilibrio de carga de toda la red, transitaba por infraestructura propiedad de un hiperescalador estadounidense. Bajo las obligaciones de infraestructura crítica de NIS2, eso no era una zona gris. El regulador emitió un aviso formal de remediación y dio a la organización noventa días para resolverlo.
La empresa suministraba energía a aproximadamente dos millones de hogares. Cualquier interrupción en sus sistemas de equilibrio de red durante una migración implicaba un riesgo operacional real. El reloj de cumplimiento corría, la complejidad técnica era considerable, y la arquitectura existente había crecido de forma orgánica durante cinco años sobre la plataforma del hiperescalador, con streaming de eventos, inferencia en el edge y analítica a largo plazo fuertemente acoplados a servicios gestionados propietarios.
La organización necesitaba un camino de migración que satisficiera al regulador, preservara la continuidad operacional y no supusiera simplemente cambiar un proveedor con dependencia excesiva por otro.
El desafío técnico y de cumplimiento
El cumplimiento de NIS2 para infraestructura crítica en un operador energético no se satisface únicamente con garantías contractuales. La preocupación de la Agencia de Energía danesa era arquitectónica: los datos abandonaban físicamente el control soberano de la UE en la capa de red, independientemente de lo que dijera el acuerdo de servicio. El aviso de remediación exigía a la empresa demostrar que la telemetría operacional, desde la ingesta hasta el procesamiento y el almacenamiento, nunca atravesaba infraestructura sujeta a jurisdicción no europea.
El pipeline existente ingería aproximadamente 140.000 eventos de sensores por minuto durante la carga máxima de la red. Esos eventos alimentaban dos sistemas posteriores: un modelo de equilibrio de red en tiempo real que ejecutaba inferencia en el edge, y una plataforma de analítica histórica utilizada para la planificación de capacidad y los informes regulatorios. Ambos estaban construidos sobre los primitivos propietarios de streaming y servicio de ML del hiperescalador. Un lift-and-shift directo no era viable; la arquitectura tenía que reconstruirse sobre estándares abiertos y portátiles para evitar recrear la misma dependencia en una nueva ubicación.
Los costes de egreso eran un problema secundario pero significativo. Los volúmenes de telemetría de la empresa suponían el pago de cuantiosas tarifas de transferencia de datos entre regiones cada mes, cargos que se habían aceptado como el coste inherente a la arquitectura en lugar de analizarse como una partida concreta. Migrar a infraestructura sin rutas de datos transatlánticas eliminaría esos cargos por completo, pero solo si la nueva plataforma se diseñaba correctamente desde el inicio.
Qué construyó DIVERSITY y cómo
La migración se ancló en las instalaciones HEL1 de DIVERSITY en Helsinki, elegidas por su proximidad geográfica a las operaciones de red danesas, su suministro de energía 100% renovable (relevante para los propios informes de sostenibilidad de la empresa) y su densa conectividad con la región nórdica. Una presencia secundaria en AMS1, en Ámsterdam, proporcionó la configuración de failover en dos sitios requerida por la política interna de recuperación ante desastres de la empresa.
La capa de streaming de eventos se reconstruyó sobre la infraestructura de streaming de eventos soberana de la UE de DIVERSITY, sustituyendo el servicio propietario del hiperescalador por una plataforma compatible con Kafka. El equipo de ingeniería de la empresa conservó su código de productores y consumidores existente con modificaciones mínimas; la compatibilidad de interfaz significó que la capa de aplicación no necesitó reescribirse, solo reconectarse. Toda la telemetría de la red SCADA se ingesta ahora directamente en HEL1, con replicación síncrona a AMS1, sin que ninguna ruta de datos toque infraestructura fuera de la jurisdicción de la UE.
La inferencia en el edge para el modelo de equilibrio de red se migró a la plataforma de inferencia GPU de DIVERSITY. El modelo en sí, un sistema de previsión de carga con gradient boosting que el equipo de ciencia de datos de la empresa había entrenado internamente, se contenerizó y desplegó sin modificaciones. La latencia de inferencia en HEL1 fue comparable a la configuración anterior; el equipo de operaciones de la empresa no reportó ningún cambio perceptible en la capacidad de respuesta del sistema de equilibrio durante el periodo de transición.
La nube soberana no es una casilla de cumplimiento. Para los operadores de infraestructura crítica, es una declaración sobre quién controla la ruta de datos cuando la red está bajo presión. Ese control tiene que ser arquitectónico, no contractual.
La plataforma de analítica histórica se migró al almacenamiento de objetos y almacenamiento en bloque gestionado de DIVERSITY, con el conjunto de datos histórico transferido mediante un plan de transición estructurado que mantuvo ambos entornos activos en paralelo durante tres semanas. Este periodo de solapamiento permitió al equipo de ingeniería de la empresa validar la integridad de los datos y confirmar que las consultas de informes regulatorios producían resultados idénticos antes de desmantelar el entorno del hiperescalador.
La infraestructura de DIVERSITY, certificada según ISO 27001, y las garantías contractuales de residencia de datos proporcionaron la evidencia documental que la empresa necesitaba para su presentación al regulador. El diagrama de arquitectura, combinado con las atestaciones a nivel de red que confirmaban que ninguna telemetría transitaba por infraestructura no europea, formó el núcleo del paquete de remediación presentado a la Agencia de Energía danesa.
El resultado: cumplimiento alcanzado y costes reducidos
El regulador aceptó la presentación de remediación con once días de margen dentro del plazo de noventa días. La revisión de la Agencia de Energía danesa confirmó que la nueva arquitectura satisfacía los requisitos de residencia de datos de infraestructura crítica de NIS2, y el aviso formal fue cerrado.
El resultado financiero no fue secundario. Al eliminar por completo los cargos de egreso entre regiones y consolidar la infraestructura en una plataforma con precios orientados a cargas de trabajo de telemetría de alto volumen, la empresa redujo su gasto anual en la nube un treinta y un por ciento. Los ahorros se atribuyeron casi en su totalidad a la eliminación del egreso y a una tarificación de cómputo más predecible, no a ninguna reducción de capacidad o redundancia. La configuración de dos sitios en HEL1 y AMS1 mejoró de hecho la postura formal de recuperación ante desastres de la empresa en comparación con su despliegue anterior en una única región del hiperescalador.
El equipo de ingeniería de la empresa opera ahora un pipeline de telemetría SCADA completamente bajo control soberano europeo, portable sobre estándares abiertos y más económico de operar que el stack propietario al que reemplaza. La crisis de cumplimiento que forzó la migración resultó ser el catalizador para una arquitectura que la organización debería haber construido desde el principio.
Para los operadores energéticos que navegan las obligaciones de infraestructura crítica de NIS2, la lección es clara: la residencia de datos en analítica de red es una cuestión de capa de red, no legal. La respuesta tiene que estar integrada en la arquitectura, y la arquitectura tiene que residir en infraestructura sujeta al derecho europeo.
