Choosing a sovereignty tier
When to require strict, and when pragmatic is enough.
Every model declares a sovereignty tier of strict or pragmatic. Picking the right one per use case, rather than defaulting to one everywhere, gets you the widest model choice without giving up the residency guarantee your workload actually needs.
The two tiers
| Tier | Meaning |
|---|---|
strict | An EU-owned provider that Kontinent rates as sovereign. |
pragmatic | Served from the EU, but by a provider with a non-EU parent or one that runs on third-party cloud infrastructure. |
Both tiers are served from the EU. The difference is who owns the provider and whose infrastructure it runs on, not where the request runs.
A practical rule of thumb
- Use
strictfor regulated data, contractual EU-ownership requirements, or anything in scope for the EU AI Act's stricter obligations. - Use
pragmaticwhere EU processing is sufficient and you want access to the widest possible model catalog, including EU regions of larger non-EU providers. - Mix tiers across your application: require
strictfor the endpoints that handle sensitive data, and allowpragmaticelsewhere for cost or model choice.
Enforce it in code, not policy
GET /v1/models returns the tier on every model, so filter the catalog in your code instead of relying on a document somewhere that says which models are approved. That way the constraint moves with your deployment and survives catalog changes. See Models & sovereignty and Maximum privacy.