Summary For a CTO mapping EU compliance, the proposed Cloud and AI Development Act (CADA) introduces a mandatory sovereignty framework that sits on top of existing technical and data protection laws. You must now integrate CADA's four-tier "Union assurance" levels into your procurement strategy, where Article 29 risk assessments dictate the minimum sovereignty tier required for public sector contracts. Crucially, CADA compliance is not optional for EU-bound cloud services; it requires formal recognition under Article 17 via self-assessment (Level 1) or independent audit (Levels 2–4), creating a new, distinct deliverable alongside your AI Act, GDPR, and NIS2 obligations.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, fundamentally changes how CTOs and architects map their compliance obligations for cloud and AI services in the EU. While existing regulations like the GDPR, NIS2, and the AI Act focus on data privacy, cybersecurity resilience, and algorithmic safety respectively, CADA introduces a sovereignty and operational autonomy layer. This layer is designed to mitigate risks associated with dependence on non-EU providers, specifically addressing the threat of extraterritorial data access and service disruption.

For a CTO, mapping CADA means understanding how it stacks with other EU laws and then implementing the specific sovereignty mechanisms CADA mandates.

1. The Compliance Stack: Where CADA Fits

To accurately map your obligations, you must first distinguish CADA from adjacent regulations. CADA does not replace them; it complements them by addressing gaps they leave open.

  • GDPR (General Data Protection Regulation): Focuses on the protection of personal data and fundamental rights. It restricts transfers to third countries without adequacy decisions or safeguards. However, as CADA's explanatory memorandum notes, GDPR compliance does not remove sovereignty concerns regarding operational autonomy or the extraterritorial reach of third-country laws (such as the US CLOUD Act). CADA adds a layer of assurance that data and infrastructure remain under EU jurisdiction and control, regardless of data type.
  • NIS2 (Network and Information Security Directive): Imposes strict cybersecurity risk management obligations on essential and important entities. It focuses on technical security, incident reporting, and supply chain security. CADA builds on this by adding sovereignty criteria. A service can be NIS2-compliant (secure) but fail CADA's sovereignty tests if it is controlled by a third-country entity with the ability to disrupt service or access data.
  • AI Act: Regulates AI systems based on risk (prohibited, high-risk, limited risk, minimal risk). It focuses on transparency, data governance, and human oversight. CADA complements the AI Act by ensuring the infrastructure hosting these AI systems is sovereign. For example, a high-risk AI system under the AI Act might need to run on a cloud service that meets CADA's Union Assurance Level 2 or 3 to protect the underlying data and infrastructure from third-country interference.
  • DORA (Digital Operational Resilience Act): Applies to the financial sector, focusing on ICT risk management and third-party risk. Like NIS2, it is sector-specific and technical. CADA provides a broader, cross-sectoral sovereignty framework that financial entities must also consider when evaluating cloud providers, especially for critical operations.
  • Data Act: Focuses on data access, sharing, and switching, reducing vendor lock-in. CADA leverages the Data Act's switching provisions to help users move to sovereign providers but goes further by defining which providers are considered trustworthy from a sovereignty standpoint.

2. The Core Mechanism: Union Assurance Levels

CADA's central innovation is the Union cloud computing sovereignty framework, established under Article 16. This framework defines four "Union assurance levels" (Levels 1 to 4), each with cumulative criteria set out in Annex II of the proposal.

  • Level 1 (Baseline): Requires the provider to be established in the Union, with infrastructure and data remaining exclusively within the Union (unless the public sector body explicitly requires otherwise). It includes state-of-the-art cybersecurity standards and transparency around subcontractors.
  • Level 2 (Substantial Cybersecurity): Adds stricter controls. Personnel involved in service provision must be available to meet Union citizenship requirements if the public sector body requires it. Data generated by the service cannot be used to train third-country AI models. It requires a European cybersecurity certificate of at least assurance level 'substantial' (or equivalent national scheme) and strict software supply chain controls, including Software Bills of Materials (SBOMs).
  • Level 3 (High Sovereignty): Further restricts third-country control. Personnel must be Union citizens (mandatory, not conditional). The provider and subcontractors must not be subject to the control of a third country, unless the Commission has adopted a specific implementing act for an "associated third country" under Article 18. This level allows for the hosting of certain classified information.
  • Level 4 (Maximum Sovereignty): The highest tier. Similar to Level 3 but with even stricter cybersecurity certification requirements (assurance level 'high') and stricter controls over software components to ensure no third-country entity holds effective control over design or maintenance.

