El plazo que obligó a tomar una decisión
El detonante fue una carta de pre-auditoría de BaFin. Un banco privado alemán de tamaño mediano, con alrededor de 1.200 empleados, operaba su plataforma de monitoreo de transacciones en tiempo real sobre un hiperescalador estadounidense. La carta señalaba que los mecanismos de transferencia de datos transfronteriza que sustentaban ese acuerdo eran legalmente cuestionables bajo la sentencia Schrems II, y exigía una remediación documentada antes de que pudiera avanzar la certificación de cumplimiento DORA del banco. El plazo era de aproximadamente cuatro meses.
No se trataba de un riesgo teórico. El Tribunal de Justicia de la Unión Europea había invalidado el Privacy Shield en 2020, y los acuerdos de cláusulas contractuales tipo posteriores habían enfrentado un escrutinio sostenido por parte de las autoridades alemanas de protección de datos. Para un banco privado que maneja datos de transacciones de clientes, la exposición era directa: continuar en infraestructura cuestionada y reprobar la auditoría, o migrar con suficiente rapidez para cumplir los requisitos de documentación de riesgo de terceros TIC que DORA ahora imponía.
El equipo de cumplimiento ya había identificado la carga de trabajo en cuestión. El sistema de monitoreo de transacciones procesaba flujos de liquidación intradía y detectaba anomalías en tiempo casi real. Era sensible a la latencia, estaba estrechamente acoplado al middleware de core bancario del banco y manejaba el tipo de datos financieros personales que no dejaba margen para reclamaciones jurisdiccionales ambiguas.
Qué exigían realmente los requisitos DORA de BaFin
El marco de riesgo de terceros TIC de DORA es específico. Las entidades reguladas deben mantener un registro de proveedores TIC, evaluar el riesgo de concentración y demostrar que los acuerdos contractuales con proveedores críticos cumplen los requisitos mínimos en materia de auditabilidad, ubicación de datos y disposiciones de salida. Para un banco cuyo monitoreo de transacciones se ejecutaba en infraestructura regida por la ley estadounidense, satisfacer esos requisitos implicaba renegociar condiciones con un hiperescalador que no tenía obligación de cumplirlas, o trasladar la carga de trabajo a un proveedor cuya base legal fuera inequívocamente europea.
El equipo de auditoría interna del banco ya había intentado utilizar la oferta de región UE del hiperescalador. El problema era estructural: los nodos en región UE de una plataforma con sede en EE. UU. siguen estando sujetos a la legislación estadounidense a través de la entidad matriz, un punto que los auditores de BaFin habían planteado específicamente. Las cláusulas contractuales tipo no resolvían eso porque la exposición legal no tenía que ver con dónde se almacenaban los datos en reposo, sino con qué jurisdicción podía exigir acceso a ellos.
Lo que los auditores requerían era un proveedor constituido y operando bajo la ley de la UE, con infraestructura físicamente ubicada en la UE, compromisos contractuales de residencia de datos y controles de riesgo de terceros TIC documentados que pudieran presentarse en un único ciclo de auditoría. Esa combinación descartaba a todos los grandes hiperescaladores estadounidenses, independientemente de la región que el banco seleccionara.
El enfoque de migración: bare metal en Múnich, sin tenencia compartida
Las instalaciones MUC1 de DIVERSITY en Múnich fueron el ancla natural. Las operaciones del banco están concentradas en la región DACH, la latencia hacia sus sistemas de core bancario era una restricción estricta, y la posición de MUC1 dentro del clúster financiero e industrial DACH significaba que las interconexiones que el banco necesitaba ya estaban disponibles. La decisión de operar en servidores dedicados bare metal en lugar de instancias de nube virtualizadas estuvo impulsada por dos factores: los costos de licenciamiento por núcleo físico y el requisito de auditabilidad.
En cuanto al licenciamiento, el proveedor del sistema de monitoreo de transacciones del banco facturaba por núcleos físicos. En una instancia compartida de hiperescalador, el banco pagaba por núcleos que no podía contabilizar con precisión, porque la capa de hipervisor introducía incertidumbre sobre la asignación de núcleos físicos. En bare metal dedicado, cada núcleo licenciado correspondía a un núcleo físico en hardware de uso exclusivo del banco. Consolidarse en una configuración de servidor definida redujo de forma significativa el gasto en licenciamiento por núcleo y simplificó también la trazabilidad para el proveedor.
En cuanto a la auditabilidad, el bare metal le ofreció a los auditores del banco algo concreto: un conjunto específico de servidores físicos, una instalación específica, una jurisdicción específica y un marco contractual que nombraba explícitamente todos esos elementos. La certificación ISO 27001 de DIVERSITY y la clasificación de infraestructura Tier III proporcionaron la capa de documentación de referencia. El registro de riesgo de terceros TIC correspondiente a DIVERSITY podía referenciar identificadores de activos físicos, no solo una cuenta en la nube en una región determinada.
La jurisdicción no es una opción de configuración. Si la entidad legal que opera tu infraestructura responde ante un gobierno extranjero, ningún ajuste regional cambia eso. La única solución es cambiar de proveedor.
Arquitectura: mantener la latencia dentro del umbral aceptable
La plataforma de monitoreo de transacciones requería una latencia de ida y vuelta inferior a 200 milisegundos hacia el middleware de core bancario del banco, que permanecía en las instalaciones propias en Fráncfort. La conexión de MUC1 a Fráncfort a través del backbone de DIVERSITY, con acuerdos de peering directo en vigor, mantuvo la latencia observada bien por debajo de ese umbral. El equipo de migración ejecutó un período de operación en paralelo de seis semanas, durante el cual tanto el entorno heredado en el hiperescalador como el nuevo entorno bare metal procesaban los mismos flujos de transacciones y conciliaban los resultados antes del corte definitivo.
El almacenamiento de la plataforma de monitoreo utilizó el almacenamiento en bloque de DIVERSITY para el registro activo de transacciones, y NVMe local en los nodos bare metal para el conjunto de trabajo en caliente. El archivo frío, conservado por motivos regulatorios, se trasladó a almacenamiento de objetos con replicación contractualmente limitada a la UE, satisfaciendo el requisito de residencia de datos tanto para los registros históricos como para los datos en vivo.
La segmentación de red siguió el modelo de zonificación de seguridad existente del banco. Los ingenieros de DIVERSITY trabajaron con el equipo de seguridad interno del banco para replicar la política de firewall y la estructura de VLAN que el banco había utilizado en el hiperescalador, adaptadas al entorno bare metal. No se introdujo ninguna arquitectura de seguridad nueva durante la migración; la prioridad era un traslado limpio con equivalencia documentada, no un rediseño que introdujera nuevas variables en un proceso de auditoría ya sometido a presión de tiempo.
Lo que produjo el ciclo de auditoría
El banco presentó su documentación de riesgo de terceros TIC ante BaFin dentro del plazo requerido. El trabajo con DIVERSITY produjo tres artefactos que los auditores solicitaron específicamente: una certificación de residencia de datos que cubría tanto los datos en vivo como los archivados, un resumen contractual que confirmaba la constitución y la jurisdicción operativa de DIVERSITY bajo la ley de la UE, y un inventario de infraestructura física que vinculaba las cargas de trabajo del banco con activos específicos en MUC1.
La exposición por Schrems II se eliminó a nivel de entidad legal, sin recurrir a parches contractuales. Los mecanismos de transferencia cuestionados que habían desencadenado la carta de pre-auditoría sencillamente dejaron de existir: ningún proveedor con sede en EE. UU., ninguna transferencia transfronteriza, ningún mecanismo que impugnar.
Los costos de licenciamiento por núcleo disminuyeron al consolidarse en hardware dedicado con un número de núcleos definido. El equipo de infraestructura del banco también recuperó simplicidad operativa: una configuración de hardware fija es más fácil de planificar en capacidad y de parchear que un entorno de nube dinámico donde la capa física subyacente es opaca. Cuatro meses después de la carta de pre-auditoría, las cargas de trabajo de monitoreo de transacciones del banco se ejecutaban en bare metal soberano de la UE, los auditores tenían lo que necesitaban y la certificación de cumplimiento DORA avanzó sin observaciones adicionales.
