Regional AI endpoints do not keep all data in the EU: establish the route per processing step

No. OpenAI, Google Cloud, Anthropic and Microsoft document that a regional or EU endpoint mainly binds storage and model processing, while routing, authentication, analytics, document extraction and operational metadata can run outside that region. So establish separately, per processing step, where data ends up; a regional endpoint name is no proof of complete data localisation.

The immediate trigger is current documentation from OpenAI about data residency and inference residency for ChatGPT. In it, OpenAI explicitly distinguishes between inference residency — the GPU execution of customer content in a chosen region — and other processing. Authentication, request routing, analytics and CPU tasks such as document extraction and coordination can, according to OpenAI, take place outside that chosen region. A regional inference therefore says nothing about where the rest of the chain runs, and so AI data residency differs per processing step.

What exactly do OpenAI, Google Cloud, Anthropic and Microsoft state about regional and global endpoints?

All four providers describe in their own documentation that the geographical outcome depends on the chosen endpoint and on separate processing flows, not on the product name. The common thread is that the geographical outcome must be checked per provider, endpoint and processing flow. Regional endpoints can bound storage and model processing, but the precise scope of supporting and operational flows differs per service.

• OpenAI places GPU inference of in-scope content in the chosen region, but does not rule out CPU processing, routing, authentication and analytics outside that region.
• Google Cloud states in its documentation about data residency for the Gemini Enterprise Agent Platform that requests to a global endpoint can be processed in any Google Cloud location and therefore offer no data localisation guarantee. Jurisdictional multi-region and locational endpoints do limit ML processing to the chosen jurisdiction or region.
• Anthropic describes regional compliance as a choice between global endpoints, which route requests dynamically to available capacity, and regional endpoints, of which Anthropic states that storage and model processing stay within the chosen region, with availability in Europe, the United States and Asia-Pacific among others.
• Microsoft notes in its EU Data Boundary change log that OpenAI-operated models within Microsoft Generative AI Services, as a subprocessor, can process and store pseudonymised user IDs in the United States for troubleshooting, debugging and security, even in the context of services covered by the EU Data Boundary.

As a technical illustration of the same principle, OpenRouter describes US in-region routing, in which requests within the United States are routed to American provider endpoints; the source additionally refers to a previously offered EU routing option. This shows that routing can be enforced geographically, but also that provider routing and inference remain separate control points.

Which processing steps must I check geographically on their own?

Our analysis of the documentation mentioned leads to a practical control framework of at least five points that you can check separately; the sources do not jointly state that this is an exhaustive or universal minimum set. In this way, AI data residency per processing step becomes visible.

1. Decryption: where is the encrypted request decrypted into readable content?
2. Pre-processing: where do prompt and document processing take place, such as CPU-based document extraction?
3. Inference: where does the GPU execution of the model run?
4. Logs and metadata: where are logs, analytics and operational identifiers processed and retained?
5. Subprocessors and fallback: which subcontractors get access, and where does traffic go if the primary region has no capacity?

In our assessment, an EU or regional endpoint name does not straightforwardly say which of these five points is bound. The precise scope must be established per provider, product and endpoint documentation.

What does this mean for directors, lawyers and CISOs who process sensitive data?

Our analysis: because OpenAI documents that CPU tasks and routing can run outside the inference region, an EU endpoint in our assessment effectively delivers no complete data localisation for organisations with special or confidential data without additional verification; our analysis is therefore that the controller must record the data flow per step before an AI service goes into production, not afterwards. Because Google Cloud expressly provides a global endpoint without a localisation guarantee, an organisation that is unknowingly on the global endpoint runs, in our analysis, an invisible transfer risk; therefore the endpoint choice belongs, in our assessment, as an explicit, documented configuration in the procurement and architecture decision, with the regional variant as the starting point for sensitive processing. Because Microsoft notes that pseudonymised user IDs within an EU Data Boundary can nonetheless be processed in the US, a reassuring product name does not, in our assessment, suffice as substantiation in a processing register or DPIA; therefore the lawyer must, in our assessment, request the subprocessor list and the operational flows and assess them as a basis for transfer. Because Anthropic offers global routing as a separate mode alongside regional endpoints, it is, in our analysis, a control point in its own right to record which routing and fallback behaviour applies to the chosen endpoint; therefore the CISO records, in our assessment, in the contract what happens on a capacity shortage and whether diversion to another region is permitted. This touches, in our analysis, on privacy by design as a lifecycle duty under GDPR Article 25 and on broader GDPR questions around AI privacy and GDPR in professional practice.

Which questions should I put to my AI provider to verify the route?

Ask per endpoint and per region for a routing matrix rather than a general residency statement. The providers' documentation shows that only a step-by-step breakdown has meaning; the same logic applies when you want to do your own checking data flows at AI chat services or test the GDPR requirements for generative AI workflows.

• Which endpoint do we actually use — global, jurisdictional multi-region or locational — and how is that enforced?
• Where is our request decrypted and where does the CPU pre-processing run, including document extraction?
• Where are logs, analytics and operational metadata processed, and for how long retained?
• Which subprocessors get access and in which countries, and does that also apply to pseudonymised identifiers?
• What is the fallback behaviour on a capacity shortage, and can we contractually exclude diversion to another region?

Without an answer to these points, a residency assumption rests, in our assessment, on a name, not on evidence. That is the concrete difference that our analysis of the recent documentation from these providers makes visible: a regional or in-region routing choice does not by itself establish the location of every processing step.

Sources: The article relies on official documentation from OpenAI, Google Cloud, Anthropic and Microsoft and on product documentation from OpenRouter about regional and global routing.