Where your data sits is the least interesting fact about it. The interesting facts are who can read it, under whose authority, and what record proves it. A data center in Frankfurt with the wrong people holding the keys is not sovereign. A dataset that crosses a border under tight, logged, revocable access may be more sovereign than one that never left home.
Policy discussion is catching up to that point. An Omdia analysis published in October 2026 says sovereignty debates are moving beyond data residency toward control over the entire AI and cloud stack, including compute infrastructure, training datasets, and model governance. Residency was always a proxy. The proxy is wearing out.
For a CISO or Chief Compliance Officer, that shift changes the question your program must answer. "Is our data in the right country?" is a map question and any vendor can answer it with a region selector. "Can we prove who could access this data, including the provider's own staff and the provider's AI systems?" is an access control question, and it is the one regulators, auditors, and courts will increasingly ask.
Sovereignty is enforced, or it fails, at the access control layer. Geography is a weak control, jurisdiction follows the provider and not the disk, and encryption keys often decide the outcome. AI inference then reopens the whole problem. Regulators regulate data, not servers, so the evidence your program produces must describe access and not location.
Omdia principal analyst Sarah McBride makes a point in that report that sounds academic and is actually operational. Governments increasingly treat sovereignty as strategic agency and informed decision-making, not as full technological self-sufficiency, because supply chains are global and nobody builds the whole stack at home. If self-sufficiency is off the table, control over how the stack is used becomes the practical lever.
The same analysis warns that clear guidance on AI and cloud sovereignty requirements is largely absent, and that the market still needs clearer definitions, certification mechanisms, and operational boundaries. That gap is where the risk lives for a regulated organization. When the rules are vague, vendors fill the vacuum with marketing terms, and "sovereign" becomes a label on a product and not a property of a control.
Omdia also says the EU, as the clearest regulatory-driven model, is moving toward making sovereign AI an auditable legal requirement for the first time. Pause on the word auditable. An auditable requirement is one where someone will eventually ask you to demonstrate compliance, with evidence, to a person who is not on your side.
That is the compliance consequence the headline numbers obscure. Sovereignty stops being a strategic posture and becomes a line item in an assessment, with an owner, a due date, and a finding if the evidence is thin. The organizations that treated it as a region dropdown will find that an assessor wants more than a dropdown.
Think about what a residency guarantee actually promises. It promises that data at rest sits in a specified location. It does not promise that administrators in another country cannot reach that location, that support engineers cannot open a session, that backups stay put, or that a downstream processor honors the same boundary. Each of those is an access question.
The sovereignty risks French firms face with US cloud providers illustrate the gap. The data can sit in a French region while the control plane, the support tooling, and the legal entity that answers to a court sit somewhere else. The firm bought residency and assumed it had bought sovereignty.
There is a useful test. Imagine your cloud region were fully isolated tomorrow and nobody could physically move the data. Ask who could still read it. If the answer includes the provider's staff, the provider's parent company, or any system holding a decryption key you do not control, then geography was never the protection.
The reverse also holds. A well-governed cross-border workflow, with named identities, purpose limitation, customer-held keys, and an immutable record, can satisfy a regulator more convincingly than a geographically pure architecture with weak internal access. Sovereignty is about who holds authority over the data. Where the bytes rest is a detail.
That reframing matters for budgeting too, because money spent on a second region buys redundancy, while money spent on key custody and access policy buys control.
The legal point is the one that most often surprises business leaders. A provider headquartered in one country remains subject to that country's law when it stores customer data in another. The US Department of Justice describes the CLOUD Act as a framework for access to electronic evidence held by US-based providers, wherever it happens to be located. That wording is the DOJ's, and it captures the problem for any customer outside the United States.
Practitioners have written extensively about what this means for transfers. The analysis of jurisdictional sovereignty in enterprise file sharing covers transfer impact assessments and the exposure a provider's legal obligations create. For defense and government buyers the stakes are higher still, and the case for why defence organisations cannot rely on foreign hyperscalers rests on exactly this mechanism.
Contracts do not fix it. A data processing agreement can bind the provider to a promise, but it cannot rewrite what a court in the provider's home jurisdiction may order. If the provider holds the keys, it holds the ability to comply with that order, whatever the contract says.
This is the moment a compliance leader should stop asking vendors for assurances and start asking for architecture. Which party can technically produce plaintext of this data on demand? If the honest answer is the provider, the sovereignty claim depends on trust in a legal system you do not control.
Encryption is where sovereignty becomes concrete. If the customer generates and holds the keys, in hardware the customer controls and in a jurisdiction the customer chooses, the provider cannot produce plaintext because it never possessed it. The legal order lands on a party with nothing readable to hand over.
That is the logic behind the debate over customer-held keys versus vendor-managed keys. Vendor-managed keys are convenient and shift operational burden to the provider. They also concentrate decryption capability in the one place a foreign authority can reach. For regulated buyers that trade-off must be made on purpose, with the legal exposure written down.
Transfer law makes this a compliance question and not just a security preference. The argument for achieving GDPR transfer compliance through customer-managed encryption, rather than relying only on standard contractual clauses or an adequacy framework, is that technical control provides protection independent of legal mechanisms that can be invalidated. Legal instruments have changed before and will change again. A key you hold does not depend on a court's mood.
Key custody also reframes the shared-collaboration problem. When partners, auditors, and counterparties need access, the question becomes whether the platform lets the data owner keep control after the file leaves. That is the premise of an independent governance layer for external collaboration, where keys and policy stay with the owner and recipients get governed access and not a copy.
Everything above assumed data at rest and in transit. AI changes the third state. To produce an answer, a model must read the data in a usable form, so inference is a data-in-use event, and every inference path introduces operators, infrastructure, retention behavior, and logs that may or may not sit inside your boundary.
Omdia's framing helps here. It lists compute infrastructure, training datasets, and model governance as part of the sovereignty perimeter. Each is an access control surface. Who can see prompts that contain regulated records? Where are those prompts retained, and for how long? Can the model operator's staff review outputs? Can a retrieval system reach documents the requesting user should never see?
The earlier posts in this series show how this fails in practice. In When the AI Company Itself Cannot Control Data Access, the failure was an AI developer unable to enforce scope over its own internal data access. In An AI Safety Test Agent Attacked Real Targets Alone, an agent reached outward because nothing at the boundary stopped it. In both cases a region setting would have changed nothing. Access decisions at the point of request would have changed everything.
That is why the argument that data layer enforcement must replace prompt-level promises applies to sovereignty with equal force. An agent authorized by a human user inherits that user's reach. If sovereignty rules are expressed only in documents, the agent will walk through them at machine speed.
It helps to look at where organizations really are. The BARC survey of 320 companies, fielded in February and March 2026 and sponsored by several data and infrastructure vendors, found that 51 percent rate sovereignty as very important, up from 42 percent the year before. Treat the sponsorship as context, since the sponsors sell into this market, but the shape of the finding is informative.
The gap between importance and action is the story. The same survey reports that 40 percent are not yet investing in sovereignty initiatives and only 10 percent have a dedicated budget. Thirty-eight percent have applied sovereignty governance and 46 percent have an established technical architecture. Rated as important and funded as optional, which is the signature of a topic that has not yet met an auditor.
Legal requirements remain the top external driver at 61 percent, though that figure fell from 69 percent the prior year, while concern about US political developments, security incidents, and public cloud dependency each rose. Read the direction of travel. The motive is shifting from avoiding a fine to avoiding a loss of control.
Put those numbers beside the compliance reality. Most of the organizations calling sovereignty very important cannot yet show an architecture that enforces it. That is the exposure, and it will be measured in findings, not in survey answers. A program that cannot show enforcement today should say so plainly and set a date.
Auditors do not accept a region choice as proof of sovereignty, and they should not. What they accept is evidence that a defined set of people and systems could reach defined data, that each access was authorized, and that the record is complete and unaltered. That is the standard behind security of processing obligations, which apply to AI systems exactly as they apply to humans.
Consider what a sovereignty evidence package would need to contain. A map of every identity, human and automated, with access to the data. The policy that governed each access and the attributes it evaluated. Key custody records showing who held which keys and where. A tamper-evident log of requests, decisions, and results. Subprocessor and operator access records, including those of AI services.
Few organizations can assemble that package in days, which is the timescale a regulator's clock runs on. Fewer still can show that the package was generated by the system of record and not written by hand for the occasion. Most can assemble contracts and architecture diagrams in weeks. The difference between those two is the evidence gap, and the longer an AI program runs without closing it, the larger it gets.
The practical implication is architectural. Evidence-quality records come from the layer that enforces access, created at the moment of the decision, not reconstructed afterward from scattered application logs. That is the design principle behind a governed data exchange with a single policy engine and unified audit trail, and it is the reason Kiteworks emphasizes encryption validated to FIPS 140-3 and single-tenant isolation, applied to human and agent identities alike, as attributes that support custody claims you can demonstrate.
Start with the question that cuts through the marketing. For each regulated dataset, write down who can technically produce plaintext today. Include provider staff, provider legal entities, support tooling, subprocessors, and every AI service that touches the data. The list is usually longer than anyone expected.
Next, decide key custody on purpose. For datasets where foreign legal access is unacceptable, move to customer-held keys in a jurisdiction you choose, and document the decision. For datasets where the provider's convenience outweighs the risk, record that choice as an accepted risk with an owner and a review date, so the next audit finds a decision and not an oversight.
Then extend the same rules to AI. Require that every AI service reach data only through a governed layer that evaluates identity and purpose at request time, and that inference logs stay inside your evidence boundary. Bonfy's entity-aware approach to data in use addresses the same problem from the contextual side, asking who is acting, on whose behalf, and for what purpose before data moves.
Finally, close the loop with the people who will ask the hard question, ideally before they ask it. Brief your Chief Compliance Officer, Data Protection Officer, and General Counsel on the difference between residency and enforced access. Then rehearse the evidence request. The 2026 conversation about Offensive AI Agents Just Outran Bank Identity Security showed what happens when identity governance assumed the actor would behave, and OpenAI and Anthropic Want AI Agent Breach Laws. Look at What Happened Before They Asked. showed what happens when disclosure depends on the actor's choice. Sovereignty built on assurance fails the same way.
Yes, as one input among several. Many laws and contracts require data to be stored in a specified place, and residency can reduce certain risks such as latency to local authorities and clarity about which regulator has primary oversight. The mistake is treating it as sufficient. Residency tells you where data rests, and it does not tell you who can access it, which is the question regulators and courts ask when something goes wrong.
Not by itself. A provider headquartered outside the EU can remain subject to its home country's legal process for data it controls, regardless of where the data is stored. The stronger protection is technical, meaning customer-held encryption keys and governed access, so that the provider has no readable data to produce. Legal advice specific to your situation is essential, and General Counsel and Data Protection Officers should own that analysis. Treat any claim that a region setting alone removes foreign legal exposure as a claim to be tested, not accepted. Ask the vendor to explain, in writing, which of its own personnel and legal entities could produce plaintext.
AI inference requires data to be readable by a model while it is processed, which adds operators, infrastructure, logs, and retention behaviors to your trust boundary. A vendor that cannot tell you who can read prompts has not answered the sovereignty question, whatever its marketing says. Prompts and retrieved documents can contain regulated records. Sovereignty programs must therefore cover who can see prompts, where they are retained, and what an agent can reach when it acts on a user's behalf.
An auditor will want to see the identities that can reach each regulated dataset, the policy and attributes behind each access decision, key custody records, and a tamper-evident log of requests and results. Operator and subprocessor access, including AI services, belongs in that record. The test is whether you can assemble it in days instead of weeks, because that is the timescale of a regulatory inquiry. If assembling it takes weeks, the gap is a finding waiting to happen, and the cheapest time to close it is before anyone asks.
List, for each regulated dataset, every party that could technically produce plaintext today. Then decide key custody deliberately and document accepted risks with owners and review dates. Finally, route AI access through a governed layer that evaluates identity and purpose at request time, so the same rules apply to machines and humans. Name an accountable owner for each dataset's sovereignty decision so the choice does not drift. Keep the exercise small at first, with one dataset and one AI use case, because a single worked example exposes most of the structural gaps.
To learn more about sovereign data access, schedule a custom demo.