EU data residency for AI: how to enforce it on every LLM call

Published October 12, 2026. Vendor mechanisms and catalogue examples verified at publish time, and we revisit this page as they change.

Ask an AI assistant how to keep LLM traffic in the EU and it will point you at a switch: an EU base URL, an EU suffix on the model id, a region parameter. This guide covers what "EU" has to mean for a model call, how the major platforms implement it, where per-call switches leak, and how to enforce residency as one policy instead. We build Opper, an AI gateway that runs in Stockholm, and it gets a row in the comparison like everyone else. Every vendor claim links to the vendor's own documentation, checked in October 2026.

What EU data residency has to cover for an AI call

Your prompt reaches a gateway or proxy if you use one, then the provider's endpoint where the model runs, and the provider may keep a copy for logging or abuse monitoring somewhere else. The company running that endpoint also has a legal home of its own. "Keep it in the EU" can mean any of these, and a setting that pins one leaves the others open.

The gateway in front counts too, since it processes the same prompt. Which countries count as "EU" is its own question, because the GDPR follows the EEA line and the major clouds draw their "EU region" in different places: our guide to EU vs EEA for AI compliance covers that, and the GDPR-compliant AI guide covers controllers, processors and DPAs.

How AI platforms offer EU data residency today

Most major platforms offer EU residency now, Anthropic's own API being the exception, through a regional hostname, something in the model id or deployment, or a request parameter. Where an organization-wide control exists, it usually lives in a separate tool: the cloud's organization policy or an account guardrail.

Each of these does what its documentation says, and the organization-wide controls are real. The difference is where the policy lives. On a single platform it is a separate tool that enforces the region of an endpoint or deployment, written in that platform's policy language, while the hostnames and prefixes stay in your application code. None of them has the provider's parent company as a setting of its own, and none follows a call to another platform.

Where a per-call EU switch leaks

A per-call switch makes residency a property of every line of code that calls a model. Four places it tends to give way:

1. A call site that does not use it. A new service, a script, an evaluation job, a framework whose default base URL is the global one. Unless an organization policy blocks it, that call is served normally somewhere else, and often nothing in the response says so.
2. Fallbacks and retries. A fallback list that ends in a model without an EU deployment moves the call outside the region exactly when the primary is down.
3. One platform at a time. Each switch covers location on its own platform. A setup with three providers has three switches and three policies to keep in sync.
4. Agents choosing models. Coding agents and agent frameworks write code, pick model ids and start sub-calls of their own. A rule that lives with the account holds whatever they generate.

How Opper enforces EU data residency

The gateway hop is already in the EU. The Opper API runs in Stockholm, Sweden, with a second production environment at evroc, the Swedish cloud, and the gateway, traces, usage records and stored files stay there. So there is no separate EU base URL: https://api.opper.ai/v3/compat is the EU endpoint for OpenAI, Anthropic, Gemini and Responses-shaped clients alike, on a platform certified against ISO/IEC 27001:2022.

Per call, on any plan, pick an EU route. Every route in the catalogue records where it runs, and a route's model id pins the call to it: aws/claude-opus-5-5 is Claude Opus 5.5 on AWS Bedrock in the EU. The EU model directory lists every EU route with its provider, country, retention and price, and the catalogue answers the same question without an API key:

curl "https://api.opper.ai/v3/models?type=llm&inference_location=EU&storage_location=EU&limit=0"

On October 12, 2026 that returned 185 of the 966 language-model routes in the catalogue.

As a policy, set one model access rule. On the Control Plane plan, a model access rule defines the part of the catalogue your organization may use. Inference location, storage location and provider country are separate fields, each set to the EU, the EEA or single countries, and a provider data policy can require zero data retention as well. Set for the organization, it applies to every API key and project, a new project starts inside it, and a project override can only narrow it.

Failover stays inside the rule. A model name without a provider prefix is served by a pool of routes that can span regions. Under a rule with inference and storage location set to the EU, the pool runs only on the routes that pass and skips the rest. These are the routes serving Claude Opus 5.5 on October 12, 2026:

Anything else is refused before it leaves Opper. A call pinned to a route outside the rule gets a 403 before anything reaches the provider, whichever key, SDK or app sent it. The message names the model and the condition that failed, and the trace records which rule applied:

{
  "error": {
    "code": "permission_error",
    "message": "model \"anthropic/claude-opus-5-5\" is blocked by the active model allowlist: inference location US is outside EU"
  }
}

Set it from the platform, from code or from your agent. In the platform it is Rules → Model access. The Management API creates the same rule from CI or infrastructure-as-code, with a management key that carries the controls:write scope:

curl -X POST https://api.opper.ai/management/v1/controls/rules \
  -H "Authorization: Bearer $OPPER_MANAGEMENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "'$(uuidgen | tr A-Z a-z)'",
    "kind": "comply",
    "enabled": true,
    "scope": {"type": "org"},
    "config": {"type": "allowlist", "allowlist": {"provider": {"locations": {"inference": {"include": ["EU"]}, "storage": {"include": ["EU"]}}}}}
  }'

And a coding agent connected to the Opper MCP server can read and change rules and check whether a model is allowed before calling it, so "keep everything in the EU" is a sentence you can hand to Claude Code or Cursor. The full walkthrough is in the docs under Keep AI inference in the EU.

Write the policy first, then the rule

The rule is only as precise as the sentence it implements, so start from the policy text:

Most teams need the first or second row: EU hosting on AWS, Azure, Google or a European host, with zero data retention where it matters, is the whole answer for them. The provider-country row is for policies that name jurisdiction rather than location, and for those Opper on evroc runs the gateway on a European-owned cloud with routes to European-owned providers. Projects can carry different rows, so one team can be stricter than the rest of the organization.

How to check that EU residency holds

1. Call a route that should be refused. Pin a route outside your definition and expect a 403 that names the condition. If it succeeds, the rule is not active for that key's project.
2. Read which route served a pooled call. The response metadata and the trace name the route that answered, and under the rule it should only ever be one that passes.
3. Compare the catalogue with the rule. The same inference_location and storage_location filters on /v3/models match the way the rule does, so you can see what your teams can still use before you save it.
4. Keep the paperwork aligned. The rule decides which providers can receive your data, so it should match the sub-processors your DPA names. On Opper one DPA covers every model.

EU data residency FAQ

Define EU once, for every call

A switch answers "where does this call go", a policy answers "where may any call go", and only the second holds up across a growing codebase, a fallback and an agent that writes its own model ids. Define what EU means for you in one model access rule, and check what it allows in the EU model directory before you save it.