Data residency for AI agents: which data sits where, and what to put in the contract

In short. Data residency means the country or region where data is stored. An AI agent produces at least five kinds of data, and they can sit in five different places: the documents you give it, the search index built from them, the prompts and replies sent to a model provider, whatever its tools touch, and the record of each run. Ask about each one separately, then write the answers into the contract.

Residency is where data is stored. Sovereignty is the wider question of who controls the system and whose rules reach it; we wrote about that in what is sovereign AI. A cloud region is a setting in one vendor's console, and it usually covers that vendor's storage and nothing else.

The three get answered as if they were the same thing. A vendor says "we are hosted in the EU", the buyer hears "everything stays in the EU", and the model behind the agent is called somewhere else entirely. Nobody lied. The question was too broad to be useful.

So split the question. Where does each piece of data sit, and who can reach it from where?

The documents you give it. Reports, contracts, tickets, spreadsheets. These are the easiest to locate and the easiest to forget, because a pilot usually starts with somebody uploading a folder.

The search index built from those documents. Most platforms turn your documents into an index so an agent can search them. Building that index usually sends the text to an embedding service, and that service is often a cloud one by default. This is the step that surprises buyers most, so ask about it by name: which service builds the index, where does it run, and can it be one you host.

The prompts and the replies. Every step the agent takes sends text to a model. That text contains whatever the agent is working on. If the model runs at a provider, this is the largest and most continuous flow of your content out of your building, and it is not covered by the vendor's hosting region.

Whatever the tools touch. A tool the agent calls reaches a system, and that system has its own location. A tool that queries a database in one country and writes a summary to a service in another has made a residency decision that no procurement document recorded.

The record of the run, and its copies. What the agent did, plus backups, monitoring and any support access. People find this one last, and it is the one an auditor asks for, so its location matters as much as the documents.

Once the five are separate, the honest answer usually has a shape like this: documents and the record stay here, model calls go there, the index depends on which embedding service is configured, and support access comes from a third place unless it is switched off.

That is a fine answer. It is checkable, and it tells you where to spend your attention. A single sentence covering the whole product ("all data stays in the EU") is not checkable. Ask instead for a small table, one row per item above, with a location and an owner in each row.

Requirements written before the demo cost nothing. The same requirements written after the pilot cost a renegotiation.

• A named location per data type, using the five items above as the rows, not one blanket sentence.
• Which model providers are in use, and what happens when the vendor wants to add one. A new provider is a new location for your prompts.
• Whether the index-building service can be one you host, and what the default is if you do nothing. Defaults decide this in practice.
• Support access: who can reach the running system, from which country, with what approval, and whether the access is recorded.
• Deletion and export: what you get on the way out, in what format, and how long copies survive in backups. Ask for the record of runs by name, not just "our data".
• Notice of change: you want to hear about a new sub-processor or a moved region before it happens, not in a release note.

Keep one question for your own counsel, because it is not a technical one: which law reaches the data once you know where it sits. Location and jurisdiction are related and not the same.

Running the software in your own environment settles several rows at once. The documents you upload, the index built from them and the record of each run sit on infrastructure you chose. You decide the retention. You decide who gets support access, and when. One caveat belongs with the index: building it calls whichever embedding service is configured, so that row stays open until you have checked which service that is.

It does not settle the model row by itself. If the agent calls a model at a provider, prompts and replies go to that provider, wherever the software runs. Self-hosting gives you the choice: point the agent at a model you host, or at a provider you have picked and named. What matters for procurement is that the choice is yours and is written down.

Be careful with any product sentence that promises nothing ever leaves. The useful promise is narrower and it is testable: the software connects to the providers you configure, and a tool you enable reaches whatever you point it at.