Stav is built in Norway and trusted across Europe. Sovereignty is the core promise behind that positioning — it tells you, precisely, where your prompts and completions live and who can compel access to them.
Every Stav inference response carries an X-Stav-Sovereignty-Tier header reporting which of three tiers actually served the request:
sovereign— Stav-hosted open-weights model, EU infrastructurerouted-commercial— commercial model proxied through Stavbyo— your own model on Stav infrastructure
Pick the right tier for the use case. They're not ranked — they're trade-offs.
Tier 1 — sovereign
The full-sovereign path. Stav hosts the model weights on hardware in EU jurisdictions (currently Green Mountain DC2 in Rjukan, Norway). Your prompt enters Stav infrastructure, runs through the model, and the completion leaves Stav infrastructure. No part of the request reaches a non-EU service.
Models in this tier: every open-weights catalogue entry tagged sovereign — Qwen3, Llama 4, Mistral, DeepSeek, Phi, Gemma, etc. Browse the full list at /v1/public/models?sovereignty_tier=sovereign.
What you get:
- Data residency. Prompts and completions are processed and logged inside the EU. Stav publishes the exact datacenter, jurisdiction, and operator for each sovereign model.
- No CLOUD Act exposure. The US CLOUD Act compels US service providers to hand over data on request from US law enforcement, regardless of where the data is stored. Stav AS is a Norwegian company with no US operations — the CLOUD Act has no jurisdiction over it. Compel-access requests would have to go through Norwegian courts under Norwegian law.
What you give up: the very latest frontier-model capabilities. The sovereign catalogue tracks frontier OSS releases closely, but you're typically 1-2 model generations behind the absolute frontier on closed-weight benchmarks.
Tier 2 — routed-commercial
Commercial model proxied through Stav. You send the request to Stav; Stav forwards it to OpenAI / Anthropic / Mistral La Plateforme / Google / xAI / Cohere over Stav's upstream relationship; the response comes back through Stav to you.
Models in this tier: every catalogue entry tagged routed-commercial — Claude, GPT-4 / GPT-5 family, Gemini, Mistral Large, Grok, Command R+, etc.
What you get:
What you give up:
- Sovereignty of the inference itself. The commercial vendor sees your prompt and computes the completion. Their terms of service apply to the content of that interaction in addition to Stav's. If the commercial vendor is a US company, the CLOUD Act applies to their data — though not retroactively to Stav's audit trail of the same exchange.
- Strict data-residency guarantees for the prompt content. The prompt is in transit to a non-EU service for the duration of the inference. The Stav-side audit log remains EU-resident.
Routed-commercial is the right tier for prototypes, frontier-capability workloads where regulatory sensitivity is lower, or workloads that explicitly need a specific commercial model. It is not the right tier for processing EU-personal-data under GDPR Articles 6, 9, 22 in a setting that requires processor-controller jurisdictional alignment.
Tier 3 — byo
Bring Your Own Model. You upload model weights to Stav (HuggingFace repo, custom fine-tune, distilled model, etc.), Stav runs them on dedicated Stav infrastructure in the EU, your team is the only consumer.
What you get:
- Same sovereignty profile as Tier 1. Inference runs on Stav-EU infrastructure. No third-party model vendor in the loop.
- Custom model behaviour. Fine-tuning, custom training data, distillation — whatever you brought.
- Predictable compute capacity. Dedicated GPUs rather than shared sovereign-pool capacity.
What you give up:
- The catalogue. BYO models aren't in the public catalogue; only your team can call them. You're responsible for the weights' performance, safety, and licensing.
- Cost predictability of the shared sovereign pool. BYO bills against your team plan's dedicated-compute budget rather than the per-token shared-pool rate.
How to choose
A rough decision rule:
- Default to
sovereign. If the catalogue has a model that fits the workload, use it. - Use
routed-commercialwhen you specifically need a frontier capability that the sovereign catalogue doesn't yet cover, and when your data classification policy permits non-EU processing of the prompt content. - Use
byowhen your workload depends on model weights that aren't public — fine-tunes, distillations, in-house pre-trains.
Reading the response
Every Stav response carries:
X-Stav-Sovereignty-Tier: sovereign
X-Request-Id: req-7a3f9c2e1b8d4a5f
If model="auto" (Smart Router) was used, the response body also includes routing_metadata.sovereignty_tier so you can log it as part of your application's audit trail without parsing headers.
The machine-readable taxonomy — names, descriptions, jurisdiction-by-tier — lives at /v1/public/sovereignty. Useful for in-app UI ("This response was served by a sovereign model in Norway") or for compliance dashboards.
Compliance documentation
Per-model EU AI Act compliance packs (Article 11 technical documentation, Annex IV summaries, deployer-side obligations under Articles 26 and 27) are available in the Customer Portal under Compliance → Model packs. Packs are signed and timestamped; if you're an Article 26 deployer of a high-risk system using a Stav model, these are designed to drop directly into your conformity-assessment file.
Next steps
- Quickstart — make your first call.
- API reference — every endpoint annotated with its sovereignty implications.
- Stav AI's commercial positioning — the why behind the architecture.