Cuando el Reglamento de Resiliencia Operativa Digital (DORA) entró en vigor, la mayoría de las entidades financieras ya sabían que se avecinaba. Lo que sorprendió a muchas fue el nivel de detalle forense que exigía: no solo que los datos permanezcan en la UE, sino que cada acuerdo TIC con terceros pueda demostrar ejecutabilidad contractual, derechos de auditoría y transparencia en la subcontratación conforme al derecho europeo. Para una gestora de activos francesa de tamaño medio, con cerca de 800 empleados, la brecha entre lo que su proveedor de nube estadounidense podía garantizar y lo que DORA realmente exigía era demasiado amplia para ignorar.
La revisión del equipo de cumplimiento partió de una pregunta directa: ¿podía el acuerdo de nube vigente satisfacer los artículos 28 y 30 de DORA, que establecen el contenido obligatorio de los contratos TIC con terceros para funciones críticas o importantes? La respuesta, tras examinar las condiciones estándar del proveedor, fue negativa. Los acuerdos contractuales no ofrecían el acceso de auditoría, la documentación de estrategia de salida ni las garantías de residencia de datos que el reglamento exige en forma ejecutable. El motor de cálculo de riesgo de cartera y los canales de reporting a clientes, ambos clasificados como funciones críticas en el mapeo interno de DORA, operaban sobre una infraestructura cuya ley aplicable no era europea y cuya ubicación de datos era un compromiso comercial, no una obligación legal.
Las consecuencias eran concretas. El regulador principal de la firma, la AMF, había alineado sus expectativas de supervisión con las directrices conjuntas de las Autoridades Europeas de Supervisión sobre la implementación de DORA. Una constatación de gestión inadecuada del riesgo TIC de terceros para una función crítica no sería un problema administrativo; sería un riesgo supervisor material. La firma tenía que actuar, y necesitaba que la infraestructura sustituta estuviera de forma inequívoca dentro del perímetro jurídico europeo.
Mapeo de las cargas de trabajo antes de tocar la arquitectura
La intervención de DIVERSITY comenzó con un ejercicio de alcance técnico y de cumplimiento, no con una propuesta de infraestructura. Los equipos internos del cliente ya habían completado un registro de activos TIC conforme a DORA, por lo que la primera tarea fue cruzar ese registro con la topología real de cargas de trabajo que corrían en el hiperscaler. El motor de cálculo de riesgo ejecutaba procesos batch nocturnos sobre datos de posiciones, consumía feeds de mercado y producía resultados de VaR y pruebas de estrés que alimentaban directamente el reporting regulatorio. La plataforma de reporting a clientes generaba documentos conformes con MiFID II para aproximadamente 4.000 clientes finales. Ambas cargas de trabajo tenían presupuestos de latencia estrictos y requisitos rigurosos de tratamiento de datos; ninguna era candidata adecuada para una migración directa a cómputo en nube compartida.
La decisión de utilizar bare metal en lugar de instancias de nube virtualizadas respondió a dos factores. Primero, las cargas de cálculo eran intensivas en CPU y estaban limitadas por la memoria, y la firma ya había observado una varianza de rendimiento significativa en instancias compartidas del hiperscaler durante las ventanas de batch en hora punta. Segundo, el bare metal ofrecía al equipo de cumplimiento algo concreto que mostrar en una conversación regulatoria: hardware dedicado de un solo inquilino sin capa de hipervisor compartida con otros clientes, alojado en la instalación MUC1 de Múnich de DIVERSITY bajo certificación ISO 27001 y condiciones contractuales regidas por el derecho de la UE.
La arquitectura de migración
DIVERSITY aprovisionó un clúster de bare metal dedicado en MUC1, con un destino de replicación secundario en AMS1 Ámsterdam para la recuperación ante desastres, satisfaciendo el requisito de replicación en dos sitios exclusivamente dentro de la UE que exigía la política de continuidad de negocio de la firma. La ruta de red entre MUC1 y AMS1 discurre íntegramente por el backbone propio de DIVERSITY, sin tránsito por infraestructura no europea. Ambos sitios son carrier-neutral y mantienen peering directo con los proveedores de conectividad existentes de la firma, lo que significó que el cutover no requirió cambios en los acuerdos de red upstream de la empresa.
La migración se ejecutó en ocho semanas. La plataforma de reporting a clientes se migró primero, al tener un límite de datos más claro y poder validarse contra conjuntos de salida conocidos del entorno anterior. El motor de cálculo de riesgo siguió después, con un período de ejecución en paralelo de cuatro semanas durante el cual ambos entornos producían resultados que el equipo quant comparaba cada noche. Las discrepancias se investigaron y resolvieron antes de que el entorno del hiperscaler fuera descomisionado. El equipo de DIVERSITY proporcionó la capa de infraestructura y las herramientas de migración; los desarrolladores internos de la firma mantuvieron la propiedad del código de aplicación en todo momento.
El bare metal bajo contrato regido por derecho europeo no es una decisión de rendimiento, es una postura de cumplimiento. Al regulador no le importa tu cifra de uptime en el SLA si la ley aplicable está fuera de su jurisdicción.
Lo que DORA exigía realmente en el contrato
El aspecto contractual del proyecto fue tan importante como el técnico. El artículo 30 de DORA exige que los contratos TIC con terceros para funciones críticas incluyan, entre otras cosas: una descripción completa de todas las funciones y servicios a prestar, las ubicaciones donde se procesarán y almacenarán los datos, disposiciones sobre derechos de auditoría y acceso, y obligaciones de estrategia de salida. El contrato empresarial estándar de DIVERSITY para servicios de bare metal fue revisado contra la lista de verificación del artículo 30 y complementado con un anexo específico para DORA que cubría la divulgación de subencargados, la atestación de residencia de datos para MUC1 y AMS1, y un compromiso estructurado de asistencia en la salida con plazos y formatos de portabilidad de datos especificados.
El equipo legal de la firma confirmó que el contrato resultante era plenamente ejecutable conforme al derecho de la UE, con cláusulas de jurisdicción que señalaban a tribunales europeos. Ese único cambio, pasar de un acuerdo regido por ley estadounidense a uno europeo, resolvió la constatación central de la revisión de cumplimiento. El expediente de supervisión de la AMF se actualizó para reflejar el nuevo acuerdo TIC con terceros, y el registro de riesgo TIC de DORA de la firma quedó cerrado para estas cargas de trabajo.
Resultados: cumplimiento cerrado, costes reducidos
La migración logró su objetivo principal: ambas cargas de trabajo críticas operan ahora en infraestructura bare metal europea bajo contratos que satisfacen íntegramente los requisitos de gestión del riesgo TIC de terceros de DORA. El equipo de cumplimiento puede demostrar a la AMF la residencia de datos, los derechos de auditoría y las disposiciones de salida sin ninguna reserva. La configuración de recuperación ante desastres en dos sitios, MUC1 y AMS1, satisface también los requisitos de resiliencia establecidos en las disposiciones de continuidad TIC de DORA, eliminando una brecha secundaria que había sido identificada durante la revisión inicial.
El resultado en rendimiento fue un beneficio secundario que resultó significativo. El clúster de bare metal dedicado eliminó la varianza en las ventanas de batch que el equipo quant había tenido que gestionar en la nube compartida. Las ejecuciones nocturnas de riesgo que ocasionalmente superaban su ventana de finalización ahora concluyen dentro de un calendario más consistente y ajustado. Esa fiabilidad tiene valor operativo independientemente del caso de cumplimiento.
El resultado financiero fue una reducción del 28 por ciento en el gasto mensual en infraestructura respecto a la factura anterior del hiperscaler. Con bare metal dedicado, la firma paga por capacidad que controla, no por un servicio medido con costes punta impredecibles. El ahorro no fue la razón de la migración, pero hizo que el business case fuera sencillo de aprobar y eliminó cualquier argumento interno de que el cumplimiento tenía un coste adicional.
