LowRouterBeta

Sovereignty and transparency

Two of the practical reasons teams move from a single LLM provider to a gateway are sovereignty (where the request goes) and transparency (what’s actually happening). This page gives concrete answers for both.

Sovereignty

LowRouter’s control plane is operated from the European Union by Carbonifer SAS. The data plane (the providers that actually run the inference) covers multiple regions: EU (Mistral, Anthropic via EU endpoints, Bedrock EU), US (OpenAI, Anthropic via US endpoints, Bedrock US), and a growing set of regional Vertex AI deployments.

When you send a request without a region preference, the router picks based on availability and the carbon-intensity heuristic described in provider routing. The chosen region is reported in the response.

When you need data residency:

  • Pin a region by encoding it in the model ID: append a UN/LOCODE as the last segment, e.g. aws-bedrock/mistralai/ministral-3-3b-instruct/br-gru.
  • Region resolution fails closed: if the model isn’t served in the requested region, the request returns an error rather than silently falling back to another region.

We do not run inference on user prompts inside our own infrastructure beyond what is required to forward and account for them. Logs are documented in usage accounting.

OVHcloud and the US CLOUD Act

OVHcloud hosts the LowRouter platform, in Gravelines, France, and also serves AI routes from there. We classify OVHcloud (OVH SAS, controlled by OVH Groupe SA, France) as not exposed to the US CLOUD Act and as an EU-sovereign provider for its EU/EEA regions. The trust center and the router use that classification.

This reverses an earlier rule in our catalogue that counted OVHcloud as exposed because OVH Groupe SA owns a US subsidiary, OVH US LLC. Our reasons:

  1. The CLOUD Act reaches the provider that has “possession, custody, or control” of the data and is subject to US jurisdiction (18 U.S.C. § 2713). OVH US LLC is a separately constituted US entity that runs only the US datacenters. It does not possess, hold or control the data of OVH SAS’s European infrastructure. Owning a US subsidiary does not give that subsidiary control of the parent’s data.
  2. OVHcloud states that its US arm is constituted separately and that services delivered from Europe, Canada and Asia are outside the CLOUD Act’s reach (DatacenterDynamics, 2019).
  3. OVHcloud holds ANSSI SecNumCloud 3.2 qualification on dedicated offerings, and that qualification includes immunity requirements against non-European extraterritorial laws (OVHcloud, press release).
  4. The providers we keep as exposed are controlled from the US. AWS, Google, Microsoft, OpenAI, Anthropic, Meta, Groq and DeepInfra are US-incorporated parents that control their EU regions, so an AWS Bedrock or Google Vertex AI route in Frankfurt or Paris is still exposed. The rule is who controls the provider, and OVHcloud is controlled from France. For the general argument about a European parent with a US subsidiary, see UpCloud (a vendor’s view, not specific to OVHcloud).

Caveats:

  • SecNumCloud does not cover the services we use. It applies to specific OVHcloud offerings (Hosted Private Cloud, Bare Metal Pod), not to AI Endpoints or the managed Kubernetes and Public Cloud services we run on. Our classification rests on corporate control (points 1, 2 and 4), not on SecNumCloud.
  • Other laws can still reach a subsidiary. In 2024 an Ontario court ordered OVH’s Canadian subsidiary to produce data stored in France, the UK and Australia, under an RCMP production order. OVHcloud is contesting the order and says French law forbids disclosure outside treaties. It is a Canadian case, not a CLOUD Act case (The Register).
  • EU-sovereign applies per route. OVHcloud documents worldwide (non-EU) availability for some AI Endpoints modes. A route served from outside the EU/EEA is not EU-sovereign, even though it is not exposed.
  • “Not exposed” is our reading of legal control as recorded in our provider catalogue. It is not a legal opinion.

Transparency

Every API response includes, in its lowrouter_metadata block, a provider field with the upstream that served it and a region field with the region it served from, alongside an X-Request-ID header you can correlate against your own logs. The dashboard shows the same data per request, per day, and aggregated per model.

The carbon and energy numbers shown on the dashboard are produced by the formula in methodology. The formula’s coefficients, the model parameter counts we use, and the grid-intensity values we apply are documented and dated. When a value changes, for instance when a new grid-intensity dataset replaces an older one, the dashboard reflects the change with the date it took effect.

A small team operates the platform, and every third-party service involved, including logging and analytics, is listed in the privacy policy.

How to verify

  • Read methodology and audit the formula.
  • Send a request with an auto/<creator>/<model> ID, then re-send it pinned to a specific provider/region via the model ID. Compare the provider, region, and eco fields in the lowrouter_metadata block.
  • Open the corresponding entries on the dashboard and confirm the numbers match.

If something doesn’t reconcile, it is a bug. Please file an issue.