Does AI Data Residency Keep Your Data in Europe?

Most agent setups process data outside the EU by default, and nothing in the interface says so. Microsoft's recommended deployment type may process prompts in any Azure region. Google's documentation tells you not to use its global endpoint if you have processing requirements, because you cannot know which region the request went to. OpenAI charges a 10% premium for regional processing and gates it behind sales approval. None of this is hidden — it is written in the documentation, and this is what it says.

A client asks where their data goes. You open your provider's privacy page, find the word "Europe", and send a reassuring reply. That reply is often wrong — not because the provider lied, but because the page you read was about storage and the question was about processing.

In a typical agent setup, the default processing location is not Europe. It is unspecified. Microsoft recommends a deployment type that may process prompts in any Azure region. Google tells you in its own documentation not to use the global endpoint if the location matters. OpenAI will process in a chosen region, for a 10% premium, once sales approves you.

Every one of those is a documented setting rather than a scandal. But each one is off by default, and none of them appears in the interface where you connect the agent.

Where does an AI agent's data actually get processed?

In two places, decided by two different people.

Layer one is the agent itself — the software that holds your message history, your credentials, and the connection to your Gmail or CRM. If the system is self-hosted, this runs on a server you rent and control, and its country is a choice you make when you provision it. OpenClaw works this way: the gateway, the connected tools, and the business data stay on your own server.

Layer two is the model call. Every time the agent needs to draft, summarise or classify, it sends text to a model provider. That request leaves your server. Where it lands is governed by the provider's settings, not yours — unless you configure them.

Most articles about AI and data protection only discuss layer two, because most vendors run layer one themselves and would rather not draw the distinction. Most compliance guidance only discusses layer one, because that is where the contracts sit. The gap between them is where the actual answer lives.

Why "stored in Europe" and "processed in Europe" are different promises

Storage is where data sits when nothing is happening to it. Processing is where the computation runs. Providers keep these apart deliberately, because they are engineered differently — storage is pinned to a datacentre, while inference capacity is scarce and gets balanced across whatever hardware is free.

Google's documentation is the clearest on the split. It separates "data at rest" from "ML processing", and states that data stored at rest in the customer-selected location stays there "independent of the … endpoint called by that customer's request." The endpoint decides the processing; the storage setting decides the storage. Two dials.

Then it adds the sentence that should end most of these conversations:

Endpoints don't guarantee data residency or in-region ML processing.

And, on the global endpoint specifically:

Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made.

That is a vendor telling you, in its own manual, that the convenient default is unknowable. It is the most useful sentence in this entire topic, and almost nobody quotes it.

What each provider does by default

The pattern repeats across the largest providers: broad geography by default, EU processing on request. The differences are in what the opt-in is called and what it costs.

Three details in that table deserve to be pulled out, because they are the ones that change decisions.

Microsoft recommends the unconstrained option. Its documentation says: "For most workloads, start with Global Standard." Global Standard is the deployment type that may process in any Azure region. This is sound engineering advice — it has the newest models, the lowest price and the broadest region coverage. It is also the reason a business that never made a deliberate choice is processing outside the EU right now.

OpenAI's EU processing has a price. Data residency endpoints "are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." It is also not self-serve: you contact sales for eligibility, and any non-US region additionally requires approval for abuse-monitoring controls and a Modified Retention amendment.

Storage and processing are separately eligible at OpenAI too. Selecting a region gets your content stored at rest there. Inference follows only "if you select a region that supports regional processing, as specifically identified below." And if your region does not support it, OpenAI "may also process and temporarily store Customer Content outside of the Region."

Which "Europe" does your provider mean?

Providers do not agree on which countries "the EU" contains, and the disagreement is not small. Two of them draw the boundary in ways that give a Swiss business opposite answers.

Two providers can both promise to keep your data "in the EU" and mean different countries. One includes Switzerland. The other explicitly excludes Zurich.

