El aviso de cumplimiento llegó antes de que el operador hubiera terminado su evaluación interna de brechas respecto a NIS2. El regulador nacional italiano había señalado a la compañía de telecomunicaciones, que da servicio a aproximadamente cuatro millones de suscriptores, por controles territoriales insuficientes sobre los datos de eventos de red en tiempo real. El requisito inmediato era claro: demostrar, con documentación lista para auditoría, que los metadatos de suscriptores procesados en flujos de eventos nunca abandonaban la jurisdicción de la UE. El operador tenía semanas, no trimestres, para presentar las evidencias.
La arquitectura subyacente había evolucionado de forma orgánica a lo largo de varios años. Los datos de eventos procedentes de sondas de red, eventos de autenticación, registros de sesión y registros de actividad de suscriptores fluían hacia una plataforma de streaming gestionada operada por un hiperescalador. El contrato permitía la conmutación por error a regiones de centros de datos fuera de la UE sin consentimiento explícito del cliente ni notificación previa, una cláusula estándar que había parecido aceptable antes de que la aplicación de NIS2 comenzara en serio. Bajo los requisitos de la directiva para infraestructuras de comunicaciones críticas, esa ambigüedad ya no era tolerable. El regulador exigía un mapa de flujos de datos, una lista de ubicaciones de procesamiento y prueba contractual de residencia de datos. El operador no podía aportar ninguno de los tres.
Al problema de cumplimiento se sumaba uno financiero. Los costes de egreso en la plataforma del hiperescalador habían crecido un treinta por ciento interanual a medida que los volúmenes de datos escalaban con la actividad de los suscriptores. El operador pagaba por mover los datos de sus propios suscriptores entre regiones que no había elegido y que no podía auditar. Los equipos de ingeniería habían intentado contener los costes limitando el throughput de eventos, lo que introdujo latencia en los pipelines de detección de fraude y correlación de fallos de red. La calidad operativa se deterioraba al mismo ritmo que la situación regulatoria.
Trazando el camino de la migración
El compromiso de DIVERSITY comenzó con una revisión de arquitectura de dos semanas centrada en tres preguntas: qué flujos de eventos transportaban metadatos de suscriptores sujetos a las obligaciones territoriales de NIS2, qué límites de throughput y latencia requerían los consumidores posteriores, y qué ubicaciones de procesamiento satisfarían tanto los requisitos de jurisdicción del regulador como los objetivos de redundancia propios del operador. Las respuestas definieron el diseño de la migración antes de que se moviera una sola carga de trabajo.
El pipeline de streaming del operador se reconstruyó sobre la infraestructura soberana de la UE de DIVERSITY, desplegada en dos sitios para proporcionar la redundancia geográfica que exigían los SLA internos del operador. La capa principal de ingesta y procesamiento se ejecutó en nodos bare metal en MAD1 en Madrid, elegido por su conectividad directa con la red italiana del operador a través de rutas de peering establecidas y su papel como hub del sur de Europa. Un destino de replicación secundario en MUC1 en Múnich proporcionó capacidad de conmutación por error dentro del perímetro de la UE, con BGP multihoming que garantiza la continuidad si alguno de los sitios experimentara una interrupción. Ambos sitios cuentan con certificación ISO 27001 y están sujetos exclusivamente a la legislación europea, sin que ninguna empresa matriz extranjera pueda recibir una orden de divulgación de datos bajo una jurisdicción no comunitaria.
La capa de streaming se construyó sobre la plataforma de event streaming compatible con Kafka de DIVERSITY, lo que permitió a las aplicaciones productoras y consumidoras existentes del operador conectarse sin necesidad de reescribir el código cliente. Los registros de esquemas internos, la gestión de offsets y las configuraciones de grupos de consumidores se migraron con herramientas que el equipo de ingeniería de DIVERSITY había desarrollado en migraciones anteriores del sector financiero. Los equipos de desarrollo del operador ejecutaron una ingesta en paralelo durante un período de validación de cuatro semanas, comparando los resultados entre el entorno legado del hiperescalador y la nueva infraestructura soberana antes del cutover. Los objetivos de throughput se alcanzaron desde la primera semana de operación en paralelo; la latencia extremo a extremo en el pipeline de detección de fraude mejoró porque el nuevo enrutamiento eliminó los saltos entre regiones que la arquitectura anterior había introducido de forma silenciosa.
Satisfaciendo los requisitos de auditoría del regulador
El paquete de auditoría que el operador debía presentar no era solo un diagrama técnico. El regulador exigía evidencia contractual de residencia de datos, una lista de todos los subencargados de tratamiento con sus ubicaciones de procesamiento, y una demostración de que ninguna ruta de conmutación por error podía dirigir datos de suscriptores fuera de la UE sin un cambio de configuración explícito que requiriera la autorización del cliente. La estructura contractual de DIVERSITY abordó cada punto de forma directa.
Dado que DIVERSITY opera su propia infraestructura y no es un revendedor que superpone servicios sobre un hiperescalador, la lista de subencargados era breve y estaba íntegramente domiciliada en la UE. El mapa de flujos de datos que el operador presentó al regulador identificaba dos ubicaciones de procesamiento, ambas dentro de la UE y ambas bajo una única relación contractual regida por la legislación europea. La arquitectura de conmutación por error entre MAD1 y MUC1 quedó documentada con diagramas de red que mostraban que no existía ninguna ruta de tráfico hacia regiones fuera del perímetro definido de la UE sin un cambio de enrutamiento explícito que requeriría la autorización del operador y generaría una entrada en el registro de auditoría.
La certeza territorial no es un parámetro de configuración. Es una propiedad contractual y arquitectónica que debe ser cierta por diseño, no aplicada mediante monitorización a posteriori.
El regulador revisó la documentación presentada dentro del ciclo de reporte y cerró el aviso de cumplimiento. No se solicitaron evidencias adicionales. El equipo de cumplimiento del operador, que había gestionado el aviso como un riesgo regulatorio activo durante varios meses, pudo cerrar el elemento en su registro de riesgos y redirigir su atención al programa más amplio de implementación de NIS2.
Resultados económicos y mejoras operativas
El impacto financiero de la migración superó la proyección inicial. El gasto mensual en infraestructura de streaming cayó más de un veinticinco por ciento respecto a la línea base del hiperescalador, impulsado por la eliminación de los cargos de egreso entre regiones y el paso a un modelo de capacidad predecible sobre infraestructura dedicada. Dado que el operador controla ahora su propia topología de retención y replicación, pudo ajustar el almacenamiento a cada categoría de eventos en lugar de aceptar la jerarquización por defecto que aplicaba el hiperescalador.
Los pipelines de detección de fraude y correlación de fallos de red que habían sido limitados para gestionar los costes de egreso se restauraron a pleno throughput. La mejora de latencia en el pipeline de fraude, una reducción de varios cientos de milisegundos en la ruta de procesamiento mediana, fue suficiente para reactivar una capacidad de intervención en tiempo real que el operador había deshabilitado dieciocho meses antes porque la arquitectura anterior no podía sostenerla económicamente.
Desde entonces, el operador ha ampliado su relación con DIVERSITY para incluir almacenamiento de objetos gestionado para la retención de archivos de eventos, y está evaluando las capacidades de SecOps de DIVERSITY para la monitorización SOC de la propia infraestructura de streaming. El cumplimiento de NIS2, que comenzó como una obligación impuesta por una acción regulatoria, se ha convertido en la base para una consolidación más amplia de infraestructura crítica en la nube soberana de la UE.
