El EDPB quiere cooperación regulatoria real, no otra mesa redonda: por qué 2026 complica la vida a privacidad, competencia y AML

La protección de datos ya no vive en su departamento. Ese es el cambio de fondo, y no hace falta forzarlo con titulares grandilocuentes: basta mirar dónde está sentado hoy el Comité Europeo de Protección de Datos cuando Bruselas discute competencia, mercados digitales, servicios financieros, espacio de datos sanitarios o identidad digital. El mensaje es menos épico, pero bastante más útil: el GDPR ha dejado de ser una pieza autónoma y se ha convertido en una capa que atraviesa otras políticas públicas. Para las empresas, eso complica el cumplimiento. Para los reguladores, también.

Lo interesante no es descubrir que las normas se tocan entre sí. Eso lo sabe cualquiera que haya sufrido una due diligence seria. Lo relevante es que esa interacción ya no se limita a choques teóricos entre despachos jurídicos. Está entrando en estructuras de cooperación, opiniones conjuntas, consultas cruzadas y obligaciones que fuerzan a los equipos de privacidad, ciberseguridad, riesgo, competencia y producto a hablar entre ellos. A veces con método. A veces a empujones.

Si tu empresa sigue organizando el cumplimiento por silos, el problema no es una fecha concreta en el calendario, sino algo bastante más incómodo: el marco regulatorio europeo se está diseñando suponiendo que esos silos ya no funcionan. Y cuando el legislador da algo por supuesto, el coste de no adaptarse acaba llegando por la vía menos elegante: retrasos de producto, fricción con supervisores, contratos mal negociados o controles duplicados que nadie sabe explicar.

La tesis: privacidad ya no es un vertical, es una capa transversal

Durante años, muchas organizaciones trataron la protección de datos como una disciplina con perímetro propio: base jurídica, información al interesado, contratos de encargo, transferencias internacionales, brechas y poco más. Era una lectura cómoda y, en empresas grandes, muy útil para repartir presupuesto. El problema es que esa fotografía se ha quedado vieja.

El propio diseño del GDPR empuja en dirección contraria. El principio de protección de datos desde el diseño y por defecto del artículo 25 no se limita a un expediente documental; obliga a integrar privacidad en la arquitectura del tratamiento. El artículo 32 exige medidas técnicas y organizativas apropiadas en función del riesgo. El artículo 35 fuerza evaluaciones de impacto cuando un tratamiento pueda entrañar alto riesgo para los derechos y libertades de las personas. Ninguna de esas obligaciones vive aislada. Todas dependen de cómo se diseña un producto, cómo se securiza una cadena tecnológica, cómo se gobierna un proveedor y cómo se gestionan datos en contextos donde también operan otras normas.

Por eso el debate actual ya no va solo de “cumplir el GDPR”. Va de cómo se aplica el GDPR cuando se cruza con el Reglamento de Mercados Digitales, con los requisitos de seguridad de NIS2, con la gobernanza de datos sanitarios del EHDS, con los deberes de resiliencia operativa de DORA o con las exigencias de transparencia y gestión de riesgos del AI Act. El trabajo del EDPB interesa precisamente por eso: no porque cada pronunciamiento cambie las reglas del juego, sino porque señala dónde va a haber fricción interpretativa.

Lo que sí puede decirse con solidez sobre el papel del EDPB

Conviene limpiar el terreno de afirmaciones más vistosas que seguras. No hace falta atribuir al EDPB una frase exacta de estrategia ni colgarle fechas dudosas para ver la tendencia. Hay hechos más sobrios y mejor anclados.

Primero, el EDPB tiene entre sus funciones promover la aplicación coherente del GDPR en toda la Unión. Eso no es una lectura periodística; está en el artículo 70 del GDPR, que enumera sus tareas, entre ellas emitir directrices, recomendaciones y mejores prácticas para fomentar una aplicación coherente del Reglamento. Cuando un órgano con ese mandato entra en conversaciones sobre mercados digitales, espacios europeos de datos o cooperación entre autoridades, no está haciendo turismo institucional. Está defendiendo que la capa de protección de datos no se desactive cuando aparecen otras prioridades regulatorias.

