EU data residency for LLM APIs requires more than a regional endpoint. Learn how to route GPT-4, Claude, and Gemini traffic through EU infrastructure and stay GDPR compliant.
Your billing address says Berlin. Your API project says us-east-1. GDPR does not care about the billing address.
Most teams building gdpr compliant ai applications treat data residency as a configuration toggle: pick the EU region, check the box, move on. The reality is messier. Each major model provider handles EU residency differently, some do not handle it at all through their direct APIs, and the legal obligations extend far beyond where inference runs. The gateway, the cache, the logging pipeline, and every sub-processor in between all fall under the same regulatory scope.
This guide covers the specific residency options (and gaps) for OpenAI, Anthropic, and Google Gemini, the legal traps that catch teams who think they have solved the problem, and how to build a routing architecture that holds up under the enforcement actions regulators are running right now.
Start with what each provider actually offers, because the defaults will surprise you.
OpenAI introduced European data residency, but it only applies to new API Projects. You create a new Project in the API Platform dashboard and select Europe as the region. Existing Projects cannot be converted. If your production app has been running on an existing Project for months, you are starting over with a new one to get EU processing.
Anthropic is more restrictive. The direct Claude API does not currently offer a customer-selectable, EU-only residency setting. Commercial data may be processed across infrastructure in several regions including Europe, but "may include Europe" is not the same as "guaranteed European processing." The compliant path is to deploy Claude through an EU-scoped AWS Bedrock or Google Vertex AI endpoint.
Gemini follows a similar split. The Gemini Developer API and Google AI Studio are global services rather than EU-pinned infrastructure. Paid API use is covered by Google's processor terms and prompts are not used to improve products, but there is no EU-region pinning. For that, you need Vertex AI regional endpoints.
The pattern: every provider has an EU-compliant path, but none of them make it the default. Each path involves a different configuration, a different endpoint, and sometimes a different billing relationship entirely.
Getting the endpoint right is necessary. It is not sufficient. Three legal mechanisms can break your compliance even after you have pinned inference to Frankfurt.
When you send a prompt through an edge-based AI router, the network routes it to the nearest node for minimum latency. That node could be in Frankfurt, London, New York, or Singapore. You do not know. The network decides based on latency, load, and availability.
For GDPR purposes, every time a request touches infrastructure outside the EU, you have a cross-border data transfer. Article 44 requires a documented legal basis for that transfer. If you cannot tell which country processed your request, you cannot satisfy this requirement. Edge-based AI proxies optimized for latency are, by design, the opposite of what compliance requires.
Some unified API vendors cache prompts and responses to reduce latency and costs. That creates a second problem. A caching unified API stores copies of EU customer payloads on its own disks, typically for 30 to 60 days. This makes the vendor an unauthorized sub-processor, violates data minimization, and expands your SOC 2 audit scope with retention windows you have to justify.
Even if you pin everything to EU infrastructure, who controls that infrastructure matters. The US CLOUD Act of 2018 requires any US-incorporated company to produce data in its possession upon receiving a valid US government demand, regardless of where the data is physically stored. Data in Frankfurt, at a US company, is still legally accessible to US authorities.
This directly contradicts GDPR Article 48, which states that foreign authorities require an international agreement to access EU data. The CLOUD Act shifts jurisdiction from where the data sits to who controls it. If your AI gateway is operated by a US-incorporated company, you inherit this conflict regardless of server location.
Theory aside, here is what this looks like when it breaks in production.
In March 2026, Microsoft activated "Flex Routing" by default for all new Microsoft 365 tenants. AI requests via Microsoft 365 Copilot could now be routed to the US, Canada, or Australia, without active administrator consent.
The problem compounded. Since January 2026, Microsoft uses Anthropic as a subprocessor for Microsoft 365 Copilot. Microsoft's own documentation states that Anthropic models are "out of scope for the EU Data Boundary." When Copilot uses Claude for processing, EU data leaves the EU regardless of Flex Routing settings.
Two vendor decisions, made months apart, combined to break EU data compliance for organizations that had not reviewed their subprocessor agreements since signing the original contract. No configuration change on the customer side triggered it. The vendor changed the defaults post-contract.
Enforcement has moved from theoretical to operational.
The March 2026 EDPB Coordinated Enforcement Action involved twenty-five Data Protection Authorities across Europe. They asked organizations a focused question: can you document what personal data your AI agents processed, in which sessions, on what legal basis, and with what protections? Most teams running AI agents could not answer.
On top of GDPR, the EU AI Act's full enforcement begins on August 2, 2026. Article 12 requires automatic event logging with minimum 6-month retention for high-risk AI systems. Penalties reach €35 million or 7% of global annual turnover, whichever is higher.
The two regimes overlap. GDPR governs how personal data flows through your AI systems. The EU AI Act governs how those systems log, monitor, and report their behavior. A gdpr compliant ai deployment that lacks the logging infrastructure for the AI Act is still non-compliant.
Four requirements must all be in place. Missing any one of them leaves a gap. To be GDPR-compliant when sending EU data to LLMs, you need a signed DPA, zero-retention configuration, Standard Contractual Clauses, and EU-region pinning.
Here is how each model family maps to those requirements:
| Requirement | OpenAI | Anthropic (Direct) | Anthropic (Bedrock/Vertex) | Gemini (Vertex AI) |
|---|---|---|---|---|
| DPA available | Yes | Yes | Via AWS/Google | Via Google |
| Zero data retention | EU Projects only | Commercial API | Configurable | Paid API |
| SCCs in place | Yes | Yes | Via cloud provider | Via Google |
| EU-region pinning | New EU Projects only | Not available | EU region endpoints | EU region endpoints |
The table makes the gap visible. Anthropic's direct API fails on EU-region pinning. OpenAI requires a new Project. Gemini requires Vertex AI instead of the Developer API. Every provider has a compliant path, but the path is different for each one.
MCP adds another layer. If you are running MCP servers between your SaaS data sources and your LLMs, every server that touches data between the SaaS origin and the LLM becomes a sub-processor, requiring its own DPA and Transfer Impact Assessment. Three MCP servers in your chain means three additional sub-processor agreements to negotiate and maintain.
Managing separate compliance paths for OpenAI, Anthropic, and Gemini, each with different endpoint configurations, different DPAs, and different retention settings, does not scale past two or three models. Add MCP sub-processors and the administrative surface area multiplies further.
An EU AI gateway centralizes OpenAI, Claude, and Gemini routing, logging, billing, and compliance under one API, one DPA, and one audit trail. Instead of negotiating separate compliance paths per provider, the gateway handles EU-region pinning for each upstream model. Instead of hoping your edge router landed in Frankfurt, the gateway provides a deterministic audit trail showing exactly where each request was processed.
This directly addresses the three traps: the audit trail gap from edge-based routing, the sub-processor sprawl from caching layers and MCP servers, and the documentation requirements from GDPR Article 44 and EU AI Act Article 12.
The architecture decision is straightforward. Either you build and maintain per-provider compliance configurations across every model you use, updating them every time a provider changes their defaults (as Microsoft did in March 2026). Or you route through a single gateway that enforces EU data residency and privacy requirements at the infrastructure layer, so individual provider changes do not cascade into compliance failures.
For teams running production AI workloads with EU users, the gateway is not an optimization. It is the difference between a compliance posture that holds under audit and one that depends on no vendor changing their defaults.