How to Enforce AI Data Residency Without Building Local Infrastructure

Deloitte’s State of AI report, which surveyed 3,235 leaders across 24 countries, found that 77% of companies now factor country of origin into their AI vendor selection. Nearly 3 in 5 say they build their AI stacks primarily with local vendors.

If your procurement team has flagged this, the common assumption is that compliance means building or renting local infrastructure. For teams that consume models through an API, it doesn’t. Your requirement is geographic inference routing, and that’s a constraint you can set in a single request.

The infrastructure framing fits governments, defense contractors, and air-gapped environments that need to own the stack. For an application team calling a third-party API, the real question is narrower. Prove that inference on regulated data happens in a specific geography, and that no provider retains or trains on that data.

Treat residency as a routing decision

A routing layer sits between your application and the model providers. Instead of configuring residency separately with each provider, where every one defines it differently, you set geography and data policy once and let the layer pick only providers that qualify.

OpenRouter’s provider object exposes the controls. order and only decide which providers can serve a request, data_collection decides whether a provider may store or train on your data, and zdr requires Zero Data Retention. These work per request, and you can set them as account-wide defaults in your privacy settings.

This shifts your trust from many individual providers to the routing layer. Before you route regulated workloads this way, audit OpenRouter’s own data handling policies and confirm the routing behavior matches your requirements.

Enforce geography in one request

Here’s geographic enforcement in a single call. It tries Anthropic’s direct API first, then Amazon Bedrock, and refuses anything else:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-4.6",
    "messages": [
      {"role": "user", "content": "Summarize this compliance report."}
    ],
    "provider": {
      "order": ["anthropic", "amazon-bedrock"],
      "allow_fallbacks": false,
      "data_collection": "deny",
      "zdr": true
    }
  }'

order sets provider priority. allow_fallbacks at false blocks routing to anything outside the list. data_collection at "deny" excludes providers that store or train on inputs, and zdr at true keeps prompts and completions from being retained after the request. For regulated workloads, set these explicitly rather than relying on defaults.

Each field maps to a different compliance layer. order and only control where inference runs; data_collection and zdr control what happens to the data afterward. They aren’t interchangeable, so set the ones your policy actually requires.

Pin EU jurisdiction when you need it

For EU requirements, you can restrict routing to EU-headquartered providers and deny data collection. Mistral, headquartered in France, is a useful EU-jurisdiction anchor, and you can express the rest through only and the data-policy filters. Independent confirmation of a provider’s data center location should still come from that provider directly.

When requests must never leave the EU, enterprise accounts can use EU in-region routing. Requests are decrypted and processed entirely within the European Union through eu.openrouter.ai, and only EU-eligible providers serve them.

Handle the no-compliant-provider case

If no provider in your list is available and allow_fallbacks is false, the API returns an error rather than routing to a non-compliant provider, which is the behavior you want for regulated data.

Your application chooses what happens next. Queue and retry, fall back to a non-regulated path for content that isn’t sensitive, or surface the failure to the caller. You decide the failure mode, not the router.

Frequently asked questions

Do I need to build local infrastructure for AI data residency?

Not if you consume models through an API. Owning the stack is the right answer for governments and air-gapped environments, but for application teams the requirement is geographic inference routing: prove that inference on regulated data runs in a specific geography and that no provider retains or trains on it. That’s a routing constraint you set per request.

How do I restrict OpenRouter to specific providers or regions?

Use the provider object on a request. order or only controls which providers can serve it, data_collection set to deny blocks providers that store or train on your data, and zdr set to true requires Zero Data Retention endpoints. You can also set these as account-wide defaults in your privacy settings.

What happens if no compliant provider is available?

With allow_fallbacks set to false, OpenRouter returns an error instead of routing to a provider outside your list. Your application decides the failure mode: queue and retry, fall back to a non-regulated path for non-sensitive content, or surface the error.

Can OpenRouter guarantee requests stay in the EU?

For enterprise accounts, EU in-region routing decrypts and processes requests entirely within the European Union through eu.openrouter.ai. For other accounts, you can still restrict routing to EU-headquartered providers and deny data collection, though independent verification of a provider’s data center location should come from that provider.

Does OpenRouter store my prompts?

You control it. Setting zdr to true restricts routing to Zero Data Retention endpoints, and data_collection set to deny blocks providers that store or train on inputs. Review the provider logging docs and your privacy settings before running regulated workloads.