Segundo, el EDPB no actúa solo a través de grandes directrices públicas. También influye mediante opiniones legislativas, declaraciones y cooperación con otros órganos europeos cuando una propuesta normativa o un esquema de gobernanza afecta al tratamiento de datos personales. Ese patrón se ha visto en expedientes muy distintos: identidad digital, acceso a datos, salud digital, publicidad comportamental o el equilibrio entre competencia y protección de datos. El dato clave aquí no es una fecha concreta, sino la dirección de viaje: Bruselas lleva años construyendo regulación horizontal, y el EDPB intenta evitar que esa horizontalidad se traduzca en atajos frente al GDPR.

Tercero, donde existe una base formal de cooperación, la participación del EDPB es jurídicamente más nítida. El ejemplo más claro no necesita hipérbole: el Reglamento de Mercados Digitales prevé un grupo de alto nivel de reguladores europeos para facilitar coherencia y coordinación entre marcos normativos. Ahí el punto no es proclamar que sea “el ejemplo más visible”, una valoración discutible, sino constatar que el legislador ya ha asumido que competencia, protección de datos, medios audiovisuales, comunicaciones electrónicas y servicios digitales no pueden supervisarse como compartimentos estancos.

DMA: donde competencia y privacidad dejaron de fingir que se ignoraban

Si quieres ver esa convergencia en un texto legal, el DMA ofrece una pista bastante clara. El Reglamento (UE) 2022/1925 no convierte al EDPB en supervisor del mercado digital, pero sí reconoce que las obligaciones impuestas a los gatekeepers rozan materias que otras autoridades ya vigilan. El artículo 40 crea un grupo de alto nivel compuesto por órganos y redes europeas relevantes, con la lógica de evitar que cada regulador opere mirando solo su parcela.

Eso importa porque buena parte de las obligaciones del DMA tocan tratamiento de datos. El artículo 5, por ejemplo, limita ciertas combinaciones y usos de datos personales por parte de gatekeepers sin consentimiento cuando el GDPR exige esa base. El artículo 6 añade deberes de interoperabilidad, acceso y portabilidad cuyos efectos prácticos pueden tensionar principios de minimización, limitación de finalidad o seguridad si se implementan mal. La conversación, por tanto, ya no es “competencia versus privacidad”, una simplificación algo perezosa, sino cómo ejecutar obligaciones procompetitivas sin atropellar el GDPR.

La dificultad real está en que ambos marcos usan lenguajes distintos. Competencia piensa en poder de mercado, contestabilidad y dependencia económica. Protección de datos piensa en derechos fundamentales, proporcionalidad, base jurídica y riesgos para personas físicas. Cuando ambos mundos analizan una misma arquitectura de datos, no siempre hacen las mismas preguntas ni aceptan las mismas respuestas.

Ahí el EDPB juega un papel que no conviene inflar, pero tampoco minimizar. No decide el sentido del DMA, pero sí puede influir en la interpretación práctica de cuestiones donde el tratamiento de datos personales es central. Para una empresa designada como gatekeeper, o para cualquier actor que dependa de ese ecosistema, la lección es bastante concreta: no basta con validar una medida con el equipo de competencia si esa medida reconfigura finalidades, bases jurídicas, flujos de datos o perfiles de acceso. El artículo 25 del GDPR vuelve a aparecer aquí con toda su mala leche operativa: si privacidad debe incorporarse desde el diseño, también debe incorporarse cuando un remedio de competencia obliga a rediseñar sistemas.

NIS2 y GDPR: la cooperación obligatoria que nadie resuelve con un organigrama bonito

