Data residency is a question about geography: where information is stored and processed. Data sovereignty is a question about jurisdiction: whose laws reach it, and who can compel its disclosure. They are related, they are not the same, and an AI deployment can satisfy one while failing the other.
What follows describes where data actually goes in an AI environment and what to establish about each location. It is not legal advice, and it deliberately does not tell you what any obligation requires of your organization. That determination belongs to whoever advises you on it.
The distinction, and why it matters here
An organization can hold data in a facility inside its own country and still find that a provider elsewhere in the corporate chain is subject to a disclosure order abroad. Conversely, data processed in another region under a well constructed arrangement may be under firmer control than data held locally by a supplier nobody has assessed.
Residency is a fact you can verify. Sovereignty is a relationship you have to reason about. For an AI environment the second is harder, because the chain is longer than most systems: an application, a retrieval service, an embedding provider, a model provider, and whichever infrastructure each of those runs on.
The seven places to ask about
Most residency assessments examine one and assume the rest. Each of these can sit in a different jurisdiction, and each is a separate question.
- Primary storage. Where the documents live. The one people check.
- The index. The vector store is a copy of your content, and it is frequently a managed service in a region nobody chose deliberately. Covered in vector databases and enterprise AI.
- Embedding. Where content is converted into vectors. A hosted embedding service means every indexed document and every query travels there, which is a transfer that no diagram of the model deployment shows.
- Inference. Where the model runs. Often the only thing a residency commitment actually covers.
- Logs. Prompts and responses, frequently retained in a provider's own region under their own terms, and frequently more sensitive than the sources.
- Backups. Replication and disaster recovery routinely cross regions by design, which is a resilience feature and a residency exception at the same time.
- Support access. Where the provider's staff are, and under what circumstances they can reach your data. Not a storage location, and squarely a sovereignty question.
The embedding step is the one most often missed. An organization that self hosts a model for data boundary reasons, and then indexes the same corpus through a hosted embedding API, has moved the content it was protecting.
What a residency commitment usually covers
Commitments vary, and the differences are load bearing. Three questions separate a strong commitment from a partial one.
Does it cover processing as well as storage? A commitment that data is stored in a region says nothing about where it is processed, and inference is processing.
Does it cover the whole chain? A model provider's regional commitment may not extend to the subprocessors it uses, and the subprocessor list is a document that changes.
Does it survive failover? Under load or outage, traffic may be served from elsewhere. Whether that is permitted is worth knowing before it happens rather than afterward.
None of these are unreasonable positions for a provider to take. They are simply things to establish rather than assume, and to record with a date so that the basis of the decision is visible at renewal.
Where the obligations come from
Requirements about location arrive from several directions at once, and it is worth separating them because they behave differently.
Regulation. In the European Union, data protection is governed by a framework the European Commission describes as comprising the General Data Protection Regulation together with the Law Enforcement Directive and the regulation covering EU institutions. In California, the California Privacy Protection Agency administers the California Consumer Privacy Act and adopts regulations under it. Sector rules add further requirements in health, education, finance and government work.
Contract. Frequently the more immediate constraint. A client agreement may require processing in a named country, or forbid subprocessors without approval, and it binds you whatever the regulatory position is.
Policy. An organization's own commitments, sometimes made in a bid or a privacy notice, which are enforceable in reputation if not in law.
The practical point is that these are often confused with one another. Establishing which of the three a given requirement actually comes from is frequently the most useful hour in the whole exercise, because a policy position can be revisited and a contractual term cannot.
What a supplier should be able to tell you
These are factual questions with factual answers, and the answers belong in writing rather than in a conversation. A supplier who has thought about enterprise use will have them ready; one who has not is telling you something useful by the difficulty.
- In which regions is our content stored, and in which is it processed? Answer both separately.
- Who are your subprocessors, and how are we told when the list changes?
- Where are prompts and responses retained, for how long, and under whose control?
- Under what circumstances does your staff access our data, from where, and is that access logged?
- What happens to the location commitment during a failover or an outage?
- If we ask you to delete our data, what is deleted, from where, and within what period?
The second and the fifth are the ones that most often reveal a commitment narrower than it first appeared, because a subprocessor list is a moving object and failover is designed to ignore ordinary constraints.
Two questions this page will not answer
Whether a particular transfer is lawful for your organization, and whether a particular provider arrangement satisfies a particular obligation. Both are specific to your circumstances, your sector and the agreements you have signed, and both change as regulation and adequacy arrangements change.
What this page can do is make sure the question is asked about all seven locations rather than one, and that the answers are written down.
Embeddings, and an open question worth knowing about
Whether a vector derived from personal data is itself personal data is a question organizations are actively working through, and one on which a general answer would be unhelpful here.
What is not in doubt is the technical position, which is that embeddings retain a great deal about the text they came from and are not anonymization. Most systems store the source passage alongside the vector in any case, which usually settles the practical question regardless of how the definitional one resolves. Treating the index as carrying the residency requirements of its sources is the conservative and straightforward course.
Designing for it rather than discovering it
Where an obligation constrains location, it removes options rather than informing a preference, and it is far cheaper to know that before an architecture exists.
- Establish the constraint first, from the contract or the adviser rather than from an assumption, and write it down in one sentence.
- Map the seven locations for the proposed design, not just the model.
- Prefer a deployment shape that satisfies the constraint by construction over one that satisfies it by configuration, since configuration drifts. The shapes are compared in on premises and cloud AI.
- Handle the constrained categories separately where only some material is affected, rather than imposing the strictest requirement on everything and paying for it everywhere.
- Re-check on subprocessor changes, which is the event most likely to move a location without anyone noticing.
Where to go next
The data protection controls are in protecting sensitive data when using AI, the policy and accountability side is AI data governance and privacy, and the deployment shapes are in on premises and cloud AI. The rules and oversight layer is AI Governance.
LABUSA maps these locations against an intended design as part of a private AI architecture assessment. We do not advise on what an obligation requires; we establish where the data would actually go, so that whoever does advise you has something accurate to work from. Get in touch to discuss it.
Sources and further reading
- European Commission, Data protection in the EU, which describes the framework comprising the GDPR, the Law Enforcement Directive and the EU institutions regulation.
- California Privacy Protection Agency, Law and Regulations, the authority that administers the California Consumer Privacy Act and adopts regulations under it.
- National Institute of Standards and Technology, AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
Every source above was opened and read on 20 August 2026. Nothing on this page is legal advice, and no statement here should be read as a determination of what any law requires of your organization.