> For the complete documentation index, see [llms.txt](https://docs.kontinent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kontinent.ai/best-practices/sovereignty-tiers.md).

# Choosing a sovereignty tier

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`    | Served by an **EU-owned** provider.                              |
| `pragmatic` | Served from an **EU region** of a provider with a non-EU parent. |

Both tiers are served from the EU. The difference is ownership of the provider, not where the request runs.

## A practical rule of thumb

* Use `strict` for regulated data, contractual EU-ownership requirements, or anything in scope for the EU AI Act's stricter obligations.
* Use `pragmatic` where 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 `strict` for the endpoints that handle sensitive data, and allow `pragmatic` elsewhere 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](/models-and-routing/models.md) and [Maximum privacy](/privacy/data-privacy.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kontinent.ai/best-practices/sovereignty-tiers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.