Summary No. Under the proposed Cloud and AI Development Act (CADA), a sovereign cloud is not simply a public cloud hosted in the EU. EU hosting is a baseline element of the lowest tier (Union assurance level 1), but it is insufficient for the higher levels required for public-order activities. As proposed, true sovereignty under CADA requires operational control, insulation from third-country legal access, and software-supply-chain transparency — well beyond data residency.
Detail
CADA would establish a tiered framework for cloud sovereignty, rejecting the idea that geographic location alone guarantees autonomy. As proposed, Article 16 creates a "Union cloud computing sovereignty framework comprising four Union assurance levels," with criteria set out in Annex II. The structure addresses the risk of dependency on non-European providers, particularly those subject to extraterritorial laws such as the US CLOUD Act, which can compel disclosure regardless of where data is physically stored.
The hierarchy of sovereignty: beyond hosting
At the foundation is Union assurance level 1. Under Annex II (Section 1), the provider must be established in the Union, with infrastructure and assets (including those of subcontractors involved in the service) located in the Union, and customer data remaining exclusively within the Union unless the public sector body explicitly requires otherwise. This aligns with the common understanding of "EU-hosted" public cloud. But CADA treats it as the entry point for public-sector procurement, not the definition of a fully sovereign service.
For activities contributing to the preservation of public order — national security, justice, law enforcement, and critical sectors under NIS2 — Member States must conduct risk assessments under Article 29, which would mandate Union assurance levels 2, 3 or 4. These higher levels impose conditions a standard EU-hosted public cloud typically cannot meet without significant restructuring.
Operational control and personnel
Union assurance level 2 (Annex II, Section 2) requires that the provider and its subcontractors involved in the service are established in the Union, and that infrastructure, assets and personnel are located in the Union. Technical and operational support must be initiated and performed exclusively within the Union. This prevents EU-hosted servers being managed remotely by staff in a third country. Union citizenship for personnel is required at level 2 only where the public sector body determines that additional screening and citizenship requirements are necessary.
Union assurance level 3 (Annex II, Section 3) raises the bar: all personnel involved in providing the service must be Union citizens (and, where handling classified information, hold the necessary national security clearance). The provider and subcontractors must not be subject to the control of a third country, with a narrow derogation only where the Commission has adopted an implementing act under Article 18 finding that the third country provides sufficient safeguards. Support must be performed exclusively within the Union by Union residents.
Union assurance level 4 (Annex II, Section 4) is the highest tier: the provider and subcontractors must not be subject to third-country control; support must be performed exclusively within the Union by Union residents and by third parties not subject to third-country control; and the provider must retain effective control over software components, ensuring no third country holds effective control over their design, development or maintenance.
Insulation from foreign law and data usage
A critical distinction between a sovereign cloud and a standard public cloud is the restriction on data usage for AI training and insulation from foreign legal compulsion. Under Annex II, for levels 2, 3 and 4, data generated by using the service must not be used to train or fine-tune any AI system operated by a third country or a legal entity established in a third country, and must not be transferred outside the Union. This addresses the data-harvesting risk associated with global providers.
Providers subject to third-country control must also guarantee (Annex II, level 1(g) and the equivalent level 2-4 criteria) that there are no existing laws in that third country requiring them to report software vulnerabilities to foreign authorities before those vulnerabilities are known to have been exploited, and must demonstrate that third-country measures cannot compel them to degrade service continuity or apply restrictive measures such as embargoes.
Software supply-chain transparency
CADA places heavy emphasis on supply-chain integrity. For levels 2, 3 and 4, providers must maintain a complete and up-to-date software bill of materials (SBOM). Where software components are owned or licensed by a third-country entity, controls must block remote features that could tamper with or disrupt the service, and a documented migration plan must exist in case a third-country vendor fails or imposes restrictions. This level of transparency is rarely standard in generic public-cloud contracts.
What this means for you
For CTOs and architects, CADA signals that "EU-hosted" would be necessary but insufficient for sensitive workloads. If your organisation operates in NIS2 Annex I or II sectors, or handles data critical to public order, you would need to look beyond the data centre's location.
- Conduct risk assessments: under Article 29, assess whether your activities contribute to public order. If they do, you may be required to procure at levels 2, 3 or 4.
- Audit your contracts: can data be used for AI training? Can support staff access your environment from outside the EU? If so, the service likely does not meet level 2+ criteria.
- Evaluate supply chains and control: is your provider subject to third-country control? If so, can it demonstrate the legal and technical separation Annex II requires?
- Plan for multi-cloud or sovereign alternatives: Article 29(9) requires you to consider whether a multi-vendor or multi-cloud strategy is appropriate.
Common misconceptions
- "GDPR compliance equals sovereignty." The GDPR protects personal-data privacy but does not address operational autonomy, supply-chain control or insulation from foreign national-security laws. CADA would target that gap.
- "Data residency is enough." Keeping data in an EU data centre does not by itself prevent a third-country-controlled provider from being subject to laws such as the CLOUD Act. CADA's higher levels require the provider and its personnel also to be insulated from third-country control.
- "Sovereign cloud means no international partnerships." Not in a blanket sense. Article 18 allows the Commission to recognise third countries as providing sufficient assurance for level 3 where they meet cumulative criteria (including a GDPR adequacy decision and procurement-market reciprocity). This is an exception, not the rule.
Official sources
Related
- Sovereign cloud vs public cloud: what's the difference under CADA?
- Hyperscaler public cloud vs CADA-recognised sovereign cloud for public buyers
- Sovereign cloud vs trusted cloud: do the terms mean the same under CADA?
- Sovereign cloud vs private cloud under CADA: which gives more control?
- CADA public-sector risk assessment vs private-sector impact assessment
This is general information about a draft EU regulation, not legal advice.