Data residency for AI agents: what reviews really ask
Published
Most vendors answer the data residency question with a dropdown. Pick a region, the compute runs there, the box on the questionnaire is ticked.
That answers where the bytes sit. It does not answer who can be compelled to hand them over, and it says nothing at all about the newest and largest gap in most agent architectures — which is that the pages your agent reads go somewhere to be interpreted, and that somewhere is frequently not the region you chose.
This is written for engineers who have been handed a data protection questionnaire and want to understand what it is actually asking, rather than for lawyers, who already know.
Four terms that are not synonyms
The vocabulary is used loosely and the looseness is doing work, usually in a vendor's favour.
Data residency is where data is stored and processed. It is a factual claim about geography, it is easy to verify, and it is the weakest of the four.
Data localisation is a legal obligation to keep certain data within a country's borders. It applies in specific sectors and jurisdictions. Most companies are not subject to it and think they are.
Data sovereignty is which legal system has authority over the data. This is the one that matters and it does not follow from geography. It follows from the entity: a company incorporated in a jurisdiction is reachable by that jurisdiction's legal process wherever the servers happen to be.
Operational sovereignty is who can technically access the data during normal operations — which support staff, from where, under whose supervision. A provider can be EU-resident, EU-owned, and still have a support organisation with global access.
The distinction that decides most European procurement conversations is the second and third: EU-hosted describes the servers. EU-sovereign describes the company operating them. Only the second is settled by looking at the vendor rather than the region menu, and only the second is what the review is actually asking about.
The seven questions
A serious review works through these. Being able to answer them plainly, including where the answer is unfavourable, shortens the process more than any certification badge.
1. Where does compute execute?
Not storage — execution. For a browser this is the important one, because the browser holds the page in cleartext in memory in order to render it. Encryption at rest is irrelevant to what a running browser can see.
Ask for the datacentre, the operator of that datacentre, and whether it is the same for every session or varies with load. "EU region" is a menu selection; "this facility, this operator" is an answer.
2. Where does each store sit, and for how long?
Enumerate them separately, because they are usually different systems with different lifetimes: the primary database, the cache, the object store holding artefacts, the logs, the backups, the metrics.
Backups are the one that catches people. A system that is scrupulously EU-resident in production and backs up to a bucket configured with a default region has a gap, and it is usually discovered during the review rather than before it.
Then retention, per store. Retention often matters more than location. Data deleted after twenty-four hours has a small exposure wherever it lived. Data kept indefinitely has a large one even in a favourable jurisdiction, and "indefinitely" is the default for logs almost everywhere.
3. Where are the encryption keys, and who can use them?
Encryption protects against a stolen disk. It does not protect against whoever holds the key, so the location and control of the key material is the real question and the ciphertext's location is secondary.
Two specifics worth asking: is the key material held on the same infrastructure that processes the data, and can the provider decrypt customer data without customer involvement? The second question has an honest answer at almost every provider — it is yes, because processing requires it — and a vendor that gets evasive there is telling you something.
4. Which sub-processors are involved, and where are they?
The list, not the summary. And specifically the ones that are easy to forget because they were adopted as infrastructure rather than as vendors: the error tracker, the log aggregator, the email service, the analytics, the CDN, the support desk.
A chain is only as sovereign as its least sovereign link, and the weak link is very rarely the compute — it is the observability stack that somebody wired up in week two.
5. Who can access it operationally?
Which staff, from which country, under what controls, with what logging. This is operational sovereignty, and it is where EU-hosted providers with global support organisations differ from EU-operated ones.
The useful question is not "do you have access controls" — everyone says yes — but "if I ask for the access log for my tenant for last month, what happens?"
6. Under whose legal process does the operating company sit?
The question the region dropdown cannot answer.
A provider incorporated in a jurisdiction with extraterritorial disclosure powers remains subject to them regardless of where the data sits. This is not hypothetical or theoretical: it is why European public-sector procurement has increasingly treated the vendor's incorporation as a criterion in its own right rather than accepting regional hosting as equivalent, and why several large sovereign-cloud tenders have been scoped to exclude providers on exactly this basis.
You do not need to take a position on whether that concern is proportionate. You need to know the answer, because whoever reviews your architecture will ask.
7. Where does model inference happen?
This is the one that gets missed, and for agents it is frequently the largest exposure in the whole design.
Consider what an agent actually does. It logs into a portal, and to decide what to click it sends a representation of the page — an accessibility tree, a filtered DOM, a screenshot — to a model. Then it does that again on the next turn, and the next. Over a single task, a substantial fraction of everything visible after authentication is transmitted to an inference endpoint.
If your browser sessions are in Frankfurt and your inference endpoint is elsewhere, you have an international transfer in the middle of your architecture, running on every turn, and it is very often not on the diagram. The browser residency question was answered carefully and the inference residency question was never asked.
Three things to establish: where the inference endpoint physically is, who operates it and under whose jurisdiction, and whether prompts are retained and for how long. All three are answerable. The mistake is not looking.
Why agents make this harder than it was
Residency questions are not new. What is new is the number of places the data goes, and it went up sharply with agents in ways that architecture diagrams have not caught up with.
A traditional application has a small number of data locations and they are all deliberate: a database, a cache, an object store, some logs. Each was chosen, each is on the diagram, and each has an owner who could tell you where it is.
An agent driving a browser adds four more, and only one of them tends to be deliberate:
The pages themselves. Whatever the browser loads is processed on the machine running the browser. That machine has a location and an operator, and if the page is a customer's finance portal then the content is theirs, not yours.
The page representation sent for inference. Covered above. This is the big one and it recurs every turn.
The replay. A recording of an authenticated session is a copy of everything that was on that screen. It is enormously useful for debugging and it is a second store of the same sensitive content, usually with a different retention policy and often in a different system.
The traces. Agent frameworks emit structured traces of reasoning and tool calls, and these are routinely shipped to a third-party observability platform. The tool call arguments frequently contain extracted values, which means the trace store holds the data too. This is the one that surprises people, because the observability vendor was adopted as infrastructure rather than evaluated as a processor.
Four new locations, of which one was a decision and three were consequences. The exercise worth doing, before a review does it for you, is drawing the actual flow of a single agent run and marking the jurisdiction of every box. It takes an hour and it is usually the most informative hour anyone spends on this.
What a good answer looks like
Not our answer specifically — the shape of one, so you can recognise it.
| Question | A weak answer | A strong answer |
|---|---|---|
| Compute location | "EU region available" | Named facility and operator |
| Stores | "Data stored in the EU" | Enumerated, each with a retention period |
| Keys | "Encrypted at rest" | Where the key lives, who can use it |
| Sub-processors | "Available on request" | A published, dated list with locations |
| Operational access | "Role-based access control" | Which staff, which country, logged how |
| Legal jurisdiction | "GDPR compliant" | Where the company is incorporated |
| Inference | Not mentioned | Endpoint, operator, retention |
The pattern: a strong answer is specific and falsifiable, a weak one is a category. "GDPR compliant" in the jurisdiction row is the clearest tell, because GDPR compliance is not a jurisdiction and the substitution is usually not accidental.
Where we sit, plainly
It would be strange to publish this and be vague about our own answers, so:
Sessions run on our own hardware in the EU. There is no region dropdown because there is nowhere else for the data to go. The operating company is a German GmbH, which settles the sixth question rather than deferring it. Session replays carry a hard retention limit measured in days, because data you never keep is data that cannot be disclosed. Profiles and credentials are encrypted with per-tenant keys under a root key held in a European key management service, not on the machine that runs the browsers. The sub-processor list is published. The detail is on the EU data residency page.
Two things we will not claim. Sessions run in hardened containers with user-namespace remapping, dropped capabilities, seccomp and default-drop networking — that is strong isolation, and it is not kernel-level isolation, and we would rather say so than let a reader assume otherwise. And on question seven: today you bring your own model keys, which means the inference routing decision is yours and not ours. An EU-routed inference gateway is on the roadmap and is not shipped, and we would rather you knew exactly where your prompts go than assumed we had handled it.
A questionnaire you can send
If you are the one evaluating rather than the one being evaluated, these are the questions in a form a vendor can answer, ordered so that the cheap ones come first and the answers to the early ones inform the later ones.
- In which datacentre, operated by which company, do browser sessions execute?
- List every store that holds customer data or artefacts, with its location and its retention period.
- Where is the encryption key material held, and can you decrypt customer data without our involvement?
- Provide the current sub-processor list with locations and the date it was last updated.
- Which staff can access customer session data, from which countries, and how is that access logged?
- In which country is the contracting entity incorporated, and which parent companies exist above it?
- Where does model inference occur, who operates that endpoint, and what is the prompt retention policy?
- What isolation exists between tenants, stated precisely rather than by category?
- On termination, what is deleted, when, and how is that evidenced?
Question eight is worth asking in exactly those words. "Isolated" is a word every vendor will use, and the precise answer — shared kernel with container hardening, versus separate virtual machines, versus separate hardware — is a meaningful difference that the word alone conceals. A vendor that answers precisely, including where the answer is less impressive than the alternative, is generally a vendor whose other answers you can trust.
Question nine is the one nobody asks and everybody eventually needs.
Three practical notes
GDPR does not require EU residency. It regulates transfers rather than mandating location, and lawful transfer mechanisms exist and are widely used. Residency is a way of making the transfer question disappear, which is a commercial convenience rather than a legal requirement. Anyone telling you the law requires it is overstating.
Certifications are not answers to these questions. ISO 27001 tells you a management system exists. It does not tell you where the data is, who can compel it, or where inference happens. A review that stops at the certificate has stopped early, and a vendor that leads with certificates in response to a jurisdiction question is redirecting.
Ask about retention first. Of the seven, it is the cheapest for a vendor to answer honestly and the most revealing. A provider that has thought carefully about deleting things has usually thought carefully about the rest. One that keeps everything indefinitely and has not considered why is telling you how the other six will go.
The short version
Residency answers where. Sovereignty answers who. Most questionnaires ask the first and mean the second, and most vendor answers exploit the gap.
For agents specifically, add the seventh question and ask it early, because the page content going to a model is a data flow that most architecture diagrams do not draw and most reviews eventually find.