Summary As proposed, the Cloud and AI Development Act (CADA) does not replace existing EU digital regulations; instead, it adds a distinct, parallel layer of sovereignty and capacity-building obligations that operate alongside the AI Act, GDPR, Data Act, NIS2, DORA, and the Cybersecurity Act. While the AI Act governs the safety and fundamental rights risks of AI systems, and the GDPR protects personal data, CADA specifically addresses the strategic risk of dependence on third-country cloud providers. Public sector bodies and critical private entities must therefore comply with multiple, simultaneous regulatory frameworks. CADA's "Union assurance levels" and data centre acceleration zones introduce new compliance checkpoints that do not substitute for existing cybersecurity or data protection duties, creating a "stack" of obligations where sovereignty is the new variable.
Detail
The European Commission's proposal for the Cloud and AI Development Act (CADA), COM(2026) 502 final, is explicitly designed to integrate into the existing EU digital single market rulebook rather than overwrite it. The proposal positions itself as complementary to a wide array of existing legislation, creating a complex "stack" of obligations that in-house counsel and compliance officers must navigate. Understanding this stacking is critical because CADA introduces a new dimension of risk assessmentβsovereignty and operational autonomyβthat is not fully captured by current cybersecurity or data protection laws.
The Sovereignty Gap: Why CADA is a New Layer
The core rationale for CADA, as outlined in the explanatory memorandum, is that existing laws address specific technical or privacy risks but fail to address the strategic risk of dependence on non-European cloud providers. The proposal states that while the GDPR and the EU-US Data Privacy Framework address transatlantic data transfers, they "do not remove sovereignty concerns about dependence on third-country providers." Similarly, the Data Act facilitates switching and interoperability but "does not contain elements to shape up a more competitive offer of European cloud computing services."
Consequently, CADA adds a new regulatory layer focused on "Union assurance levels" (Article 16). This framework categorizes cloud services based on their sovereignty profile, ranging from Level 1 (basic establishment in the Union) to Level 4 (highest assurance, including strict personnel citizenship requirements and no third-country control). This tiered system is unique to CADA. No existing EU law mandates that public procurement decisions be tied to these specific sovereignty tiers. Therefore, compliance with CADA does not exempt an entity from GDPR, NIS2, or AI Act obligations; rather, it adds a parallel requirement to verify the sovereignty status of the underlying infrastructure.
Stacking with the AI Act
CADA and the AI Act (Regulation (EU) 2024/1689) have distinct but overlapping scopes. The AI Act harmonizes rules for the safety, transparency, and fundamental rights compliance of AI systems placed on the market. It does not cover aspects of sovereignty. CADA, conversely, focuses on the infrastructure (cloud and data centres) that enables AI development and deployment.
The proposal notes that CADA "reinforces key objectives of the AI Act" by ensuring that the computational resources required for AI development are available and secure within the Union. However, the obligations are separate. A provider of a high-risk AI system under the AI Act must still ensure that the cloud infrastructure hosting that system meets the relevant Union assurance levels if it is procured by a public authority under CADA Article 30. Furthermore, CADA establishes "Experience and Acceleration Centres for AI" (Article 5) to support the uptake of AI, which complements the AI Act's regulatory sandboxes but focuses more on industrial competitiveness and capacity building.
Stacking with the GDPR and Data Act
The General Data Protection Regulation (GDPR) remains the primary framework for the protection of personal data. CADA explicitly states it is "consistent with existing rules on the processing of personal data, including the GDPR." However, CADA introduces stricter data localization and control requirements for public sector procurement.
Under CADA Article 16 and Annex II, Union assurance levels 2, 3, and 4 require that customer data remain exclusively within the Union and that the cloud provider is not subject to third-country control that could allow unauthorized access. This goes beyond the GDPR's adequacy decisions or standard contractual clauses. For instance, while the GDPR may permit data transfers to a third country with appropriate safeguards, CADA's higher assurance levels (3 and 4) impose strict prohibitions on third-country control.
Crucially, the mechanism for derogation is specific and limited. Article 18 of the proposal allows the Commission to identify third countries where cloud providers subject to their control may be audited for Union assurance level 3, provided specific criteria are met. However, Annex II, Section 4 (Level 4) explicitly requires that the provider and subcontractors "are not subject to the control of a third country," with no reference to an Article 18 derogation. Therefore, Level 4 effectively prohibits third-country control without exception, whereas Level 3 allows for a Commission-approved exception. Thus, a public sector body must satisfy both GDPR data protection standards and CADA's sovereignty criteria, which may be more restrictive regarding data location and provider control.
The Data Act complements CADA by reducing vendor lock-in through switching and interoperability requirements. CADA leverages this by encouraging the use of European providers, but the Data Act's obligations on data access and sharing remain independent of CADA's sovereignty framework.
Stacking with NIS2, DORA, and Cybersecurity Legislation
The Directive on Security of Network and Information Systems (NIS2) and the Digital Operational Resilience Act (DORA) impose rigorous cybersecurity risk management obligations on essential and important entities. CADA does not replace these technical cybersecurity requirements. Instead, it adds a "non-technical" sovereignty dimension.
The proposal explains that NIS2 "improves the cybersecurity risk management of cloud computing service providers... but does not contain measures to boost the uptake and use of such services and is fully focused on technical cybersecurity as opposed to broader sovereignty considerations." Similarly, DORA shapes compliance obligations for cloud providers serving financial entities but is sector-specific. CADA's sovereignty framework applies across all public sector procurement and, through risk assessments, influences critical private sector entities listed in NIS2 Annex I.
Furthermore, CADA interacts with the Cybersecurity Act (Regulation (EU) 2019/881) and the forthcoming European Cybersecurity Certification Scheme for Cloud Services (EUCS). Under CADA Annex II, Union assurance levels 2 and 3 require a European cybersecurity certificate of at least "substantial" assurance, while Level 4 requires a certificate of at least "high" assurance. This means that to achieve a high sovereignty rating under CADA, a provider must also comply with the technical cybersecurity certification under the Cybersecurity Act. The two frameworks are thus stacked: EUCS certifies technical security, while CADA certifies strategic sovereignty.
Obligations for Public and Private Sector
The stacking effect is most pronounced in public procurement. Under CADA Article 29, Member States and Union entities must conduct risk assessments to determine which Union assurance level (2, 3, or 4) is appropriate for their activities. Article 30 then mandates that contracting authorities procure only services that meet the required assurance level. This creates a dual compliance burden: the procured service must be technically secure (NIS2/EUCS), legally compliant with data protection (GDPR), and sovereignly assured (CADA).
For private sector entities, particularly those in sectors listed in NIS2 Annex I, Article 31 allows for similar impact assessments. While not mandatory in the same way as for the public sector, the proposal notes that private sector requirements often mirror public sector standards, creating a de facto stacking of obligations for critical infrastructure operators.
What this means for you
For in-house counsel and compliance officers, the introduction of CADA means that "compliance" is no longer a single checklist but a matrix of intersecting regulations. You must update your vendor due diligence and procurement processes to account for this new layer.
- Update Vendor Assessments: Your current vendor risk assessments likely cover GDPR compliance, NIS2 cybersecurity controls, and AI Act conformity. You must now add a "Sovereignty Assessment" component. For public sector bodies, this is mandatory under Article 29. For private entities in critical sectors, you should conduct similar impact assessments under Article 31 to anticipate market shifts and procurement requirements.
- Map Assurance Levels to Use Cases: You need to determine which of your cloud workloads fall under "public order relevance" as defined in Article 29. If your activities involve national security, defense, or critical infrastructure, you may be required to use Union assurance levels 3 or 4. This may necessitate switching providers if your current hyperscaler does not meet the strict criteria (e.g., no third-country control, Union-based personnel) outlined in Annex II. Note that Level 4 has no derogation for third-country control, unlike Level 3 which may allow it under Article 18.
- Coordinate with Cybersecurity Teams: Ensure that your cybersecurity team is aware that achieving a high Union assurance level under CADA requires specific EUCS certifications. Technical security (NIS2/EUCS) is a prerequisite for sovereignty assurance (CADA), but it is not sufficient on its own. You must verify that your providers are pursuing both technical certification and sovereignty recognition.
- Monitor Deadlines and Risk Assessments: Member States must conduct risk assessments by the date of entry into force plus one year (Article 29). You should engage with your national competent authorities early to understand how they interpret "public order relevance" for your specific sector. Delaying this engagement could lead to non-compliant procurement decisions.
- Prepare for Parallel Penalties: Non-compliance with CADA can result in penalties under Article 24, which are separate from GDPR fines or NIS2 sanctions. Ensure your compliance monitoring systems can track CADA-specific obligations, such as the transparency requirements in Article 23 and the reporting of material changes in circumstances.
Common misconceptions
Misconception 1: CADA replaces the GDPR for data transfers. Reality: CADA does not replace the GDPR. The GDPR remains the primary law for personal data protection. CADA adds stricter sovereignty requirements for public sector cloud procurement. A transfer that is lawful under the GDPR (e.g., via Standard Contractual Clauses) may still fail to meet the sovereignty criteria for Union assurance levels 3 or 4 under CADA, which may prohibit certain third-country controls or data flows.
Misconception 2: If a cloud provider is NIS2 compliant, it is CADA compliant. Reality: NIS2 compliance ensures technical cybersecurity resilience. CADA compliance ensures strategic sovereignty and autonomy. A provider can be NIS2-compliant but still be subject to third-country control that disqualifies it from Union assurance levels 3 or 4 under CADA. The two frameworks address different risk types: technical cyber risk vs. geopolitical dependency risk.
Misconception 3: CADA only applies to public sector bodies. Reality: While the mandatory procurement requirements in Article 30 apply to public sector bodies, the sovereignty framework (Article 16) and the recognition mechanism (Article 17) apply to all cloud computing service providers seeking to serve the public sector. Furthermore, Article 31 allows private sector entities in critical sectors (NIS2 Annex I) to conduct similar impact assessments, and the proposal notes that private sector practices often mirror public sector requirements, creating a broad market impact.
Misconception 4: The AI Act makes CADA redundant for AI infrastructure. Reality: The AI Act regulates the AI systems themselves (safety, transparency, fundamental rights). CADA regulates the cloud and data centre infrastructure that hosts and enables AI. They are complementary. A company can have an AI Act-compliant model but host it on cloud infrastructure that fails CADA's sovereignty requirements for public sector use.
Misconception 5: Article 18 allows third-country control for all high-assurance levels. Reality: Article 18 provides a specific derogation mechanism only for Union assurance level 3, allowing providers controlled by a third country to be audited if that country meets strict criteria. Union assurance level 4 explicitly requires that the provider is not subject to third-country control, with no such derogation available.
Official sources
- EU AI Act (Regulation (EU) 2024/1689)
- GDPR (Regulation (EU) 2016/679)
- Cybersecurity Act (Regulation (EU) 2019/881)
- Data Act (Regulation (EU) 2023/2854)
Related
- Which CADA obligations stack on top of AI Act obligations?
- Which CADA obligations stack with NIS2 obligations?
- CADA vs Existing EU Cloud Rules: The Missing Sovereignty Layer
- CADA vs GDPR: How Processor Due Diligence Changes Under the New Sovereignty Framework
- CADA for SaaS Providers: How NIS2, Data Act and Sovereignty Tiers Stack
This is general information about a draft EU regulation, not legal advice.