European companies need cloud and AI capacity, and they increasingly have to explain where their data goes and who controls the systems that process it. Customers ask in security questionnaires, auditors ask during reviews, and public-sector tenders now score the answers. Three terms tend to get mixed up in these conversations:
- Data residency: where data is physically stored or processed.
- Data sovereignty: which legal, operational and technical controls govern that data, and who can exercise them.
- GDPR compliance: whether personal data is processed lawfully and protected appropriately.
Short answer: Data sovereignty in Europe means keeping appropriate control over your data, the infrastructure that processes it, who can access it and which laws apply to it. Hosting data in an EU data center helps meet data residency requirements. On its own, it does not guarantee sovereignty or GDPR compliance.
European Data Sovereignty in 2026: What Is Changing?
Digital sovereignty has moved from a policy slogan to a procurement criterion. In 2026, three developments matter for anyone choosing cloud infrastructure in Europe.
The Commission's Cloud Sovereignty Framework
The European Commission's Cloud Sovereignty Framework assesses cloud services against eight objectives:
- strategic;
- legal and jurisdictional;
- data and AI;
- operational;
- supply chain;
- technology;
- security and compliance;
- environmental sustainability.
Each objective is rated on a scale of Sovereignty Effectiveness Assurance Levels (SEAL). The scale runs from SEAL-0, meaning no sovereignty, to SEAL-4, which requires a full EU supply chain from chips to software.
The Commission used the framework in a sovereign cloud tender worth up to €180 million over six years, awarded to four European providers in April 2026. It also noted that non-European technologies can meet the minimum sovereignty level when they are operated within a strict framework. Any organization can use the framework in its own procurement.
The proposed Cloud and AI Development Act
On 3 June 2026, the Commission proposed the Cloud and AI Development Act (CADA). It would introduce four Union assurance levels for cloud services used by the public sector. Level 1 is a baseline; level 4 rules out third-country interference.
Under the proposal:
- providers seeking levels 2 to 4 would need a third-party audit;
- public bodies would run risk assessments every two years to decide which level each activity needs;
- the Commission could later extend these risk assessments to private companies in sectors regulated under NIS2, such as banking and energy.
CADA is still a proposal going through the legislative process. It is not yet binding law.
The Data Act already applies
The Data Act has applied since 12 September 2025, and it affects cloud providers directly:
- Providers must state which jurisdiction their infrastructure is subject to.
- They must describe the measures they take to prevent unlawful international governmental access to non-personal data.
- They must support customers who want to switch provider. From 12 January 2027, they can no longer charge for switching, including data egress fees.
Even if you never sell to the public sector, these criteria are shaping what enterprise buyers and auditors ask about your infrastructure. Sovereign cloud in 2026 is becoming something you need to evidence, not just claim.
Data Residency vs. Data Sovereignty vs. GDPR
These three requirements overlap, but none of them substitutes for the others.
| Requirement | What it addresses | What to verify |
|---|---|---|
| Data residency | Where data is stored or processed | Primary data, backups, logs, disaster recovery copies |
| Data sovereignty | Control over data and the systems that handle it | Jurisdiction, ownership, administrative access, operational control |
| GDPR | Lawful and secure processing of personal data | Legal basis, processor terms, security, data subject rights, international transfers |
EU data residency is often assumed to be a GDPR requirement, but GDPR does not generally require personal data to stay in the EU. Transfers outside the European Economic Area are allowed when the conditions in Chapter V are met, for example through an adequacy decision or standard contractual clauses.
The EU-US Data Privacy Framework, which covers transfers to certified US companies, was upheld by the EU General Court in September 2025. An appeal is pending before the Court of Justice, so organizations that rely on the framework should keep a fallback option ready.
Residency also does not settle who can compel access to data. A provider subject to US jurisdiction can be required under the US CLOUD Act to disclose data it controls, even when that data is stored in Europe. Article 48 of GDPR limits when such foreign orders can justify a transfer, but the potential conflict is a risk to assess, not a solved problem.
Where to Run AI Workloads and Store AI Data in Europe
AI makes the data map more complex. Sensitive information can sit in several layers at once:
- prompts and model outputs;
- documents and vector embeddings in retrieval-augmented generation (RAG) pipelines;
- fine-tuning datasets and model weights;
- inference logs, monitoring data and telemetry;
- backups and disaster recovery copies;
- support tickets and human review queues.
Each layer can live in a different place, so each path has to be assessed separately. For example, a model can run on EU infrastructure while:
- a third-party API logs the prompts;
- telemetry flows to a monitoring service abroad;
- support engineers access the environment from another country.
| Deployment option | Potential advantages | Questions to assess |
|---|---|---|
| EU-based public cloud | Managed services and flexible capacity | Who owns the provider, which laws apply to it, and which services depend on infrastructure outside the EU? |
| Sovereign cloud offering | Additional legal and operational controls | Which sovereignty criteria are actually met, and is there independent evidence such as an audit or assurance level? |
| Private cloud or dedicated infrastructure | Greater control over configuration, isolation and access | Who operates, patches and monitors it, and who responds to incidents? |
| Self-hosted AI inference | Prompts, outputs and model weights stay in your environment | Is there enough GPU capacity, and who maintains models, telemetry and support access? |
| Hybrid or multi-cloud | Each workload placed according to its risk and performance needs | How are cross-border flows, duplicated data and consistent governance managed? |
If you use external model APIs, check four things:
- the processing region;
- the retention period;
- whether your data is used for training;
- how long data is kept for abuse monitoring.
An AI router or LLM gateway can enforce these choices centrally, for example by routing sensitive prompts only to models hosted in the EU. For full control over the data flow, self-hosted inference with vLLM on GPU servers keeps prompts and outputs inside your own environment.
No single option is best for every workload. The right choice depends on:
- data sensitivity;
- the regulations that apply to you;
- your model architecture;
- latency and GPU requirements;
- your threat model.
For broader provider selection, see our overview of IaaS providers beyond AWS and Azure.
GDPR Cloud Compliance for AI: Mapping Requirements to Controls
Sovereignty requirements only become useful when they translate into controls you can configure and verify. For the data protection basics, see our guide to GDPR compliance in the cloud.
| Requirement | Infrastructure and operational controls |
|---|---|
| Control over data location | Documented regions for compute, storage, backups and disaster recovery |
| Restricted access | Least-privilege identity and access management, privileged-access controls and regular access reviews, in line with Zero Trust principles |
| Confidential AI inputs | Encryption, private networking, secrets management, retention limits for prompts and outputs, and confidential computing for data in use |
| Traceability | Logs of administrative actions, application activity and, where appropriate, inference requests |
| Operational independence | Documented support model, escalation paths, recovery procedures and exit options |
| Supply-chain visibility | Inventory of providers, subprocessors and dependencies, backed by contractual commitments |
| Resilience | Backups, tested recovery plans, and capacity and availability monitoring |
Responsibilities are split between provider and customer:
- The cloud provider controls the physical infrastructure, the virtualization layer and its own staff's access.
- The customer controls identity configuration, encryption choices, data placement and what its applications send to third parties.
Infrastructure controls support compliance, but they do not establish it automatically.
Data Sovereignty Checklist for European Businesses
Use this checklist when assessing a cloud provider or planning an AI deployment:
- Classify workloads by the sensitivity of the data they process.
- Map where data, backups, prompts, outputs, embeddings, logs and telemetry are stored or sent.
- Identify the provider's corporate jurisdiction, its parent company and any laws that could compel access.
- Find out who can access the environment for support or administration, and from which countries.
- Review data processing agreements, subprocessor lists and international transfer mechanisms.
- Confirm encryption, key management, identity management, privileged access and audit logging.
- Define retention, deletion, incident response and recovery procedures.
- Ask for evidence behind any "sovereign" claim: contracts, audit reports, certifications or an assurance level.
- Check portability, exit procedures and dependence on proprietary services. Our guide to cloud migration tools can help you plan an exit route.
- Document your decisions and reassess them when workloads or providers change.
Choose Cloud Infrastructure Based on Control, Not Geography Alone
An EU data center location is one factor in a sovereignty assessment, not the final answer. Evaluate:
- the full data lifecycle;
- the legal arrangements that apply;
- who has operational access;
- how your AI architecture moves data.
Then tie each decision to a requirement you can verify, rather than to a provider's "sovereign" label.
Cloud4U offers cloud servers and private cloud environments in data centers in Frankfurt and the Netherlands. Related services include GPU servers for machine learning, virtual machine encryption, cloud backup and disaster recovery. These services can support data location, access control and resilience requirements. We encourage you to put the checklist above to every provider you consider, including us.
