EU routing is two layers, not one: the questions legal, engineering and procurement are asking this month

Three conversations from the last ten days, from three different roles, that turn out to be one question.

Engineering versus legal. On 4 September an employee at an EU company posted in r/ClaudeAI: Legal says employees can only use LLMs through a LLM gateway "for GDPR". Is that true, or is it a policy choice? The product path was settled ("the platform's AI features go through an LLM gateway in an EU region, everything is documented, no debate there"); the fight was about employee tools. The poster's argument, in four points: GDPR does not require EU processing because US transfers are lawful under the Data Privacy Framework; an EU region on a US cloud does not escape the CLOUD Act anyway; names and emails are Article 6 data, not Article 9; so split by data class, not by tool.

Procurement. On 2 September, in r/AI_Governance, a buyer who had narrowed nine gateways asked what legal verified, because "every vendor has it on their security page" and "most of them treat EU sovereignty as an enterprise tier conversation." The requirement list was specific: traffic staying in the EU, auditable subprocessors, a DPA ready to sign, "hard to tell from docs alone what is enforced or listed."

Engineering versus the market. On 9 September OpenRouter launched an EU regional entry point, described in its docs as in region routing in the EU and US for enterprise customers. One reply made the sharp point: "in-region processing removes the cross-border transfer itself instead of trying to secure it, which kills most of the transfer-assessment friction for EU procurement. TLS termination location effectively becomes the compliance boundary." Another pushed back: "routing AI requests through Europe is not the same thing as building AI infrastructure for Europe." The next day a user reported that the EU variant doesn't work, and r/openrouter logged in-region routing fails, Cloudflare 522 on the eu.openrouter.ai URL while the normal API worked. On 11 September a developer asked why one gateway can offer regional inference for OpenAI models on Azure in the EU while another cannot, "since you have Azure there."

Legal, procurement and engineering are each asking a version of the same thing: what does "EU" attach to? The answer is that it attaches to two different things, and almost every disagreement in those threads comes from treating them as one.

Layer one: where the gateway runs

The gateway layer is everything the routing service itself does with your request: TLS termination, authentication, policy evaluation, logging, caching, analytics, billing metadata. When a vendor says "EU endpoint," this is the layer they mean. For Requesty it is router.eu.requesty.ai, running in Frankfurt on AWS eu-central-1; the EU routing documentation describes it as "request routing, logging, caching, analytics, all in EU."

The X reply about TLS termination is right about this layer and only this layer. If the request is decrypted in Frankfurt, processed in Frankfurt and logged in Frankfurt, the gateway leg involves no transfer. That is a real simplification for a transfer impact assessment, because there is nothing to assess.

What it does not do is say anything about where the model ran. An EU endpoint that forwards to anthropic/claude-opus-5, the global route, has sent the prompt to the United States for inference. The gateway leg was in the EU; the request was not. The Requesty documentation says this in bold because people miss it: "using the EU endpoint alone only guarantees that Requesty's processing stays in the EU."

Layer two: where the model runs

The model layer is the deployment that performs inference. It is not a property of the model or even of the provider; it is a property of a specific deployment in a specific region. Claude Opus 5 is one model with at least six deployments that matter to a European team: the global Anthropic API (US), Bedrock Frankfurt, Bedrock Ireland, Bedrock Paris, Bedrock Stockholm, and Vertex EU. Only the last five keep inference in the EU, and they are five separate quota pools as well.

This is also the answer to the 11 September question. Why can one gateway offer regional inference on Azure and another cannot, when both "have Azure"? Because "having Azure" as a provider integration is not the same as holding deployments in France Central, Sweden Central, Germany West Central and West Europe and exposing each as a distinct, routable model id. Regional inference is a catalog property. In the Requesty catalog it shows up as the region suffix: azure/gpt-5.6-terra@swedencentral, vertex/gemini-3.8-flash@eu, bedrock/claude-sonnet-5@eu-north-1. A gateway whose Azure integration is one global endpoint cannot promise where the inference ran because it does not know.

