Data Residency: Keeping Inference in the EU
5 min read · updated August 3, 2026
“Our data stays in the EU” is four different promises wearing one sentence. They are independently true or false, they are usually delivered by different parts of a system, and only one of them is what most buyers actually care about.
Treat this as engineering guidance rather than legal advice. Residency is a technical property; whether a given residency arrangement discharges a legal obligation is a separate question with a different expert attached to it.
Four residencies, sold as one
| Guarantee | Description |
|---|---|
| Storage residency | Data at rest sits on disks in a stated region. The easiest to promise, the easiest to verify, and — for stateless inference — often the least relevant, because ideally nothing is at rest at all. |
| Processing residency | The computation itself happens on hardware in the region. For inference this is the one that matters: the prompt is in memory on a GPU somewhere, and that somewhere has a jurisdiction. |
| Control-plane residency | Where the metadata lives: account records, usage counters, audit logs, request identifiers, billing. Very often a different region from the data plane, and very often not mentioned. |
| Access residency | Where the humans are who can reach production. Support, on-call engineers, and the vendor's own operations staff. Remote access from a third country is a transfer even when every disk stays put. |
A vendor can hold the first honestly while the third and fourth sit elsewhere entirely, and no one has lied. Ask about all four separately, in those words.
What residency means for an inference call
Inference is unusual because the interesting copy is transient. Your prompt is transmitted, held in memory, expanded into activations, possibly cached as key-value state for the duration of the request, and then — under a zero-retention arrangement — never written down at all. There is no disk to point at. The residency question is therefore about where the accelerator physically is, and about the path taken to reach it.
Two mechanisms routinely defeat an assumed answer. The first is overflow: a region under load can fail over to capacity elsewhere unless the contract and the configuration forbid it, and a failover that improves your availability can quietly change your jurisdiction. The second is brokering — if the party you contract with does not own the hardware, residency is a property of somebody you have no agreement with, and the guarantee is only as good as the flow-down.
Ask specifically: what happens to a request when the stated region has no capacity? A vendor that answers “it fails” is offering you a real residency guarantee with a real availability cost. A vendor that answers “it is served elsewhere” is offering something else, which may still be fine — but you should know which one you bought.
What it does not give you
- It is not immunity from foreign legal process. Jurisdiction can follow the corporate entity as well as the hardware. Where a provider is subject to another country’s law, storing bytes in an EU region does not by itself settle what that law can compel. This is exactly the sort of question to put to counsel rather than to an architecture diagram.
- It is not a lawful basis. Keeping data in-region does not make processing lawful; it addresses one specific class of obligation, and the rest of the analysis is unchanged.
- It says nothing about retention. In-region data kept forever is still kept forever. Residency and retention are orthogonal and are frequently conflated in the same sentence of the same brochure.
- It says nothing about who reads it. An in-region prompt reviewed by staff on another continent is an in-region prompt that left. See access residency, above.
How to verify rather than believe
Some of this is verifiable from your own side, which is worth doing before the questionnaire goes out:
- Resolve the endpoint. Look at where the hostname actually points and whether it is fronted by an anycast network. An anycast edge is not a violation of anything, but it means the first hop terminates somewhere you did not choose, so ask where TLS terminates and what that node sees.
- Ask for the region in the response. Some APIs return a serving region or a request identifier that encodes one. If yours does, log it — it turns residency from a claim into a field you can audit.
- Read the sub-processor list for regions, not just names. A list without locations does not answer the question you are asking it.
- Get the failover behaviour in the contract. If the only guarantee is on a status page, it is a description rather than a commitment.
What it costs you to insist
Residency is not free and pretending otherwise leads to a bad negotiation. Fewer regions means fewer providers, which means a smaller model catalogue, later access to new releases, less capacity during a spike, and usually a higher price per token. It also removes a failover option, so your availability target and your residency target are in direct tension and someone has to decide which wins.
Decide it explicitly, per workload rather than globally. A great deal of traffic in a typical product carries no personal data at all — classification of public documents, code assistance on your own repository, internal tooling — and constraining that traffic buys nothing. Segment first, then apply the expensive guarantee to the segment that needs it.