La interacción entre privacidad y ciberseguridad es menos novedosa, pero ahora está mucho más apretada. NIS2, en su artículo 21, obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de seguridad de redes y sistemas de información. Entre esas medidas están la gestión de incidentes, la continuidad de negocio, la seguridad de la cadena de suministro, el uso de criptografía y, donde proceda, la autenticación multifactor.

Hasta aquí, cualquier CISO asentiría con cara de “ya lo sé”. El problema aparece cuando esas obligaciones se cruzan con el GDPR. Una brecha de seguridad con datos personales activa el artículo 33 del GDPR, que exige notificar a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella. Si además el incidente afecta a una entidad dentro del perímetro NIS2, pueden activarse canales de notificación distintos, con umbrales y destinatarios diferentes según la transposición nacional y la arquitectura institucional de cada Estado miembro.

No es una contradicción jurídica pura. Es algo más pesado: una fricción operacional. Equipos distintos, definiciones no siempre calcadas, tiempos que corren en paralelo y autoridades que no necesariamente comparten procedimientos. El legislador europeo ha intentado amortiguar eso. NIS2 incluye previsiones de cooperación y busca evitar duplicidades innecesarias cuando un incidente compromete datos personales, pero la realidad de la ejecución dependerá mucho de cada país. Aquí no hay milagro doctrinal. Hay gobernanza interna o hay caos.

¿La implicación práctica? Si tu procedimiento de incidentes sigue separando en carpetas distintas “brecha GDPR” e “incidente NIS2”, probablemente estás diseñando un problema para tu yo del futuro. Lo correcto no es fusionar sin matices marcos distintos, sino construir un esquema de triaje único que permita identificar desde el minuto uno qué hechos activan qué obligaciones, con qué evidencias y frente a qué autoridades. Quien no tenga eso atado no sufrirá por falta de norma, sino por exceso de norma mal coordinada.

DORA no sustituye al GDPR, pero obliga a hablar el mismo idioma

En finanzas, esa convergencia se vuelve todavía más severa. DORA no es una ley de privacidad, ni pretende serlo. Su foco está en la resiliencia operativa digital de las entidades financieras. Pero cualquiera que lea sus capítulos sobre gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia y terceros proveedores críticos entiende enseguida que el tratamiento de datos personales está por todas partes, aunque no figure en el título.

El artículo 5 de DORA exige un marco interno de gobernanza y control para gestionar el riesgo TIC. El artículo 17 regula la clasificación de incidentes relacionados con las TIC y las ciberamenazas significativas. El artículo 19 entra en la notificación de incidentes graves a las autoridades competentes. Y el artículo 28 abre el capítulo sobre gestión del riesgo derivado de terceros proveedores de servicios TIC. Tradúcelo a castellano llano: inventario, dependencias, registros, evidencias, escalado, contratos, auditorías y trazabilidad. Todo eso roza de lleno información personal, ya sea de clientes, empleados o usuarios autorizados.

La tentación en muchas entidades ha sido repartir papeles: DORA para riesgo operacional y seguridad; GDPR para privacidad; outsourcing para compras y legal. Funciona hasta que deja de funcionar. Por ejemplo, una incidencia en un proveedor cloud puede activar deberes contractuales de DORA, medidas de seguridad del artículo 32 del GDPR y una posible notificación de brecha del artículo 33. Si cada función opera con taxonomías incompatibles, el incidente se convierte en un concurso de PowerPoint.

La clave no está en decir que DORA y GDPR “se solapan” y quedarse tan ancho. La clave está en mapear exactamente dónde interactúan. El registro de información sobre acuerdos con terceros TIC que exige DORA no sustituye al registro de actividades de tratamiento del artículo 30 del GDPR, pero ambos deberían poder dialogar. Las pruebas de resiliencia de DORA no equivalen a una evaluación de impacto del artículo 35 del GDPR, pero pueden aportar evidencia relevante sobre riesgos y controles. El principio de minimización del artículo 5.1.c del GDPR no desaparece porque una función de seguridad quiera retener más telemetría; obliga a justificar mejor qué se recoge, para qué y durante cuánto tiempo.

