Cloud and AI Development Act, Union Assurance Levels, soberanía digital y el futuro del cloud europeo

Actualizado al 12 de agosto de 2026

La soberanía digital está dejando de ser un concepto abstracto.

Durante años, gran parte de la conversación sobre cloud sovereignty se concentró en una pregunta relativamente sencilla:

¿Dónde están almacenados mis datos?

Pero Europa está avanzando hacia una definición mucho más amplia.

El 3 de junio de 2026, la Comisión Europea presentó formalmente la propuesta del Cloud and AI Development Act (CADA), COM(2026) 502, como parte de un paquete más amplio destinado a fortalecer la soberanía tecnológica europea.

CADA propone impulsar la capacidad europea de cloud e inteligencia artificial, facilitar nuevas inversiones en datacenters y, probablemente su elemento más transformador, crear un marco común europeo para evaluar formalmente la soberanía de los servicios cloud.

La propuesta introduce cuatro Union Assurance Levels — UAL 1, 2, 3 y 4, que podrían convertirse en un elemento fundamental para determinar qué servicios cloud pueden utilizar las administraciones públicas europeas dependiendo de la sensibilidad, criticidad y riesgo de sus cargas de trabajo.

Esto podría transformar profundamente la relación entre:

Cloud + AI + Cybersecurity + Procurement + Digital Sovereignty + GRC.

Primero: CADA todavía no es una regulación vigente

Esta distinción es fundamental.

CADA es actualmente una propuesta legislativa.

El expediente oficial es:

2026/0138(COD)

y está siendo tramitado mediante el procedimiento legislativo ordinario de la Unión Europea.

A fecha de 12 de agosto de 2026, EUR-Lex identifica el procedimiento como ongoing. Esto significa que el texto presentado por la Comisión Europea puede sufrir modificaciones durante las negociaciones entre el Parlamento Europeo y el Consejo antes de una eventual adopción definitiva.

Por lo tanto, todavía no debería afirmarse que una empresa:

“cumple CADA”;
“tiene UAL 3”;
“está certificada bajo CADA”;
o “no puede alcanzar determinado UAL”.

Los niveles y requisitos que analizamos en este artículo corresponden a la propuesta COM(2026) 502 presentada el 3 de junio de 2026.

¿Por qué Europa propone CADA?

La Comisión identifica la infraestructura de cómputo como un recurso estratégico para:

competitividad;
resiliencia;
seguridad económica;
soberanía;
desarrollo de inteligencia artificial.

El crecimiento de la IA está aumentando significativamente la demanda de capacidad computacional y, al mismo tiempo, Europa reconoce una elevada dependencia de proveedores de cloud y AI no europeos.

La propuesta identifica cuatro grandes objetivos:

Incrementar la capacidad computacional y de IA desarrollada y desplegada dentro de la Unión Europea.
Crear condiciones atractivas para desplegar infraestructura de cómputo sostenible e innovadora.
Abordar preocupaciones relacionadas con soberanía de datos y continuidad operacional.
Incrementar la resiliencia del suministro de servicios cloud, particularmente dentro del sector público.

Por eso CADA no es simplemente otra regulación de privacidad.

Está relacionada con una pregunta mucho más estratégica:

¿Qué nivel de control real conserva Europa sobre la infraestructura digital de la que depende?

La diferencia entre residencia de datos y soberanía digital

Una de las principales consecuencias conceptuales de CADA es que almacenar información dentro de Europa podría no ser suficiente para considerar soberano un servicio.

Podemos distinguir:

Data Residency

Responde principalmente a:

¿Dónde se almacenan y procesan físicamente los datos?

Digital Sovereignty

Añade preguntas como:

¿Quién controla legalmente al proveedor?

¿Desde dónde se administra la infraestructura?

¿Dónde se encuentra el personal con acceso privilegiado?

¿Quién controla las actualizaciones del software?

¿De qué proveedores tecnológicos depende el servicio?

¿Puede una jurisdicción extranjera obligar al proveedor a entregar información?

¿Puede una autoridad extranjera interrumpir o degradar el servicio?

¿Puede el cliente continuar operando si pierde acceso al proveedor?

Este cambio es significativo.

Data residency es solamente una dimensión de la soberanía.

Los Union Assurance Levels: UAL 1, 2, 3 y 4

El Annex II de la propuesta CADA define criterios acumulativos para cuatro niveles de assurance.

