EU-Datensouveränität für KI: Self-Hosting nach Schrems II
EU-Datensouveränität für KI ist 2026 keine Architektur-Vorliebe mehr, sondern ein Beschaffungsfilter. DACH-Enterprise-Einkäufer, deutsche öffentliche Auftraggeber und jede Organisation unter NIS2 oder dem EU AI Act stellen bei KI-Projekten dieselbe Eröffnungsfrage: Wo liegen die Daten tatsächlich, und welche Jurisdiktion kann Zugriff erzwingen? „EU-Region auf einem US-Hyperscaler" war früher eine akzeptable Antwort. Nach Schrems II, der Klage gegen das EU-US-Data-Privacy-Framework und der FISA-702-Reauthorisierung 2024 ist sie es nicht mehr.
Dieser Leitfaden ist die praktische Sicht eines Betreibers darauf, was sich verändert hat, warum selbst gehostete KI auf europäischer Infrastruktur für viele Anwendungsfälle der rechtlich einfachste Weg ist und wo sie nicht hilft. Geschrieben für Engineers und Architekten, die ihren Stack gegenüber einem Datenschutzbeauftragten verteidigen müssen — nicht für Compliance-Teams, die interne Policies schreiben.
Der rechtliche Rahmen, mit dem Sie tatsächlich umgehen müssen
Für ein KI-System, das personenbezogene Daten von EU-Bürgern 2026 verarbeitet, greifen vier Regime ineinander:
DSGVO (weiterhin das Fundament)
Rechtsgrundlage der Verarbeitung, Betroffenenrechte, Auftragsverarbeiter-Verträge, Meldepflichten. KI ändert die DSGVO nicht; sie stresst die bestehenden Kontrollen — besonders die Zweckbindung und das Recht auf Erklärung nach Artikel 22.
EU AI Act (in Kraft, gestaffelt)
Hochrisiko-KI-Systeme tragen Dokumentations-, menschliche Aufsichts- und Risikomanagement-Pflichten. Die meisten B2B-KI-Tools landen bei „Limited Risk" — Transparenzpflichten ohne Zertifizierungspfad. Foundation-Model-Anbieter haben ab Mitte 2025 eigene Pflichten.
NIS2 (operative Sicherheit)
Für wesentliche und wichtige Einrichtungen legt NIS2 Mindest-Sicherheitskontrollen und Lieferketten-Risikopflichten fest. KI-Tools, die in betroffenen Einrichtungen genutzt werden, erben diese Pflichten über die Lieferkette. „Wir nutzen OpenAI" muss dieselbe Lieferanten-Risikoprüfung überstehen wie jeder andere kritische Vendor.
Schrems II + EU-US-Data-Privacy-Framework
Internationale Datentransfers in die USA stützen sich auf den Angemessenheitsbeschluss von 2023 unter dem EU-US-DPF. Diese Entscheidung wird aktiv beklagt. Vorsichtige Organisationen behandeln sie als bedingt und legen jedem Transfer eine Transfer-Folgenabschätzung zugrunde.
Warum „EU-Region" keine Souveränität ist
Das häufigste Missverständnis in Enterprise-KI-Projekten: „Wir nutzen OpenAIs EU-Datenresidenz, also sind wir souverän." Diese Aussage vermischt zwei verschiedene Dinge — wo die Bytes liegen und wer Zugriff erzwingen kann.
Der US Cloud Act
US-amerikanische Cloud-Anbieter können gezwungen werden, Daten herauszugeben, die ihre Tochtergesellschaften weltweit halten. EU-Datenresidenz begrenzt, wo die Bytes ruhen — sie begrenzt nicht die extraterritoriale US-Jurisdiktion über die Konzernmutter.
FISA 702 und Section-702-Überwachung
Die Reauthorisierung von Section 702 im April 2024 hat das Überwachungsregime erhalten, das ursprünglich Schrems II ausgelöst hat. Daten von EU-Betroffenen, sobald sie für einen US-„Electronic-Communications-Service-Provider" erreichbar sind, bleiben im rechtlichen Rahmen, der die Angemessenheit ursprünglich gekippt hat.
„Sovereign-Cloud"-Branding
Microsoft Cloud for Sovereignty, AWS European Sovereign Cloud, Googles „EU-souveräne" Partnerschaften — jede ist eine Verbesserung und keine vollständige Antwort. Die Architektur trennt Personal und Infrastruktur-Kontrolle; die Konzernstruktur der Mutter bleibt. Lesen Sie die Verträge; sie sind explizit.
Die Falle der Transfer-Folgenabschätzung
Nach den Empfehlungen des Europäischen Datenschutzausschusses braucht jeder internationale Transfer eine Transfer-Folgenabschätzung (TIA), die das Rechtsregime des Empfängerlandes gegen EU-Äquivalenz prüft. TIAs für die USA nach Schrems II sind auf dem Papier wenig überzeugend. Der EU-US-DPF erlaubte es, Teile der Analyse zu überspringen; sollte das DPF erneut gekippt werden, ist jede TIA, die auf diesem Angemessenheitsbeschluss basierte, über Nacht unzureichend.
Die pragmatische Konsequenz: Wenn Ihre KI-Architektur von transatlantischen Transfers abhängt, tragen Sie ein rechtliches Restrisiko, das nicht in Ihrer Kontrolle liegt. Bei hochsensiblen Verarbeitungen — Gesundheit, Recht, Finanzberatung, kritische Infrastruktur — ist dieses Restrisiko das, was den Deal in der Beschaffung killt.
Self-Hosting auf EU-Infrastruktur: Was Sie damit gewinnen
KI auf Hetzner, OVH, IONOS, Scaleway — oder im eigenen Rack — zu betreiben gibt Ihnen etwas, das ein Sovereign-Cloud-SKU eines US-Hyperscalers nicht kann: Die juristische Person, die die Infrastruktur stellt, ist europäisch, unterliegt nur europäischer Jurisdiktion, und Ihre Daten verlassen kein Regime, in dem die DSGVO der Maßstab ist.
Ein einziges Rechts-Forum
Streitigkeiten, Vorladungen, Meldungen — alles unter europäischem Recht, in europäischen Sprachen, mit europäischen Aufsichtsbehörden. Keine „Wir müssen unser US-Rechtsteam fragen"-Umwege.
Foreign-Access-Blocking-Statute greifen
Artikel 48 DSGVO und der EU-Rahmen gegen Drittstaaten-Urteile haben tatsächlich Wirkung, wenn der Auftragsverarbeiter ausschließlich europäisch ist. Sie werden beratend, sobald eine US-Mutter ins Spiel kommt.
Reduzierte TIA-Last
Ohne internationale Transfers in der Architektur kollabiert das TIA-Kapitel im Verzeichnis von Verarbeitungstätigkeiten zu „n/z, ausschließlich in der EU verarbeitet durch EU-Akteure." Beschaffung liebt diese Antwort; Auditoren ebenfalls.
Was Self-Hosting nicht löst
Self-Hosting ist keine Compliance-Wunderwaffe. Folgendes bleibt unabhängig vom Standort der Hardware Ihre Verantwortung:
- Rechtsgrundlage nach Art. 6 / 9 DSGVO. Wo Daten verarbeitet werden, macht die Verarbeitung nicht rechtmäßig.
- Verzeichnis von Verarbeitungstätigkeiten (Art. 30). Zwecke, Empfänger, Aufbewahrung und Schutzmaßnahmen werden weiter dokumentiert. Self-Hosting macht nur den Schutzmaßnahmen-Teil leichter.
- Datenschutz-Folgenabschätzungen. Hochrisiko-Verarbeitung (großflächiges Profiling, besondere Kategorien, systematische Überwachung) verlangt eine DSFA, egal ob das Modell lokal oder in einer Cloud läuft.
- Technische und organisatorische Maßnahmen. Self-Hosting ist eine TOM unter vielen; Verschlüsselung, Zugriffskontrolle, Audit-Logging und Incident Response müssen weiter existieren.
- Subprozessor-Management. Wenn Ihr selbst gehostetes KI-Tool Embeddings an einen US-basierten Vector-Database-SaaS schickt, ist der Drittlandtransfer wieder da. End-to-End auditieren.
Ein pragmatisch compliance-orientierter Stack
Was ich betreibe und was ein deutscher DSB beim ersten Lesen durchwinkt, sieht so aus:
Compute
Hetzner Dedicated Server in Deutschland. Hetzner GmbH ist eine deutsche juristische Person ohne ausländische Mutter, ISO-27001-zertifiziert, Hosting in EU-Rechenzentren. Äquivalente Optionen: OVHcloud (Frankreich), IONOS (Deutschland), Scaleway (Frankreich).
Inferenz
Ollama lokal mit Open-Weight-Modellen — Llama, Mistral, Qwen, Phi. Die Modellgewichte liegen auf Ihrer Disk, kein Call verlässt den Host, keine Telemetrie. Für höhere Qualität oder Durchsatz ist Mistral La Plateforme eine EU-basierte gehostete Alternative.
Vektor- und Betriebsdaten
Postgres mit pgvector auf demselben EU-Host. Keine SaaS-Vektordatenbanken, keine gemanagten Embedding-Services, keine externe Telemetrie. Backups verschlüsselt und auf EU-Object-Storage desselben Anbieters.
Hilfsdienste
E-Mail-Versand über einen EU-Anbieter (Mailgun EU, Postmark EU-Region, oder selbst gehostetes Postfix). DNS über einen EU-Anbieter mit DNSSEC. Monitoring über selbst gehostetes Grafana / Prometheus, keine Drittanbieter-SaaS, die Logs außer Region versendet.
Wann Cloud-APIs akzeptabel werden
Ich bin kein Self-Hosting-Purist. Es gibt Workloads, bei denen ein US-Cloud-API-Call in Ordnung ist, und andere, bei denen er fahrlässig ist. Die Trennlinie liegt meist auf drei Fragen:
- Enthält der Prompt oder die Antwort personenbezogene Daten von EU-Bürgern, und hängt die Verarbeitungsgrundlage an einem Transfer-Mechanismus, den Sie ungern verteidigen würden?
- Sind die Daten besondere Kategorien, finanzieller, medizinischer, rechtlicher Natur oder unterliegen Berufsgeheimnissen?
- Ist die Verarbeitung Hochrisiko unter dem AI Act oder fällt sie beim verbrauchenden Unternehmen unter NIS2?
Drei „Nein" und ein OpenAI- / Anthropic-Call ist ok — das Kosten-Qualitäts-Argument trägt. Ein „Ja" und Sie schulden eine ernsthafte TIA. Zwei „Ja" und Self-Hosting auf EU-Infrastruktur ist der Pfad mit dem geringsten Bedauern.
Das DACH-Kunden-Gespräch
DACH-Enterprise-Beschaffung hat eine eigene Note, auf die jeder, der KI-Services in den DACH-Raum verkauft, vorbereitet sein sollte. Die typische Eröffnung: Wo werden die Daten verarbeitet; wer hat Zugriff; welche vertraglichen Rechtsmittel gibt es bei Lecks; haben Sie eine DSFA für genau diesen Use Case; übersteht Ihre Architektur die nächste Schrems-Entscheidung unverändert? Self-Hosting auf Hetzner beantwortet vier von fünf, bevor jemand etwas aufsetzen muss.
Speziell bei Ausschreibungen im öffentlichen Sektor wird Sovereign-by-Architecture zunehmend harte Anforderung statt Präferenz. Die Bundesleitlinien-Welle 2024 in Deutschland (BSI-C5-Cloud-Kriterien, BAYERN-CLOUD-artige regionale Initiativen) bevorzugt explizit reine EU-Lieferketten. Ihr KI-Stack ist nun Teil dieses Gesprächs.
Fazit
Souveränität ist eine architektonische Eigenschaft, kein Marketing-Anspruch. Sie bekommen sie, indem Sie auf europäischer Infrastruktur betrieben durch europäische Akteure laufen, mit Open-Weight-Modellen, die Sie end-to-end kontrollieren, und indem Sie diese Tatsache für das Compliance-Team des Käufers dokumentieren. Der technische Stack, der das 2026 liefert, ist reif, performant und betrieblich nahezu nicht vom äquivalenten SaaS-Pfad zu unterscheiden. Die Ersparnis an rechtlichem Kopfzerbrechen bei einem DACH- oder öffentlichen-Sektor-Deal zahlt sich vielfach aus.
Verwandt: selbst gehostete KI vs. Cloud-APIs, EU AI Act Compliance für KI-Entwickler, und produktive Docker-Patterns für KI-Anwendungen.