A sovereign cloud does not make your data sovereign

Why a residency commitment is not evidence of custody.

Western European technology leaders are moving workloads toward local providers at scale. Gartner surveyed 241 chief information officers and information technology leaders across the region and found that 61% expect geopolitical factors to increase their reliance on local or regional cloud providers, while 53% said geopolitics will restrict their organizations’ future use of global cloud providers.¹ Sovereign cloud capacity has moved out of policy discussion and into bank and insurer budgets.

Stanford’s Institute for Human-Centered Artificial Intelligence (HAI) examined what that money buys. Its July 2026 issue brief surveyed commercial sovereignty offerings across the technology stack, from Nvidia and Microsoft down to regional providers, and concluded that these offerings “often reconfigure, rather than eliminate, dependence” on the companies selling them.²

For regulated firms, that finding carries a narrower and more immediate consequence than the geopolitical one. A sovereign region settles where your infrastructure runs and which court holds jurisdiction over it. It cannot tell you which data crossed into that region, what permissions traveled with it, or who authorized the crossing. A supervisor asks those questions, and the answers live in records of what your firm did, which no provider’s architecture supplies.

Sovereignty offerings answer a location question

Vendors that make sovereignty claims describe where the stack runs more than what it is built from, according to Stanford HAI’s survey. As the brief puts it, “the sovereignty claim, despite the scope of what the company is marketing, appears to focus less on the origin of the components and more on where the stack is deployed and under whose legal jurisdiction it operates.”³ Sovereign Australia AI sells compute, data centers, and applications built for Australian customers, and still runs on Nvidia chips.

Independent scrutiny of this market has barely begun, and the brief says as much. Whether these offerings deliver on their promises “or whether they simply rebrand existing dependencies to meet the moment, is a question that has increasingly been raised but has not been examined systematically.”⁴ Several initiatives have drawn criticism for what the authors call “sovereignty washing.”⁵

Title: Three tiers of sovereign cloud, and what each one covers

• Sovereignty controls on hyperscaler-operated clouds: The provider keeps ownership and operation, then layers on data residency controls, confidential computing, and customer-held encryption keys. Microsoft’s Sovereign Public Cloud lets customers hold keys outside Microsoft’s cloud and revoke access at any time.
• Partner-operated clouds: A national entity operates the infrastructure and controls administrative access using hyperscaler technology, creating a jurisdictional shield against extraterritorial requests such as those under the U.S. CLOUD Act. France’s S3NS and Bleu are both pursuing SecNumCloud qualification.
• Disconnected and air-gapped clouds: Built for defense and critical infrastructure, with open questions in the research about how completely air-gapped these deployments are in practice.

Stanford HAI notes that Microsoft and AWS, by committing to legally contest orders to suspend European services and to compensate customers for disclosures that violate the General Data Protection Regulation, “have implicitly (and, in some cases, explicitly) admitted that these ‘sovereignty overlays’ do not remove jurisdictional exposure to the United States.”

All three sovereignty tiers answer a question about location and legal authority over infrastructure, and they answer it from an engineering perspective. None observes what your business does with regulated data once it arrives. That second question is the one a regulatory agency will ask you to evidence, and it is answered from your own records or not at all.

Regulators are asking a custody question

Residency asks where data sits. Custody asks a harder question: who touched this data, when, and under what authority. A supervisor examining your firm will not audit your cloud provider’s sovereignty marketing, and a contractual residency commitment describes an intended state when an examiner wants an observed one. An earlier post in this series made a version of this case about AI use policies, which state a rule without observing whether anyone holds to it.

The Digital Operational Resilience Act (DORA) has been in force across European financial services since January 2025, and it asks custody questions throughout. Article 28 requires documented exit strategies for information and communication technology (ICT) arrangements that support critical or important functions. Article 30 sets out mandatory contractual provisions, including rights of access, inspection, and audit, with an enhanced set applying wherever a service supports a critical or important function.⁶ An audit right is exercised against records of what happened, not against an architecture diagram of where servers live.

Any firm that hoped the European Union’s AI Act would set the pace here got a reprieve, not relief. The Digital Omnibus on AI, which the Council adopted on June 29, 2026, deferred full compliance for standalone high-risk systems listed in Annex III from August 2, 2026 to December 2, 2027.⁷ Credit scoring and insurance pricing sit inside Annex III, so much of financial services AI now has sixteen additional months. DORA didn’t move at all, which means the obligation to prove where regulated data went and who was entitled to see it is already live and already being examined.