For most businesses this is academic. For a Swiss firm, an Austrian firm with Swiss clients, or anyone whose contract names specific countries rather than "the EU", it is the whole question. Microsoft's boundary may sweep in Switzerland; Amazon's routing rules deliberately keep Zurich out of the EU destination set and handle it as its own source region instead.

Microsoft also reserves the right to move the line: it "can add regions to either data zone without prior notice to improve capacity and availability." A boundary you verified in March is not necessarily the boundary you have in September.

What leaves the region even when residency is switched on

Turning residency on narrows the flow. It does not close it, and the providers document the gaps.

System data is carved out. OpenAI states that data residency "does not apply to system data", and then defines system data broadly: account data, metadata, usage data, analytics, usage statistics, billing information, support requests — and structured output schemas. That last item is worth a second read. If your agent asks the model to return JSON in a defined shape, the shape itself is system data. The field names in your schema can describe your business in some detail.

Sub-processors sit outside the promise. Mistral's commitment is precise about this: inference and associated processing "take place in the selected region, subject to limited, safeguarded transfers to sub-processors that may occur outside that region." That is an honest sentence, and every provider has some version of it.

Tiers can be exempt. Microsoft's Developer deployment type, for evaluating fine-tuned models, "doesn't include data residency guarantees" at all. It is a narrow tier with a 24-hour lifetime, which is exactly the kind of thing someone uses for a quick test with real data.

Your own users can undo it. OpenAI notes residency does not cover transmission or storage caused by "the location of an End User or Customer's infrastructure when accessing the services." Region-pinned processing does not help if the person using the agent is somewhere else.

None of this makes EU processing pointless. It makes the claim narrower than it sounds: the commitment covers customer content inside the model call, not every byte the service touches. That is still the difference between a documented transfer basis and an unknown one, which is what your GDPR obligations actually turn on.

Which part of this is your decision?

The two layers split cleanly, and confusing them is what makes the topic feel unanswerable.

The first three rows are ordinary infrastructure decisions. A self-hosted gateway runs where you put it, and putting it in Frankfurt rather than Virginia costs nothing extra. This is the part most buyers assume is hard and is in fact easy.

The last three rows are the ones that need reading. They are also the ones that change without you doing anything, which is why they need a review date rather than a decision.

This is a different question from what the agent is allowed to touch in the first place. Permissions decide what it can see; residency decides where what it sees gets processed. A tightly scoped agent processing in an unknown region is still a transfer you cannot document.

How to check where your own setup processes data

Five checks. None needs a developer, and each one has a definite answer.

Find the deployment type, not the region name. In Azure, a resource in "West Europe" running a Global Standard deployment is a West Europe resource processing anywhere. The region in the resource name is not the answer; the SKU is. Ask which deployment type is in use and whether it starts with Global or DataZone.

Check the API base URL. For OpenAI, an unprefixed api.openai.com call carries no processing constraint. eu.api.openai.com does. This is a single line in a configuration file and it is the whole difference.

Ask which endpoint, for Google. The global endpoint and aiplatform.eu.rep.googleapis.com are different strings in the same config. Only one of them constrains processing.

Ask which inference profile, for Bedrock. A geographic EU profile keeps routing inside EU regions. A global profile does not. If your business is in Zurich or London, ask specifically how those are treated, because they are not EU destinations under the EU profile.

Get the transfer basis in writing, not the marketing page. If any part of the path leaves the EEA, there has to be a documented mechanism — an adequacy decision, standard contractual clauses, or a derogation. Anthropic, for example, names adequacy decisions and standard contractual clauses in its privacy policy and identifies Anthropic Ireland as the controller for European users. Where a US provider claims an adequacy decision, the check is whether they appear on the official EU–US Data Privacy Framework participant list at dataprivacyframework.gov. Look them up rather than taking the claim.

Run those five and you can answer a client's question with a sentence that survives follow-up. That is a materially different position from "our provider says Europe."

What this does not tell you

