Ultima revision
8 de julio de 2026
Fuente
AI Office EU
Bruselas ha abierto una consulta sobre soberanía de los datos, y eso merece más atención de la que sugiere el lenguaje burocrático del anuncio. No porque la expresión sea nueva —no lo es—, sino porque vuelve a aparecer en un momento en el que la UE ya no discute solo privacidad o transferencias internacionales: discute control económico, dependencia tecnológica y capacidad real de imponer condiciones en la cadena digital.
La pregunta útil no es si la soberanía del dato suena bien en un titular institucional. La pregunta es otra: qué problema concreto intenta resolver la Comisión cuando pide aportaciones sobre almacenamiento, acceso, tratamiento y transferencia de datos en Europa. Si uno lee esta consulta junto a normas ya vigentes y expedientes regulatorios en marcha, el panorama se aclara bastante. La UE no está inventando un concepto nuevo; está tanteando hasta dónde puede empujar obligaciones, incentivos o restricciones sin chocar con su propio mercado interior, con sus compromisos internacionales y con la realidad operativa de empresas que llevan años montadas sobre proveedores extracomunitarios.
No hace falta adornarlo: el debate no va solo de dónde se aloja un dataset. Va de quién puede exigir acceso, bajo qué ley, con qué garantías, con qué dependencia técnica y con qué coste de salida. Esa es la versión adulta del asunto.
Aunque la consulta pueda presentar la soberanía del dato como una cuestión abierta, la UE ya ha legislado partes sustanciales del problema por piezas. Y esas piezas, vistas juntas, dibujan una agenda bastante reconocible.
El GDPR no habla de “soberanía” en esos términos, pero sí establece un régimen estricto para transferencias internacionales de datos personales en sus artículos 44 a 49. Ahí está el nervio jurídico de fondo: los datos no pueden salir del Espacio Económico Europeo alegremente si no existe una base válida, como una decisión de adecuación (art. 45), garantías adecuadas como las cláusulas contractuales tipo (art. 46), o una de las excepciones del art. 49. Después de Schrems II, además, el debate dejó de ser formalista. No basta con firmar papeles si la ley del tercer país permite accesos desproporcionados por parte de autoridades públicas. Ese punto no es retórica europea: es doctrina asentada por el Tribunal de Justicia.
El Data Act también mete la cuchara, y de forma más práctica de lo que muchos departamentos jurídicos admitieron al principio. Su artículo 23 aborda el cambio entre servicios de tratamiento de datos, con el objetivo de reducir el bloqueo del proveedor. El mensaje es bastante claro: no sirve de mucho hablar de autonomía si luego migrar de un entorno cloud a otro cuesta una fortuna, exige rehacer arquitecturas enteras o depende de condiciones contractuales diseñadas para que nadie se vaya nunca. La soberanía, cuando se pone en contrato y código, se parece mucho a la portabilidad real y bastante menos al eslogan.
La misma lógica aparece en DORA para el sector financiero. El reglamento exige gestionar el riesgo derivado de terceros proveedores de servicios TIC y lo hace con más detalle que muchas políticas internas heredadas. El art. 28 obliga a un marco sólido para la gestión del riesgo de terceros TIC. El art. 30 enumera elementos contractuales clave, incluidos aspectos sobre localización de datos, disponibilidad, acceso, integridad, recuperación y derechos de terminación. El art. 31 añade una capa específica sobre concentración de riesgo. Dicho de otro modo: en finanzas ya no basta con decir que el proveedor es “estratégico” y rezar. Hay que mapear dependencias, revisar contratos y demostrar capacidad de salida o contingencia.
NIS2 no usa el vocabulario de la soberanía como eje central, pero refuerza el mismo impulso desde la seguridad operativa. El art. 21 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de las redes y sistemas de información. Ese mismo artículo menciona, entre otras cosas, seguridad de la cadena de suministro, gestión de incidentes, continuidad de negocio, higiene cibernética y uso de criptografía cuando proceda. Si tu dependencia de un proveedor o de una jurisdicción externa impide cumplir razonablemente con esas obligaciones, el problema deja de ser filosófico y se vuelve regulatorio.
Incluso el esquema europeo de certificación cloud, debatido bajo el Cybersecurity Act, ha mostrado hasta qué punto Bruselas lleva tiempo orbitando esta cuestión. No hace falta exagerar lo que no está cerrado. Basta observar el patrón: seguridad, control de acceso, jurisdicción aplicable, cadena de suministro y capacidad de auditoría son variables que aparecen una y otra vez. Cambia el instrumento. El dolor operativo, no tanto.
Las consultas públicas no son leyes. Tampoco conviene leer cada formulario de la Comisión como si escondiera un reglamento listo para salir de imprenta. Pero tampoco son un ejercicio inocente de participación cívica digital. Sirven para recoger definiciones, medir resistencias, identificar sectores afectados, preparar impacto y testar qué soluciones podrían sobrevivir al escrutinio jurídico y político.
Aquí está el detalle interesante: cuando Bruselas pregunta por soberanía del dato, no está preguntando solo por privacidad. Está abriendo la puerta a que el debate se formule en términos de resiliencia económica, seguridad, contratación, interoperabilidad y dependencia estratégica. Eso amplía el perímetro de actores afectados. Ya no hablamos solo de DPOs, abogados de privacidad o equipos de transferencias internacionales. Entran CISO, procurement, arquitectos cloud, responsables de continuidad, compliance financiero y, en algunos casos, consejo de administración. Como suele pasar en Bruselas, el formulario puede parecer administrativo; la factura operativa llega después.
Además, el concepto de soberanía del dato tiene una ventaja política evidente: permite reagrupar bajo una misma bandera problemas que en realidad nacieron en silos distintos. Transferencias internacionales bajo GDPR. Riesgo de concentración bajo DORA. Seguridad de la cadena de suministro bajo NIS2. Portabilidad y switching bajo Data Act. Certificación y confianza bajo el Cybersecurity Act. Gobernanza sectorial de espacios de datos. Cada expediente tiene su base jurídica y su técnica. La soberanía sirve como pegamento narrativo. Y cuando un concepto funciona como pegamento narrativo, conviene vigilar qué se le pega.
La soberanía del dato es una preocupación legítima. El problema empieza cuando se usa para describir demasiadas cosas a la vez. Si significa control sobre transferencias de datos personales, el GDPR ya ofrece un marco jurídico preciso. Si significa capacidad de cambiar de proveedor sin quedar secuestrado por costes técnicos o contractuales, el Data Act entra de lleno. Si significa reducir la exposición del sistema financiero a un puñado de proveedores cloud, DORA ya apunta a esa concentración. Si significa impedir accesos extraterritoriales incompatibles con derechos fundamentales, volvemos al terreno de Schrems II y a los arts. 44 a 49 GDPR.
Donde el concepto se vuelve resbaladizo es cuando pasa de describir riesgos concretos a sugerir una preferencia general por localización, proveedores europeos o restricciones de mercado sin explicar qué riesgo exacto se mitiga ni con qué coste. Ahí el debate se complica. Y con razón.
No toda dependencia exterior es un fallo regulatorio. No toda localización dentro de la UE equivale a control efectivo. No todo proveedor europeo ofrece mejor seguridad, mejor auditabilidad o mejor capacidad de resiliencia. Tampoco todo proveedor no europeo genera el mismo nivel de riesgo. Confundir geografía con gobernanza es un atajo tentador, pero jurídicamente y técnicamente flojo.
Hay un ejemplo clásico. Una empresa puede alojar datos en un centro de datos situado en la UE y seguir expuesta a conflictos de leyes, acceso desde terceros países, administración remota fuera de la Unión o dependencia extrema de herramientas propietarias. El marketing dirá “local data residency” y todos contentos. El CISO serio y el abogado que haya leído contratos largos no deberían quedarse tan tranquilos.
Si tu organización opera en sectores regulados o depende de tratamiento intensivo de datos, esta consulta no es un tema para dejar a un único equipo. Requiere una lectura cruzada. Y conviene empezar por preguntas bastante terrenales.
Primero: qué datos estás intentando proteger exactamente. Datos personales, secretos comerciales, datos operativos críticos, telemetría industrial, modelos entrenados, logs de seguridad, metadatos, copias de respaldo. Mezclarlo todo bajo la palabra “datos” lleva a respuestas torpes. El régimen jurídico cambia según la categoría, y también la estrategia técnica. El GDPR, por ejemplo, aplica a datos personales. DORA y NIS2 se preocupan por funciones, servicios y sistemas críticos con una mirada operativa más amplia.
Segundo: qué forma adopta la dependencia. Hay dependencias jurídicas, técnicas, económicas y operativas. Jurídica, cuando el proveedor o parte del soporte cae bajo una jurisdicción que puede generar exigencias de acceso problemáticas. Técnica, cuando no puedes migrar sin rediseñar medio entorno. Económica, cuando el coste de salida es disuasorio. Operativa, cuando una interrupción o un cambio contractual comprometen procesos esenciales. Esta tipología no es académica; es la diferencia entre un mapa de riesgo utilizable y una presentación bonita para comités.
Tercero: si tu contrato realmente te protege o solo te da la ilusión de control. DORA art. 30 exige mirar con lupa cuestiones como descripción de funciones, lugares de prestación, disponibilidad, acceso, recuperación, asistencia en caso de incidente y derechos de terminación. En protección de datos, el art. 28 GDPR impone obligaciones para encargados del tratamiento y el art. 32 exige medidas de seguridad apropiadas. Todo eso suena razonable hasta que uno revisa anexos técnicos, subprocesadores, soporte remoto y compromisos de cooperación en escenarios de crisis. Ahí es donde se descubre si el contrato gobierna la realidad o solo la comenta.
Cuarto: si puedes demostrar una alternativa creíble. El Data Act no convierte la multicloud en obligación universal ni promete migraciones mágicas. Pero la dirección de viaje es nítida: reducir barreras de salida y dependencia injustificada. Si tu empresa no ha probado restauración en un entorno alternativo, no ha clasificado workloads por criticidad y no ha valorado qué servicios son sustituibles y cuáles no, hablar de soberanía se queda en tertulia.
Quinto: quién responde internamente por este problema. Si soberanía del dato se reparte entre privacidad, seguridad, legal, compras y negocio sin un dueño claro, terminará ocurriendo lo de siempre: cada función gestionará una esquina del riesgo y nadie el conjunto. Luego llegará el regulador preguntando por dependencias críticas, transferencias, continuidad o auditoría, y aparecerá el deporte corporativo favorito: mirar alrededor por si la responsabilidad era de otro.
En el sector financiero, este debate tiene menos margen para el postureo. DORA ya está obligando a aterrizar muchos de estos conceptos en inventarios, contratos, pruebas y gobernanza. El art. 5 deja claro que el órgano de dirección define, aprueba, supervisa y es responsable de la aplicación del marco de gestión del riesgo TIC. No es un asunto para delegarlo por completo en la segunda o tercera línea y olvidarse.
Si una entidad financiera depende de un proveedor cloud para funciones críticas o importantes, la cuestión de la soberanía del dato no puede tratarse solo como un debate de política industrial europea. Tiene implicaciones directas en clasificación de funciones, estrategia de salida, escenarios de interrupción, concentración de terceros y resiliencia. DORA art. 28 y siguientes obligan a documentar y gobernar esa relación. Y el art. 30, con sus requisitos contractuales, convierte la conversación abstracta en una lista bastante concreta de cosas que deben estar escritas, auditables y operativamente defendibles.
Aquí aparece una tensión incómoda. La regulación quiere reducir dependencia y mejorar control. El mercado, en muchos segmentos, sigue concentrado. No es un secreto. Tampoco hace falta inventar porcentajes para entender el problema. La combinación de economías de escala, servicios avanzados, ecosistemas de desarrollo y costes de migración ha dado a unos pocos proveedores una posición estructuralmente fuerte. Pedir a las entidades financieras que mitiguen ese riesgo es razonable. Fingir que pueden resolverlo solo con una cláusula contractual es otra cosa.
Por eso la consulta sobre soberanía del dato importa también fuera del expediente específico que la origine. Puede servir para alimentar futuras decisiones sobre contratación, estándares, certificación, guías supervisoras o incentivos a la interoperabilidad. Eso no significa que vaya a desembocar automáticamente en una nueva norma dura. Significa que las empresas harían bien en no contestar con mensajes genéricos sobre “innovación” y “confianza”. Bruselas ya tiene suficientes folletos de ese tipo.
Hay una ironía aquí que merece subrayarse. Durante años, muchas empresas trataron las transferencias internacionales de datos personales como un ejercicio documental: firmar SCCs, archivar un assessment, seguir adelante. Luego llegaron las autoridades, las reclamaciones, la litigación y la constatación de que el conflicto entre flujos globales de datos y acceso estatal extraterritorial no se arregla con una casilla marcada.
La jurisprudencia del TJUE y la arquitectura de los arts. 44 a 49 GDPR dejaron una lección dura: cuando el derecho europeo exige un nivel de protección sustancialmente equivalente, hay que mirar la realidad del entorno legal y técnico de destino. No vale con invocar buenas intenciones. Esa experiencia pesa sobre cualquier nueva discusión sobre soberanía del dato, aunque la consulta no se limite a datos personales.
De hecho, el riesgo para Bruselas es doble. Si define soberanía de forma demasiado estrecha, se quedará en una reedición de debates de transferencias ya conocidos. Si la define de forma demasiado amplia, abrirá expectativas regulatorias imposibles de cumplir de manera coherente entre sectores. La línea fina está en identificar riesgos materiales y remedios proporcionados. Suena poco sexy, lo sé, pero es donde se decide si una política sirve para algo o solo multiplica anexos.
En ciberseguridad, el lenguaje de soberanía a veces eclipsa una pregunta más simple: si el proveedor falla, te ataca un tercero o te quedas sin soporte, ¿puedes seguir operando? NIS2 art. 21 obliga a trabajar justamente esa clase de resiliencia. No pide adhesión a consignas. Pide medidas adecuadas y proporcionadas, incluyendo gestión de riesgos en la cadena de suministro y relaciones con proveedores.
Esa distinción importa. Una organización puede cumplir peor NIS2 con un proveedor supuestamente “local” si carece de madurez, transparencia o capacidades operativas, que con uno global bien auditado y bien integrado en su modelo de control. Al revés, también puede descubrir que su dependencia de un proveedor global vuelve inviables ciertos requisitos de visibilidad, respuesta o recuperación. La nacionalidad comercial del proveedor no resuelve la ecuación. Lo hacen la arquitectura, el contrato, la monitorización y la capacidad de contingencia.
Eso obliga a salir del debate de brochazo grueso. Soberanía sin operatividad es eslogan. Seguridad sin capacidad de salida es dependencia maquillada. Y cumplimiento sin inventario de terceros es, siendo generosos, un acto de fe.
Sin atribuir intenciones que no constan en negro sobre blanco, sí se puede identificar el abanico de herramientas que la UE ya utiliza cuando detecta una dependencia estructural o una asimetría de mercado. Puede promover certificación, estándares comunes, requisitos contractuales mínimos, condiciones de interoperabilidad, obligaciones de portabilidad, criterios para sectores regulados, orientaciones supervisoras o señales en contratación pública. Todo eso existe en mayor o menor grado en otros expedientes. No haría falta inventar la rueda; bastaría con decidir dónde apretar.
Lo que debería evitar es disfrazar como soberanía una preferencia indiferenciada por localización o por origen corporativo, sin demostrar por qué esa preferencia reduce un riesgo concreto y compensa sus costes. Una mala política de soberanía del dato podría producir al menos cuatro problemas muy reales.
La UE ya ha vivido algo parecido con otros conceptos nobles convertidos en burocracia abundante y resultado discutible. No hace falta repetir el experimento solo porque “soberanía” suena mejor que “gestión de dependencia contractual y técnica”. Aunque, claro, en una nota de prensa queda bastante peor.
La peor respuesta posible es la declaración genérica a favor de la innovación responsable y la confianza del usuario. Eso no ayuda a nadie. Si una empresa quiere influir de verdad, debería responder con casos de uso, costes de implementación, cuellos de botella técnicos y fricciones regulatorias concretas.
Por ejemplo: explicar cuándo la localización geográfica de datos mitiga un riesgo real y cuándo no. Describir qué cláusulas contractuales faltan a menudo para cumplir de forma seria con DORA art. 30 o con las exigencias de encargados del tratamiento bajo GDPR art. 28. Identificar barreras técnicas al switching que chocan con la lógica del Data Act art. 23. Detallar cómo ciertas arquitecturas de soporte remoto o administración privilegiada complican el control de acceso o la respuesta a incidentes. Se trata de bajar la conversación del manifiesto al diagrama.
También conviene separar peticiones razonables de tentaciones proteccionistas. Pedir claridad sobre acceso gubernamental, auditabilidad, subprocesadores, localización de soporte para funciones críticas o mecanismos de salida es defendible. Pedir que la solución sea siempre un proveedor “europeo” por definición, sin más análisis, es una forma elegante de pedir al regulador que simplifique por ti un problema que tu evaluación de riesgos debería haber resuelto mejor.
Si uno despeja la retórica, la soberanía del dato se reduce a cinco preguntas muy concretas. Quién controla el acceso. Quién puede imponer una obligación legal incompatible con ese control. Quién puede auditar lo que ocurre. Cuánto cuesta salir. Y qué pasa si el proveedor deja de estar disponible, cooperativo o alineado con tus obligaciones regulatorias.
Esas preguntas no son nuevas. Lo nuevo es que Bruselas parece querer reunirlas bajo una misma conversación política. Eso puede ser positivo si sirve para corregir incoherencias entre expedientes y aterrizar medidas proporcionadas. Puede ser un problema si produce una definición expansiva que cada sector interprete a su manera y cada proveedor use como argumento comercial.
Conviene recordar algo elemental. Una estrategia seria de soberanía del dato no se prueba con una bandera en la web del proveedor ni con una promesa de residencia regional. Se prueba con arquitectura, cifrado, gestión de claves, logs, segregación, control de accesos privilegiados, derecho de auditoría, transparencia sobre subprocesadores, pruebas de salida y gobierno interno. Lo demás es branding con acento regulatorio.
La lectura razonable no es que la Comisión tenga ya escrita una intervención cerrada ni que todo vaya a traducirse en obligaciones nuevas inmediatas. Tampoco que estemos ante un mero ejercicio cosmético. Lo más plausible, a la luz del marco existente, es que Bruselas esté intentando ordenar un debate que hoy vive disperso entre privacidad, ciberseguridad, cloud, competencia, resiliencia sectorial y política industrial. Eso ya es relevante.
Para las empresas, la consecuencia práctica es sencilla y bastante menos glamurosa que el término “soberanía”: toca hacer inventario serio de dependencias, revisar bases de transferencia, reforzar contratos, probar salida, clasificar funciones críticas y alinear a legal, seguridad, compras y negocio. Si no lo haces, cualquier giro futuro del regulador te pillará con el discurso preparado y la operativa sin preparar. Mala combinación.
Y para Bruselas, el reto es no vender como novedad absoluta lo que en gran medida ya está repartido en el GDPR, DORA, NIS2, Data Act y el ecosistema de certificación y supervisión asociado. La aportación de valor no estará en bautizar otra vez el problema. Estará en definir qué riesgos quiere mitigar, con qué instrumento y con qué límites. Si lo hace bien, la consulta puede ayudar a convertir un concepto nebuloso en criterios operativos. Si lo hace mal, tendremos otra ronda de retórica solemne sobre autonomía digital mientras los equipos de cumplimiento siguen peleando con contratos innegociables, soporte opaco y arquitecturas de las que cuesta salir.
A estas alturas, la diferencia entre una política útil y un eslogan caro debería estar bastante clara. Pero no conviene dar nada por supuesto. En Bruselas, como en compliance, las palabras importan. El problema es que luego hay que hacerlas funcionar.
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en GDPR: DPIA, brechas de datos y plazos de notificación a la AEPD.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment GDPR.
Las brechas de datos personales que supongan un riesgo para los derechos y libertades deben notificarse a la autoridad de control (en España, la AEPD) sin dilación indebida y, cuando sea posible, en un máximo de 72 horas.
Una Evaluación de Impacto relativa a la Protección de Datos (DPIA) es un análisis obligatorio cuando un tratamiento puede entrañar un alto riesgo para los derechos de las personas (art. 35 RGPD).
Las multas pueden alcanzar hasta 20 millones de euros o el 4% de la facturación anual global, la cifra que sea mayor, según la gravedad de la infracción.