How Frontière AI determines sovereignty

The principle

Why “hosted in Europe” is not enough

Any US provider can run a compute region inside the EU and market it as “EU data residency”. That is true and irrelevant: the operating company remains subject to the US CLOUD Act, so a US court order can compel it to hand over the data it processes — even when that data is stored in Frankfurt.

This is why we follow the SecNumCloud reasoning: what decides your exposure is who controls the company operating the infrastructure, not where the servers physically sit. Physical location is one input (it tells us which jurisdiction's law applies to the compute), but capital control and legal jurisdiction are the load-bearing ones.

A model labeled EU sovereign is one whose inference — the company that runs the model and the cloud it runs on — is designed to stay under EU jurisdiction, not US legal process. That intent is what 'outside US jurisdiction by design' means on every model page. It covers who runs the model, not every company a request crosses: the operators table below lists them all.

The two labels

EU Sovereign vs fast access

Every model carries one of two labels — on its model page and in the models API, before you call — and every chat or embeddings response names the provider that served it. There is no third, ambiguous state.

Routing controls

Sovereign by default, US only by choice

A model labeled EU sovereign stays on sovereign providers by default. If its provider fails (HTTP 429 or 5xx), the gateway only tries another sovereign route, when the model has one; otherwise it returns the provider's error rather than reroute your request to a US provider.

Leaving the sovereign lane is an explicit choice, per request or per API key. Fast-access models use their own routes, which are US by definition — so a request restricted to sovereign providers is refused for them.

X-Data-Sensitivity: sensitive

Sovereign providers only, whatever the model. A model with no sovereign route answers 503 no_sovereign_provider.

X-Data-Sensitivity: insensitive

Allows non-sovereign routes, including the backup route of a sovereign model.

API key setting

Dashboard → API keys → Data sensitivity: “Sovereign only” or “All providers (US fallback allowed)”. When the key and the header disagree, the stricter one wins — a key set to “Sovereign only” cannot be loosened by the header.

x-routed-provider · x-sovereign

Response headers: the provider that served the call, and whether it is sovereign.

x-fallback-provider · x-fallback-attempts

Added when the first provider failed and a backup route answered.

MCP

The chat_completion tool of our MCP server follows the same rules: the key's setting and the X-Data-Sensitivity header of the MCP connection.

The score

The Sovereignty Score

A deterministic 0–100 figure, recomputable by anyone from the public methodology below and the facts in our model registry. It aggregates five weighted factors — it does not add a single new fact, and it makes no claim about security, quality, or legal warranty.

Five factors, weights summing to 100:

Operating-company ownership

40

Hosting jurisdiction (observed)

30

Cloud-provider control

15

Data retention

10

Deployment control

5

Score tiers

Because the score follows the registry, it updates the moment a model changes provider. You can recompute it yourself on any model page (breakdown included) or from the formula above.

Frontière Verified

Verification and sovereignty are separate

Sovereignty answers 'under which jurisdiction does this model run?'. Frontière Verified answers 'which of our six checks has this model passed?'. The two are complementary — a 6/6-verified model can be fast access, and a sovereign model can still be awaiting verification.

Today, 11 of the 25 live models are Frontière Verified (all six checks passed). Verified models show their checklist on their model page.

Operators & sub-processors

Who touches your requests

The provider that runs each model is named on its model page before you call, and every chat or embeddings response names the one that served it (x-routed-provider, x-sovereign). A model labeled EU sovereign is never served by a US-controlled provider unless you explicitly allow it. Every request also transits our application host, Vercel — a US company, in its Paris region — which stores no prompt or response.

Optional tools add a provider: web search in the web console and the MCP web_search and web_fetch tools go to Linkup (Paris); voice dictation in the console goes to Mistral AI (Paris).

The legal question

The US CLOUD Act, stated precisely

The CLOUD Act lets US authorities compel any provider subject to US jurisdiction — US companies, and foreign companies with enough business in the United States — to produce data in its possession, custody or control, wherever the data sits. Frontière AI is a French company with no US parent and no non-EU capital control. On models labeled EU sovereign, inference — operator and cloud — is designed to stay outside US jurisdiction. Requests do transit our application host, Vercel, a US company (Paris region), which stores no prompt or response; the privacy policy says so. We state this as intent grounded in corporate structure, not as an absolute legal guarantee — audit our basis, don't take a slogan on faith. Assessed per model before you call, and confirmed on every chat response.

FAQ