Los niveles superiores incorporan requisitos progresivamente más estrictos.

Además existe una diferencia importante respecto de cómo se demostraría el cumplimiento:

UAL 1: conformity self-assessment.
UAL 2, 3 y 4: auditoría independiente realizada por terceros.

La propuesta establece que los proveedores que aspiren a UAL 2, 3 o 4 deberán obtener un informe y una opinión positiva de auditoría, y posteriormente solicitar reconocimiento ante la autoridad nacional competente correspondiente.

Resumen conceptual

Nivel	Características principales propuestas
UAL 1	Presencia europea, residencia de infraestructura y datos, cybersecurity, transparencia de subcontractors
UAL 2	Auditoría independiente, operaciones y personal en la UE, controles frente a third-country control, SBOM y supply-chain governance
UAL 3	Mayores requisitos sobre ciudadanía del personal, independencia jurisdiccional, soporte europeo, cybersecurity assurance y control de terceros países
UAL 4	Máximo nivel propuesto: fuerte control europeo sobre proveedor, infraestructura, operaciones, personal, datos sensibles y tecnología

Esta tabla es una simplificación. Los requisitos legales completos están contenidos en el Annex II de COM(2026) 502.

UAL 1: la línea base europea

El Union Assurance Level 1 ya incorpora requisitos significativos.

Según la propuesta, entre otros criterios acumulativos, el proveedor deberá:

estar establecido en la Unión Europea;
mantener dentro de la UE la infraestructura y los activos involucrados en la prestación del servicio, salvo que el organismo público requiera expresamente lo contrario;
mantener dentro de la UE customer data, metadata y telemetry data, nuevamente sujeto a determinadas excepciones solicitadas expresamente por el cliente público;
demostrar prácticas de cybersecurity actualizadas;
ofrecer transparencia respecto de subcontractors;
aplicar due diligence, obligaciones contractuales y supervisión sobre terceros.

Una diferencia importante es que UAL 1 se basaría en self-assessment.

El proveedor emitiría una EU Statement of Conformity, asumiría responsabilidad por dicha declaración y debería hacerla públicamente disponible.

UAL 2: aparece la auditoría independiente

El salto hacia UAL 2 es significativo.

El proveedor y determinados subcontractors involucrados en el servicio tendrían que estar establecidos en la UE, mientras que infraestructura, activos y personal relevantes deberían encontrarse dentro de la Unión.

Además, la propuesta introduce requisitos relacionados con:

controles frente a influencia de terceros países;
continuidad operacional;
localización del soporte;
software supply chain;
SBOM;
auditoría de componentes de software;
planes de migración frente a fallos de proveedores;
controles frente a funcionalidades remotas potencialmente disruptivas.

Un aspecto particularmente relevante para inteligencia artificial aparece expresamente en el texto.

Los datos generados mediante el servicio no deberían utilizarse para entrenar o fine-tune sistemas de IA operados por un tercer país o por entidades establecidas en terceros países y tampoco deberían transferirse fuera de la Unión bajo los criterios definidos para este nivel.

Esto conecta directamente AI Governance con Cloud Sovereignty.

Software Bill of Materials entra en la conversación de soberanía

Uno de los elementos interesantes de CADA es la importancia que asigna a la cadena de suministro de software.

Para determinados niveles, el proveedor deberá documentar un:

Software Bill of Materials — SBOM

junto con las dependencias relevantes para la prestación del servicio.

El objetivo es entender:

qué componentes utiliza el servicio;
quién los desarrolla;
de qué jurisdicción proceden;
quién controla sus actualizaciones;
qué ocurriría si desaparece un proveedor;
si existen mecanismos remotos capaces de modificar o interrumpir el software.

Esto demuestra que la soberanía digital deja de ser únicamente una conversación contractual.

También se convierte en una conversación de:

software supply-chain security.

UAL 3: soberanía jurídica y operacional mucho más fuerte

UAL 3 incorpora requisitos sustancialmente superiores.

Entre otros criterios, la propuesta establece que:

el proveedor auditado y determinados subcontractors deben estar establecidos en la UE;
infraestructura, activos y personal deben estar ubicados en la Unión;
customer data, metadata y telemetry data deben permanecer dentro de la UE;
el personal involucrado debe ser ciudadano de la Unión;
cuando corresponda, deberá disponer de security clearance nacional;
el servicio deberá obtener un nivel elevado de cybersecurity assurance;
soporte técnico y operacional deberá ejecutarse exclusivamente desde la UE;
deben existir fuertes controles sobre software supply chain.

