Data sovereignty is an engineering property

“Our data is hosted in Frankfurt” is the sentence I hear most often when sovereignty comes up, and it is the least informative one. Location is one of four dimensions of sovereignty, and on its own it settles almost nothing. This article lays out the four dimensions, why AI has made them urgent, and a method for designing systems that are sovereign to the degree you actually need — no more, and no less.

Four dimensions, not one

Location. Where the bytes are stored and processed. Necessary, not sufficient. A datacentre in Frankfurt operated by a company headquartered elsewhere is in Frankfurt physically and somewhere else legally.

Jurisdiction. Which legal orders can compel access to the data. A provider subject to foreign law — the US CLOUD Act is the well-known example, but not the only one — can be ordered to produce data regardless of where it is stored. The Court of Justice’s Schrems II judgment invalidated one transfer framework on exactly this reasoning; its successor has been challenged in turn. Adequacy decisions and standard contractual clauses manage the legal risk of a transfer. They do not change who the provider answers to.

Control. Who holds the encryption keys, who administers identity, who can read logs. If the provider holds the keys, the provider can be compelled to use them. Customer-managed keys, held outside the provider’s control plane, and identity that is not federated through the same provider are what make control real.

Portability. Whether you can leave. Proprietary data formats, provider-specific services with no equivalent elsewhere, and undocumented infrastructure turn a hosting decision into a permanent one. Sovereignty without an exit is a preference the provider is currently honouring.

A useful exercise is to score each system on all four dimensions. Most organisations discover that they have optimised for location, assumed jurisdiction, ignored control and never tested portability.

Why AI made this urgent

Until recently, sovereignty debates were mostly about storage and email. Three things changed:

First, AI workloads concentrate the most sensitive data an organisation has — contracts, case files, internal knowledge, customer communication — into a single pipeline that reads all of it. A retrieval system over your document store is, by construction, a copy of your document store in a new place with a new access path.

Second, the default way to consume frontier models has been an API operated by a small number of non-EU companies. Every prompt is a data transfer, every retrieved passage in the context window is a disclosure.

Third, regulators and customers noticed. DORA asks financial entities for exit strategies and concentration-risk assessments. Public procurement and funding conditions increasingly require EU hosting. The AI Act adds documentation obligations that are easier to meet when you control the stack.

The good news is that the technical constraint has relaxed at the same time. Open-weight models — from several European and non-European labs — now cover the majority of enterprise use cases at quality levels that were frontier-only two years ago, and they can be run on EU infrastructure: sovereign cloud offerings from European providers, GPU capacity in EU datacentres, or on-premise clusters that are smaller and cheaper than most teams expect.

A design method

1. Classify data before choosing infrastructure

Not everything needs the highest tier. Sort data into classes — public, internal, confidential, regulated — and decide per class which sovereignty level is required on each of the four dimensions. Marketing copy can go anywhere. Customer case files probably cannot leave EU jurisdiction and need customer-held keys. Write the mapping down; it is the document every later decision refers to.

2. Map the flows, including the invisible ones

Draw where each data class actually travels: storage, processing, backups, logs, monitoring, error reporting, model inference, embedding, analytics. The invisible flows — a crash reporter that ships stack traces with user data, an observability SaaS receiving prompt logs, a CI runner that pulls production fixtures — are where sovereignty is most often broken.

3. Choose the smallest sovereign stack that satisfies the classes

For most organisations this is a hybrid: regulated and confidential classes on EU-jurisdiction infrastructure with customer-managed keys and self-hosted or EU-hosted models; everything else wherever it is cheapest. Prefer open standards at every boundary — object storage APIs, OCI containers, Postgres, OpenAI-compatible inference endpoints — so that components can be replaced.

4. Design and test the exit

For each critical component, write down how you would leave: export format, re-import procedure, time and cost estimate. Then test the cheapest step. Restore a backup to a second provider. Re-embed a sample of the corpus with a different model. Redeploy the inference service from infrastructure code onto different hardware. Untested exits are fiction, and DORA supervisors know it.

5. Document the reasoning, not just the result

Auditors, customers and your own future team need to know why a data class is where it is. A short decision record per class — requirement, options considered, choice, residual risk — is worth more than any certificate. Certificates (C5, ISO 27001, SOC 2) tell you the provider follows a process; they do not tell you which law the provider answers to.

Sovereignty as a competitive fact

Organisations that can state, precisely and with evidence, where their data lives, who can reach it and how they would leave are winning tenders, passing audits faster and negotiating from strength with providers. That is an engineering achievement, and it starts with treating sovereignty as a property of the architecture rather than a clause in a contract.