Final Router

EU gateway

Residency claims you can check, not just believe

Plenty of AI products say 'EU-hosted' and stop there. Final Router's platform runs in Frankfurt, every provider's processing region is recorded with its source and the date we checked it - and the catalogue tells you plainly which models actually process in the EU, instead of implying they all do.

  • The platform itself runs on EU infrastructure - Frankfurt, fra1 - not just a marketing badge
  • Every model's processing region is recorded with its source and the date we verified it
  • The EU-only guardrail routes a key exclusively to models whose recorded policy processes in the EU
Residency you can verifyGatewayFrankfurt · fra1processed_in: "EU"recorded with source + dateprocessed_in: "US"skipped when EU-only is on
The platform runs in Frankfurt, each model's processing region is on record with source and date, and the EU-only guardrail routes exclusively inside the ring.

What is actually where

Four facts, each verifiable - not a badge wall.

The platform is EU-hosted

The gateway runs in Frankfurt and the database lives in the EU. Your requests, keys, logs and analytics never leave European infrastructure on our side.

gateway: fra1 · database: EU region

Every provider's region, on record

Where each provider processes API traffic is recorded per model with the policy URL it came from and the date it was checked - and shown in the catalogue and model pages.

processed_in + policy source + checked-on date

An EU-only guardrail

Attach it to a key and requests route exclusively to models whose recorded policy processes in the EU. Today that means Mistral's models - and the page says so instead of rounding up.

narrow on purpose: honest scope beats implied scope

Nothing stored, nothing trained

Prompt and response text is not stored unless you opt in (then 30 days, deletable instantly), we never train on your data, and models whose providers train on API traffic ship switched off.

io logging off by default · DPA available

Moving to EU infrastructure is one line

  1. 1

    Create a key

    Sign up and mint an fr_live_ key - the free tier works before any payment.

  2. 2

    Swap the base URL

    Point your OpenAI SDK at finalrouter.com/api/v1. Traffic now flows through Frankfurt.

  3. 3

    Choose your strictness

    Route freely across all seven providers, or attach the EU-only guardrail for traffic that must stay in EU processing.

  4. 4

    Verify

    GET /v1/models shows each model's recorded region; every response names the provider that answered.

Residency, enforceable per key
// Attach the EU-only guardrail to a key, and requests on it
// route exclusively to models whose RECORDED data policy
// processes in the EU. Everything else routes freely.

GET /v1/models   // each entry carries its data policy:
"final_router": {
  "data_policy": {
    "processed_in": "EU",
    "trains_on_prompts": false
  }
}

Why teams pick EU infrastructure

The EU AI Act and GDPR moved data-handling from a preference to a requirement for many organisations. The gateway's job is to make the requirement enforceable, not aspirational.

Sensitive traffic stays put

The EU-only guardrail is enforcement, not documentation: a key carrying it cannot route outside EU-processed models, whatever the request asks for.

The rest routes freely

Compliance rarely covers everything. Keys without the guardrail keep the full seven-provider catalogue, so one account serves both kinds of traffic.

Audits get receipts

Recorded regions with sources and dates, per-request provider attribution, and a DPA - the paperwork answers itself.

Through the gateway vs going direct

Final RouterDirect to each provider
Platform residencyFrankfurt gateway, EU databaseVaries per provider and product
Model processing regionRecorded per model, with source and dateBuried in each provider's policy pages
EU-only enforcementA guardrail on the key - enforced before routingA convention your developers must remember
Prompt retentionOff by default; opt-in, 30 days, deletablePer-provider defaults, reviewed one by one
Provider attributionNamed on every responseImplicit - you called them directly

FAQ - including the uncomfortable ones

Which models actually process in the EU?

By our recorded policies: Mistral's models process in the EU. OpenAI, Anthropic, Google, Meta and xAI process in the US, DeepSeek in China, Moonshot in Singapore - all recorded in the catalogue with sources and dates. The EU-only guardrail routes to the EU-processed set and nothing else; we would rather state a narrow truth than imply a broad one.

Is Final Router itself EU-hosted?

Yes. The gateway runs in Frankfurt and the database is in the EU, so requests, keys, logs, analytics and billing records stay on European infrastructure on our side regardless of which model answers.

Are you SOC 2 or ISO certified?

Not yet, and we won't imply otherwise. What exists today: GDPR-aligned practices, a DPA, encrypted key storage, prompt storage off by default, and per-provider data policies on record. Certifications are a matter of company stage, and this page will say so the day they land.

Do you or the providers train on our prompts?

We never do. Each provider's trains-on-prompts policy is recorded per model; providers that train on API traffic ship switched off by default, so reaching them is an explicit choice, never a surprise.

What about zero data retention?

On our side, text retention is zero unless you opt in. On the provider side, retention is theirs to define - which is exactly why we record each policy with its source instead of stamping a blanket claim over seven companies' terms.

Compliance that survives an audit

One base URL into Frankfurt, a guardrail that enforces residency, and a catalogue that tells the truth about where models run.

Related: the AI gateway, security practices, the DPA, the model directory.