La propuesta contempla además un mecanismo particularmente interesante relacionado con proveedores bajo control de terceros países.

Associated Third Countries: una pieza estratégica de CADA

El artículo 18 establece que la Comisión Europea podría identificar determinados terceros países como suficientemente confiables para permitir que proveedores sujetos al control de esos países puedan ser evaluados para UAL 3.

No sería automático.

La Comisión tendría que adoptar un implementing act y evaluar varios criterios.

Entre ellos:

existencia de una decisión de adecuación bajo GDPR;
protección frente a determinadas formas de acceso extraterritorial a datos;
ausencia de mecanismos capaces de obligar al proveedor a degradar o interrumpir servicios;
acceso abierto para proveedores europeos al mercado de dicho país;
reciprocidad en contratación pública.

Este mecanismo puede convertirse en una pieza geopolítica considerable.

CADA no evaluaría únicamente tecnologías.

También podría evaluar la relación jurídica entre jurisdicciones.

UAL 4: el nivel máximo propuesto

UAL 4 representa el nivel más exigente del framework propuesto.

Entre sus criterios encontramos:

proveedor y subcontractors relevantes establecidos en la UE;
infraestructura, activos y personal dentro de la Unión;
sensitive customer data exclusivamente dentro de la UE;
personal involucrado formado por ciudadanos de la Unión;
security clearances cuando correspondan;
nivel de cybersecurity assurance elevado;
ausencia de control por terceros países sobre el proveedor o subcontractors relevantes;
soporte técnico y operacional dentro de la Unión;
control reforzado sobre la cadena de suministro de software.

Uno de los criterios más importantes se refiere al effective control over software components.

El proveedor tendría que poder demostrar que entidades de terceros países no ejercen control efectivo sobre aspectos como:

diseño;
desarrollo;
mantenimiento;
evolución;
prioridades técnicas;
security remediation;
continuidad del componente.

Esto nos lleva a una conclusión muy importante:

La soberanía tecnológica no depende solamente de dónde se ejecuta el software, sino también de quién puede modificarlo, mantenerlo, actualizarlo o dejar de soportarlo.

CADA puede cambiar el procurement público europeo

Probablemente ésta sea una de las consecuencias más importantes de toda la propuesta.

CADA vincula directamente los Union Assurance Levels con public procurement.

Según el artículo 30 de la propuesta, los organismos públicos cuyas actividades no hayan sido identificadas como relevantes para preservar el orden público tendrían que utilizar, como mínimo, servicios reconocidos en UAL 1.

Para actividades consideradas relevantes para el orden público en áreas como:

sectores cubiertos por NIS2;
national security;
internal security;
external border management;
defence;
justice;
law enforcement;

el procurement debería limitarse a servicios reconocidos como UAL 2, UAL 3 o UAL 4, dependiendo del resultado del correspondiente risk assessment.

Esto cambia la naturaleza de una licitación cloud.

Una futura contratación podría no limitarse a preguntar:

¿Cuál es el precio?

¿Qué SLA ofrece?

¿Dónde está ubicado el datacenter?

También podría preguntar:

¿Qué Union Assurance Level ha obtenido este servicio?

Sovereignty Risk Assessment antes del procurement

CADA plantea un enfoque basado en riesgo.

Los Estados miembros y entidades de la Unión deberían realizar evaluaciones periódicas para determinar qué nivel de assurance corresponde a diferentes actividades públicas.

Entre los factores que deberían considerarse están:

sensibilidad de los datos;
criticidad;
volumen;
impacto sobre derechos y libertades;
riesgo de acceso ilegal desde terceros países;
riesgo de interrupción del servicio.

La Comisión podría posteriormente proporcionar metodologías y templates comunes.

Incluso existe una disposición interesante:

si una evaluación de riesgo determina que un organismo debe migrar hacia otro servicio cloud, la propuesta establece un período de transición que no debería superar 12 meses, teniendo en cuenta viabilidad técnica, continuidad y portabilidad.

Multi-cloud y reducción del concentration risk

Otro aspecto interesante es que CADA pide considerar si una estrategia:

multi-vendor;
o multi-cloud

resulta apropiada como parte de la evaluación de riesgo y procurement.

Esto conecta CADA con otro gran tema de GRC:

