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.
Das 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 eben 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 erarbeiten sie sich, indem Sie auf europäischer Infrastruktur laufen, betrieben durch europäische Akteure, mit Open-Weight-Modellen, die Sie end-to-end kontrollieren, und indem Sie genau das für das Compliance-Team des Käufers dokumentieren. Der Stack, der das 2026 liefert, ist reif, performant und betrieblich kaum vom äquivalenten SaaS-Pfad zu unterscheiden, und bei einem DACH- oder Öffentlicher-Sektor-Deal zahlt sich das ersparte rechtliche Kopfzerbrechen 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.
Häufig gestellte Fragen
Ist 'EU-Region auf AWS' 2026 noch DSGVO-konform für KI?
Die Region allein reicht nicht. Nach Schrems II (2020) und der Reauthorisierung von FISA 702 im Jahr 2024 unterliegen EU-Regionen von US-Hyperscalern (AWS, Azure, Google Cloud) weiterhin US-extraterritorialen Zugriffsgesetzen. Das EU-US Data Privacy Framework bietet nur begrenzten Schutz und wird durch laufende Verfahren in Frage gestellt. Für Beschaffungsteams in regulierten Sektoren (Banken, Gesundheit, öffentlicher Sektor) genügt EU-Region-auf-US-Cloud allein nicht mehr für die DSGVO-Grenzübertritts-Hürde; Sie brauchen entweder EU-residente Infrastruktur oder ergänzende technische Schutzmaßnahmen (Verschlüsselung mit EU-gehaltenen Schlüsseln), die US-Zugriff sinnvoll verhindern.
Was hat Schrems II für KI-Hosting verändert?
Schrems II hat das EU-US-Privacy-Shield-Abkommen für ungültig erklärt und Standardvertragsklauseln allein als unzureichend bestätigt, wenn das Importland Überwachungsgesetze hat, die deren Schutz aushebeln. Für KI ist das besonders relevant, weil LLM-Inferenz oft Prompts übermittelt (die personenbezogene oder geschäftlich sensible Daten enthalten können) an US-gehostete Endpunkte. Self-Hosting auf europäischer Infrastruktur entfernt die Grenzübertritts-Frage komplett aus dem Rechts-Stack.
Verlangt der EU AI Act Self-Hosting?
Nein, der AI Act reguliert nach Risikoklasse (verboten, hoch, begrenzt, minimal) und Pflichten-Typ (Anbieter, Betreiber, Vertreiber), nicht nach Hosting-Standort. Aber der Act schichtet sich über DSGVO, NIS2 und Branchenrecht, und alle drei erzeugen Druck Richtung EU-residenter Infrastruktur für viele Anwendungsfälle. Der Act verlangt zudem detaillierte technische Dokumentation, Logging und menschliche Aufsicht für Hoch-Risiko-Systeme, leichter zu erfüllen, wenn Sie den Stack selbst kontrollieren.
Was ist der günstigste Weg zu einem selbst gehosteten EU-KI-Stack?
Eine praxistaugliche Basis für DACH-Käufer: Ein GPU-fähiger Mittelklasse-VPS (Hetzner GEX-Serie in Falkenstein oder Helsinki, etwa EUR 150-400 pro Monat) mit Docker, Ollama für Inferenz, PostgreSQL plus pgvector für Retrieval, und ein Next.js- oder FastAPI-Frontend. Das deckt die meisten internen LLM-Anwendungsfälle für ein kleines Team ab, Chatbot, RAG über interne Dokumente, Dokumenten-Klassifikation, ohne dass irgendeine US-kontrollierte Stack-Komponente beteiligt ist.
Beeinflusst NIS2 KI-Infrastruktur-Entscheidungen?
Ja. NIS2 (seit Oktober 2024 in Kraft) hat die Menge der als 'wesentlich' oder 'wichtig' eingestuften Organisationen erheblich erweitert, mit verpflichtenden Cybersecurity- und Vorfall-Meldepflichten. Für KI-Deployments innerhalb solcher Organisationen stärkt NIS2 das Argument für Self-Hosted oder EU-Cloud-Setups, weil Incident Response, Supply-Chain-Risikomanagement und die 24-Stunden-Meldepflicht für Vorfälle einfacher operationalisierbar sind, wenn Sie die Infrastruktur selbst kontrollieren.