Sovereign AI

Does OpenRouter support EU data residency?

Yes, for prompts and completions. Requests to eu.openrouter.ai are decrypted in the EU and routed only to shared provider endpoints in Europe (the EU/EEA, the UK, and Switzerland). Requests served by your own BYOK key go to your deployment’s region, which you control. Account, billing, and other operational records may be stored or processed in the US. EU in-region routing is self-serve on Business: no contract, no monthly minimum.

What sovereign AI means

Sovereign AI refers to a nation’s or region’s ability to develop, deploy, and control artificial intelligence systems within its own borders, using local infrastructure and under local regulatory frameworks. As AI becomes critical infrastructure, governments and enterprises increasingly require that AI workloads, and the data they process, stay within specific geographic and jurisdictional boundaries. OpenRouter offers EU and US in-region routing. There is no setting to turn on: you choose the region for each request by sending it to that region’s base URL. This page describes what OpenRouter covers and what it doesn’t, so you can map it to your own requirements.

Drivers of sovereign AI

Sovereign AI is driven by two converging forces:

Regulatory Compliance

Regulations like the EU AI Act, GDPR, and sector-specific rules (healthcare, finance, defense) impose strict requirements on where data can be processed and stored. Organizations operating across jurisdictions need infrastructure that respects these boundaries.

Data Residency and Privacy

Sensitive data (whether personal, financial, or classified) may need to be processed within a particular jurisdiction. For AI workloads, the core requirement is usually that prompts and completions are processed in a designated region.

What OpenRouter covers

In-Region Routing

For Business and Enterprise customers, OpenRouter supports EU and US in-region routing. When you send a request to a regional base URL, the request is decrypted within the designated region and routed only to shared provider endpoints in that region: Europe (the EU/EEA, the UK, and Switzerland) for eu.openrouter.ai, and the US for us.openrouter.ai. Requests served by your own BYOK key go to your deployment’s region, which you control. Server tools and plugin engines run on a regional domain only when they have a backend resident in that region; a request that uses any other tool or engine fails instead of falling back to global infrastructure. See Privacy and regional availability for each tool’s regional availability. In-region routing fails closed: if no endpoint eligible for the region (shared, BYOK, or private) can serve the requested model, the request errors instead of leaving the region. Features that would process data outside the region are rejected on regional domains. See Feature Availability for the list. Choosing a regional base URL per request is the first step. To guarantee that every request in a workspace stays in-region regardless of how a client is configured, restrict the allowed data regions in a guardrail. The guardrail’s allowed_data_regions setting (global, europe, us) lists the OpenRouter domains that governed requests must arrive through; requests through any other domain are rejected with a 403 before processing. Setting it on the workspace default guardrail enforces the policy for all keys and members in that workspace, and per-member or per-key guardrails can narrow it further. See Enforcing In-Region Routing with Guardrails. To use in-region routing, send API requests through the region-specific base URL:

https://eu.openrouter.ai
https://us.openrouter.ai

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({
  apiKey: '<OPENROUTER_API_KEY>',
  serverURL: 'https://eu.openrouter.ai/api/v1',
});

const completion = await openRouter.chat.send({
  chatRequest: {
    model: 'meta-llama/llama-3.3-70b-instruct',
    messages: [{ role: 'user', content: 'Hello' }],
    stream: false,
  },
});

fetch('https://eu.openrouter.ai/api/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer <OPENROUTER_API_KEY>',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: 'meta-llama/llama-3.3-70b-instruct',
    messages: [{ role: 'user', content: 'Hello' }],
  }),
});

import requests

headers = {
  'Authorization': 'Bearer <OPENROUTER_API_KEY>',
  'Content-Type': 'application/json',
}

response = requests.post('https://eu.openrouter.ai/api/v1/chat/completions', headers=headers, json={
  'model': 'meta-llama/llama-3.3-70b-instruct',
  'messages': [{ 'role': 'user', 'content': 'Hello' }],
})

curl https://eu.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer <OPENROUTER_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

In-region models listTo see which models are available for in-region routing, you can:

Call /api/v1/models through the EU domain to get the full list programmatically, or pass a region query parameter (eu or us) on the main domain
Browse EU-eligible models or US-eligible models on the models page with the In-Region Routing filter
See the live EU model list, what may be stored or processed in the US, and guardrail setup on EU in-region routing on Business