concentration risk.

La dependencia excesiva de un único hyperscaler puede representar:

operational risk;
systemic risk;
exit risk;
supply-chain risk;
geopolitical risk.

La discusión sobre multi-cloud deja así de ser exclusivamente una decisión arquitectónica.

También puede convertirse en una decisión regulatoria.

CADA puede extender su influencia más allá del sector público

Aunque el framework está fuertemente orientado al sector público, sería un error asumir que sus efectos terminarían allí.

La propia propuesta permite que entidades privadas de sectores de alta criticidad cubiertos por NIS2 realicen assessments similares.

También permite a la Comisión desarrollar orientación adicional y, bajo determinadas circunstancias, establecer necesidades de impact assessment para entidades privadas de sectores altamente críticos.

Además, la propia Comisión reconoce que los requisitos utilizados en procurement público frecuentemente generan efectos indirectos sobre sectores privados regulados.

Podríamos ver eventualmente impacto en organizaciones de:

banca;
energía;
telecomunicaciones;
salud;
transporte;
infraestructura crítica;
defensa;
servicios públicos.

European Added Value en las licitaciones

CADA no se limita a sovereignty assurance.

La propuesta establece también que determinadas contrataciones públicas de cloud e inteligencia artificial deberían incorporar criterios no económicos que permitan evaluar la contribución del proveedor al ecosistema europeo.

Entre los aspectos considerados aparecen:

utilización de tecnologías desarrolladas en Europa;
fortalecimiento de la supply chain europea;
resultados procedentes de investigación europea;
componentes diseñados o fabricados dentro de la Unión;
participación de SMEs europeas.

Incluso se establece como objetivo que al menos 25% del procurement público de cloud computing services y AI systems sea adjudicado a SMEs innovadoras.

CADA también quiere crear una EuroCloud Federation

Otra propuesta interesante es la creación de una:

European Public Sector Cloud Federation — EuroCloud Federation

Sería un mecanismo voluntario para facilitar que entidades públicas europeas compartan:

datacenter services;
cloud services;
computing resources;
storage;
networking capacity.

Esto demuestra que CADA no es únicamente una regulación defensiva.

También es una estrategia industrial.

Europa quiere simultáneamente:

reducir dependencias;
aumentar capacidad propia;
crear un mercado tecnológico europeo más competitivo.

CADA y la estrategia europea de AI

CADA forma parte de un paquete de soberanía tecnológica más amplio.

La Comisión Europea presentó el Tech Sovereignty Package el 3 de junio de 2026 incluyendo, entre otras iniciativas:

Cloud and AI Development Act;
Chips Act 2.0;
Open Source Strategy;
Strategic Roadmap for Digitalisation and AI in Energy.

Además, la Comisión vincula CADA con su AI Continent Action Plan, cuyo objetivo incluye ampliar significativamente la capacidad europea de datacenters y computing infrastructure.

La visión es clara:

Europa no quiere limitarse a regular la inteligencia artificial.

También quiere disponer de la infraestructura necesaria para desarrollarla y operarla.

CADA y AI Agents

Una sección particularmente interesante del Annex I está dedicada a:

AI Agents Platform.

La propuesta identifica como uno de sus “Grand Challenges” el desarrollo de un framework europeo de orquestación de agentes capaz de soportar múltiples AI agents trabajando conjuntamente con requisitos elevados de seguridad y resiliencia.

Los posibles casos mencionados incluyen:

healthcare;
cybersecurity;
scientific research.

Esto es relevante porque demuestra que el debate europeo sobre soberanía ya está avanzando desde:

cloud infrastructure

hacia:

sovereign agentic AI infrastructure.

CADA vs Cloud Sovereignty Framework: UAL no es SEAL

Existe otra distinción fundamental.

La Comisión Europea ya dispone de un Cloud Sovereignty Framework — CSF, utilizado en procesos recientes de procurement.

Este framework utiliza:

Sovereignty Effectiveness Assurance Levels — SEAL.

En junio de 2026 la Comisión explicó que el CSF utiliza:

SEAL-0;
SEAL-1;
SEAL-2;
SEAL-3;
SEAL-4;

además de 48 criterios distribuidos entre ocho sovereignty objectives.

Los objetivos incluyen:

Strategic Sovereignty.
Legal & Jurisdictional Sovereignty.
Data & AI Sovereignty.
Operational Sovereignty.
Supply Chain Sovereignty.
Technology Sovereignty.
Security & Compliance Sovereignty.
Environmental Sustainability.