We checked the top 16 models on the intelligence ranking (live page) against the catalog this week: 13 have an EU deployment, at a typical 10% vendor uplift, and three (GPT-6 Astra, Grok 4.6, Qwen3.8 Max) do not exist in the EU at all. No gateway endpoint changes that. If the model has no EU deployment, an EU gateway is forwarding it abroad.

Both layers, or neither

Put the two together and the residency claim has four possible states:

The r/AI_Governance poster's frustration ("hard to tell from docs alone what is enforced or listed") is the difference between a vendor that offers the bottom right cell and a vendor that enforces it. Offering means the option exists. Enforcing means the other three cells are impossible for your organisation. That is the property legal can verify, and it is a configuration rather than a contract:

1. Restrict the serving region. In the Compliance panel, set the organisation's allowed Requesty region to EU. The global, US and AP endpoints now reject every key in the organisation and the Playground only offers EU. Nobody can put a key on the wrong base URL by accident.
2. Restrict Approved Models to EU region deployments. Filter the Model Library by EU regions, approve, done. A request for a global model id is rejected at the gateway. The top left three cells of the table are now unreachable.
3. Log the region. Every request in the logs records the deployment that served it, region suffix included, and telemetry is retained even under Zero Data Retention because it contains no prompt content. That log is the auditor's evidence: not "we configured EU," but "here are the deployments that served every request in Q3, and none of them is outside the EU."
4. Sign the DPA. Article 28 processor terms, subprocessors, breach notification. This is the part procurement can hold; the three settings above are the part they can check.

Back to the legal debate

The r/ClaudeAI poster's four points are mostly correct as law and mostly beside the point as architecture.

Correct: GDPR does not mandate EU processing, the Data Privacy Framework and standard contractual clauses make transfers to certified US vendors lawful, and an EU region on AWS or Google does not remove the vendor from US jurisdiction. Nothing in this post claims otherwise. EU residency is a choice, not a statute.

Beside the point: the reason most regulated European companies make that choice is not that GDPR forces it but that their customers, their sector regulators and their own risk committees do. A bank's DORA obligations, a hospital's national health data rules, a public body's procurement conditions and a hundred enterprise customer contracts say "EU only" in so many words. Once one of those applies, the question is no longer "is this legally required" but "can we prove it," and proof is what the two layer enforcement above produces. The poster's own conclusion, split by data class, is exactly right, and it is implemented with the same controls: an access list for the keys that touch sensitive customer data restricting them to EU deployments, and looser lists for keys that do not. The team model access post walks through the layering.

One more distinction the debate needed. The poster noted that the gateway "blocks native features (coding agents, projects, connectors, browser integrations)." A gateway does not have to. Claude Code and the coding agents run against router.eu.requesty.ai with a base URL change, as the EU routing docs show for Claude Code, Cline and Roo Code, and provider native tools work through the gateway. Whether the token billed cost of that beats a seat licence is a separate, legitimate finance question, not a residency one.

What the 522 taught everyone

The OpenRouter EU endpoint returning Cloudflare 522 errors on its second day, while the global endpoint kept working, is worth one paragraph because it illustrates a fourth property nobody put on the requirements list: an EU endpoint has to be the primary path, not a bolt on. A regional entry point added in front of a global architecture is a second system, with a second failure mode and a second maturity curve. When it fails and the global endpoint does not, the temptation for an on call engineer at 2am is to flip the base URL back, and the residency guarantee is gone until someone remembers to flip it forward. The counterweight is enforcement again: if the organisation's serving region is restricted to EU, flipping back is not possible, so the incident is a real outage that gets a real fix, and the residency claim survives the night.

The takeaway

"EU" is not one switch. It is a gateway region and a model region, enforced separately, and the residency claim is exactly as strong as the weaker one. Legal is right that GDPR does not require it; procurement is right that offering is not enforcing; engineering is right that regional inference is a per deployment fact. All three are satisfied by the same configuration: EU serving region, EU only approved models, region in every log line, DPA on file. The /eu page has the endpoint, and the EU routing documentation has the two layer explanation this post is built on.