OpenRouter can now fail AI requests rather than let regulated data leave the US or EU

OpenRouter launched `us.openrouter.ai` on September 9, 2026, adding a US In-Region Routing endpoint alongside its existing EU endpoint. Requests sent to either regional hostname keep the same API keys, request bodies and model IDs, but OpenRouter says they are decrypted and processed inside that region and may only be served by provider endpoints operating there. If no in-region provider can serve a requested model, the call returns a 404 instead of falling back outside the selected jurisdiction. Business and Enterprise customers can also use Guardrails to require one data region for a workspace, team or API key.

AI data-residency promises can fail before inference even starts if a gateway decrypts prompts in another jurisdiction or if a server-side tool sends data elsewhere. OpenRouter is making the gateway itself part of the compliance boundary: routing, plaintext processing, eligible provider selection and supported server tools are meant to stay inside the requested region. For builders using a multi-provider gateway, that can preserve model choice without writing a separate provider integration for every jurisdiction, but it also means a model that works globally may legitimately become unavailable on a regional endpoint.

OpenRouter distinguishes end-to-end regional routing from merely pinning inference to a regional provider. It says regional requests are decrypted inside the selected jurisdiction and processed there throughout the request path, rather than exposing plaintext to a globally operated gateway before forwarding it to regional inference.

The regional catalog is a subset of OpenRouter's global catalog. If no provider can serve a requested model inside the chosen region, the request fails with `No endpoints found supporting your data region` instead of escaping the region to preserve availability. That is the safer default for contractual residency, but applications need to handle regional model gaps deliberately.

OpenRouter says models such as DeepSeek V4 Pro, Kimi K3 and GLM 5.2 can be offered through US In-Region Routing when independent infrastructure providers host them in US data centers. The model developer therefore does not necessarily receive the request, although builders still need to evaluate the hosting provider and model-license/procurement requirements separately.

Business and Enterprise teams can restrict allowed data regions for a workspace, team or API key. OpenRouter says requests covered by such a guardrail are rejected when they arrive through a hostname outside the allowed region. That provides a second control beyond relying on every application call site to select the correct base URL.

OpenRouter says it evaluates server tools before exposing them through a regional route and disables tools that would send data outside the jurisdiction rather than falling back to global infrastructure. Builders should still verify the exact tool/model combination they depend on because regional availability can be narrower than the global API.