This page reports what provider documentation said on 24 August 2026. It is not legal advice, and it does not certify any provider as GDPR-compliant — that assessment depends on your data, your purposes and your contracts, and belongs with a qualified data protection professional.

Three specific limits worth naming. Provider region policies change, sometimes explicitly without notice, so every row here has a retrieval date and should be re-verified before you rely on it. Certification status under the EU–US Data Privacy Framework is not stated for any provider here, because the official list is the only authoritative source and you should read it directly. And knowing where processing happens tells you nothing about whether the provider trains on what you send — that is a separate question with separate answers per plan.

The useful outcome is narrower than certainty and more useful than reassurance: you can name where each leg of the path runs, and you can show why.

Frequently asked questions

Where is my data stored when I use an AI agent? In two different places, decided separately. The agent's own working data — message history, credentials, connected files — sits wherever the agent software runs, which is your server if the system is self-hosted. The prompts sent to the model go wherever that provider processes them, which is a separate setting under the provider's control. Answering the question for your business means answering it twice, once for each layer.

Does AI data stay in the EU? Not by default at most large providers. Microsoft's Global deployment types may process inferencing data in any Azure region, and Microsoft recommends Global Standard as the starting point for most workloads. Google's documentation states plainly that endpoints do not guarantee data residency or in-region ML processing. EU processing is available at both, and at OpenAI, AWS and Mistral, but it is an option you select rather than the state you start in.

What is the difference between data residency and data processing location? Data residency usually refers to where data is stored at rest. Processing location is where the model computation happens. They are separate commitments and they are frequently confused. Microsoft's documentation states that data stored at rest remains in the designated Azure geography while inferencing data under a Global deployment may be processed in any Azure region. Both statements are true at the same time, which is why reading only the first one is misleading.

Does using an EU region mean my data never leaves the EU? No, and providers say so. OpenAI states that data residency does not apply to system data, which includes account data, metadata, usage statistics, billing information, support requests and structured output schemas. Mistral commits that inference takes place in the selected region subject to limited, safeguarded transfers to sub-processors that may occur outside that region. The commitment covers customer content in the model call, not everything the service touches.

Which countries count as the EU for an AI provider? It depends on the provider, and they do not agree. Microsoft's EU Data Boundary can include European Free Trade Association countries such as Norway and Switzerland in addition to EU member states. Amazon's EU cross-Region inference does the opposite: requests from EU source regions cannot be routed to non-EU regions, and Zurich and London are explicitly not treated as EU destinations. Same word, different map.

Notes

All provider documentation retrieved 24 August 2026.

1. Microsoft Learn, Understanding deployment types in Microsoft Foundry Models. Document date 6 August 2026, updated 12 August 2026. Source for the at-rest versus inferencing split, Global and Data Zone behaviour, the EU Data Boundary and EFTA inclusion, the "without prior notice" clause, and the Developer tier exemption.
2. Google Cloud, Deployments and endpoints, Generative AI. Source for "Endpoints don't guarantee data residency or in-region ML processing", the global-endpoint warning, and the EU multi-region hostname.
3. Google Cloud, Data residency. Source for the data-at-rest versus ML-processing definitions.
4. OpenAI, Your data. Source for the 10% uplift, the regional-processing condition, the system-data carve-out, and the eligibility requirements.
5. AWS Machine Learning Blog, Unlocking AI flexibility in Europe: a guide to cross-Region inference for EU data processing and model access. Source for EU CRIS routing rules and the treatment of Zurich and London.
6. Anthropic, Privacy Policy. Source for Anthropic Ireland as European controller and the adequacy-decision and standard-contractual-clause transfer mechanisms.
7. Anthropic, Models overview. Source for global versus regional endpoint availability on Bedrock and Google Cloud.
8. Mistral AI, Regional inference, open models, and new compute, 11 August 2026. Source for regional endpoints and the sub-processor transfer caveat.
9. European Commission, EU–US Data Privacy Framework participant list. Cited as the reader's own check; no provider's certification status is asserted in this article.