When sovereignty becomes a design constraint
Sourcing starts with a risk register now For a decade the infrastructure question had one default answer: put it in the …
The Phrase That Stopped Being Useful
For a long time, “EU-hosted” or “data stays in the EU” was a meaningful claim. A customer asked where their data lived; a vendor said “Frankfurt”; the customer was satisfied. The infrastructure underneath was clear: a database in a Frankfurt data center, a backup in Amsterdam, application servers in Dublin. Data lived where the vendor said it lived.
That phrase has quietly stopped being useful, for two reasons.
First, the cloud providers serving the EU are American-headquartered. AWS Frankfurt is operated by Amazon. Azure Frankfurt is operated by Microsoft. GCP Frankfurt is operated by Google. All three are subject to US law — specifically the CLOUD Act of 2018, which obligates US-headquartered companies to produce data on US legal request, regardless of where the data is physically stored. A Schrems II ruling in 2020 established that this is not theoretical — the European Court of Justice explicitly held that data hosted by US providers, even inside the EU, is not adequately protected from US government access.
Second, AI introduces an entirely new exfiltration vector. The data may live in Frankfurt, but when an AI application calls a foundation model, the request — including any context the application included — leaves the customer’s perimeter and goes to the model provider. If that provider is Anthropic, OpenAI, or Google, the inference request is now subject to a different legal jurisdiction than the data store. The data residency claim about the database is technically true; the data residency claim about what the model saw is a different question entirely.
For organizations that genuinely need data sovereignty — and not just the marketing posture of it — the architecture has to be different. “EU-hosted” is the start of the conversation, not the end.
What “Real” Data Residency Requires
┌───────────────────────────────────────────────────────────────┐
│ │
│ What customers asked for in 2018: │
│ "Keep our database in the EU." │
│ │
│ What customers ask for in 2026: │
│ 1. Database in the EU (still) │
│ 2. Application servers in the EU │
│ 3. Backups in the EU │
│ 4. Logs and telemetry in the EU │
│ 5. Operator access from EU staff or under EU controls │
│ 6. Cloud provider operating under EU sovereignty controls │
│ 7. AI inference inside the same perimeter │
│ 8. Audit evidence that all seven of these are real │
│ │
└───────────────────────────────────────────────────────────────┘
Items 1–4 are the classical residency picture. Most mid-market organizations have these in reasonable shape. Items 5–7 are where the real work of 2026 is happening, and where “EU-hosted on AWS” stops being a defensible answer for regulated workloads.
Item 5 — operator access from EU staff or under EU controls — is what Schrems II surfaced. The data is in Frankfurt; the cloud provider’s operators are in Seattle. Whose jurisdiction governs the operators? Schrems II concluded that, under the GDPR, it has to be EU jurisdiction for the residency claim to hold. The cloud providers responded with various “sovereign cloud” arrangements (AWS European Sovereign Cloud, Azure Local for sovereign customers, Google Sovereign Controls). These help but are still in early operational maturity.
Item 7 — AI inference inside the same perimeter — is the new requirement. The model providers (Anthropic, OpenAI, Google, Mistral, Cohere) each have different residency stories. Some offer EU-only endpoints. Some are inherently US-only. The picture is: if the inference call leaves the EU, the residency claim about the underlying data weakens proportional to what context the inference call carried.
The Three-Layer Residency Picture
┌──────────────────────────────────────────────────────────────┐
│ │
│ Layer 1 — Data residency │
│ ─────────────────────── │
│ Where does the structured data live? │
│ (Databases, object stores, backups, logs) │
│ Solved by: cloud-provider region selection │
│ │
│ Layer 2 — Operational residency │
│ ─────────────────────────────── │
│ Whose hands can touch the infrastructure? │
│ (Cloud operators, support staff, on-call) │
│ Solved by: sovereign-cloud arrangements, │
│ operator gating, EU-staffed support │
│ │
│ Layer 3 — Inference residency │
│ ───────────────────────────── │
│ Where do AI model calls actually go? │
│ (Prompts, context, outputs) │
│ Solved by: EU-hosted model providers (Mistral, │
│ some Anthropic/OpenAI regional endpoints), │
│ or open-source models running │
│ inside the perimeter (Ollama, vLLM) │
│ │
└──────────────────────────────────────────────────────────────┘
A real data residency posture in 2026 addresses all three layers. An organization that has only Layer 1 — “the database is in Frankfurt” — has the same posture they had in 2018, and it is no longer sufficient.
The hardest of the three to solve cleanly is Layer 3. The model providers’ regional availability changes quarterly. The features available on the EU endpoint of a given provider often lag the US endpoint by months. The cost may differ. The latency may differ. Organizations that need consistent Layer 3 residency need an architecture that handles the routing — not one that hopes the provider’s residency story stays stable.
What the Architecture Looks Like
The architectural response is a policy gateway that knows the residency requirements of every workload and routes inference accordingly:
┌──────────────────────────────────────────────────────────────┐
│ │
│ Application in EU cloud (Layer 1 + 2) │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────┐ │
│ │ Policy Gateway │ │
│ │ (knows residency requirements) │ │
│ └──────────────┬─────────────────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ EU-hosted EU-only Local │
│ Anthropic Mistral Ollama/vLLM │
│ endpoint (inside the │
│ EU cloud) │
│ │
│ The gateway picks per request, based on: │
│ - workload's residency requirement (strict/relaxed) │
│ - data classification in the request │
│ - model capability requirements │
│ - cost and latency budgets │
│ │
│ Every routing decision is recorded in the audit chain. │
│ │
└──────────────────────────────────────────────────────────────┘
This is what Zentinelle.ai does in the Calliope stack: every model call is mediated by the gateway, every call has a residency policy applied, and every routing decision is audit-trailed with the destination, the data classification, and the rationale.
For workloads that need strict Layer 3 residency — clinical-trial data, government data, financial-regulator data — the gateway can be configured to route only to EU-hosted Mistral endpoints or to local open-source models running inside the perimeter. For workloads where Layer 3 is relaxed, the gateway can route to the best-fit model regardless of region. The same gateway, the same audit chain, different policies per workload.
What Mid-Market Organizations Get Wrong
The most common mid-market data-residency mistake we see is uniform policy applied across uneven data. The organization picks “EU-hosted” as a blanket requirement, then discovers six months in that 80% of their workloads do not actually need it — and the cost of routing everything through EU endpoints is high for no compliance benefit.
The opposite mistake is no policy applied across uniform-sensitivity data. A general AI assistant for staff has different residency needs than a clinical-trial analysis pipeline; an organization that treats them identically either over-restricts the assistant (poor user experience) or under-restricts the pipeline (compliance risk).
The middle path is workload-specific residency policy, enforced by the gateway, audit-trailed for the regulator. This requires three things:
- Classification of workloads by residency requirement (strict / preferred / relaxed).
- Routing rules in the gateway that map each classification to acceptable model destinations.
- Continuous audit evidence that the rules were followed for every request.
A mid-market organization with ~10 distinct AI workloads might end up with 3–4 residency classifications and a clear routing table. A larger organization with ~50 distinct workloads might need 6–8. Either way, the architecture is the same; only the policy density changes.
Why BYOC Matters For Residency
Astrolift — running the customer’s AI runtime in the customer’s own cloud — is what makes Layer 1 and Layer 2 residency operationally tractable. The runtime lives in the cloud the customer already chose for residency purposes. Operator access is governed by the customer’s IAM, not by Calliope-operated infrastructure.
For Layer 2, this matters specifically because the operator-access question is about whose hands touch the system. When the runtime is hosted by Calliope, those hands are Calliope’s. When the runtime is in the customer’s cloud, those hands are the customer’s. The Schrems II concern about cloud-operator-jurisdiction is reduced — the cloud is still under US-provider control, but the runtime above it is under customer control, with audit evidence to prove it.
For organizations with extremely strict residency (defense, sovereign government, certain healthcare), the runtime can be deployed on a fully-sovereign cloud (Bleu, S3NS, Microsoft Cloud for Sovereignty), or on vanilla Kubernetes in an on-prem or air-gapped install. The same Astrolift runtime runs on all of these substrates.
The Compliance Evidence Story
The end-state for a residency posture is that, when a regulator asks “where did data go in the last 90 days,” the answer is a query. Every model call recorded with destination region. Every data classification tagged on every event. Every routing decision rationale audit-trailed.
This is true for both the model-call dimension and the operator-access dimension. With Zentinelle providing the audit chain and Astrolift providing the runtime audit, the two dimensions land in the same store, queryable together.
GDPR Article 30 (records of processing activities), the EU AI Act’s Article 12 (automatically generated logs for high-risk systems), and the data-residency clauses of sector-specific regulations (DORA, NIS2, HIPAA’s various provisions) all expect this kind of evidence. Producing it as a side effect of operating the platform — not as a deliverable produced at audit time — is how the architecture earns its keep.
Where to Go Next
- Astrolift — the BYOC runtime that lands inside the cloud you chose for residency.
- Zentinelle.ai — the policy gateway that enforces and audits inference residency.
- The three-pillar architecture — the technical foundation.
- Real-time GRC for AI agents — the audit chain detail.
- calliope.ai/contact — for a residency-specific architecture conversation.
Next in this series: the same residency argument, applied to pharmaceutical and life-sciences organizations, where clinical-trial data and patient PII carry the strictest jurisdictional rules in the regulated economy.
