# Regions & data sovereignty

# Regions & data sovereignty

Porten is built to be **EU-sovereign**: the Hub and the nodes it routes to run on European-owned infrastructure, not the EU regions of US-owned clouds. If data residency matters to you, this is the point of the project.

## Region-pinned API keys

An API key can be restricted to one or more regions. A request made with that key only routes to nodes in those regions; if none can serve the model there, you get a clear error rather than a silent fall-back to another region.

- Set a key's regions in the portal under [API keys](/build/keys).
- A request that can't be satisfied within the key's allowed regions returns `403 model_not_allowed` or `404 model_not_found` (no eligible node), never a cross-region route.

## Node trust classes

Nodes carry an operator-assigned **trust class** (e.g. community, verified, trusted, confidential). A key's policy can require a minimum class, so sensitive workloads only land on vetted nodes. Region and class are operator-authoritative — a node can't self-declare them — so routing guarantees like "EU-only, trusted-only" hold.

## What's logged

Usage is metered per request (model, token counts, timestamp) for billing and abuse prevention. Prompt and completion **content** is not part of the durable usage record. See the portal's account and usage views for what's retained.

> If you're evaluating Porten for a regulated workload, the combination of region-pinned keys + minimum node class is the mechanism that keeps inference on infrastructure you trust.