Digital Sovereignty Stopped Being a Policy Debate and Became an Infrastructure Bill

For most of the last decade, digital sovereignty lived in the same drawer as "data is the new oil" and other phrases people say at conferences to fill the time before lunch. It was a policy debate, conducted by think tanks and trade negotiators, with stakes that felt theoretical to anyone actually shipping software. You could nod along and go back to your sprint.

That drawer is now empty, because the contents got promoted to the contract. Sovereignty has moved from the white paper to the purchase order, and it arrived with specifics: encryption-key control, data residency clauses, extraterritorial exposure, the right to audit. When AI entered the picture, the urgency compounded, because an AI system does not just store your data, it ingests it, reasons over it, and routes it somewhere you may not be able to point to on a map. The companies treating this as next year's problem are the ones who will lose a tender to a competitor who read the rubric.

From rhetoric to requisition

Digital sovereignty became real the moment it acquired a price tag and a scoring sheet. The clearest signal is that EUR 180 million European Commission tender, which does not ask vendors whether they are sovereign in the abstract. It scores them across eight objectives covering legal, operational, supply-chain, and security dimensions, per the European Commission. That is the tell. When a buyer turns a value into a rubric, the value has stopped being a debate and started being a requirement.

The money confirms it. The global sovereign cloud market is on track to grow from $154.69 billion in 2025 to $195.35 billion in 2026, with a longer arc toward $826.09 billion by 2034, according to Fortune Business Insights. In Europe specifically, the sovereign cloud market is projected to expand from just over EUR 20 billion in annual revenue to more than EUR 100 billion by 2031, even though three US providers currently hold roughly 70% of European cloud infrastructure, per Broadcom. Hold those two facts next to each other: the incumbents own most of the market, and the buyers are actively shopping for an exit. That is what a procurement shift looks like before it shows up in the revenue charts.

Gartner expects more than 50% of multinational organizations to have a digital sovereignty strategy by 2029, up from less than 10% in 2025, as reported by Niveus Solutions. A fivefold jump in four years is not a trend, it is a reclassification. Sovereignty is becoming table stakes the same way security questionnaires did fifteen years ago, back when "do you encrypt data at rest" was an edgy question instead of line nine of a standard form. If you sell software, you already know how that story ends. The question becomes mandatory, then it becomes a gate, then nobody remembers it was ever optional.

Who holds the keys, really

Sovereignty is decided by key custody, not by geography. This is the single most expensive misunderstanding in the category, so it is worth being blunt: where your data physically sits is data residency, and data residency is the easy 30% of the problem. Data sovereignty is about which laws govern that data and, in practice, who can be compelled to decrypt it. You can store a database in Frankfurt, on German soil, in a building with a German flag out front, and still have that data be legally reachable by a foreign government if the parent company operating the cloud is subject to that government's jurisdiction.

The mechanism that makes this concrete is the encryption key. If your cloud provider holds the keys, then the provider, not you, is the party a court order lands on. The provider can be compelled to hand over readable data without your involvement and, in some legal regimes, without your knowledge. If you hold the keys, the compulsion has to come to your door, under your jurisdiction, where you have standing to fight it. That difference is the whole ballgame. It is also why "bring your own key" and customer-held key management quietly became the features that close enterprise deals while flashier capabilities sit unused.

This is the same lesson that shows up every time a company examines what it has actually outsourced versus what it thinks it outsourced. I have written before that vendor lock-in is just outsourcing with better branding, and key custody is the purest example. The moment you hand someone else the keys to your data, you have not bought a service, you have transferred control, and control is extremely hard to get back. For AI systems the stakes climb again, because the model does not just hold your data, it derives new information from it. The same discipline I have argued for around feeding data to an AI vendor applies with force here: ask who can read the keys before you ask what the model can do.

The extraterritorial problem

The thing keeping procurement officers awake is not where the data lives, it is whose laws can reach across the border to grab it. Extraterritorial reach is the formal name for the problem, and the United States CLOUD Act is its most-cited example: it can compel a US-based provider to produce data under its control regardless of where in the world that data is physically stored. The provider does not get to point at the German flag. Jurisdiction follows the corporate parent, not the data center.

This is why a majority of Western European CIOs now expect geopolitical risk to constrain their use of global cloud providers, and why 58% of enterprises treat sovereign cloud capability as a baseline requirement rather than a nice-to-have, per Niveus Solutions. It is a rational response to a real exposure, not a fashion. When a buyer cannot guarantee that a foreign government will not be able to read their citizens' or patients' or defendants' data, the buyer does the sensible thing and writes a clause that closes the gap.

Here is where I have to be honest about the other side of the argument, because it is a good one. The Information Technology and Innovation Foundation argues, in a paper bluntly titled From Sovereignty to Control, that chasing the sovereignty label can be misguided, and that governments are usually better served by focusing on real control over security, access, and lock-in, which a well-governed mainstream cloud plus strong legal and technical controls can often deliver. The Dutch government, from a different angle, has pressed the EU to actually define "sovereign cloud" in law, warning that without a standard definition buyers cannot tell genuine sovereignty from vendor branding, per the Government of the Netherlands. Both are right that some of this market is theater. The label is not the protection. But the underlying exposure is real, and "the marketing is overheated" is not the same as "the risk is fake." The mature move is to ignore the badge and audit the controls.

