Data Residency Isn't Sovereignty: The Distinction That Costs Companies

Here is the sentence that quietly costs companies money: "Our data stays in the EU, so we're sovereign." The first half is often true. The second half usually is not. The distinction between data residency vs data sovereignty is not academic hair-splitting. It is the difference between a checkbox your vendor sold you and a control you actually hold. I have watched capable teams spend a year and a real budget relocating workloads into an in-region datacenter, feel finished, and then learn that the guarantee they thought they bought thins out the moment a foreign government hands the provider a lawful request.

The Comforting Illusion of In-Region Storage

Choosing an in-region cloud satisfies data residency, and residency is a legitimate requirement, but on its own it does not deliver sovereignty. Residency is about geography. It tells you the postal code of the datacenter. That feels like control because we are wired to think of possession as physical, but for data the physical location is the least interesting fact about who can touch it.

The market makes the illusion easy to buy into. European cloud providers hold only about 15% of their own local market, a share that has stayed flat since 2022, while AWS, Microsoft, and Google together take roughly 70% of it, according to Synergy Research Group. The European cloud market reached about €61 billion in 2024 and grew sixfold from 2017 to 2024, with the hyperscalers capturing most of that growth per Data Center Dynamics. So when a European company "stays in region," it is overwhelmingly staying in region on infrastructure owned by an American parent. The flag on the building is local. The corporate ownership is not. As I argued when digital sovereignty stopped being a policy debate and became an infrastructure bill, the spending follows the anxiety, and the EU's Digital Decade program is pushing for more than 75% of EU enterprises to use cloud, big data, and AI by 2030 according to the European Commission. More workloads, same ownership problem.

Who Can Still Reach Your Data

Even when your data never leaves the region, the company operating that region can be legally compelled to reach into it. This is the part residency does not fix. The US CLOUD Act of 2018 lets American authorities compel a US-headquartered provider to disclose data in its custody or control regardless of where in the world that data is physically stored, per the US Department of Justice. A German datacenter run by the European subsidiary of a US corporation is still, up the ownership chain, subject to that reach.

Courts have already drawn this line in bright ink. In Schrems II (2020), the EU Court of Justice struck down the EU-US Privacy Shield precisely because US surveillance law could reach European personal data held by US-linked providers, per the Court of Justice of the European Union. The ruling made the point cleanly: the provider's corporate jurisdiction, not the location of the disk, decides which government can compel access. This is the same uncomfortable truth I dug into in the sovereignty gap, where governments discover they don't actually control their own cloud. If someone else can be ordered to open the door, it was never only your door.

Data Sovereignty as an Operational Property

Data sovereignty is a control mechanism, not a storage feature, which means you earn it through operational choices rather than a region dropdown. Ken McBride of VMware Cloud Foundation put it well in a November 2025 piece: "Data residency is a feature linked to geography; data sovereignty is a control mechanism that defines autonomy," and the real question is not where the data sits but who has ultimate control over it. VMware named the marketing pattern too: "sovereign washing," selling an in-region datacenter as jurisdictional protection when the operating entity is still a subsidiary that answers to a foreign government.

Operationally, sovereignty lives in three places. Who holds the encryption keys, because whoever holds them can read the data or be compelled to. Who controls the control plane, the administrative layer where identity, access, and provisioning actually happen, because root access beats geography every time. And which subprocessors sit underneath, because a sovereign front end resting on a non-sovereign backend is theater. The tell that the industry knows residency was never enough: the hyperscalers now sell dedicated sovereign products, like the AWS European Sovereign Cloud operated by EU-resident staff. You do not build a separate sovereign offering if the regular in-region one already delivered sovereignty.

What It Takes for AI Workloads

AI raises the stakes because it concentrates your most sensitive material into one system, so a sovereignty gap that was tolerable for cold storage becomes acute. A model does not just hold a database. It absorbs training data, ingests live prompts that often contain the exact things people would never paste into a public form, and emits outputs derived from both. If the platform running that model is subject to foreign compulsion, then your training corpus, your users' prompts, and your generated answers are all reachable through a single legal request.

The fixes are architectural, not geographic. Customer-managed encryption keys so the provider cannot decrypt without you. Confidential computing so data stays encrypted even while the model is using it in memory. Independent identity and access management that the provider cannot silently override. And a hard look at where inference actually runs, since sending a prompt to a hosted model can move sensitive data across a jurisdiction line in milliseconds. This is the same discipline I described in keeping student data where it belongs with sovereign AI for schools: the sensitive workload sets the requirement, and the architecture has to meet it rather than the region label pretending to.

A Practical Data Sovereignty Test

You can pressure-test any "sovereign" claim in about five minutes with three questions, and if the answer to any of them is "the provider," you have residency, not sovereignty. First, who holds the encryption keys? If you cannot revoke access unilaterally, you do not control the data. Second, who controls the control plane and holds root and administrative access? If a foreign-owned operator can provision, inspect, or reset without your sign-off, geography is irrelevant. Third, whose courts can compel the operating company? Follow the ownership chain all the way up, not to the datacenter, but to the parent that would receive the subpoena.

Run those three on your current setup before you run them on a vendor's pitch. Most teams find they pass the residency question and fail at least one of the sovereignty questions, which is exactly the gap that costs money later. If you want a second set of eyes on where your data and AI workloads actually sit versus where you think they sit, that is precisely what we do in a System Review Diagnostic. Better to find the gap on a whiteboard than in a legal request.

Frequently Asked Questions

What Is the Difference Between Data Residency and Data Sovereignty?

Residency is about where data is physically stored. Sovereignty is about whose laws govern it and who can ultimately compel or control access. You can satisfy residency and still lack sovereignty.

Does Data Residency Guarantee Data Sovereignty?

No. Data stored in-region on a foreign-owned provider can still be reached by that provider's home government under laws like the US CLOUD Act, so location alone does not settle the control question.

Why Does Data Sovereignty Matter for AI Workloads?

AI systems concentrate training data, prompts, and outputs in one place, so who can legally and technically access the model and its data becomes a control question that region choice alone does not answer.

Can You Have Data Sovereignty in a Public Cloud?

Yes, but only if the architecture adds customer-held encryption keys, independent identity, enforceable limits on provider access, and alignment between data location and governing law. Standard public-cloud defaults usually do not.

How Do Data Localization, Data Residency, and Data Sovereignty Differ?

Localization requires that data never leave a jurisdiction, residency specifies where it is stored, and sovereignty determines which government's law applies and what that government can demand.

References

• European Cloud Providers' Local Market Share Now Holds Steady at 15% (Synergy Research Group)
• European cloud providers hold 15% of local market share (Data Center Dynamics)
• CLOUD Act Resources (US Department of Justice)
• Judgment C-311/18, Schrems II (Court of Justice of the European Union)
• Europe's Digital Decade (European Commission)
• AWS European Sovereign Cloud (Amazon Web Services)
• The Great Cloud Charade: Why Data Residency Isn't Data Sovereignty (VMware Cloud Foundation)
• Digital Sovereignty Became an Infrastructure Bill (Automata Intelligentsia)
• The Sovereignty Gap: Why Governments Don't Actually Control Their Cloud (Automata Intelligentsia)
• Sovereign AI for Schools: Keeping Student Data Where It Belongs (Automata Intelligentsia)