London Stock Exchange Group treated DORA as exactly this kind of obligation. The regulation was the stated trigger point for the group’s data lineage program, which began mapping datasets field by field in 2023.⁸ Operational resilience requirements moved a global market infrastructure firm to element-level lineage years before the AI rules arrived.

You cannot negotiate a dependency you cannot see

The brief’s prescription deserves more attention than its critique, and it translates directly to the enterprise. “The core policy challenge of AI sovereignty is not eliminating dependence but calibrating interdependence,” the brief argues. “Sovereignty should be viewed as the capacity to shape and negotiate dependencies, not avoid them entirely.”⁹

Capacity to negotiate presumes knowledge of what is being negotiated. A firm that cannot enumerate which regulated data reaches which provider, under which contractual obligation and which jurisdiction, has no position at the table regardless of what its master services agreement says. Concentration risk works the same way. DORA’s register of information, the inventory of ICT arrangements every firm keeps for its supervisor, exists because regulators want institutions to understand their own dependency structure, and a register assembled from procurement records describes what was bought, which is seldom what is running.

Few organizations will replace an entire data ecosystem with a sovereign region. The realistic destination is a mixed enterprise data environment, with public hyperscaler capacity, one or more sovereign regions, and air-gapped enclaves operating at the same time. Once that is the architecture, jurisdiction stops behaving like a property of a datacenter and starts behaving like an attribute attached to a data flow. Answering whether a particular customer record may move from the public region into the sovereign one, or out of it, requires knowing what that record is, which obligation governs it, and which downstream systems consume it.

The real test is whether you could leave

At the enterprise level, Stanford HAI’s brief frames control in terms a chief risk officer will recognize: “Full control of your AI stack means you are not beholden to any one company that could withhold its capabilities at any moment.”¹⁰ For a European financial institution, that is not a philosophical position. DORA Article 28 already requires a documented exit strategy for any ICT arrangement supporting a critical or important function, and operational resilience is where that obligation is examined.¹¹

To move a workload out of a provider, you have to know every downstream consumer of every flow that provider touches, including the reports, models, and regulatory submissions that would break on the way out. Firms that run this exercise find dependencies they never documented, which is why they should run it before an exit is forced on them.

Plan a migration of this kind as a model before running it as a project. A future-state model is a branch of a version-controlled data lineage graph representing a proposed change, which teams diff against production to see every affected consumer in advance. An earlier post on impact analysis covers how that works and what asset managers have learned from planning replatforming this way. The same discipline applies whether the destination is a sovereign region, a partner-operated cloud, or an exit from a provider that has become too concentrated to be comfortable.

Where to start

Sovereignty programs tend to begin in procurement and stall when someone asks for evidence. Three pieces of groundwork are worth more than another vendor assurance, and each can begin ahead of the next contract renewal or migration:

1. Attach jurisdiction and obligation to the flow, not to the system inventory: A system-level record of where applications are hosted cannot answer a question asked at the level of a customer record or a risk attribute. Data lineage that carries business meaning alongside technical flow lets you ask which regulated data may enter a sovereign region and which may not, and get an answer at attribute level instead of an educated guess.
2. Build the exit test before you need it: Take one provider supporting a critical or important function and trace every downstream consumer of the data it holds, through to the reports and models that depend on it. Where the trace runs out, that is the part of your DORA Article 28 exit strategy that currently exists only on paper.
3. Model the sovereign migration before committing to it: Build the target environment as a future state, compare it against production, and identify which data flows change jurisdiction as a result. Version-controlled data lineage generates that comparison, where the alternative is weeks of workshops.

None of this work requires resolving the geopolitics. It requires a firm to know its own data well enough to defend a sovereignty claim when someone asks for evidence.

Sovereignty is an evidence problem

Organizations that get this right treat sovereignty as an operational capability they run and evidence, not a box closed at procurement. They can show where regulated data flows, which obligations travel with it, and what would break if a provider became unavailable. Solidatus is a data lineage platform built for that work in regulated industries, combining end-to-end lineage with the business context that makes a data flow interpretable, and the AI Lineage Assistant extends it to the training data and outputs of AI systems now entering the same regulatory perimeter.

A sovereign cloud is a reasonable purchase, and for many regulated firms it is the correct one. It is not an answer to the question your supervisor will ask.