Critical Correction on Cybersecurity Levels: A common error is assuming Level 3 requires "high" cybersecurity certification. Under Annex II, Level 2 and Level 3 both require a certificate of at least 'substantial' assurance. Only Level 4 requires the 'high' assurance level.

3. The Driver: Article 29 Risk Assessments

The choice of assurance level is not arbitrary; it is driven by risk. Article 29 obliges Member States and Union entities to conduct risk assessments to determine which public sector activities contribute to the preservation of public order.

  • The Assessment: These assessments must identify activities in sectors like national security, defense, justice, and critical infrastructure. They must evaluate the sensitivity, criticality, and magnitude of data processed.
  • The Outcome: Based on this assessment, the contracting authority determines the minimum Union assurance level required. If an activity is deemed to contribute to public order, the authority must procure cloud services recognized as offering Union Assurance Levels 2, 3, or 4. For non-public-order activities, the minimum requirement is Union Assurance Level 1.
  • Procurement Impact: This directly dictates your procurement strategy. You cannot simply buy the cheapest or most feature-rich cloud service; you must buy one that matches the sovereignty tier dictated by the risk assessment.

4. The Deliverable: Recognition under Article 17

For cloud providers and the CTOs evaluating them, the key deliverable is recognition. A cloud service is not sovereign by default; it must be formally recognized.

  • Application: Providers submit an application to the national competent authority of their establishment (Article 17).
  • Evidence:
    • For Level 1, providers perform a conformity self-assessment and issue an "EU statement of conformity" (Article 19). For SMEs, this is automatically recognized across the Union.
    • For Levels 2, 3, and 4, providers must undergo independent third-party audits (Article 20). Auditors must be independent, have no conflicts of interest, and provide a "positive" audit opinion.
  • Central Repository: Once recognized, the service is listed in a central repository maintained by the Commission (Article 22). This repository becomes the go-to source for procurement officers to verify a provider's sovereignty status.
  • Ongoing Compliance: Providers must report material changes that could affect their assurance level (Article 23), and audits must be reviewed annually.

What this means for you

For CTOs and architects, CADA transforms compliance from a technical checklist into a strategic procurement and architecture decision.

  1. Audit Your Current Stack: Identify all cloud and AI services currently in use. Check if they are recognized in the CADA central repository (once established) or if they can meet the criteria for Union Assurance Level 1. If you serve public sector clients, you likely need Level 2 or higher.
  2. Integrate Sovereignty into Vendor Due Diligence: Update your RFPs and vendor assessments to include CADA criteria. Ask providers for their EU statement of conformity (Level 1) or audit reports (Levels 2–4). Verify their supply chain transparency, especially regarding software components and subcontractors.
  3. Map Data Flows and Personnel: Ensure that data processing, storage, and backup remain within the EU. Verify that personnel with access to your data and systems are located in the EU and, for higher levels, are Union citizens.
  4. Prepare for Risk Assessments: Work with legal and security teams to understand how your use cases might be classified under Article 29. If your work involves critical infrastructure or sensitive public data, plan for the higher costs and stricter controls associated with Levels 2–4.
  5. Plan for Migration: If your current provider cannot meet the required assurance level, start planning a migration. CADA allows for a reasonable transition period, but public sector bodies must migrate within a maximum of 12 months if a risk assessment requires it (Article 29(6)).

Common misconceptions

  • "CADA replaces the GDPR." No. CADA complements the GDPR. You must still comply with GDPR for personal data. CADA adds sovereignty requirements that apply to all data, personal or not, and focuses on operational control and infrastructure location.
  • "NIS2 compliance is enough for CADA." No. NIS2 focuses on cybersecurity resilience. CADA focuses on sovereignty and autonomy. A provider can be NIS2-compliant but fail CADA's sovereignty tests if it is subject to third-country control or allows data to leave the EU.
  • "CADA only applies to large hyperscalers." No. CADA applies to all cloud computing service providers seeking to serve Union entities and public sector bodies. SMEs can achieve Level 1 recognition through self-assessment, and their statements of conformity are automatically recognized across the EU (Article 17(3)).
  • "Sovereignty means data localization only." No. While data localization is a key component (data must remain in the EU), sovereignty also includes control over personnel, software supply chains, and the absence of third-country legal reach (e.g., laws that compel data disclosure or service disruption).
  • "Level 3 requires 'high' cybersecurity certification." No. Under Annex II, Levels 2 and 3 require a 'substantial' cybersecurity certificate. Only Level 4 requires the 'high' assurance level.

Official sources

Related

This is general information about a draft EU regulation, not legal advice.