Regional AI endpoints do not keep all data in the EU

You must establish where data flows at each processing step within an AI service, because a regional endpoint name does not guarantee that all handling stays within that region. Document the routing, authentication, and supporting operations separately from model inference, then verify each against your provider's actual configuration.

The prompt is an analysis of 12 October 2026 of data residency routing across processing steps in regional AI endpoints, which argues that regional or EU endpoints bind storage and model processing whilst routing, authentication, analytics and operational tasks can run outside the chosen region. The analysis draws on current documentation from OpenAI, Google Cloud, Anthropic and Microsoft showing that inference residency and data residency differ per processing step. In our assessment, this means you cannot rely on an endpoint name or region label to establish compliance with data localisation requirements; you must instead map the actual data flow per provider, product and processing stage before deployment.

What does a regional endpoint actually guarantee?

A regional AI endpoint typically binds two things: the storage of your data and the execution of the model itself on GPUs within that region. The documentation from the four major providers shows that this does not extend to the full processing chain. Authentication, request routing, analytics, document extraction and operational metadata can, according to their own technical documentation, run outside the chosen region. This means the endpoint name alone tells you nothing about where supporting operations occur. You need to treat each processing step as a separate control point and verify its location independently.

Which processing steps must you check separately?

• Inference execution — the GPU processing of your prompts and model outputs within the chosen region.
• Request routing — the path your request takes from client to endpoint, which may traverse infrastructure outside the region.
• Authentication and access control — verification of your identity and permissions, which may be handled by systems outside the region.
• Operational metadata and analytics — logs, performance data and usage metrics collected during the interaction.
• Supporting CPU tasks — document extraction, text processing and coordination functions that support but do not constitute model inference.

What controls must you document before going live?

1. Map the data flow per endpoint — for each regional endpoint you plan to use, obtain from your provider a diagram or matrix showing which processing steps run in which region.
2. Record the routing and fallback behaviour — document whether requests can be diverted to another region on capacity shortage, and whether that diversion is permitted under your data protection obligations.
3. Verify the subprocessor list — request the list of any third parties who handle data at each step, and confirm their locations match your requirements.
4. Establish the configuration as a procurement decision — make the regional endpoint choice an explicit, documented requirement in your contract and architecture review, not a default assumption.
5. Update your processing register and data protection impact assessment — record the actual data flows, not the product name, as the basis for your transfer risk assessment under GDPR.

Why does the provider's documentation matter more than the product name?

Google Cloud offers a global endpoint without a localisation guarantee. Microsoft notes that pseudonymised user IDs within an EU Data Boundary can nonetheless be processed in the United States. Anthropic offers global routing as a separate mode alongside regional endpoints. OpenAI explicitly distinguishes between inference residency and other processing. Each provider's documentation reveals control points that a product name alone would obscure. A reassuring label does not suffice as substantiation in a processing register or data protection impact assessment. The lawyer and the information security lead must each request the operational flows and assess them as a basis for any transfer risk analysis.

How should you verify this yourself?

Ask your provider for a routing matrix per endpoint and per region rather than a general residency statement. Request the subprocessor list and the operational flows. Map the data flow at each processing step before the AI service goes into production, not afterwards. Treat the regional endpoint choice as a control point in its own right, to be recorded in the contract and reviewed as part of privacy by design under GDPR Article 25. Without an answer to these points, a residency assumption rests on a name, not on evidence.

Tooling can help you document and track these flows, but the assessment of whether each step meets your data protection obligations remains your own professional judgement. No automated check can substitute for your reading of the provider's documentation against your own regulatory and business requirements.