GDPR LLM data residency: region controls, zero retention, EU options

GDPR LLM work is really data-residency work with a model in the middle. The moment your server sends a prompt to a hosted model, personal data has left your database, crossed a network, and landed on infrastructure you do not operate, under a retention policy you did not write. As of September 2026 the interesting question is no longer whether that is possible — it obviously is — but which routes actually keep processing inside the European Union, and what each one costs you in retention, features and debugging.

This article walks the boundary from the inside out: what exactly crosses it, why Claude's first-party API has no EU region to switch on as of September 2026, how the hyperscaler EU regions became the practical answer, what zero data retention really removes, how to shrink the payload before it leaves, when a self-hosted open-weight model is the right call, and an architecture you can copy. Claims about provider behaviour are dated and sourced; verify them against your own contract before you rely on any of it.

What actually leaves your servers when you call a model API

Four things travel, and only one of them is the text you typed. The prompt: your system prompt, the conversation history, the retrieved chunks, the tool results. The attachments: uploaded files, images, PDFs, and whatever metadata travels with them. The identity context: a user ID, a tenant ID, a session ID, a request ID, and the account or API key you authenticate with. And the telemetry you did not think of: request metadata, latency and token counts, error payloads, and any trace or span you attach for observability.

The failure mode is not usually the prompt. It is the userId you put in the system prompt for convenience, the trace that captures the full request body, and the retrieved document chunk that still contains an email address because nobody redacted it upstream. The provider sees all of it. What happens next depends on two independent settings: where inference runs, and how long anything is kept.

First-party region controls, and the EU option that is not there

On Anthropic's first-party Claude API, region control exists and it is genuinely well documented. The data residency documentation is explicit: the inference_geo request parameter accepts exactly two values, "global", the default, where inference may run in any available geography for optimal performance and availability, and "us", where inference runs only in US-based infrastructure. You can set it per request or as a workspace default, restrict the allowed values with allowed_inference_geos, and check where a call landed in the response's usage.inference_geo field. That last part is the one to build a test on.

Here is the surprise, and as of September 2026 it is the single most useful thing to know if you are planning around EU residency: there is no EU inference region on the first-party API. Workspace geography — which controls where data is stored at rest and where endpoint processing happens — is set when you create a workspace, cannot be changed afterwards, and "us" is currently the only value available. So the strongest control the first-party API offers is a choice between "anywhere" and "the United States".

Two smaller constraints follow from the same page. inference_geo is supported on Claude 4.6 and later; sending it with an older model returns a 400. And US-only inference is priced at 1.1× the standard rate across input tokens, output tokens, cache writes and cache reads. Pinning geography is not free, it is just cheaper than the alternative of not knowing where your data went.

Hyperscaler EU regions are the practical route

The same models are available through Amazon Bedrock and Google Cloud, and there the geography is chosen by the endpoint rather than by a parameter. On those platforms the docs say the inference region is determined by the endpoint URL or the inference profile, and inference_geo does not apply. That inverts the problem: instead of asking the provider to keep processing in a region, you address a regional endpoint and the region follows.

The distinction between endpoint types matters and is easy to get wrong. The models overview spells it out: Amazon Bedrock offers both global endpoints, which route dynamically, and regional endpoints, which guarantee data routing, with that guarantee applying to Claude Sonnet 4.5 and later. Google Cloud offers global, multi-region and regional endpoints. If EU residency is a requirement rather than a preference, a global or dynamically routed endpoint does not give it to you; a regional one does. Note also that the data processor relationship changes here — on Bedrock and Google Cloud the cloud provider is the processor, so their retention and compliance documentation is what governs, not the first-party API policy.

For OpenAI, the data residency in Europe announcement of 5 February 2025, updated since, describes API customers choosing to process data in Europe for eligible endpoints by creating a new Project in the API Platform dashboard and selecting Europe as the region. Requests through those Projects are handled in-region with zero data retention, meaning model requests and responses are not stored at rest. Two caveats from the same page: European residency can only be configured for new Projects, and it covers eligible endpoints, so check your own endpoint list before you design around it. OpenAI also states that models are not trained on customer data by default unless a customer explicitly opts in, encrypts data at rest with AES-256 and in transit with TLS 1.2 or higher, and offers a data processing addendum for GDPR roles and responsibilities.

Zero data retention and what it costs you in debugging

Zero data retention is the most misunderstood control in this space, because providers describe it as "we do not store your data" when what they mean is narrower. On the Claude API, the retention documentation says ZDR means prompts and responses are not stored at rest once the response has been returned. It is enabled per organization on request, each organization needs it enabled separately, and there is a feature eligibility table that says which endpoints and features it actually covers.

