LLM router hosted in Europe

Most LLM gateways you have heard of run on US infrastructure. That was fine when nobody was asking questions about where prompts flow. In 2026 the questions are everywhere — from procurement checklists, from DPOs, from the legal team that finally read the EU AI Act properly. If you ship to European users, or you operate from Europe, the hosting country of your routing layer is no longer a detail.

This page explains what actually changed, where the main gateways are physically hosted, and what a properly EU-aligned LLM router looks like in practice.

Why EU hosting matters in 2026

There are three regulatory pillars stacked on top of each other, and they do not pull in the same direction.

GDPR (in force since 2018). When an LLM request contains personal data — a customer name, an email, a support ticket, anything that identifies a human — you are processing personal data. That triggers the full GDPR machinery: lawful basis, data minimization, cross-border transfer rules, DPAs with every processor, and a right to erasure that does not play well with black-box models.

Schrems II (CJEU, 2020). This was the ruling that invalidated Privacy Shield and made transfers of personal data to the US legally fragile. The EU-US Data Privacy Framework (DPF, 2023) replaced it, but it is already being challenged in court. The uncertainty is the point: every time you route a prompt to a US-hosted gateway, you are placing a bet that the current transfer mechanism will still be valid in eighteen months. Some legal teams are no longer willing to take that bet without compensating controls.

EU AI Act (phased 2025–2027). This is the piece most teams underestimate. The AI Act does not just regulate the model providers. It regulates anyone who puts an AI system on the EU market — including the infrastructure layers. Article 9 (risk management), Article 10 (data governance), Article 12 (logging), Article 15 (accuracy and robustness) all create documentation and traceability obligations. If your routing layer cannot produce a per-request audit trail, or cannot tell you which sub-processors touched a prompt, you are going to have a hard conversation with your auditor.

The three together create a simple operational conclusion: the fewer jurisdictions your prompts cross, and the more your infrastructure can document itself, the less risk you carry.

Where the main LLM gateways are actually hosted

Per their public documentation as of 2026-04-22:

• OpenRouter — US-hosted. No EU region. Prompts logged by default (opt-out available).
• LiteLLM Cloud — US-hosted (AWS). Self-hosted OSS option lets you run it anywhere, including in an EU region.
• Vercel AI Gateway — runs on Vercel's edge, which does have EU PoPs, but the control plane and logs sit in the US.
• Portkey — US-hosted primary region; they offer a dedicated EU deployment on enterprise tiers.
• Helicone — US-hosted. Primarily an observability layer; prompt data stored in their infrastructure.
• Cloudflare AI Gateway — runs on Cloudflare's global edge; data locality is handled through Cloudflare's regional services add-on.
• HiWay2LLM — EU-hosted on OVH (France). No US control plane. Zero prompt logging by default.

This is not a statement that US-hosted is wrong. For a US team serving US customers, it is often the correct default. It is a statement that if you need a European data path, most of the market will not give it to you without an enterprise contract or self-hosting effort.

What "EU-hosted" actually needs to mean

"Our servers are in Frankfurt" is not enough. A proper EU-aligned LLM router has to answer six questions:

1. Where does the control plane run? Not just the edge that serves the request, but the dashboard, the metadata DB, the billing system, the logs. If any of those sit in the US, your prompts flow through the US the moment you open the dashboard.

2. Who is the legal operator? A company registered in Ireland with a US parent is not the same as a French SAS. The parent's jurisdiction is what applies under Schrems II.

3. Do you log prompts by default? If the answer is yes, you now have a processor hosting your users' personal data. If the answer is no, you have dramatically reduced your surface area.

4. Can you sign a DPA? At any tier, not just enterprise. The Article 28 DPA is a hard requirement under GDPR, not a negotiation leverage point.

5. Do you publish sub-processors? The model providers you route to (OpenAI, Anthropic, Google) are all sub-processors. If the gateway does not list them, your Article 30 record of processing is incomplete.

6. Can you produce an audit log per workspace? The AI Act Article 12 logging obligation is not satisfied by "we have some logs somewhere." It needs to be queryable and attributable to a specific request.

A router that scores yes on all six is doing EU hosting. One that scores yes on one or two is doing marketing.

HiWay's posture

For transparency, here is where HiWay sits on each of those six:

1. Control plane runs on OVH servers in France. No US component in the data path.
2. Legal operator is Mytm-Group, a French SAS, so French law applies — and therefore GDPR and the AI Act apply natively, with no transfer mechanism needed.
3. Zero prompt logging by default. Prompts transit through memory and are never persisted. You can enable logging per workspace if you want it (e.g. for debugging), and you control retention.
4. DPA is available on every plan, including the free tier. Nothing is gated behind a sales call.
5. Sub-processors are published on the legal page and updated when we change anything. Today the list is: OpenAI, Anthropic, Google, Mistral, Groq, DeepSeek, xAI, Cerebras (the providers you choose to route to), OVH (hosting), Stripe (billing), Postmark (transactional email).
6. Per-workspace audit log is queryable from the dashboard and exportable as JSON or CSV.

That is not a marketing claim to make us look better. It is what the EU regulatory stack requires, and it is how the product was built.

Side-by-side on EU/compliance axes

This table focuses narrowly on EU compliance. For a broader feature comparison, see the per-competitor compare pages.

A buyer's checklist

If you are evaluating LLM routers for an EU-facing product, the shortlist of questions you should send to every vendor:

1. Which jurisdiction is the operating entity registered in?
2. In which regions is the control plane physically hosted, and can that be changed?
3. Are prompts and completions logged by default? What is the retention period? Can it be disabled?
4. Can you sign a DPA under Article 28 of the GDPR? At which plan tier?
5. Which sub-processors do you rely on? Can that list be consulted publicly and is it updated when it changes?
6. Can you produce a per-request audit log attributable to a specific workspace, API key, and model call?
7. Does any part of the data flow require an EU–US transfer mechanism (SCCs, DPF)?
8. Do you provide a mechanism to respond to a GDPR subject access request or erasure request regarding traces that passed through your infrastructure?
9. What happens to logs, metadata, and backups when a workspace is deleted? Documented SLA for full erasure?
10. Can you produce, on request, documentation that maps your product to the AI Act obligations that apply to you?

A vendor that can answer all ten without a sales meeting is a vendor whose compliance posture is real. One that cannot is one you will be explaining to your auditor later.

FAQ

Bottom line

The market for LLM routers is largely US-built, for understandable reasons — the ecosystem, the capital, the first wave of customers were all in the US. That is changing. European teams and regulated industries are applying real compliance pressure, and the AI Act is moving that pressure from nice-to-have to must-have.

If your product serves EU users, the question is not whether EU hosting matters. It is how soon your auditor will ask about it, and whether you will have a clean answer. Picking an EU-hosted router removes a category of risk from your stack in one decision.