Data residency & sovereignty.
A region toggle in a provider console answers one question — where the computation ran — and your legal team is asking four. Residency is geography; sovereignty is jurisdiction, and a US-incorporated parent company remains subject to US legal process regardless of which datacentre served the request. For an agent the gap widens further, because the thing that leaves your boundary is not the user's question but the whole assembled context, plus a second copy of it in your traces.
Four questions, one of which the region picker answers.
- Where is it processed? The datacentre that runs inference. This is what "EU region" usually means, and it is the easiest to satisfy and the easiest to over-read.
- Where is it stored, and for how long? Processing and retention are separate settings with separate defaults. Providers commonly retain API traffic for a limited abuse-monitoring window even when they do not train on it, and that window is a different question from the region.
- Who can compel access? The jurisdiction of the operating company and its parent, not of the building. This is the sovereignty question, and it is why a European region operated by a US-incorporated provider does not close the extraterritorial-access gap that European buyers are usually asking about.
- Who else touches it? The sub-processors: the model provider's own cloud host, your observability vendor, your vector database, every third-party tool the agent calls. Each is a boundary crossing you are accountable for and may not have listed.
Sovereign-cloud offerings from the major clouds are a real narrowing of the gap — separate legal entities, local staff, local operational control — and they are also the reason the distinction matters. They exist precisely because the region flag was never sufficient. Read what any given offering commits to on the third question specifically; that is where they differ most and market where they differ least.
The retention dial usually matters more than the map.
Three commitments get conflated in procurement conversations, and they are independent. "We do not train on your data" is the weakest and now close to universal on commercial API tiers. "We retain it for a bounded period for abuse monitoring" is the common default, and it is a retention commitment, not a training one. "We retain nothing beyond the life of the request" — zero data retention — is the strongest, and in practice it typically requires a negotiated enterprise agreement rather than a checkbox on a self-serve plan.
- Ask for the trio explicitly. Training use, retention window, and access-under-legal-process, answered separately and in writing. A vendor page saying "your data is private" answers none of them.
- Check the scope of the commitment. Zero-retention agreements often cover the core API and not every surface, feature or beta the same vendor ships. The scope clause is where the exceptions live.
- Remember it cuts both ways. No retention means no server-side logs to appeal to when you are debugging a bad response or investigating an incident. You have to keep your own — which relocates the data rather than eliminating it.
- Consumer plans are not enterprise plans. The same brand can have entirely different training and retention defaults across its chat product and its API. The one your staff pastes documents into may not be the one you negotiated.
An agent leaks along more edges than a chatbot.
A single model call sends one prompt. An agent sends an accumulating transcript, and everything a tool pulls in becomes part of it — permanently, for the rest of that run. This changes the shape of the compliance problem rather than its size.
- Retrieved content crosses the boundary too. Documents that live safely inside your region are transmitted to the model the moment retrieval puts them in the context. Where the vector store sits is not where the data goes; see local knowledge bases for which dials are actually independent.
- Traces are a full second copy. Good observability records the prompt as actually sent — which means your tracing vendor now holds every document, every tool result and every customer identifier your agent ever saw. This is the residency violation teams find last, and it is often the largest one.
- Third-party tool servers are undeclared sub-processors. Every remote MCP server or external API the agent calls receives whatever the agent sends it, under that vendor's terms and jurisdiction, with no entry in your data map unless you put one there.
- Sub-agents inherit nothing automatically. In a multi-agent system each agent may be configured with a different model, region or provider. The strictest constraint has to be enforced at every node, and it is not.
- Memory persists past the session. Anything written to long-term agent memory becomes stored personal data with a retention obligation and a deletion requirement, in a store that was probably designed with neither in mind.
The ladder, and what each rung costs.
There are only about four postures, and they trade capability for control in a predictable order. Pick the highest rung your actual obligation requires, not the highest rung available.
- Commercial API with contractual terms. Frontier capability, a data processing agreement, region selection where offered. Sufficient for a large majority of workloads and the honest default.
- Regional deployment via a cloud catalogue. The same or near-same models served inside a cloud region you already have a compliance posture for. Buys jurisdictional clarity on storage; frequently lags on model availability and newest versions.
- Sovereign or locally-operated deployment. A separately-incorporated operator with local staff and local control. Narrows the compelled-access gap materially; costs money, model choice and release velocity.
- Self-hosted open-weight models on your own hardware. The only option where no third party sees the data at all. You give up frontier capability and take on serving, scaling and evaluation — see open-weight vs closed models.
A fifth move often beats climbing the ladder: send less. Redact identifiers before the call, keep the sensitive join server-side, use a local model for the extraction step and a hosted one for the reasoning. A hybrid split usually delivers the compliance outcome at a fraction of the capability cost.
Before choosing a rung, write the data flow down for one real request — every hop, every vendor, every store, including the trace, the vector database and every third-party tool the agent can call. Then answer all four questions for each hop. Nearly every team that does this finds the leak somewhere other than the model endpoint they were about to spend six weeks relocating: it is in the observability pipeline, the third-party tool, or the memory store. Fix the data map first; the region decision is easy once it is accurate.
Related: serving & access for the deployment options, data governance for the operational controls, and the regulatory landscape for the obligations driving all of this.