For full details on how requests are routed, which features are available on regional domains, and how BYOK works with regional routing, see the In-Region Routing guide.

Zero Data Retention (ZDR)

When Zero Data Retention is enforced, OpenRouter routes model inference only to provider endpoints that have a Zero Data Retention policy. ZDR enforcement does not apply to plugins, server tools, or their backends, which follow their own retention policies. See Privacy and regional availability for each server tool’s execution path and backend policy. ZDR can be enforced per model group (Anthropic, OpenAI, Google, SpaceXAI, and all other models) in your privacy settings, via guardrails, or per-request:

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "messages": [{ "role": "user", "content": "Hello" }],
  "provider": {
    "zdr": true
  }
}

Data Collection Controls

Control whether providers can collect your data with the data_collection parameter:

{
  "provider": {
    "data_collection": "deny"
  }
}

When set to "deny", your requests are only routed to providers that do not collect user data. This can also be configured as an account-wide default in your privacy settings. OpenRouter supports GDPR programs with a DPA and Standard Contractual Clauses. The DPA includes an EU-only processing addendum (Exhibit A) for API payloads, which applies when you elect it in writing. See the Data Processing Agreement.

What OpenRouter doesn’t cover

In-region routing applies to the prompts and completions in requests sent to a regional domain. It doesn’t move every record OpenRouter keeps about your account into the region:

Processed in Europe (requests to `eu.openrouter.ai`)	May be stored or processed in the US	Your responsibility
Prompt and completion processing	Account data	BYOK deployment region
Provider inference, on shared provider endpoints in Europe (the EU/EEA, the UK, and Switzerland)	Billing records	Broadcast and observability destinations you configure
OpenRouter’s request handling	Authentication data
	Security logs
	Abuse-monitoring metadata
	Other operational records

For setup details, see BYOK with In-Region Routing and Observability with In-Region Routing.

Building an in-region stack with OpenRouter

Combine these features to keep prompts and completions in one region:

Send requests to a regional base URL (eu.openrouter.ai or us.openrouter.ai) to keep model inference and supported tools within that region
Restrict allowed data regions in a guardrail so every request in a workspace, member, or API key must arrive through that regional domain
Enforce ZDR to route inference only to provider endpoints with a Zero Data Retention policy
Deny data collection to prevent training on your data
Provision BYOK deployments and Broadcast destinations in the same region, since OpenRouter can’t move resources in your own accounts

This gives you a single API with unified billing and per-request control over where prompts and completions are processed, without managing relationships with individual providers in each region.

Getting Started

In-region routing (EU or US) is self-serve on Business: no contract, no monthly minimum. To get started:

Upgrade to Business in Settings > Manage plan, then send requests to https://eu.openrouter.ai or https://us.openrouter.ai. For Enterprise, contact our enterprise team.
Create an API key and use provider routing to control which providers serve your requests
Enable ZDR and data collection controls
Restrict allowed data regions with a guardrail

For a complete enterprise setup guide, see the Enterprise Quickstart.

Overview

Models & Routing

Tool Calling

Features

Observability

Authentication

Ori

Developer Tools

Privacy

Best Practices

Providers

Community

Does OpenRouter support EU data residency?

What sovereign AI means

Drivers of sovereign AI

Regulatory Compliance

Data Residency and Privacy

What OpenRouter covers

In-Region Routing

Zero Data Retention (ZDR)

Data Collection Controls

What OpenRouter doesn’t cover

Building an in-region stack with OpenRouter

Getting Started

​Does OpenRouter support EU data residency?

​What sovereign AI means

​Drivers of sovereign AI

​Regulatory Compliance

​Data Residency and Privacy

​What OpenRouter covers

​In-Region Routing

​Zero Data Retention (ZDR)

​Data Collection Controls

​GDPR programs

​What OpenRouter doesn’t cover

​Building an in-region stack with OpenRouter

​Getting Started

Does OpenRouter support EU data residency?

What sovereign AI means

Drivers of sovereign AI

Regulatory Compliance

Data Residency and Privacy

What OpenRouter covers

In-Region Routing

Zero Data Retention (ZDR)

Data Collection Controls

GDPR programs

What OpenRouter doesn’t cover

Building an in-region stack with OpenRouter

Getting Started