Imagen generada por IAWashington y Bruselas han vuelto a prometerse cooperación en finanzas digitales y ciberseguridad. La novedad no está en la foto ni en el lenguaje diplomático, que suena al de siempre con mejor pulido. Está en otra parte: cuando dos bloques reguladores tan distintos deciden dedicar espacio político a resiliencia operativa, uso de tecnologías emergentes y riesgos transfronterizos, el mensaje real para bancos, aseguradoras, proveedores TIC y equipos de compliance es bastante menos decorativo de lo que parece.
La declaración conjunta del UE-EEUU Financial Regulatory Forum no rediseña por sí sola el mapa normativo. No crea obligaciones directas. No sustituye una norma por otra. Pero sí señala algo más útil que muchos comunicados grandilocuentes: qué temas están en la mesa regulatoria transatlántica y qué fricciones van a seguir acompañando a las entidades que operan entre ambos lados del Atlántico.
Y aquí conviene cortar una tentación habitual del comentario regulatorio: leer cualquier declaración conjunta como si fuera un anticipo de una gran convergencia normativa. No lo es. Europa no va a americanizar DORA para resultar simpática a Washington. EEUU tampoco va a importar el enfoque europeo de gobernanza, supervisión y documentación por pura cortesía institucional. Lo que sí veremos es algo más prosaico y bastante más importante: mayor coordinación, intercambio de prioridades supervisoras y presión indirecta sobre las empresas para demostrar que controlan mejor a sus terceros, entienden mejor sus dependencias tecnológicas y pueden responder a incidentes serios sin improvisar a las tres de la madrugada.
El valor de este tipo de textos no está en sus verbos. Está en su selección de temas. Un regulador puede repetir durante años que la resiliencia, el riesgo tecnológico y la cooperación internacional son fundamentales. Hasta ahí, ninguna sorpresa. La cuestión es qué asuntos decide destacar en un momento concreto y junto a qué contraparte.
Si una declaración bilateral pone el foco en estabilidad financiera, innovación, digitalización y resiliencia operativa, las empresas deberían leerla como una señal de continuidad regulatoria, no como una pieza ornamental para archivar en la carpeta de “relaciones institucionales”. En Europa, esa continuidad ya tiene cuerpo legal muy preciso. DORA establece requisitos de gestión del riesgo TIC en su art. 6 y siguientes, régimen de notificación de incidentes graves en los arts. 17 a 23, pruebas de resiliencia digital en los arts. 24 a 27 y un marco específico para terceros proveedores de servicios TIC en los arts. 28 a 30, además del esquema de supervisión de proveedores críticos en los arts. 31 a 44. Eso no depende de lo que diga un comunicado bilateral. Pero un comunicado así ayuda a entender que el problema que DORA intenta resolver no es solo europeo: es estructural y transfronterizo.
La misma lógica vale fuera del sector financiero estricto. NIS2 endurece la gestión de riesgos de ciberseguridad y la gobernanza de incidentes para entidades esenciales e importantes en su art. 21, e impone obligaciones de notificación en el art. 23. GDPR mantiene la notificación de violaciones de seguridad a la autoridad de control en 72 horas en su art. 33 y, cuando procede, la comunicación a los interesados en el art. 34. Ninguna de estas piezas desaparece porque Bruselas y Washington hablen de cooperación. Más bien al contrario: cada conversación transatlántica sobre riesgo digital confirma que las autoridades consideran ya la dependencia tecnológica y la ciberresiliencia como una cuestión de estabilidad, no solo de seguridad informática.
Durante mucho tiempo, la geopolítica regulatoria podía parecer un asunto lejano, casi de seminario de think tank. Hoy se cuela en decisiones muy concretas: qué proveedor se contrata, en qué jurisdicción se aloja una función relevante, cómo se redacta una cláusula de acceso y auditoría, quién tiene autoridad para activar un plan de contingencia y qué dependencia tecnológica no documentada te puede estallar delante del supervisor.
DORA es especialmente incómodo en ese sentido, y con razón. El art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. No como un apéndice de procurement. No como una tabla Excel mantenida por compras. Como parte del control operativo de la entidad. El art. 30 va más allá y fija elementos contractuales clave para servicios que apoyen funciones críticas o importantes: descripción completa de funciones, lugares de prestación y tratamiento de datos, disponibilidad, integridad, acceso, derechos de inspección y auditoría, asistencia en incidentes, terminación y salida, entre otros. Esa arquitectura importa especialmente cuando el proveedor está fuera de la UE o forma parte de una cadena compleja de subcontratación.
Aquí conviene afinar el lenguaje para no vender una simplificación falsa. No puede afirmarse sin matices que cualquier proveedor estadounidense que preste servicios a entidades financieras europeas quede, por ese solo hecho, “dentro del perímetro” de DORA como si estuviera sometido directamente a la norma en los mismos términos que una entidad financiera. Lo que sí es verificable es otra cosa, y ya es bastante: DORA impone a las entidades financieras europeas obligaciones concretas sobre la selección, contratación, supervisión, documentación y salida de terceros proveedores TIC, especialmente cuando soportan funciones críticas o importantes, y esas obligaciones se proyectan operativamente sobre la relación con proveedores establecidos dentro o fuera de la Unión. La diferencia no es académica. Es la clase de detalle que separa un análisis serio de una consigna bonita.
Para muchos proveedores no europeos, eso significa algo muy simple: aunque la norma no les trate como entidad regulada del sector financiero, el mercado europeo empezará a exigirles capacidades contractuales, de evidencia y de cooperación que antes podían negociarse con mucha más alegría. Y si no pueden darlas, no siempre hará falta una sanción para que pierdan negocio. Bastará con que el cliente europeo concluya que el riesgo de dependencia, opacidad o falta de auditabilidad ya no compensa.
La tentación política de hablar de “alineamiento” es comprensible. Queda bien. Suena moderno. Pero una empresa que opere en ambas jurisdicciones haría mal en confundir coordinación con armonización.
Europa ha construido en los últimos años un aparato regulatorio más prescriptivo, más documental y bastante más invasivo en materia de gobernanza tecnológica. DORA, NIS2, GDPR, el Reglamento de Ciberresiliencia y el resto del paquete digital responden a una misma intuición: si una dependencia digital puede afectar a la continuidad del servicio, la confianza del mercado o la seguridad de los datos, el regulador quiere verla, clasificarla, probarla y, llegado el caso, supervisarla. EEUU, según sector y agencia, ha tendido históricamente a un enfoque más fragmentado, apoyado en guías supervisoras, exigencias sectoriales y enforcement posterior. El resultado para las empresas no es una elección entre dos filosofías. Es una doble carga: demostrar cumplimiento formal en Europa y, al mismo tiempo, responder a expectativas supervisoras estadounidenses que a menudo se expresan de otra manera, pero no son necesariamente más ligeras.
La declaración conjunta importa precisamente porque no resuelve esa tensión. La confirma. Y eso obliga a dejar atrás una comodidad peligrosa: la idea de que bastará con construir un marco global de alto nivel y luego “localizar” detalles regulatorios. Ese modelo ya falla en ciberresiliencia, outsourcing TIC, gobernanza del dato y respuesta a incidentes. Las diferencias entre marcos ya no son cosméticas.
Un ejemplo claro es la gestión de incidentes. DORA exige un proceso armonizado para clasificar incidentes relacionados con TIC y reportar los graves a la autoridad competente, con criterios que el propio reglamento estructura y que las normas técnicas desarrollan sobre base de los arts. 17 a 20. GDPR obliga a evaluar si una violación de seguridad entraña riesgo para derechos y libertades y, si es así, a notificar a la autoridad en 72 horas conforme al art. 33. NIS2 impone alertas tempranas, notificación del incidente y un informe final en el esquema del art. 23. No es el mismo lenguaje. No son los mismos umbrales. No persiguen exactamente la misma finalidad. Pero la organización que responde con tres equipos separados, tres taxonomías distintas y tres circuitos de escalado incompatibles está pidiendo problemas a gritos.
Si hay una idea que recorre buena parte de la regulación reciente, aunque cada texto la formule a su manera, es esta: el riesgo tecnológico ya no se entiende solo dentro del perímetro corporativo. Se entiende a través de cadenas de suministro, ecosistemas cloud, proveedores de software, integradores, filiales de grupo y servicios compartidos que sostienen funciones esenciales sin aparecer siempre en los mapas de criticidad con la claridad que uno esperaría.
DORA lo aterriza de forma explícita. El art. 28 exige que la entidad gestione el riesgo de terceros TIC, teniendo en cuenta, entre otras cosas, la criticidad o importancia de la función apoyada, las posibles concentraciones y el impacto potencial de la insolvencia, fallos operativos o interrupciones del proveedor. El art. 29 obliga a mantener un register of information respecto de todos los acuerdos contractuales sobre el uso de servicios TIC prestados por terceros. El art. 30 especifica qué debe contener el contrato. Y los arts. 31 y siguientes diseñan un régimen de supervisión para determinados proveedores TIC críticos.
A la vista de ese marco, la cuestión no es si la conversación transatlántica menciona expresamente cada detalle técnico imaginable, sino qué se deriva de la prioridad política otorgada a la resiliencia y al riesgo digital. Sin acceso verificable al texto completo en su versión íntegra, no conviene afirmar de forma categórica que la declaración omite términos concretos como registros de información, pruebas TLPT o concentración en terceros TIC. Lo prudente es decir algo más útil y más preciso: la declaración, al menos en el resumen disponible, se mueve en un plano de principios y cooperación general; el detalle operativo sobre terceros críticos, pruebas avanzadas o registros contractuales sigue estando en los textos regulatorios sectoriales, especialmente en DORA. Esa distinción es menos llamativa que un titular rotundo, pero resiste mejor una comprobación seria.
Y tiene consecuencias prácticas inmediatas. Si tu entidad está esperando a que una señal política internacional le diga cómo resolver su dependencia de un proveedor dominante, llega tarde. La obligación de mapear servicios TIC, vincularlos a funciones críticas o importantes y asegurar derechos contractuales suficientes no nace de una declaración bilateral. Ya está en el Reglamento.
El error clásico de muchas organizaciones consiste en dividir el mundo entre “norma vinculante” y “ruido institucional”. Es una categoría demasiado cómoda para un entorno regulatorio que funciona, cada vez más, por capas. Primero llegan discursos, prioridades supervisoras, declaraciones conjuntas y consultas. Luego aparecen guías, RTS, ITS, expectativas de supervisión, revisiones temáticas y requerimientos de evidencias. Y cuando la empresa quiere reaccionar, descubre que el margen temporal era más corto de lo que parecía.
No se trata de sobrerreaccionar a cada comunicado. Se trata de leer el patrón. En Europa, ese patrón es nítido: la resiliencia digital se ha desplazado desde la periferia del cumplimiento hacia el centro de la gobernanza. DORA, en su art. 5, exige que el órgano de dirección defina, apruebe, supervise y sea responsable de la aplicación del marco de gestión del riesgo TIC. NIS2, en su art. 20, también atribuye al órgano de dirección la aprobación y supervisión de las medidas de gestión del riesgo de ciberseguridad. Eso ya no encaja con el viejo modelo en el que la ciberseguridad vivía encerrada en TI y compliance aparecía al final para revisar papel.
La declaración UE-EEUU encaja en esa evolución. No porque cree una nueva obligación de consejo de administración, sino porque normaliza un hecho institucional: el riesgo digital se discute en foros de estabilidad financiera y regulación de alto nivel. Esa reubicación importa. Cuando un asunto entra en esa categoría, deja de ser un problema “técnico” que puede aplazarse con una actualización de política interna cada semestre.
En torno a la inteligencia artificial se ha instalado otra costumbre peligrosa: meter cualquier referencia a tecnología emergente en el mismo saco y presentar un supuesto calendario inexorable aunque la fuente analizada no lo concrete. Eso sirve para asustar al lector y queda vistoso en una diapositiva. También es una mala práctica periodística y regulatoria.
Si la conversación transatlántica menciona innovación financiera, tecnologías emergentes o riesgos derivados de la digitalización, la implicación razonable para las entidades financieras es que la gobernanza de sistemas algorítmicos, modelos y procesos automatizados seguirá ganando peso regulatorio y supervisor. Hasta ahí, terreno firme. Lo que no conviene afirmar, si la fuente no lo sostiene, es que en un año concreto “entra una fase” determinada del AI Act y que eso produce ya una consecuencia temporal cerrada para todo el sector financiero. Sin precisar qué obligaciones aplican, a quién y desde cuándo, esa frase se vuelve más efectista que exacta.
La forma rigurosa de abordarlo es otra. La UE ya ha colocado la IA dentro de un marco regulatorio que no puede tratarse como un accesorio de innovación, y las entidades financieras que usen sistemas de IA en procesos relevantes tendrán que evaluar su encaje normativo, su gobernanza interna y su relación con marcos ya vigentes de riesgo operacional, seguridad, privacidad y externalización. Eso afecta especialmente cuando la IA se integra en servicios de terceros, tratamiento de datos personales, monitorización antifraude, clasificación de clientes, decisiones automatizadas o herramientas internas de seguridad. No hace falta forzar una fecha discutible para sostener esa conclusión. La propia trayectoria regulatoria europea ya basta.
De hecho, el punto más interesante no es temporal. Es estructural. Muchas entidades siguen tratando la IA como un problema de modelo, mientras sus riesgos más inmediatos nacen de su forma de adquisición: APIs externas, funciones embebidas en suites cloud, herramientas de productividad con capacidades generativas activadas por defecto y proveedores que prometen “automatización segura” con mucha facilidad verbal y bastante menos transparencia técnica. Ahí DORA vuelve a colarse por la puerta lateral: si una capacidad tecnológica de tercero soporta una función crítica o importante, la pregunta no es si lleva la etiqueta IA, sino si la entidad puede gobernarla con evidencia suficiente.
La utilidad real de esta señal política se mide en decisiones operativas. Si quieres saber si tu organización se lo está tomando en serio, no mires el comunicado. Mira estas cinco piezas internas.
DORA no está pensado para organizaciones que solo conocen sus dependencias tecnológicas a nivel de marca comercial. El art. 29 obliga a mantener un registro de información sobre acuerdos contractuales de servicios TIC. Eso exige algo más que una lista de proveedores. Exige vincular el servicio al proceso de negocio, a la función crítica o importante que soporta, a su localización, a posibles subcontratistas y al responsable interno. Si tu inventario no permite responder rápido a qué servicio falla, qué proceso afecta y qué opción de salida existe, no tienes un inventario regulatoriamente maduro. Tienes una aproximación administrativa.
El arte de muchos contratos TIC consiste en sonar contundentes mientras evitan compromisos realmente ejecutables. DORA, sobre todo en el art. 30, no deja demasiado espacio para esa literatura creativa. Si el proveedor sostiene una función crítica o importante, la entidad necesita derechos claros de acceso, inspección, auditoría, asistencia en incidentes, notificación de cambios materiales y condiciones de terminación y salida. El problema no es solo jurídico. Es logístico. Hay proveedores globales que aceptan ciertas cláusulas en abstracto y luego las trocean en anexos, programas de auditoría compartida o limitaciones operativas que, en la práctica, reducen mucho su valor. Esa distancia entre la firma y la ejecutabilidad es una de las zonas de mayor riesgo real.
No tiene sentido seguir operando con un circuito para ciberseguridad, otro para privacidad y otro para continuidad si al final todos dependen del mismo incidente base. Lo que necesitas es una capa común de detección, clasificación, escalado y preservación de evidencias, y después ramas de notificación regulatoria adaptadas a DORA, GDPR, NIS2 u otros marcos aplicables. El art. 17 de DORA exige establecer un proceso de gestión de incidentes relacionados con TIC. El art. 33 de GDPR impone la notificación de violaciones de seguridad de datos personales en determinadas condiciones. El art. 23 de NIS2 fija otro carril de notificación. Si esos carriles parten de hechos operativos distintos según el equipo que los vea, el caos no es una posibilidad remota; es el diseño por defecto.
La mayoría de entidades ya sabe quiénes son sus grandes proveedores directos. Lo que muchas siguen sin ver con suficiente nitidez es la capa de subprocesadores, subcontratistas, afiliadas y servicios de infraestructura que sostienen el servicio real. DORA exige valorar también el riesgo de concentración y la cadena de suministro digital dentro de la gestión del riesgo TIC vinculada a terceros. No hace falta adornarlo: si dependes de varios proveedores que, a su vez, dependen de la misma infraestructura subyacente, tu diversificación puede ser más teatral que real.
El art. 5 de DORA y el art. 20 de NIS2 son claros al elevar responsabilidades del órgano de dirección. Eso no significa que los consejeros deban convertirse en arquitectos cloud. Significa que deben poder demostrar supervisión efectiva sobre prioridades, tolerancia al riesgo, asignación de recursos, pruebas, dependencias críticas y preparación ante incidentes. Si la información que reciben es un resumen trimestral con semáforos verdes y dos adjetivos tranquilizadores, la organización está confundiendo reporting con gobierno.
Hay otro punto que suele quedar en segundo plano cuando el debate se concentra en resiliencia operativa: la transferencia y el tratamiento de datos. Y, sin embargo, sigue siendo uno de los lugares donde la fricción transatlántica se vuelve más material para el negocio. Una entidad puede tener un contrato impecable de servicios TIC y, aun así, tropezar con problemas de base jurídica, minimización, acceso, localización operativa o gestión de incidentes con impacto en datos personales.
GDPR no se flexibiliza porque el proveedor sea estratégico o porque exista un interés supervisor en la estabilidad digital. Si hay violación de seguridad de datos personales, el art. 33 sigue exigiendo evaluar la notificación en 72 horas. Si un proveedor procesa datos por cuenta de la entidad, el art. 28 de GDPR sigue exigiendo un acuerdo de encargo con contenido concreto. Y si entran en juego transferencias internacionales, la organización debe apoyarse en el mecanismo jurídico que corresponda y verificar que su arquitectura operativa no contradice lo que el papel promete.
La ironía regulatoria aquí es bastante conocida: muchas organizaciones han invertido enormes recursos en redactar cláusulas de transferencia o anexos de seguridad mientras mantienen una visibilidad mediocre sobre qué datos circulan realmente por qué herramientas, con qué niveles de acceso y bajo qué régimen de soporte remoto. La cooperación UE-EEUU puede facilitar el clima político. No sustituye el trabajo ingrato de saber qué pasa de verdad en tu stack.
Primero, no convertir una declaración política en una profecía normativa concreta. Si el texto no menciona un expediente legislativo específico, una reforma determinada o una obligación temporal cerrada, atribuirle ese contenido solo porque encaja con la narrativa del momento es una mala idea. Produce titulares rápidos y estrategias torpes.
Segundo, no usar la falta de detalle del comunicado como excusa para retrasar trabajo interno. Que un texto bilateral sea general no reduce la especificidad de DORA, NIS2 o GDPR. Más bien la hace más relevante: el detalle vinculante sigue estando en esas normas y en sus desarrollos.
Tercero, no separar la agenda de resiliencia digital de la agenda de negocio. El supervisor ya no compra la idea de que continuidad, ciberseguridad, outsourcing, privacidad, datos e innovación viven en cajones distintos. La dependencia tecnológica atraviesa todo el modelo operativo. Si tu estructura interna sigue premiando silos, tu cumplimiento será más caro y menos creíble.
Y cuarto, no sobredimensionar la palabra “cooperación”. Cooperar no significa ver el riesgo igual, exigir lo mismo ni supervisar del mismo modo. Significa, a menudo, compartir preocupaciones mientras cada bloque conserva sus propias herramientas. Para las entidades multinacionales, eso no reduce complejidad. La organiza.
La declaración conjunta entre la UE y EEUU no necesita mencionar cada expediente de moda para ser relevante. Su señal más útil es otra: confirma que la resiliencia digital, el riesgo tecnológico y la supervisión de dependencias críticas seguirán en el centro de la conversación regulatoria transatlántica. Para las entidades financieras, eso significa una cosa bastante poco glamurosa: hay que ejecutar mejor.
Ejecutar mejor el inventario de terceros. Ejecutar mejor la clasificación de funciones críticas o importantes. Ejecutar mejor los contratos. Ejecutar mejor los planes de salida. Ejecutar mejor la respuesta a incidentes. Ejecutar mejor la información al consejo. El resto —los grandes titulares sobre convergencia, disrupción y futuro digital compartido— puede esperar. Siempre encuentra una manera de volver en la siguiente declaración.
La pregunta útil, por tanto, no es si Bruselas y Washington están alineados del todo. No lo están, y tampoco hacía falta fingirlo. La pregunta es más práctica: si mañana tu supervisor te pide demostrar cómo controlas una dependencia tecnológica transfronteriza relevante, podrías enseñarle evidencias consistentes, contractualmente exigibles y operativamente reales?
Si la respuesta es “más o menos”, ya tienes el problema identificado. Y, a estas alturas, no es un problema de comunicación institucional.
Nota editorial
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en AI Act: clasificación de riesgo de tus sistemas de IA y obligaciones por nivel.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment AI Act.
Aporta contexto, plantea una duda o responde a la conversación. Los comentarios son públicos y moderables.
Cargando comentarios…