That table is where the engineering cost shows up. Features that are inherently stateful are not ZDR-eligible: the Files API retains files until you delete them, batch processing keeps jobs for 29 days, the code execution container keeps data for up to 30 days, and Managed Agents transcripts persist until you delete them. Some are "qualified" rather than clean — structured outputs cache your JSON schema for up to 24 hours, and prompt caching holds cache representations in memory for the cache TTL. Prompt caching is the interesting one for cost work, and you can read more about that in caching, routing and batching. Some models are excluded outright: the designated Covered Models require 30-day retention and are not available under ZDR unless Anthropic authorises it.

Two consequences bite. First, debugging gets harder exactly when you need it most. If you cannot replay a conversation from the provider, then your own store is the only record, which means you need to keep a redacted, minimised copy yourself — and you need to know that is a deliberate decision rather than a side effect. Second, ZDR is not absolute: retention can still apply where the law requires it, and a session flagged by automated trust and safety systems may have its inputs and outputs retained for up to two years. Read the retention-except-the-arrangement section before you promise anyone nothing is kept.

Minimising and pseudonymising before the prompt

The cheapest privacy control is not a region setting; it is not sending the data. Article 5(1)(c) of the GDPR states data minimisation as personal data that must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed", and that principle applies to the prompt just as much as to the database column. If the model needs to know that an order is late, send the order status, not the customer's name, address and order history.

Pseudonymisation is the second lever, and it needs care. Article 4(5) defines it as processing such that personal data can no longer be attributed to a specific data subject without the use of additional information, provided that additional information is kept separately and is not subject to technical and organisational measures that could reasonably be used to re-identify. That is pseudonymisation, not anonymisation: the data is still personal data under the GDPR, it just cannot be read without a lookup you control. Only genuinely anonymised data falls outside the regulation, which is a much higher bar than most prompts reach.

// Illustrative pattern: resolve identifiers before the prompt, never in it
// PSEUDONYM_KEY comes from the environment, never from a file in the repo.
function buildPrompt(order) {
  const subjectRef = hmac(order.customerId, process.env.PSEUDONYM_KEY)
  return [
    `Customer ${subjectRef}: order ${order.id} is ${order.status}.`,
    `Ship to ${order.region}, carrier ${order.carrier}, ETA ${order.eta}.`,
  ].join('\n')
}
// The mapping subjectRef → customerId lives in your EU store, not in the prompt.

Two practical habits make the difference. Replace stable identifiers in the prompt with a keyed reference you can resolve server-side, and keep the key in your own store — that is pseudonymisation, and the prompt is then no longer a record of a named person. And strip the request body from your own traces: log a hash of the prompt, its token count and the model, not the prompt text, unless you have a specific reason and a retention period. Both are cheap. Redoing them after launch is not.

When self-hosting an open-weight model in the EU is the right call

Self-hosting is the only option on the list where the region and retention answers are "wherever we say". If the data must not leave EU infrastructure under any configuration, or the workload is steady enough to amortise GPUs, running an open-weight model on infrastructure you rent in the EU removes the entire provider question. There is no cross-border inference option to audit, because there is no other party.

What you take on is the full operational burden: capacity planning and headroom for peak traffic, keeping the runtime and the weights patched, watching GPU cost per token against a hosted API's price, and — the part teams underestimate — owning the evaluation work, because quality now varies with your serving configuration rather than with a version number someone else ships. If you are already running regression evals in CI, you have the harness for that last part.

My rule: self-host the narrow, high-volume, low-ambiguity work — classification, routing, extraction, summarisation of material you have already minimised — and keep a frontier model for the requests where quality is actually the product. The boundary is a routing decision, which means it belongs in code where you can measure it, not in a wiki page.

An architecture template you can copy

The design that keeps working as providers change is a gateway between your application and every model, with the policy in one place. The application code never holds a provider key and never decides where data goes; it calls your own endpoint, and the gateway classifies the request, applies the minimisation rules, picks a route and records what it did.

Four properties make the gateway hold up. The provider credentials live only in the gateway, so the browser never holds a key and a leaked frontend bundle leaks nothing. The route is chosen from a policy, not a default, so "EU only" is a config change with a test behind it. Every request produces one audit record — route, model, region, token count, prompt hash — and that record is the only thing that has to be kept. And the minimisation step sits in front of the provider call, so the rules apply no matter which route wins.

The same trust-zone thinking shows up wherever an agent can reach data: an allowlist of permitted destinations, not a blocklist of forbidden ones, is what makes the boundary real. I covered that pattern in sandboxing coding agents in CI, and the gateway here is the same idea with a model provider on the other side. If you want one built for your stack, that is the kind of work I do as an AI engineer.

Sources

1. Claude API docs: Data residency (inference_geo, workspace geo, pricing)
2. Claude API docs: API and data retention (zero data retention scope and eligibility)
3. Claude API docs: Models overview (platform model IDs, endpoint types)
4. OpenAI: Introducing data residency in Europe
5. Regulation (EU) 2016/679 (General Data Protection Regulation) – EUR-Lex