Compliance Guide

EU Data Sovereignty for AI: Self-Hosting in the Post-Schrems II Era

Nicholas Falshaw

·2026-04-28·12 min read

EU data sovereignty for AI in 2026 is no longer an architecture preference; it's a procurement filter. DACH enterprise buyers, German public-sector clients, and any organisation working under NIS2 or the EU AI Act now ask the same opening question on AI projects: where does the data actually live, and which jurisdiction can compel access to it? "EU region on a US hyperscaler" used to be an acceptable answer. After Schrems II, the EU-US Data Privacy Framework challenge, and the FISA 702 reauthorisation in 2024, it isn't.

This guide is a working operator's view of what changed, why self-hosted AI on European infrastructure is the path of least legal resistance for many use cases, and where it doesn't help. It's written for engineers and architects who have to defend their stack to a DPO, not for compliance teams writing internal policy.

The Legal Stack You Actually Have to Reason About

For an AI system processing personal data of EU residents in 2026, four regimes interact:

GDPR (still the foundation)

Lawful basis for processing, data subject rights, processor contracts, breach notification. AI doesn't change GDPR; it just stresses the existing controls — particularly purpose limitation and the right to explanation under Article 22.

EU AI Act (in force, phased)

High-risk AI systems carry documentation, human-oversight, and risk-management obligations. Most B2B AI tools land in "limited risk" — transparency duties, but no certification path. Foundation-model providers face their own obligations from mid-2025 onward.

NIS2 (operational security)

For essential and important entities, NIS2 sets minimum security controls and supply-chain risk obligations. AI tools used in covered entities inherit those obligations through the supplier chain. "We use OpenAI" has to survive the same supply-chain risk review as any other critical vendor.

Schrems II + the EU-US Data Privacy Framework

International transfers to the US ride on the 2023 adequacy decision under the EU-US DPF. That decision is under active challenge. Prudent organisations treat it as conditional and put a transfer impact assessment behind every transfer.

Why "EU Region" Isn't Sovereignty

The most common misunderstanding I encounter on enterprise AI projects: "we're using OpenAI's EU data residency, so we're sovereign". That statement conflates two different things — where the bytes sit and who can compel access to them.

The US Cloud Act

US-headquartered cloud providers can be compelled to produce data held by their subsidiaries anywhere in the world. EU data residency limits where the bytes are stored at rest; it does not limit extraterritorial US jurisdiction over the parent company.

FISA 702 and Section 702 surveillance

Section 702 reauthorisation in April 2024 preserved the surveillance framework that originally tripped Schrems II. EU data subjects' data, when accessible to a US "electronic communications service provider," remains within the legal scope of the regime that unsettled adequacy in the first place.

"Sovereign cloud" branding

Microsoft Cloud for Sovereignty, AWS European Sovereign Cloud, Google's "EU sovereign" partnerships — each is an improvement and none is a complete answer. The architecture splits operational personnel and infrastructure control; the corporate parent structure remains. Read the contracts; they're explicit.

The Transfer Impact Assessment Trap

Under the European Data Protection Board's recommendations, every international transfer needs a transfer impact assessment (TIA) examining the recipient country's legal regime against EU equivalence. TIAs for the US after Schrems II are deeply unconvincing on paper. The EU-US DPF allowed organisations to skip parts of the analysis; if the DPF is invalidated again, every TIA waiting on that adequacy decision becomes inadequate overnight.

The pragmatic consequence: if your AI architecture depends on cross-Atlantic transfers, you carry residual legal risk that's not under your control. For high-stakes processing — health, legal, financial advice, critical infrastructure — that residual risk is what kills the deal in procurement.

Self-Hosting on EU Infrastructure: What It Actually Buys You

Running AI on Hetzner, OVH, IONOS, Scaleway — or your own racks — gives you something a sovereign-cloud SKU from a US hyperscaler doesn't: the legal entity providing the infrastructure is European, subject only to European jurisdiction, and your data never leaves a regime where the rule of law is the GDPR.

One legal forum

Disputes, subpoenas, breach notifications — all under European law, in European languages, with European supervisory authorities. No "we'll have to ask our US legal team" detours.

