EU Data Sovereignty & Sovereign AI Routing

The Residency Attribute & Tiered Routing

The gateway cannot infer sensitivity from a prompt alone. Every object that the platform controls therefore carries either a tier or a residency attribute: tools and MCP servers are registered with a maximum data tier they may return; agent profiles and virtual keys carry a clearance tier; model deployments carry both a maximum tier and a residency attribute such as EU or US. The request or session carries the highest tier touched so far as a runtime taint. The policy evaluated on every call is simple and enforceable: data tier touched <= min(user clearance, agent clearance, model max tier). Once a session has read Confidential data, it cannot be sent to a model deployment approved only for Internal.

DLP detectors add a second signal. Secrets, credentials, PII and customer identifiers are scanned on input and output, and a detector hit can raise the session tier. The combination of declared tier and detected content means the routing decision is checkable and reproducible, not a guess. Fallback is also governed: a fallback target must satisfy the same tier and residency as the primary target, so a reliability event never becomes a routing escape.

The sovereignty model is built on three boundaries, not one. The Customer boundary holds credentials, tool execution and raw source-system access; these never leave it. The Approved processing boundary allows Confidential data to be processed by approved EU-resident processors under Article 28 DPAs. The Restricted boundary is reserved for self-hosted or sovereign deployments, or is blocked by default. Because tool execution and credentials live inside the customer boundary, sovereignty does not depend on trusting every model provider perfectly.

Object	Carries	Set by
Tool / MCP server	Maximum data tier it can return	Registration in the tool hub
Agent profile	Clearance tier	Agent registry
Virtual key / user group	Clearance tier	Identity group mapping
Model deployment	Maximum tier and residency attribute	Gateway model config
Request / session	Highest tier touched so far (taint)	Runtime, updated when tools return data

EU API Gateways vs. Sovereign Specialists

EU routing comes in three classes, from least to most control. The right choice depends on the data tier, latency tolerance and how much of the stack the customer wants to operate. An EU API gateway is a routing and billing layer; inference still runs on upstream GPUs inside the EU. Sovereign specialists add stricter legal guarantees and NIS2 compliance. Managed EU cloud inference removes the third-party gateway entirely but requires the customer to operate more of the stack.

Provider class	Examples	What it provides	Cost / trade-offs
EU API gateways	Requesty EUrouter Eden AI	OpenAI-compatible aggregation of open-weight models routed only through EU data centers. Article 28 DPAs, zero-retention payload defaults.	Roughly 5-15% premium over global aggregators; smaller catalog; EU GPU pools can mean peak-hour latency.
Sovereign specialists	Apertus AI Nordference	Built for regulated industries. NIS2 compliance, zero retention, strict sovereignty guarantees.	Higher prices, narrower model catalog.
Managed EU cloud inference	Scaleway OVHcloud IONOS	Open-weight models on EU infrastructure via managed endpoints or GPU instances. No third-party gateway.	Customer operates more of the stack; closest to self-hosting without owning GPUs.

The EU premium reality

The cost gap is smaller than often assumed. For mainstream open models such as Qwen 2.5 72B and Kimi K2.6, EU gateway prices are within about 5% of global aggregators; Requesty states it adds only a ~5% margin. The premium reaches 10-15% mainly on new or supply-constrained models. Provider prompt caching offsets part of the difference: cache-hit input costs for DeepSeek V4 Flash can drop to $0.007 per 1M tokens. EU provider spend appears as separate cost lines in FinOps so the premium is visible and allocable, not hidden.

Article 28 DPAs & Zero-Retention Defaults

EU providers operate under GDPR Article 28 Data Processing Agreements that legally bind them to the customer's data protection rules. This is a contractual default, not an opt-in privacy mode. The contrast with many US providers is operational: the latter often require manual toggling of a "privacy mode" to stop prompt logging, which creates audit risk if a toggle is missed. The EU default removes that dependency.

Zero-retention applies to payloads. Gateway logs carry metadata only: timestamps, token counts, model requested, cost, latency. Payload logging is off by default for Confidential and above, matching the logging privacy policy. EU DPAs also include explicit prohibitions on using API traffic for training, fine-tuning or improving future models. For EU customers, the combination of EU jurisdiction, Article 28 DPAs and zero-retention defaults is designed to minimize exposure to extraterritorial data-access requests, including those issued under the US CLOUD Act. No legal structure can eliminate every risk, but the architecture deliberately reduces exposure compared with routing the same data through US-controlled providers.

NIS2 alignment matters for essential and important entities. Sovereign specialists such as Nordference are NIS2-compliant, and the provider catalog records both the gateway and the upstream inference provider so routing policy can forbid fallback to non-EU upstream nodes. Prompts live transiently in GPU memory for seconds; the logging, residency and retention controls are what remain as evidence.

Control	What it means in practice
Article 28 DPA	Contractual default binding the processor to the customer's data-protection rules
Zero-retention payloads	Gateway logs carry metadata only; payload logging off by default for Confidential and above
No training use	DPA explicitly forbids using API traffic to train, fine-tune or improve future models
Residency + upstream tracking	Catalog records gateway and upstream provider; fallback blocked to non-EU upstream nodes
Minimized extraterritorial exposure	EU jurisdiction, DPAs and zero-retention defaults reduce exposure to extraterritorial data-access requests

Localized Memory & Vector Stores

Embeddings of Confidential content and above never leave the platform. The memory service scopes data per user, per agent, per team and organization knowledge, and each item carries the tier of its source. Retrieval checks the requester's clearance before returning a memory item, so a user with Internal clearance cannot recall a Confidential team memory. Cross-scope reads are blocked by policy and tested in the evaluation suite.

The vector store runs on pgvector on managed PostgreSQL, keeping embeddings in-house. There is no external memory SaaS for Confidential or Restricted data. Self-hosted embeddings, such as BGE served by Infinity, keep Confidential text out of provider embedding APIs. Reference memory options include Mem0 for user, agent and session scopes, and Cognee where explicit forget and delete APIs on a single Postgres are valued. Graphiti remains an option for temporal incident history but requires Neo4j or FalkorDB.

Retention and deletion are first-class functions, not afterthoughts. Each memory scope has a TTL. Users can view and delete personal memory. Offboarding triggers verified deletion that is propagated to backups within the backup retention window. This keeps the data lifecycle aligned with GDPR and works-council expectations, not just the live query path.