“Data sovereignty” has become one of the hottest phrases in technology conversations, a fixture of vendor briefings, conference panels and boardroom discussions about AI adoption and it’s almost always underspecified. Ask three people in the same conversation what they mean by it and you’ll often get three different answers: some mean “our data stays where we expect it to” some mean “no foreign authority can ever be compelled to access it” and some mean something closer to “we don’t fully trust externally developed AI models and want more control over the alternative.”
These are not the same problems and treating them as one is how vendors end up promising something no contract can deliver. The honest answer to “can we achieve data sovereignty?” is: yes, in parts, with real trade-offs that differ depending on which part you mean. Sovereign cloud offerings from the major hyperscalers have matured rapidly over the past two years, giving buyers something concrete to point to. However, security-conscious buyers, particularly in regulated sectors, are starting to write more specific data residency and control language into their requirements, even where “sovereignty” itself isn’t yet the formal term of art.
The Four Layers of “Sovereignty”
- Data residency. Where the data is physically stored and processed, the layer most people mean when they first raise the issue.
- Subprocessor and support jurisdiction. Which subprocessors, support engineers, and incident responders can access the data, and whether they sit inside or outside the sovereign boundary.
- Model residency and training provenance. Whether the model itself was trained and fine-tuned entirely within a sovereign boundary, on data that never left it.
- Legal jurisdiction over the vendor entity. Whether the vendor can be legally compelled by a foreign authority to disclose the data, regardless of where it’s stored or processed.
Where the Trade-offs Bite
If residency is genuinely the whole requirement, then it is achievable at low cost and low friction. EU and UK data centre options from established cloud providers are mature, well-tested, and available with minimal compromise on service quality. However, add the remaining layers, and the trade-offs against total sovereignty become real.
Subprocessors are the first surprise. Data residency doesn’t automatically mean sovereign handling: remote support engineers, incident responders and subprocessors may sit outside the sovereign boundary even when the underlying infrastructure doesn’t. Closing this gap through geographically gated support teams and vetted subprocessor lists is achievable, but it carries a genuine cost premium, and not every vendor offers it as standard. The quality compromise applies here too: narrowing the pool of eligible support staff and subprocessors to a sovereign boundary can mean slower response times, less specialist coverage, or reduced redundancy compared with an unrestricted global support model.
Model residency is where “we’ll have to compromise on quality” becomes structurally true, not just an inconvenience. Asking whether a model was trained and fine-tuned entirely within a sovereign boundary, on data that never left it, takes you into a much smaller pool of options than the open market offers. Genuinely sovereign models do exist and are improving quickly, but they can still lag behind the leading international options on capability.
Legal jurisdiction is the hardest layer, because it’s a matter of public international law, not technical architecture. Even where a vendor can guarantee residency, support jurisdiction and model provenance, the underlying question becomes whether you can eliminate the vendor’s legal exposure to compelled disclosure by a foreign authority not merely reduce the likelihood or narrow its scope. Where a vendor entity is subject to a foreign legal regime (the US CLOUD Act being the most cited example), no amount of DPA drafting fully insulates the data from a lawful compulsion order in that jurisdiction. The best available mitigations narrow the risk: contractual obligations requiring the vendor to challenge unlawful demands before complying, notice provisions so you can intervene where legally permitted and transparency reporting showing how often such requests occur in practice. However, none of them eliminate it.
A Worked Example
Take a hypothetical (composite) scenario: a public sector authority issues an RFP which has a requirement for “full data sovereignty” as a condition of award. On its face, that reads as a requirement for an absolute guarantee against foreign legal compulsion (see layer 4 above). However, in practice, when you sit down with the authority’s procurement and security teams, the actual driver usually turns out to be narrower, namely, a specific security classification requirement that maps to layers 1 and 2 above – residency and vetted support access but not a genuine need for sovereign model training, or immunity from all foreign jurisdictions. Once that’s established, the vendor can meet the real requirement without either side chasing an unachievable guarantee on layer 4 and the resulting contract terms are both deliverable and enforceable. That gap between the word used in the tender and the risk being managed is where deals stall, warranties get overpromised and disputes eventually surface.
The Practical Takeaway
When “data sovereignty” comes up, the first useful move is diagnostic, not contractual. Before drafting anything, ask which of the four layers is driving the request: is this about where data sits, who can access it, how capable the model needs to be, or which legal system ultimately governs the vendor? Most of the time, what’s really driving the request is narrower than “full sovereignty” often it’s local hosting, local support, vetted personnel, security, and compliance with recognised international certifications. Once you’ve identified which of these matters most, you can draft something that’s both commercially deliverable and legally honest, rather than a warranty the vendor can’t perform.
The lawyer’s value here isn’t promising sovereignty. It’s refusing to let an undifferentiated buzzword become an unperformable warranty and doing the unbundling before the ink dries, not after a dispute forces the question.