La entidad que entienda esa lógica ahorrará fricción. La que no, acabará duplicando controles y descubriendo demasiado tarde que dos equipos describen el mismo flujo crítico con nombres distintos.

Espacios europeos de datos: la vieja fantasía de compartir más datos, ahora con manual de instrucciones

Hay un terreno donde la tensión entre reutilización de datos y derechos fundamentales se vuelve especialmente visible: los espacios europeos de datos. El de salud es el caso paradigmático, porque combina ambición política, sensibilidad extrema del dato y una complejidad institucional que haría bostezar a un santo.

El debate de fondo no es nuevo. Europa quiere facilitar usos primarios y secundarios de datos para asistencia, investigación, innovación y política pública. La protección de datos no impide ese objetivo, pero exige que se articule con bases jurídicas claras, delimitación de finalidades, garantías, seguridad y gobernanza robusta. Cuando esos elementos quedan vagos en una propuesta legislativa, el EDPB suele reaccionar recordando algo bastante menos glamuroso que la retórica de la innovación: si el tratamiento implica datos personales, el GDPR sigue dentro de la sala.

Eso vale también para proyectos de intercambio de información entre autoridades o entre actores públicos y privados. La cuestión verdaderamente incómoda no es si compartir datos suena útil, que casi siempre suena útil, sino bajo qué base jurídica se hace, con qué límites, con qué minimización y con qué salvaguardas frente a reutilizaciones expansivas. El principio de limitación de la finalidad del artículo 5.1.b del GDPR y el requisito de base jurídica del artículo 6 no son adornos. Son el punto donde muchas arquitecturas bienintencionadas empiezan a torcerse.

Por eso resulta más riguroso hablar de una presión regulatoria creciente para coordinar marcos que de anuncios puntuales difíciles de verificar. El patrón sí está claro: a medida que la UE impulsa ecosistemas de datos sectoriales, la protección de datos deja de ser un checklist y se convierte en condición de diseño institucional.

eIDAS 2.0, cartera de identidad y el espejismo de la “máxima reutilización”

La identidad digital europea promete comodidad, interoperabilidad y una reducción del festival de credenciales dispersas que sufrimos todos. También promete nuevos dolores de cabeza. La razón es sencilla: un sistema de identidad reutilizable a escala europea concentra atributos, relaciones de confianza y accesos a servicios públicos y privados. Si eso se gobierna mal, el riesgo no es teórico.

Aquí el GDPR aporta una disciplina muy concreta. Minimización, limitación de finalidad, exactitud y seguridad no son principios abstractos; son reglas de diseño para evitar que una cartera de identidad termine convirtiéndose en una navaja suiza para recopilar más datos de los necesarios en cada interacción. El artículo 25 vuelve a ser determinante: si el diseño por defecto no limita la divulgación de atributos al mínimo necesario, luego ya puedes redactar avisos de privacidad impecables que el problema seguirá en la arquitectura.

El atractivo político de estos sistemas está en la reutilización y la interoperabilidad. El riesgo jurídico está en que la reutilización derive en función deslizante: un atributo emitido para un contexto acaba siendo atractivo para muchos otros. Ese desplazamiento suele presentarse como eficiencia. A veces lo es. Otras veces es simplemente un caso elegante de creep regulatorio y funcional.

Por eso el valor del EDPB en este terreno no depende de adjudicarle un titular concreto, sino de algo más estructural: recordar que interoperar no equivale a legitimar cualquier flujo de datos, y que una infraestructura paneuropea no queda al margen de los principios del GDPR por muy bonita que sea la capa tecnológica.

AI Act: la próxima gran pelea será de gobernanza, no de eslóganes

