Storage residency is not processing residency
Most EU data residency claims describe where data sits at rest, not where the model runs. OpenAI's own documentation separates the two. The distinction decides whether a transfer happened, and it is the question procurement should be asking.
Storage residency describes where data sits when nothing is happening to it. Processing residency describes where computation happens, where the model actually runs. Most vendor claims about “EU data residency” mean the first and are read by the buyer as the second.
This is not a semantic quibble. Under the GDPR, sending personal data to a third country for processing is a transfer whether or not it comes back and whether or not anything is stored there. This article separates the two concepts, shows how the major providers describe them in their own words, and sets out the four questions that settle it.
The two things being confused
Storage residency is a statement about data at rest: the database, the object store, the backups. “Your files are stored in Frankfurt” is a storage claim.
Processing residency is a statement about compute: where the request is executed, which for a language model means where the GPUs are. “Your prompt is processed in Frankfurt” is a processing claim.
A system can hold either without the other. Data can rest in the EU and be shipped to Virginia for every inference call. It can also be processed entirely in the EU while backups land elsewhere. The claims are independent, which is why hearing one and assuming both is the most common error in AI procurement.
The reason the distinction has teeth is legal rather than technical. Chapter V of the GDPR governs transfers of personal data to third countries, and processing in a third country is a transfer. Nothing has to be kept there for the obligation to attach. A round trip that leaves no trace is still a round trip.
The providers say this themselves
The clearest evidence is not in a critique of the industry. It is in the industry’s own documentation.
OpenAI’s help centre keeps two separate terms with two separate definitions: data residency controls where in-scope customer content is stored at rest (chat history, files, configurations) while inference residency controls where model inference runs on GPUs. Two settings, two commitments, described distinctly (Data residency and inference residency for ChatGPT).
OpenAI’s own documentation defines data residency as storage at rest and inference residency as where the model executes, as two different controls.
OpenAI Help Center, checked 7 October 2026
On the API side, OpenAI introduced European data residency in 2025 and its data controls documentation lists ten residency regions with two columns for each one, regional storage and regional processing. Only three carry a yes in both, the United States, Europe (EEA plus Switzerland) and the United Arab Emirates. The other seven store in-region and let the model run elsewhere, and even inside Europe the commitment runs per supported endpoint rather than per account, which means an application calling four different APIs can be in-region on three of them and not on the fourth without anyone noticing.
Microsoft’s position is the most explicitly documented of the large providers. The EU Data Boundary is a published commitment to “store and process Customer Data and personal data” inside the EU and EFTA, not merely to store it, and a model in Microsoft Foundry, the platform that absorbed the Azure OpenAI Service at the start of 2026, can be pinned to a Data Zone Standard deployment that processes prompts and responses only within that boundary. Since 15 January 2026 there is a second route with the same kind of paperwork behind it, the AWS European Sovereign Cloud, whose first region sits in Brandenburg and which AWS says is operated exclusively by EU residents. Those two are where a hard in-region processing requirement currently lands, a point that also shows up in our comparison of the model providers on EU residency.
Why “we’re GDPR compliant” answers a different question
GDPR compliance and EU residency are not the same claim, and a vendor can hold the first while processing everything in the United States.
The mechanism is the EU-US Data Privacy Framework. The Commission adopted its adequacy decision on 10 July 2023 (Implementing Decision (EU) 2023/1795), and more than 3,600 organisations hold an active EU-US certification. Under it, transfers to a certified US recipient are lawful without further safeguards. So “we transfer to the US and we are compliant” can be perfectly true.
What makes this worth watching rather than filing away is that the framework is under live challenge. The EU General Court dismissed Philippe Latombe’s action against the adequacy decision on 3 September 2025 (T-553/23), and he appealed to the Court of Justice on 31 October 2025 (C-703/25 P). That appeal is pending.
The adequacy decision remains in force unless the Commission repeals it or the courts annul it, so it can be relied on today. But two previous transfer frameworks, Safe Harbour and Privacy Shield, were struck down at the Court of Justice, and the second time it took companies by surprise. A stack that only works because of an adequacy decision has a single point of failure that is not under your control.
That is the real argument for in-region processing, and it is a continuity argument rather than a legal one. If the mechanism falls, a system already processing in the EU does not care. A system relying on the framework has to be redesigned under time pressure, along with everyone else’s, using the same scarce people.
What to ask, in four questions
Word them so a marketing page cannot answer them.
In which country is content stored at rest, including backups and disaster recovery? Backups are the usual gap. Primary storage in Frankfurt with a replica in another region is a common and rarely volunteered architecture.
In which country is inference executed? Ask for the region, not the continent, and ask whether it holds for every endpoint you call or only some.
Does any part of the request leave the region, including moderation, safety filtering, logging or telemetry? This is where in-region deployments most often leak. The model may run in Sweden while the safety classifier runs elsewhere.
Which sub-processors see content, and where does each of them run? Under Article 28 GDPR they must be named. An answer with no list is the answer.
Put the responses in the data processing agreement rather than in an email. And keep the retention question separate while you are at it, because how long a provider keeps prompts is a third, independent promise that neither storage nor processing residency implies.
When you actually need in-region processing
Not every company does, and pretending otherwise wastes money.
You need it when a regulator, a works council, a public-sector customer or an existing contract requires it, and in those cases it is binary rather than a preference. You also need it when your own customers ask, which in the DACH mid-market they increasingly do at the security-review stage, and where the answer “US, with the Data Privacy Framework” ends deals that a one-line region change would have kept.
You do not need it for data that is not personal data at all, and a surprising share of what companies protect reflexively is not. Anonymised aggregates, product documentation and public information carry no Chapter V obligation.
The point of the distinction is not to force everyone into a European deployment. It is that the decision should be made knowingly. “We assumed EU residency covered it” is the sentence that shows up in a post-incident review.
Frequently asked questions
Does EU data residency mean my data never leaves Europe?
Not automatically. Most residency commitments cover storage at rest. Unless the vendor also commits to in-region processing, the content can still be sent elsewhere to be computed on and returned.
Is processing in the US illegal under GDPR?
No. It is a transfer, which requires a legal basis under Chapter V, usually the EU-US Data Privacy Framework for certified recipients, or standard contractual clauses with a transfer impact assessment. Lawful, but documented, and dependent on a mechanism that is currently under appeal.
Is Schrems II still relevant?
Yes, for transfers not covered by the Data Privacy Framework. The judgment kept standard contractual clauses valid but requires a case-by-case assessment of the destination country’s law and supplementary measures where protection falls short.
Does self-hosting a model solve this?
For residency, yes: you choose the region and nothing leaves it. It moves the work rather than removing it: you now own model updates, availability and security. That is a real trade, not a free win.
How do we check a vendor’s claim rather than take it?
Ask for the region per endpoint in writing, ask specifically about moderation and logging paths, and require the sub-processor list in the DPA with notification on change. If a vendor will commit in a contract to what it says on its website, the claim is real.
Sources: OpenAI on data residency and inference residency and data controls in the OpenAI platform, Microsoft on the EU Data Boundary and Foundry deployment types, EU-U.S. Data Privacy Framework program overview, General Court press release 106/25 on T-553/23, EDPB guidance on the framework, GDPR Article 28.
Strategy Call