Summary No. Complying with the AI Act, GDPR, NIS2, DORA, or the Data Act does not automatically satisfy the Cloud and AI Development Act (CADA). As proposed in COM(2026) 502 final, CADA establishes a distinct "Union cloud computing sovereignty framework" with four specific assurance levels that are legally separate from existing cybersecurity or data protection regimes. Even if a cloud service is fully compliant with all other EU digital laws, it must still undergo a specific conformity self-assessment or independent third-party audit to obtain formal recognition by a national competent authority. Without this specific CADA recognition, a provider cannot legally supply cloud services to public sector bodies for activities deemed to preserve public order.

Detail

The proposed Cloud and AI Development Act (CADA) addresses a specific policy gap identified by the European Commission: while existing EU legislation regulates how data is processed or how systems are secured, none of them regulate the sovereignty of the cloud infrastructure itself. The explanatory memorandum explicitly states that the AI Act "does not cover aspects of sovereignty," and similarly, the Data Act, GDPR, and NIS2 do not establish a harmonised framework for mitigating risks related to third-country control, extraterritorial access, or operational autonomy.

Consequently, CADA creates a parallel, mandatory compliance track that cannot be substituted by "stacking" other certifications.

The Unique Nature of CADA's Sovereignty Framework

CADA introduces a framework of four Union assurance levels (Levels 1 to 4), defined in Article 16 and detailed in Annex II. These levels are cumulative and address criteria that are entirely absent from other EU digital laws:

  • Operational Autonomy & Third-Country Control: Unlike the GDPR (which focuses on data subject rights) or NIS2 (which focuses on technical risk management), CADA explicitly prohibits or strictly limits control by third countries or legal entities established outside the Union. Annex II, Section 3.1(g) and 4.1(g) require that providers at Levels 3 and 4 are not subject to third-country control, unless a specific derogation under Article 18 is granted.
  • Personnel & Citizenship Requirements: CADA introduces personnel criteria that are unique to the sovereignty framework. For Union assurance levels 3 and 4, Annex II mandates that personnel involved in the provision of the service must be Union citizens. Furthermore, for Level 2, personnel requirements are conditional: they apply only "if the public sector body determines that imposing additional personnel screening and Union citizenship requirements are necessary" (Annex II, 2.1(d)). No other EU regulation imposes citizenship requirements on cloud service personnel.
  • Data Localisation & AI Training: CADA imposes strict data residency rules. Annex II, 2.1(f) and 3.1(f) prohibit using data generated by the service to train or fine-tune any AI system operated by a third country or a legal entity established in a third country. This is a specific sovereignty constraint not found in the AI Act (which regulates the AI system's output) or the Data Act (which regulates data portability).
  • Software Supply Chain Transparency: While NIS2 addresses supply chain security, CADA requires a specific Software Bill of Materials (SBOM) and documented controls to block remote tampering features, particularly for services involving third-country software components (Annex II, 2.1(i) and 3.1(i)).

The Mandatory Recognition Process

Compliance with CADA is not a matter of self-declaration (except for Level 1 under specific conditions) or holding a separate certification. It requires a formal recognition procedure established in Article 17.

  1. Application for Recognition: A cloud computing service provider must submit an application to the national competent authority of establishment.
  2. Evidence Submission:
    • Level 1: Requires a conformity self-assessment and an EU statement of conformity. Notably, for SMEs, this statement is "directly and automatically recognised in all Member States without the need for prior recognition by the evaluating national competent authority" (Article 17(3)). For non-SMEs, formal recognition by the authority is still required.
    • Levels 2, 3, and 4: Require an independent third-party audit. The provider must submit an audit report and a "positive" audit opinion from an auditing organisation that meets strict independence criteria (e.g., no non-audit services in the preceding 12 months) (Article 20).
  3. Competent Authority Decision: The national competent authority assesses the evidence. If satisfied, it adopts a recognition decision. This decision is then notified to other Member States for a review period. Only upon successful completion of this process is the service "recognised throughout the Union" (Article 17(7)).
  4. Central Repository: Recognised services are registered in a central repository maintained by the Commission (Article 22).

Without this specific recognition recorded in the repository, a provider cannot claim to offer a "Union assurance level" service, regardless of their status under GDPR, NIS2, or the AI Act.

The Public Sector Procurement Barrier

The practical consequence of this separation is found in Article 30. Public procurement under CADA is strictly tied to the assurance level determined by a risk assessment under Article 29.

  • Baseline Requirement: All public sector bodies must procure at least Union assurance level 1 services (Article 30(2)).
  • Public Order Requirement: For activities identified as contributing to the preservation of public order (e.g., national security, law enforcement, defence), contracting authorities must only procure services recognised at Union assurance levels 2, 3, or 4 (Article 30(3)).

This creates a hard legal barrier: a cloud provider could be fully GDPR-compliant, hold a NIS2 certification, and host AI Act-compliant models, yet be legally barred from selling to a Ministry of Justice or a police force if they have not obtained the specific CADA recognition for Level 2, 3, or 4. The risk assessment under Article 29 is the trigger; the recognition under Article 17 is the prerequisite.

What this means for you

For legal counsel, compliance officers, and cloud service providers, the implication is clear: CADA is a new, standalone compliance obligation that cannot be satisfied by existing certifications.

  1. Conduct a Gap Analysis Against Annex II: Do not rely on your current ISO 27001, NIS2, or GDPR compliance reports. You must map your service architecture against the specific cumulative criteria in Annex II. Key gaps often include:
    • Personnel: Can you guarantee Union citizenship for staff (Levels 3/4) or prove conditional compliance (Level 2)?
    • Control Structure: Do you have a third-country parent or shareholder that exercises control? If so, you may be ineligible for Levels 3 and 4 unless a derogation under Article 18 is secured.
    • Data Flows: Are you using customer data to train third-country AI models? This is strictly prohibited for Levels 2–4.
  2. Initiate the Recognition Process Early: The recognition process under Article 17 is not instantaneous. For Levels 2–4, you must engage an independent auditing organisation that meets the strict independence criteria in Article 20(4). The audit report and "positive" opinion must be submitted to the national competent authority, which then conducts a 60-day review period.
  3. Prepare for Public Sector Scrutiny: If you target the public sector, your marketing and tender responses must explicitly state your Union assurance level and reference your recognition decision. A generic claim of "EU-compliant" or "GDPR-compliant" will be insufficient for public order-related procurements.
  4. Monitor Delegated Acts: The Commission is empowered to adopt delegated acts to amend Annex II (criteria) and Annex III (audit evidence) (Article 16(2)). Stay alert to updates, as the specific evidence required for audits may evolve.

Common misconceptions

Misconception 1: "If we are GDPR-compliant, our data sovereignty is handled." Reality: The GDPR allows data transfers outside the EU under mechanisms like Standard Contractual Clauses (SCCs). CADA's higher assurance levels (2, 3, and 4) explicitly prohibit data transfers outside the Union unless the public sector body explicitly requires otherwise (Annex II, 2.1(c), 3.1(c)). GDPR compliance does not satisfy CADA's strict data localisation requirements.

Misconception 2: "NIS2 certification is enough for cybersecurity sovereignty." Reality: NIS2 focuses on technical cybersecurity risk management and incident reporting. CADA's sovereignty framework includes cybersecurity (requiring EUCS certification at Levels 2–4) but goes much further. It demands freedom from third-country political control, specific personnel citizenship, and supply chain transparency. A service can be NIS2-compliant but still be disqualified from CADA Levels 3 and 4 due to third-country control.

Misconception 3: "We don't need to do anything new if we already have AI Act compliance." Reality: The AI Act regulates the AI system (the software/model). CADA regulates the cloud infrastructure hosting it. You can host an AI Act-compliant model on a non-sovereign cloud. However, if you wish to sell that cloud service to the EU public sector for critical functions, you must separately obtain CADA recognition. The two acts regulate different layers of the stack.

Misconception 4: "Self-declaration is sufficient for all levels." Reality: Only Level 1 allows for a conformity self-assessment (and even then, only SMEs get automatic recognition). Levels 2, 3, and 4 strictly require independent third-party audits and formal recognition by a national competent authority. You cannot self-declare compliance for higher tiers.

Official sources

Related

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