Muchos directivos siguen tratando la privacidad y la gobernanza de IA como dos proyectos paralelos. Es un error de libro. El AI Act y el GDPR no son intercambiables, pero se pisan constantemente en sistemas que usan datos personales para entrenamiento, ajuste, inferencia, monitorización o toma de decisiones que afectan a personas.

El GDPR ya contiene reglas que golpean de lleno en esos casos: licitud del tratamiento, minimización, transparencia, derechos de acceso, oposición y, en determinados supuestos, el artículo 22 sobre decisiones individuales automatizadas. El AI Act añade otra capa: clasificación de riesgos, obligaciones de documentación, gobernanza de datos, supervisión humana, exactitud, robustez y ciberseguridad para sistemas de alto riesgo. Dicho sin ceremonia: si tu organización lleva la privacidad por un lado y la IA responsable por otro, está construyendo dos maquetas del mismo edificio.

La interacción futura entre autoridades será inevitable. No porque todos vayan a sentarse felices en la misma mesa, sino porque muchos expedientes no se podrán resolver con una sola lente. Un sistema de IA que segmenta usuarios, prioriza contenidos, detecta fraude o apoya decisiones de admisión o precio puede activar a la vez preguntas de protección de datos, consumo, no discriminación, ciberseguridad y, en ciertos mercados, competencia. El sueño del cumplimiento modular se desvanece justo cuando más lo necesitan los departamentos jurídicos.

La empresa inteligente no esperará a que cada autoridad publique su guía definitiva sobre cada borde gris. Hará algo bastante menos heroico y mucho más efectivo: un inventario unificado de casos de uso, bases jurídicas, flujos de datos, dependencias tecnológicas, medidas de control y responsables internos. Sin ese mapa, cualquier discusión sobre IA fiable es cosmética.

La objeción habitual: “esto siempre ha sido así”

La réplica más común a todo este argumento suena razonable: los marcos regulatorios siempre se han tocado, y las empresas siempre han tenido que coordinar equipos. Cierto. Pero esa objeción se queda corta por tres motivos.

El primero es de intensidad normativa. No estamos ante un único reglamento más, sino ante una acumulación de piezas europeas que comparten datos, tecnología y gobernanza como materia prima. GDPR, NIS2, DORA, DMA, AI Act, Data Act, eIDAS 2.0 o los espacios sectoriales de datos no forman un sistema perfectamente unificado, ni mucho menos, pero avanzan sobre objetos organizativos parecidos: infraestructuras digitales, acceso a datos, trazabilidad, seguridad, proveedores críticos y derechos de usuarios.

El segundo motivo es institucional. Ya no basta con que una empresa coordine internamente equipos que antes no se hablaban. También debe asumir que la coordinación, con mayor o menor fortuna, se está intentando del lado supervisor. Cuando el regulador se organiza para mirar un problema desde varias lentes, las respuestas puramente locales pierden recorrido.

El tercero es económico. El coste de la descoordinación ya no aparece solo en forma de sanción. Aparece mucho antes: proyectos retrasados porque nadie resolvió la base jurídica de una funcionalidad que seguridad ya había desplegado; contratos con proveedores que cubren resiliencia operativa pero dejan mal atada la posición como encargado o subencargado; procesos de notificación de incidentes que no comparten criterios de materialidad; equipos de producto que descubren demasiado tarde que una obligación sectorial exige cambios incompatibles con el modelo de consentimiento ideado al principio.

Así que sí, había interacción antes. La diferencia es que ahora resulta más visible, más frecuente y más cara.

Qué deberían hacer las empresas, sin teatro ni organigramas de postal

La primera tarea es aceptar que “coordinación” no significa crear otro comité con siglas solemnes. Significa identificar decisiones concretas que hoy se toman de forma fragmentada y que ya no deberían tomarse así. Hay al menos cinco frentes donde esto se nota enseguida.

