Gateway alternatives · 2026-09-08
EU Data Residency Through a Gateway: How to Control Routing
See how to narrow down where your request is processed on a multi-provider gateway, which artefacts count as evidence for a region claim, and which ones do not.
Routing turns residency into a per-model question
A multi-provider gateway routes to several infrastructures behind one endpoint. That is a good design for model variety and resilience; for data protection it changes the question. You no longer ask "where is this platform" but "which route did this request take".
The same model name can be served through two different providers, and the route can vary per request. A platform-level region statement therefore does not show where one request was processed.
Keep route selection in your own hands
The practical way to make the assessment tractable is to leave nothing about the route implicit. Three mechanisms do that, and not every gateway offers all three — where one is missing, that absence is itself the answer.
- Name the provider explicitly inside the model identifier; a request sent without a prefix can land on another route.
- Use the catalog's provider filter and pin the list of rows you have accepted on your own side.
- Ask about fallback behaviour: when the primary route fails, where does the request go, and can that be switched off?
What counts as evidence
The documentary side of a region claim has three parts: contract text stating where processing happens, a sub-processor list, and a commitment on how changes to that list are announced. With all three you have something defensible in an internal audit.
What does not count is equally clear: a flag icon on a marketing page, an endpoint domain ending in .eu, or a region code in a response header. None of those shows where processing takes place.
For the models in this category, processing inside the European Union is what the provider states; LLMTR has not independently verified it.
How this works on LLMTR
The catalog has a European Union filter; with it on, only the rows whose provider states processing inside the EU are listed, and the selection appears in the address bar. The filter is a narrowing, not a promise: it makes visible which rows carry the statement.
Use each row's identifier exactly as written. Because identifiers sent without a provider prefix also resolve, writing the prefix is the cheapest step that removes route ambiguity.
Frequently asked questions
Can I verify the region from response headers?
No. A header or a domain suffix does not show where processing physically happens. The basis is the contract text and the sub-processor list.
What happens if I omit the provider prefix from the model identifier?
The request still resolves, but which row it reaches depends on catalog matching. Always write the prefix so the route is never ambiguous.
Why does fallback behaviour matter?
When a primary route fails, the request can go to another infrastructure. If you have a regional constraint you need to know in advance what that behaviour does and whether it can be disabled.