Foreign access blocking statutes apply

Article 48 of GDPR and the EU's foreign-judgment-blocking framework actually have force when the processor is exclusively European. They become advisory the moment a US parent enters the picture.

Reduced TIA burden

With no international transfers in the architecture, the TIA chapter of your records of processing collapses to "n/a, processed in the EU only by EU-controlled entities." Procurement loves this answer; auditors love this answer.

What Self-Hosting Doesn't Solve

Self-hosting is not a compliance silver bullet. The following remain your responsibility regardless of where the metal sits:

Lawful basis under GDPR Article 6 / 9. Where the data is processed doesn't make the processing lawful.
Records of processing (Article 30). You still document purposes, recipients, retention, and safeguards. Self-hosting just makes the safeguards section easier.
Data Protection Impact Assessments. High-risk processing (large-scale profiling, special categories, systematic monitoring) requires a DPIA whether the model runs locally or in a cloud.
Technical and organisational measures. Self-hosting is one TOM among many; encryption, access control, audit logging, and incident response still need to exist.
Subprocessor management. If your self-hosted AI tool sends embeddings to a US-based vector database SaaS, the cross-border transfer is back. Audit your stack end-to-end.

A Pragmatic Compliance-Aware Stack

What I run, and what passes a German DPO review on the first read, looks like this:

Compute

Hetzner dedicated server in Germany. Hetzner GmbH is a German legal entity, no foreign parent, ISO 27001 certified, hosting in EU-located data centres. Equivalent options: OVHcloud (France), IONOS (Germany), Scaleway (France).

Inference

Ollama running locally with open-weight models — Llama, Mistral, Qwen, Phi. The model weights are on your disk, no calls leave the host, no telemetry. For higher-quality or high-throughput needs, Mistral La Plateforme is an EU-based hosted alternative.

Vector and operational data

Postgres with pgvector on the same EU host. No SaaS vector databases, no managed embeddings services, no external telemetry. Backups encrypted and stored on EU object storage with the same provider.

Auxiliary services

Email transport via an EU provider (Mailgun EU, Postmark EU region, or a self-hosted Postfix). DNS via an EU provider with DNSSEC. Monitoring via self-hosted Grafana / Prometheus, not third-party SaaS shipping logs out of region.

When Cloud APIs Become Acceptable

I'm not a self-hosting purist. There are workloads where calling a US cloud API is fine, and others where it's negligent. The dividing line usually sits on three questions:

Does the prompt or response contain personal data of EU residents, and is the basis for processing dependent on a transfer mechanism you'd hate to defend?
Is the data special-category, financial, health, legal, or covered by professional secrecy regimes?
Is the processing high-risk under the AI Act, or covered by NIS2 in the consuming organisation?

Three "no" answers and an OpenAI / Anthropic call is fine — the cost and quality argument carries the day. One "yes" and you owe a serious TIA. Two "yes" and self-hosting on EU infrastructure is the path of least regret.

The DACH Client Conversation

German, Austrian, and Swiss enterprise procurement has a particular flavour that anyone selling AI services into DACH should be ready for. The typical opening sequence runs: where is the data processed; who has access; what's the contractual recourse if it leaks; have you done a DPIA on this specific use case; can your architecture survive the next Schrems decision unchanged. Self-hosting on Hetzner answers four out of five of those before anyone has to draft anything.

For public-sector tenders specifically, sovereign-by-architecture is increasingly a hard requirement, not a preference. The 2024 wave of federal-level guidance in Germany (BSI's C5 cloud criteria, BAYERN-CLOUD-style regional initiatives) explicitly favours EU-only supply chains. Your AI stack is now in that conversation.

Closing

Sovereignty is an architectural property, not a marketing claim. You get it by running on European infrastructure operated by European entities, using open-weight models you control end-to-end, and documenting that fact for the buyer's compliance team. The technical stack that delivers this in 2026 is mature, performant, and operationally close to indistinguishable from the equivalent SaaS path. The legal headache savings on a DACH or public-sector deal pay for it many times over.