• Incidentes: unifica el triaje inicial para evaluar, con la misma evidencia factual, si se activan deberes bajo GDPR, NIS2, DORA u obligaciones contractuales. La clasificación puede divergir después; la captura de hechos no debería.
• Terceros: cruza el inventario de proveedores TIC críticos, subencargados y servicios con acceso a datos personales. DORA art. 28 y GDPR arts. 28 y 32 no piden exactamente lo mismo, pero castigan la misma pereza documental.
• Diseño de producto: integra revisión de privacidad, seguridad y requisitos sectoriales antes de congelar arquitectura. El artículo 25 del GDPR pierde buena parte de su utilidad si entra cuando ya está decidido todo lo caro.
• Gobernanza del dato: documenta finalidades, bases jurídicas, periodos de conservación y controles de acceso de modo que sirvan también para auditoría tecnológica y resiliencia, no solo para un registro formal del artículo 30.
• IA y analítica avanzada: evita evaluaciones separadas que describen el mismo sistema con vocabularios incompatibles. Si el modelo usa datos personales, la evaluación de impacto, la evaluación de riesgos de IA y los controles de seguridad deben conversar de verdad, no mediante anexos que nadie lee.

Nada de esto exige adivinar el futuro. Exige algo más prosaico: gobernanza operativa. La ironía es que muchas organizaciones llevan años invirtiendo en herramientas GRC capaces de modelar dependencias complejas, pero siguen gestionando sus interacciones regulatorias por vía oral y a última hora.

Lo que no conviene sobreactuar

Tampoco hace falta convertir cada gesto institucional en prueba de una gran unificación regulatoria. Europa sigue produciendo zonas grises, solapamientos torpes y competencias repartidas con una pasión burocrática casi artesanal. Habrá conflictos interpretativos. Habrá autoridades defendiendo perímetros propios. Habrá textos que pidan interoperabilidad con una mano y prudencia extrema con la otra.

Además, no toda cooperación interregulatoria implica armonía sustantiva. Que varios supervisores hablen entre sí no significa que compartan prioridades, umbrales o remedios. A veces la coordinación sirve precisamente para hacer visible el desacuerdo y administrarlo mejor. También eso es progreso, aunque venda menos titulares.

Por eso conviene ser preciso con lo que sí sabemos. Sabemos que el EDPB tiene un mandato legal de coherencia bajo el artículo 70 del GDPR. Sabemos que varias normas europeas recientes fuerzan puntos de contacto entre privacidad, competencia, seguridad, resiliencia e identidad digital. Sabemos que el DMA institucionaliza al menos una forma de cooperación entre marcos supervisores a través de su artículo 40. Sabemos que NIS2 y DORA generan obligaciones operativas que, en múltiples supuestos, coexistirán con las del GDPR. Y sabemos, sobre todo, que ninguna empresa puede responder a ese paisaje con equipos que solo comparten información cuando ya hay una crisis.

La conclusión incómoda

La pregunta ya no es si la protección de datos debe coordinarse con otros dominios regulatorios. Esa pantalla está pasada. La pregunta es quién dentro de la empresa tiene autoridad real para resolver los puntos de fricción cuando privacidad, seguridad, resiliencia, competencia y producto no quieren lo mismo al mismo tiempo.

Ese es el test serio. No el discurso sobre cultura de cumplimiento. No la presentación con tres líneas de defensa y colores corporativos. El test consiste en comprobar si tu organización puede contestar, en una misma mesa y con evidencia común, preguntas tan básicas como estas: qué datos usa este servicio, con qué base jurídica, qué proveedor lo soporta, qué dependencia crítica crea, qué incidente podría comprometerlo, qué autoridad habría que notificar y qué cambio normativo podría obligar a rediseñarlo.

Si la respuesta hoy sale de cinco sistemas distintos y tres cadenas de correos, no tienes un problema de retórica regulatoria. Tienes un problema de ejecución. Y ese, a diferencia de algunos titulares inflados, sí está perfectamente verificado.