Summary Under the proposed Cloud and AI Development Act (CADA), cloud sovereignty would become a structured, four-tier legal framework that shapes how CTOs and architects design, procure, and operate public-sector and critical private-sector systems. Article 16 would introduce "Union assurance levels" mandating specific technical, operational, and jurisdictional controls — from data localisation to personnel citizenship and third-country-control restrictions. For architects, this means mapping each workload to an assurance level, designing exit strategies to avoid lock-in, and aligning infrastructure choices with the levels set by national risk assessments.

Detail

The proposed CADA would shift cloud architecture from a purely technical optimisation problem to a compliance-driven sovereignty challenge. It would not ban non-EU providers outright but would create an EU-wide framework classifying cloud services into four "Union assurance levels" that determine which services public sector bodies and certain private entities can procure.

The four Union assurance levels

Article 16 would establish the framework; the criteria are in Annex II. The levels are cumulative — a higher level requires all lower-level criteria (Article 20(1)).

  • Union assurance level 1: the baseline. The provider must be established in the Union; infrastructure, assets, and customer data (including metadata and telemetry) must remain exclusively within the Union, unless the public sector body explicitly requires otherwise; the service must meet state-of-the-art cybersecurity standards; and subcontractor use must be fully transparent. If subject to third-country control, the provider must guarantee no third-country law requires reporting software vulnerabilities to foreign authorities before they are known to be exploited (Annex II, point 1.1).
  • Union assurance level 2: for more sensitive workloads. The provider and subcontractors must be established in the Union; infrastructure, assets, and personnel must be located in the Union; data generated by the service may not be used to train or fine-tune AI systems operated by third-country entities; the service must hold a European cybersecurity certificate of at least "substantial"; and providers subject to third-country control must prevent that country from restricting delivery, accessing customer data, or disrupting continuity (Annex II, point 2.1). (Union citizenship is required only where a public sector body determines additional screening is necessary — point 2.1(d).)
  • Union assurance level 3: for high-sensitivity public order activities. Personnel involved in the service must be Union citizens (with national security clearance where appropriate); subcontractors must be Union-established and located; and the provider must not be subject to third-country control unless the Commission has recognised the third country under Article 18. Support must be performed within the Union by Union residents (Annex II, point 3.1).
  • Union assurance level 4: the highest tier. Like level 3, it requires Union-citizen personnel and prohibits third-country control (with no derogation). It additionally requires a cybersecurity certificate of at least "high" and that no third country holds effective control over the design, development, maintenance, and evolution of software components (Annex II, point 4.1).

Jurisdictional and continuity risks in architecture

The primary architectural challenge would be mitigating jurisdictional risk — the risk that a provider's home country can legally compel data access or service disruption. The explanatory memorandum and Recital 50 highlight risks of unauthorised access, data manipulation, and operational discontinuity.

Architects should evaluate whether a provider's legal structure exposes EU workloads to extraterritorial laws. Under the US CLOUD Act, providers subject to US jurisdiction may be compelled to disclose data in their possession, custody, or control wherever located. CADA's framework — particularly at levels 3 and 4 — seeks to eliminate this by prohibiting third-country control or requiring specific safeguards. Continuity risk is equally important: at higher levels, providers must show they are not subject to measures that could compel them to degrade or disrupt service, so architectures should avoid single-vendor, single-jurisdiction dependencies.

Mapping workloads to assurance levels

CADA would require Member States and Union entities to conduct risk assessments (Article 29) to identify which public sector activities contribute to the preservation of public order. Contracting authorities would then procure at the appropriate level (Article 30):

  • Low sensitivity: activities not identified as contributing to public order use level 1 services (Article 30(2)).
  • Higher sensitivity: activities in sectors under Annex I or II of the NIS2 Directive, or in national security, internal/external security, defence, justice, or law enforcement, use level 2, 3, or 4 (Article 30(3)).

Private entities listed in Annex I of NIS2 that are not public sector bodies may carry out similar assessments (Article 31(1)).

Exit strategies and avoiding lock-in

Vendor lock-in is a sovereignty risk. If a provider ceases to meet requirements or geopolitical relations shift, organisations must be able to migrate without paralysis — and Article 29(6) would set a transition period not exceeding 12 months where a risk assessment requires migration. Article 29(9) would require Member States and Union entities to consider whether a multi-vendor or multi-cloud strategy is appropriate. Architects should design for sovereign exit: data portability in standard formats, multi-cloud architectures avoiding single points of failure, and contractual termination/retrieval clauses tied to a change in sovereignty status.

What this means for you

  1. Conduct a sovereignty audit. Map all cloud workloads to their sensitivity, identifying those processing personal data, critical infrastructure data, or information bearing on public order.
  2. Evaluate provider assurance levels. Check whether current providers are recognised at the required Union assurance level via the central repository (Article 22). For SMEs, note that level 1 EU statements of conformity are automatically recognised across Member States (Article 17(3)).
  3. Design for interoperability. Avoid proprietary APIs and formats that create lock-in; use open standards and ensure migratable data.
  4. Implement multi-cloud strategies. For critical workloads, consider distributing components across providers to reduce exposure to a single provider's failure or status change.
  5. Prepare for risk assessments. Engage national authorities to understand how assessments will run in your sector and align architecture with the likely required levels.
  6. Review subcontractor chains. Ensure providers have full subcontractor transparency; for levels 2–4, subcontractors must also meet location and control requirements.

Common misconceptions

  • "CADA bans all non-EU cloud providers." It would not. Non-EU providers could compete if they meet the criteria — e.g., a level 1 service requires EU establishment, data localisation, and cybersecurity. For levels 3 and 4, third-country control is heavily restricted, but level 3 remains possible where the Commission recognises the third country under Article 18.
  • "Sovereignty is only about data location." Data localisation is one component; the framework also covers personnel citizenship, third-country control, cybersecurity certification, and software supply-chain transparency. A provider can host data in the EU yet fail higher levels if controlled by a third-country entity.
  • "Only the public sector is affected." While the procurement mandate applies to public sector bodies, private entities in critical sectors may assess voluntarily (Article 31), and market demand for sovereign services would reshape provider offerings broadly.

Related

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