Data Sovereignty Is Not Data Residency

Your IT team just sent a reassuring email: “We’ve migrated everything to the Frankfurt region. All data stays in the EU now.” The compliance officer reads it, nods, and then asks one question that changes the entire conversation: “But who owns the company that runs the data center?”

Silence.

That question — not “where is the server?” but “who can legally demand what’s on it?” — is the line between data residency and data sovereignty. Most organizations don’t know the difference. They should, because getting it wrong can mean your “EU-protected” data is one court order away from landing on a desk in Washington.

Two terms that sound alike but aren’t

Data residency is geography. It’s about where your data physically lives — which country, which data center, which rack. When your cloud provider says “EU region,” they’re making a residency promise. Your bits are stored on hardware inside EU borders.

Data sovereignty is jurisdiction. It’s about which country’s laws govern access to your data — and more importantly, which governments can legally compel someone to hand it over. Sovereignty isn’t about the server’s address. It’s about the server operator’s legal obligations.

Here’s the simplest way to think about it: residency answers “where does my data sleep at night?” Sovereignty answers “who has a key to the building?”

You can have residency without sovereignty. A US company can store your data in Frankfurt and still be legally required to hand it over to US authorities under the CLOUD Act. The data is EU-resident. It’s not EU-sovereign.

You can also have sovereignty without residency — though that’s rarer and less useful in practice. A European company could theoretically store data on US hardware and still argue that EU law governs access. But nobody does this, because it creates more problems than it solves.

What you actually want is both: data that lives in the EU and is governed exclusively by EU law, with no legal pathway for a foreign government to compel access.

Residency answers where your data sleeps at night. Sovereignty answers who has a key to the building.

Why the CLOUD Act makes this distinction critical

The Clarifying Lawful Overseas Use of Data Act is a US law that says: if a company is subject to US jurisdiction, it must hand over data when served with a valid US warrant — regardless of where that data is physically stored. Frankfurt, Dublin, Singapore — it doesn’t matter. The corporate chain is what counts.

We covered the CLOUD Act in detail in The CLOUD Act and Your AI Research. The short version: every major US cloud and AI provider — Amazon, Microsoft, Google, OpenAI, Anthropic — falls under it. If they store your data, a US court can reach it.

This is why “EU region” isn’t a sovereignty answer. It’s a residency answer to a sovereignty question.

The subsidiary trap

Cloud providers know this distinction makes customers nervous. So they’ve created a clever workaround: European subsidiaries. On paper, it looks like problem solved. In practice, it’s a trap.

AWS European Sovereign Cloud launched in January 2026, operated by AWS European Sovereign Cloud GmbH — a German subsidiary. Sounds sovereign, right? But that GmbH is 100% owned by Amazon.com, Inc., a US company. A CLOUD Act warrant served to Amazon in Seattle can compel data production from the German subsidiary. As Techzine’s analysis noted: “AWS and the AWS European Sovereign Cloud are part of the American company Amazon. That company therefore ultimately has to listen to what the US government expects, desires, and demands.”

Microsoft Azure’s EU Data Boundary is a data residency commitment. It controls where data is stored, not who can legally demand it. Microsoft’s own director of public and legal affairs in France acknowledged under oath at a French Senate hearing that the company cannot guarantee EU data is safe from US access requests.

Google doesn’t even offer a standalone sovereign cloud. It partners with T-Systems in Germany and S3NS — the Thales–Google joint venture — in France to run sovereign controls, but the underlying platform still flows through Google’s US-incorporated corporate structure.

The pattern is the same every time: operational separation (EU staff, EU data centers, EU subsidiary) doesn’t sever legal jurisdiction. As long as the ultimate parent is US-incorporated, the CLOUD Act has a path to your data.

Operational separation — EU staff, EU data centers, EU subsidiary — does not sever legal jurisdiction. The corporate chain is what counts.

The one question that cuts through the noise

You don’t need a law degree to figure out whether your data is sovereign. You need one question:

“If a US court issues a CLOUD Act warrant for our data, can this provider legally refuse to comply?”

If the answer is no — and for any company with a US parent, it’s always no — then your data isn’t sovereign. It’s resident. There’s a big difference.

This test works for every vendor, every service, every region. You don’t need to read marketing whitepapers about “operational sovereignty” or “data boundary commitments.” You just need to follow the corporate chain upward until you find the ultimate parent company and check where it’s incorporated.

Here’s a quick version you can run on your existing stack right now:

1. List every cloud service and AI tool your organization uses
2. For each one, find the ultimate parent company (not the subsidiary, not the operating entity — the top of the chain)
3. Check where that parent is incorporated
4. If it’s a US company → CLOUD Act applies → your data is resident, not sovereign

That’s it. Four steps.

What real sovereignty looks like

Genuine data sovereignty means there’s no legal pathway for a non-EU government to compel access to your data. That requires three things:

1. EU-incorporated provider — the company operating your infrastructure must be incorporated in an EU/EEA member state, with no US parent, subsidiary relationship, or controlling interest that would bring it under US jurisdiction.

2. EU data residency — data must be physically stored and processed within EU/EEA borders. This is the easy part. Most providers offer it.

3. No US-jurisdiction dependencies — the entire stack, from hardware to software to support, must operate without involving any entity subject to US legal process. This is the hard part.

European-headquartered cloud providers like Scaleway, OVHcloud, and Hetzner meet these criteria. They’re EU-incorporated with no US parent company. A US court has no CLOUD Act pathway to their customers’ data.

For AI specifically, open-source models running on EU-sovereign infrastructure offer the strongest position. The model weights are public, inference runs on EU hardware, and no US company is anywhere in the data path. Your research queries never leave European jurisdiction.

LumaVista takes this approach — running multiple open-source models on dedicated EU GPU servers. No US company in the corporate chain, no US cloud provider underneath, no API calls crossing jurisdictional boundaries.

EU regulators aren’t buying “sovereign” branding either

This isn’t just a theoretical distinction. EU data protection authorities have already taken action against the assumption that “EU region” equals “EU sovereign.”

France’s CNIL raised concerns about data transfers and recommended that schools stop deploying Microsoft Office 365 and Google Workspace — guidance the Education Ministry circulated to school administrators. The French Health Data Hub faced sustained pressure to migrate off Microsoft Azure. Denmark’s DPA ordered a municipality to stop using Google Workspace for Education entirely.

Most telling: in March 2024, the European Data Protection Supervisor found that the European Commission’s own use of Microsoft 365 infringed data protection law for EU institutions. If the EU’s own institutions can’t legally use these services, what does that tell you about your organization’s exposure?

The direction of travel is clear. Regulators are moving from “where is the data?” to “who has jurisdiction over it?” Organizations that made the same shift early will be ahead of the curve when enforcement tightens.

If the EU’s own institutions cannot legally use these services, what does that tell you about your organization’s exposure?

Your sovereignty audit checklist

Here’s how to move from “we think we’re covered” to “we know we’re sovereign”:

1. Map your data flows. Every AI tool, every cloud service, every SaaS platform that touches sensitive data. Don’t just list the vendors — map what data goes where and through which corporate entities.

2. Run the parent company test. For each vendor, trace the corporate chain to the top. Where’s the ultimate parent incorporated? If it’s the US, mark it red. If it’s the EU with no US controlling interest, mark it green.

3. Read the fine print on “sovereign” offerings. Marketing teams love the word “sovereign.” Check whether it means EU-incorporated parent (real sovereignty) or EU subsidiary of a US parent (data residency with better branding).

4. Classify your data by sensitivity. Not everything needs sovereign infrastructure. A public-facing marketing site on AWS is fine. Client transaction records processed through a US-jurisdiction AI tool? That’s a different risk profile entirely.

5. Brief your legal and compliance teams together. Lawyers understand jurisdiction. IT understands infrastructure. Few people understand both. Bridge that gap — make sure the people writing vendor contracts understand the CLOUD Act, and make sure the people choosing cloud regions understand that geography isn’t jurisdiction.

6. Evaluate EU-sovereign alternatives for your highest-risk data. Start with the workloads where exposure would hurt most: legal research, financial analysis, medical records, IP-sensitive queries. These are the ones that justify the migration effort.

7. Prepare for regulatory tightening. Most remaining EU AI Act obligations apply from August 2, 2026, with high-risk system requirements following from December 2027. Organizations using AI for high-risk applications will need to demonstrate they understand where their data goes and who can access it. “We use the EU region” won’t satisfy an auditor who knows how the CLOUD Act works.

8. Build sovereignty into procurement. Going forward, add the parent company test to your vendor evaluation process. It takes five minutes and saves months of migration later.

The distinction between residency and sovereignty isn’t academic. It’s the difference between data that’s geographically in Europe and data that’s legally in Europe. Your compliance posture depends on knowing which one you actually have.