What procurement teams are now asking about digital sovereignty

Procurement has converted sovereignty from a sentiment into a checklist, and the checklist is where deals are won or lost. If you are selling, you should be able to answer every one of these before the buyer asks, because the buyer who has done their homework will. Microsoft, for its part, frames sovereignty as a continuum of controls rather than a single destination, combining residency, encryption, operational transparency, and AI governance, per Microsoft. That framing is useful, because it turns one intimidating question into a set of answerable ones.

The questions that now show up in real tenders cluster into a few themes:

• Key custody. Who holds the encryption keys, and can the customer hold them exclusively? Can keys be revoked unilaterally?
• Jurisdiction and corporate parentage. What entity operates the service, under whose law, and is that entity exposed to extraterritorial production orders like the CLOUD Act?
• Data residency and flow. Where is data stored, processed, and backed up, including for any AI inference and logging? Does any data leave the jurisdiction, even transiently?
• Operational autonomy. Can the system run, and be supported, by personnel within the jurisdiction, without foreign-based administrators holding privileged access?
• Auditability and exit. Can the buyer audit these controls, and can they leave with their data intact and the keys destroyed, without a lock-in penalty?

Notice that only one of those five is about physical location. The other four are about control, and control is the part that "we host in-region" does not, by itself, answer. The willingness to pay up to a 20% premium for sovereign options, reported by Niveus Solutions, is buyers paying for those four answers, not for the map pin. This is also why sovereignty has become a buy-versus-build pressure point: the cost-of-ownership math on AI software changes when "buy" means importing someone else's jurisdictional exposure along with their feature set.

Designing for sovereignty from day one

Sovereignty is far cheaper to design in than to bolt on, and the design choices are knowable today. The companies that will keep winning regulated tenders are not the ones with the loudest sovereign branding, they are the ones who made a handful of architectural decisions early enough that compliance is a configuration, not a rebuild. If you have ever tried to retrofit security into a system that did not plan for it, you already know the difference in cost between a design decision and a remediation project.

A workable approach looks less like a slogan and more like a set of defaults. Hold the keys, or give the customer a clean way to hold them, so that compulsion has to route through the customer's own jurisdiction. Keep a clear data-flow map, including for AI inference, logging, and any third-party model calls, so you can answer the residency question with a diagram instead of a shrug. Architect for operational autonomy, so the system can be run and supported from inside the jurisdiction when a tender demands it. And classify data early, so the genuinely sensitive material gets the sovereign treatment while the rest rides on cheaper infrastructure, because treating everything as maximally sensitive is how you price yourself out of every deal.

This is the same discipline that separates an AI deployment that survives its first audit from one that becomes a liability with a cover page. I made that argument about governance frameworks in the case for an AI governance policy people will actually follow, and it holds here: the controls that work are the ones designed into the path of least resistance, not the ones written down and hoped for. Sovereignty is not a posture you adopt. It is a set of decisions you make about keys, jurisdiction, data flow, and autonomy, and the best time to make them is before the contract that requires them lands on your desk. The mediator between the head and the hands, as the old line goes, must be the heart, and in this case the heart is the unglamorous architectural work nobody puts on a slide.

Frequently Asked Questions

What is meant by digital sovereignty?

Digital sovereignty is an organization's or state's ability to keep control over its data, infrastructure, and critical technology under its own laws, rather than depending on foreign jurisdictions or vendors. In Europe it is now written into cloud, AI, and data policy as a procurement and regulatory requirement, not just a political principle.

What is the difference between data residency and data sovereignty?

Data residency is about where data physically sits; data sovereignty is about which laws govern it, including who can compel access. Storing data in-country does not make it sovereign if a foreign parent company or extraterritorial law can still reach it.

What is a sovereign cloud?

A sovereign cloud is a cloud environment designed so data, operations, and infrastructure stay under a specific country's or region's legal control and out of reach of foreign government access. The term has no single official definition, so the actual criteria vary by buyer and jurisdiction, which is why auditing the controls matters more than trusting the label.

Is data residency enough for data sovereignty?

No. Data can live in-country and still be legally reachable by a foreign parent or an extraterritorial statute like the US CLOUD Act, so sovereignty also needs governance, contractual, and technical controls. Customer-held encryption keys and local operational autonomy are the controls that actually move the needle.

Why is digital sovereignty important for AI systems?

AI systems do not just store data, they ingest it and derive new information from it, often routing it through models and logs across borders. That widens the exposure, so the same key-custody and jurisdiction questions you ask of a database matter even more for an AI vendor.

What are the benefits of a sovereign cloud?

A sovereign cloud offers stronger assurance that regulated data stays under domestic legal control, a cleaner local-compliance posture, and reduced exposure to foreign access or sanctions. The trade-offs are cost and complexity, and many workloads can meet the same risk bar with well-governed standard cloud plus added controls.

References

• European Commission, Commission moves forward on cloud sovereignty with a EUR 180 million tender
• Fortune Business Insights, Sovereign Cloud Market
• Broadcom, Three Predictions for Sovereign Cloud in 2026
• Niveus Solutions, Sovereign Cloud and the New Era of Digital Control
• Government of the Netherlands, Strengthening Cloud Sovereignty of Public Administrations
• ITIF, From Sovereignty to Control
• Microsoft, Navigating digital sovereignty at the frontier of transformation