Sin embargo:

CADA UAL y CSF SEAL no son el mismo framework.

El CSF actualmente publicado es un instrumento de procurement desarrollado por la Comisión.

CADA propone un framework regulatorio europeo.

Aunque existen similitudes conceptuales, no debe asumirse una equivalencia matemática como:

SEAL-3 = UAL-3.

Un nuevo significado para “Sovereign Cloud”

Todo esto obliga a reconsiderar la definición tradicional de sovereign cloud.

Propongo pensar en al menos siete dimensiones.

1. Data Sovereignty

¿Dónde están los datos?

¿Dónde son procesados?

¿Dónde se almacenan metadata, telemetry y logs?

2. Legal Sovereignty

¿Qué jurisdicciones pueden ejercer autoridad sobre el proveedor?

¿Existen leyes extraterritoriales aplicables?

3. Operational Sovereignty

¿Quién administra la plataforma?

¿Desde qué país?

¿Puede operarse sin personal extranjero?

4. Technology Sovereignty

¿Quién controla el software?

¿Quién mantiene el código?

¿Quién controla las actualizaciones?

5. Supply-Chain Sovereignty

¿De qué fabricantes, librerías, frameworks y terceros depende la solución?

6. Security Sovereignty

¿Quién controla SOC, monitoring, incident response, keys y privileged access?

7. Continuity Sovereignty

¿Puede la organización continuar operando si pierde acceso a determinado proveedor o jurisdicción?

Desde esta perspectiva:

Data residency es solo una pieza de un sistema de soberanía mucho más grande.

La conexión con AI Governance

CADA también puede cambiar profundamente la forma en la que evaluamos sistemas de inteligencia artificial.

Un AI Risk Assessment tradicional podría analizar:

accuracy;
bias;
explainability;
privacy;
security;
human oversight;
model risk.

Una evaluación futura de Sovereign AI podría tener que añadir:

model provider jurisdiction;
cloud provider jurisdiction;
location of inference;
training-data location;
model update authority;
software supply chain;
operational personnel;
subcontractors;
foreign government exposure;
exit strategy;
portability;
disconnected operation.

Es posible que veamos converger dos disciplinas que hasta ahora muchas organizaciones trataban por separado:

AI Governance + Digital Sovereignty Governance.

¿Cómo se relaciona Microsoft con esta evolución?

Es importante separar CADA de las iniciativas comerciales de los proveedores.

CADA sigue siendo una propuesta legislativa y no debe inferirse qué UAL alcanzaría hoy un producto concreto.

Sin embargo, Microsoft ya ha venido desarrollando públicamente una estrategia europea de soberanía.

European Digital Commitments

El 30 de abril de 2025, Microsoft anunció cinco compromisos digitales para Europa, incluyendo expansión de infraestructura cloud y AI y medidas destinadas a fortalecer resiliencia digital.

EU Data Boundary

El 26 de febrero de 2025, Microsoft anunció la finalización del EU Data Boundary for the Microsoft Cloud.

Para los servicios incluidos, clientes europeos comerciales y del sector público pueden almacenar y procesar customer data y pseudonymized personal data dentro de regiones EU/EFTA, sujeto a las condiciones y excepciones documentadas por Microsoft.

Microsoft Sovereign Cloud

Microsoft define actualmente su Sovereign Cloud como una oferta unificada que incluye:

public cloud;
private environments;
partner-operated clouds;

y capacidades destinadas a controlar dónde viven los datos, cómo se gobierna el acceso y cómo se realizan las operaciones cloud.

Microsoft también ha venido ampliando capacidades para workloads altamente controlados y entornos disconnected.

Estas inversiones son relevantes para la evolución del mercado europeo, aunque no deben interpretarse como una declaración de conformidad con los futuros UAL de CADA.

Qué deberían hacer las organizaciones ahora

CADA todavía está en proceso legislativo.

No es necesario comenzar a “certificarse en CADA”.

Pero sí es un buen momento para mejorar la capacidad de demostrar soberanía.

Una organización podría empezar por:

1. Identificar critical workloads

Determinar qué aplicaciones soportan:

servicios esenciales;
infraestructura crítica;
funciones públicas;
información sensible;
operaciones de seguridad nacional.

2. Mapear jurisdicciones

Documentar:

proveedor cloud;
matriz corporativa;
subsidiaries;
subcontractors;
soporte;
SOC;
proveedores de modelos AI.

3. Construir un Data Residency Map

No solamente customer data.

También:

metadata;
telemetry;
diagnostic information;
logs;
backup;
support data.

4. Evaluar privileged access

Determinar:

quién puede acceder;
desde dónde;
bajo qué jurisdicción;
mediante qué controles JIT/JEA/PAM.

5. Crear un Software Supply Chain Inventory

Mantener:

SBOM;
dependencies;
open-source components;
critical third parties;
update mechanisms.

6. Desarrollar Exit Strategies

Preguntar:

¿Podemos migrar?

¿Cuánto tardaríamos?

¿Podemos exportar nuestros datos?

¿Podemos reemplazar el modelo?

¿Qué ocurre si desaparece una dependencia?

7. Evaluar concentration risk

Identificar si la organización depende excesivamente de:

un hyperscaler;
un modelo;
una región;
un identity provider;
una tecnología propietaria.

Preguntas que un comité de GRC debería comenzar a hacer

Más que preguntar simplemente:

“¿Este proveedor tiene datacenters en Europa?”

las organizaciones deberían evolucionar hacia preguntas como:

Data

¿Dónde están almacenados customer data, metadata, telemetry y backups?

Legal

¿Qué autoridades extranjeras podrían ejercer jurisdicción sobre el proveedor?

Operations

¿Dónde está localizado el personal con acceso administrativo?

Security

¿Quién controla encryption keys y privileged access?

¿Dónde ocurre inference?

¿Pueden los datos utilizarse para entrenamiento o fine-tuning?

Supply chain

¿Existe SBOM?

¿Quién controla las actualizaciones?

Resilience

¿Puede el servicio funcionar si desaparece una dependencia externa?

Exit

¿Cuál es nuestro tiempo real de migración?

Governance

¿Podemos demostrar todo lo anterior mediante evidencia verificable?

CADA puede crear una nueva disciplina de GRC

Estamos observando una convergencia muy interesante.

Hasta ahora tratábamos como áreas relativamente separadas:

Cloud Governance;
Cybersecurity;
AI Governance;
Privacy;
Third-Party Risk;
Business Continuity;
Regulatory Compliance.

CADA muestra que estas áreas están empezando a converger alrededor de un nuevo concepto:

Digital Sovereignty Governance

Un programa de Digital Sovereignty Governance tendría que responder simultáneamente preguntas:

Técnicas

¿Dónde se ejecuta la infraestructura?

Operacionales

¿Quién puede administrarla?

Legales

¿Qué jurisdicciones ejercen autoridad?

Contractuales

¿Qué obligaciones tienen los proveedores?

Geopolíticas

¿Puede un conflicto entre gobiernos afectar el servicio?

De seguridad

¿Quién controla claves, código y actualizaciones?

De continuidad

¿Podemos continuar operando independientemente?

Conclusión

CADA podría representar uno de los cambios más importantes de los próximos años en la política cloud europea.

Su importancia no proviene únicamente de introducir cuatro Union Assurance Levels.

El cambio verdaderamente significativo es conceptual:

Europa propone convertir la soberanía cloud en algo medible, demostrable, auditable y utilizable en decisiones de procurement.

Esto significa pasar de preguntar:

“¿Dónde están mis datos?”

a preguntas mucho más maduras:

“¿Quién controla realmente mi infraestructura?”

“¿Quién administra mi servicio?”

“¿Quién controla mi software?”

“¿De qué jurisdicciones dependo?”

“¿Qué ocurre si una de esas dependencias desaparece?”

“¿Puedo continuar operando?”

“¿Puedo demostrarlo ante un auditor o regulador?”

Para arquitectos, profesionales de cybersecurity, responsables de GRC y líderes de AI Governance, CADA merece seguimiento cercano.

Porque la próxima generación de cloud governance probablemente no estará definida exclusivamente por:

Security + Privacy + Compliance.

También estará definida por:

Control + Autonomy + Resilience + Sovereignty.

Referencias oficiales

Este artículo tiene fines educativos e informativos. CADA continúa siendo una propuesta legislativa y su contenido puede cambiar durante el procedimiento legislativo de la Unión Europea. Las organizaciones deberían evaluar cualquier impacto regulatorio concreto con sus equipos jurídicos, de compliance y de gestión de riesgos.