Summary Under the proposed Cloud and AI Development Act (CADA), keeping data in the EU is not, on its own, enough for sovereignty, because jurisdiction follows the service provider, not the physical location of the data. The higher Union assurance levels would require customer data to stay within the Union and add controls on third-country influence, personnel citizenship, supply-chain transparency, and the absence of third-country control. A service hosted in the EU but controlled by a foreign entity can still be reached by foreign laws such as the US CLOUD Act, which compels production of data regardless of where it is stored.
Detail
The CADA proposal seeks to reduce the EU's dependence on a limited number of non-European cloud providers. A central pillar is a harmonised "Union cloud computing sovereignty framework" of four assurance levels (Article 16). A common misconception among legal and technical teams is that ensuring data resides physically in the EU satisfies these requirements. As proposed, CADA rejects that view: physical location does not equate to legal or operational control.
Jurisdiction follows the provider, not the data
The core problem is extraterritoriality. The Explanatory Memorandum states that large market incumbents are subject to third-country jurisdictions where laws with extraterritorial effect apply, "including laws mandating data access and transfer that may conflict with EU fundamental rights and data protection frameworks."
The US CLOUD Act illustrates this. Under 18 U.S.C. Β§ 2713, a provider of electronic communication service or remote computing service must comply with obligations to preserve, back up, or disclose the contents of communications and records pertaining to a customer "within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States." So if an EU public authority contracts a provider incorporated in or controlled by a US entity, that provider may be compelled by US courts to produce data stored in Frankfurt, Berlin or Paris. EU residency provides no shield. CADA's framework is designed to look past storage location to the provider's legal and operational independence.
The limits of "tailored" offerings
Recital 48 of the proposal addresses current market responses directly. It states that providers "have launched tailored versions of their service offerings in response to the Union's growing concerns over sovereignty," but that "those versions do not address the core sovereignty issues allowing for the extraterritorial reach of third-country laws and the possible degradation or disruption of the service." As proposed, such offerings do not ensure autonomy or control over data, assets and digital infrastructure; the framework instead requires a holistic assessment of the provider's independence.
CADA's multi-layered assurance levels
Article 16 establishes four Union assurance levels, with criteria in Annex II. Requirements escalate sharply, showing residency is the floor, not the ceiling.
- Union assurance level 1 (Annex II, Section 1) is the baseline. It requires the provider to be established in the Union; that infrastructure and assets are in the Union unless the public sector body requires otherwise (point 1(b)); and that customer data, including metadata and telemetry, remain exclusively within the Union unless the body explicitly requires otherwise (point 1(c)). It permits outsourcing technical and operational support outside the Union only where measures ensure traceability, security and governance and do not compromise operational autonomy (point 1(d)).
- Union assurance levels 2, 3 and 4 add controls well beyond residency:
- Personnel and subcontractors: At level 2, the audited provider and subcontractors must be established in the Union, with infrastructure, assets and personnel located in the Union (Annex II, Section 2). At levels 3 and 4, personnel involved in the service must be Union citizens (Annex II, Sections 3(d) and 4(d)).
- Third-country control: At level 3, the provider and subcontractors must not be subject to the control of a third country, with a narrow derogation for "associated third countries" recognised under Article 18 (Annex II, Section 3(g)). Level 4 prohibits any third-country control (Annex II, Section 4(g)).
- Data usage: Data generated by using the service must not be used to train or fine-tune any AI system operated by a third country, nor transferred outside the Union (Annex II, Sections 3(f) and 4(f)).
- Supply-chain transparency: Providers must demonstrate software supply-chain measures, including a complete and up-to-date Software Bill of Materials (SBOM) and controls to block remote features that could tamper with or disrupt the service (Annex II, Sections 2, 3 and 4).
By requiring Union citizenship for personnel, prohibiting third-country control, and mandating supply-chain audits, the framework would insulate the entity providing the service from foreign compulsion β fundamentally different from merely hosting data in an EU data centre.
Risk assessments and public order
Under Article 29, Member States and Union entities would conduct risk assessments to determine which public-sector activities contribute to the preservation of public order, considering the sensitivity, criticality and magnitude of data processed, the risk of unlawful access by a third country, and the risk of service disruption. Where an activity has public-order relevance, the contracting authority must procure services recognised at levels 2, 3 or 4 (Article 30(3)) β forcing buyers to look past residency to structural sovereignty.
What this means for you
For in-house counsel and compliance officers, the residency/sovereignty distinction carries direct procurement consequences.
Procurement strategy. "Data hosted in the EU" can no longer serve as a sovereignty checkbox. For activities with public-order relevance under your Article 29 assessment requiring level 2, 3 or 4, you would verify that the provider is not subject to third-country control, that personnel are Union citizens, and that the supply chain is transparent and audited.
Vendor due diligence. Examine providers' ownership structures. Annex II's criteria require auditors to analyse control; an EU subsidiary of a foreign-controlled group may qualify, if at all, only for level 3 under the Article 18 derogation, and not for level 4.
Contractual safeguards. For level 1, ensure robust clauses on the traceability and security of any outsourced support. For higher levels, contracts should prohibit using customer data for third-country AI training and address remote-feature controls.
Transition planning. Where a risk assessment requires migration to another service, Article 29(6) provides a reasonable transition period not exceeding 12 months. Start assessing current vendors now.
Common misconceptions
"If the data stays in the EU, it's sovereign." Incorrect. The US CLOUD Act and similar laws compel disclosure based on corporate jurisdiction, not data location. CADA addresses this by requiring structural independence from third-country control, not just geographic containment.
"GDPR adequacy decisions ensure sovereignty." Adequacy concerns the level of data protection, not operational autonomy or resilience against coercion. The proposal treats adequacy as one input β for example, an adequacy decision is a precondition for recognising an associated third country under Article 18 β but the Explanatory Memorandum is clear that mechanisms addressing transfers "do not remove sovereignty concerns about dependence on third-country providers." CADA goes further by addressing operational continuity and supply-chain security.
"Open-source software solves sovereignty." Open-source code still needs a provider for hosting, maintenance and support; if that provider is under third-country control, the risks remain. Even where open-source is used, providers must implement controls to block remote features that could tamper with or disrupt the service (Annex II, Sections 2, 3 and 4).
Official sources
Related
- Data residency vs data sovereignty: the difference under CADA
- CADA Sovereignty: Why Assessment is Per Service, Not Per Provider
- Why is sovereignty a competitiveness issue, not just a security one? | CADA
- Why the EU-US Data Privacy Framework doesn't solve CADA sovereignty
- Cloud vs AI Sovereignty: How CADA Distinguishes Control Over Data, Compute and Models
This is general information about a draft EU regulation, not legal advice.