EU-gehostete vs. US-LLMs: Datensouveränität, Drittlandtransfer & On-Premise — der rechtlich-technische Leitfaden (Stand 2025)

Sie haben sich entschieden, ein Large Language Model produktiv einzusetzen. Die schwierigere Frage kommt erst jetzt: Wo läuft das Modell, wer kann auf Ihre Daten zugreifen — und welches Recht gilt im Ernstfall? Genau hier scheitern die meisten KI-Projekte im Mittelstand nicht an der Technik, sondern an einer ungeklärten Souveränitätsfrage. Ein Rechenzentrum in Frankfurt klingt sicher. Ob es das ist, hängt von etwas ganz anderem ab als von der Flagge auf der Website des Anbieters.

Dieser Leitfaden trennt Marketing von Recht. Er zeigt, warum US-Modelle ein reales Drittland-Risiko tragen, warum ein EU-Rechenzentrum allein keine Firewall ist, welche europäischen und lokalen Alternativen es inzwischen wirklich gibt — und nach welcher Logik Sie sich entscheiden sollten. Geschrieben aus der Doppelperspektive: erst die juristische Pflicht, dann die technische Umsetzung.

Was bedeutet datensouveräne KI?

Datensouveräne KI bedeutet, dass Sie die vollständige Kontrolle über Ort, Zugriff und anwendbares Recht der Datenverarbeitung behalten. Konkret: Ihre Daten liegen in einem Rechtsraum, dem Sie vertrauen, kein Dritter kann ohne Ihre Kontrolle darauf zugreifen, und kein ausländisches Gesetz kann den Anbieter zur heimlichen Herausgabe zwingen. Souveränität ist also keine Eigenschaft des Modells, sondern der gesamten Verarbeitungskette — Standort, Betreiber, Vertrag und Konfiguration zusammen.

Das ist der Kerngedanke dieses Artikels: Compliance entsteht aus Vertrag, Konfiguration, Standort und Kontrolle über den Anbieter — nicht aus dem Markennamen oder der Flagge am Rechenzentrum.

Warum US-LLMs ein Souveränitäts-Risiko sind

US-Modelle wie GPT, Claude oder Gemini sind technisch hervorragend. Ihr Problem ist nicht die Qualität, sondern die Jurisdiktion ihres Betreibers. Drei Hebel greifen ineinander.

Der CLOUD Act: Zugriff unabhängig vom Speicherort

Der U.S. CLOUD Act (2018) verpflichtet US-Unternehmen, auf Anordnung US-amerikanischer Behörden Daten herauszugeben — und zwar unabhängig davon, wo auf der Welt die Daten gespeichert sind. Ein US-Konzern, der Daten in einem deutschen Rechenzentrum hält, unterliegt dieser Anordnung genauso wie in den USA. Der physische Standort der Festplatte schützt also nicht; entscheidend ist, welcher Jurisdiktion der Betreiber unterliegt.

Drittlandtransfer und Schrems II

Sobald personenbezogene Daten an einen US-Anbieter fließen, greift Kapitel V der DSGVO (Art. 44–50, Drittlandübermittlung). Der EuGH hat im Urteil Schrems II (C-311/18, 16.07.2020) den damaligen „Privacy Shield” gekippt, weil US-Überwachungsgesetze (insb. FISA Section 702) keinen der EU gleichwertigen Schutz boten. Seitdem ist jeder Transfer in die USA begründungspflichtig.

Der unauflösbare Normkonflikt: CLOUD Act vs. Art. 48 DSGVO

Hier liegt der juristische Kern. Art. 48 DSGVO verlangt, dass Gerichts- oder Behördenanordnungen eines Drittlands nur dann zur Datenherausgabe führen dürfen, wenn sie auf einem internationalen Rechtshilfeabkommen beruhen. Eine direkte CLOUD-Act-Anordnung erfüllt das nicht. Der Europäische Datenschutzausschuss (EDSA/EDPB) hat in seiner gemeinsamen Stellungnahme mit dem EDPS (Juli 2019) klargestellt, dass eine solche Herausgabe nur in eng begrenzten Ausnahmefällen DSGVO-konform ist.

Ergebnis: Ein US-Anbieter, der eine CLOUD-Act-Anordnung erhält, steht vor einer echten Zwickmühle — entweder er bricht US-Recht oder er bricht die DSGVO. Diesen Konflikt kann kein Vertrag und kein EU-Rechenzentrum vollständig auflösen.

Schützt ein EU-Rechenzentrum vor dem CLOUD Act?

Nein — ein EU-Rechenzentrum allein schützt nicht vor dem CLOUD Act. Entscheidend ist nicht, wo die Daten liegen, sondern welcher Jurisdiktion der Betreiber unterliegt. Betreibt ein US-Konzern (oder dessen EU-Tochter, die vom US-Mutterkonzern beherrscht wird) das Rechenzentrum in Frankfurt, bleibt er CLOUD-Act-exponiert. Die Flagge am Gebäude ändert daran nichts.

Eine echte Firewall entsteht erst, wenn der Betreiber ausschließlich europäischem Recht unterliegt und nicht von einer US-Muttergesellschaft kontrolliert wird — also bei einer „Sovereign Cloud” im engeren Sinne oder beim Betrieb in den eigenen vier Wänden (On-Premise).

Ist das EU-US Data Privacy Framework eine sichere Grundlage?

Das EU-US Data Privacy Framework (DPF) ist seit dem Angemessenheitsbeschluss der EU-Kommission vom 10.07.2023 in Kraft. Für zertifizierte US-Unternehmen ermöglicht es Datentransfers ohne zusätzliche Garantien. Es ist eine gültige, aber wackelige Rechtsgrundlage — und es löst die CLOUD-Act-Exposition ausdrücklich nicht.

Stand Dezember 2025 ist die Lage so: Die Nichtigkeitsklage des Abgeordneten Philippe Latombe wurde vom Gericht der EU (EuG) am 03.09.2025 abgewiesen — das DPF gilt damit zunächst weiter. Gegen dieses Urteil wurde jedoch Ende Oktober 2025 Rechtsmittel zum EuGH eingelegt (Rs. C-703/25 P), das noch anhängig ist. Parallel sehen viele Datenschützer ein „Schrems III” am Horizont. Zusätzlich beunruhigend: Das US-Aufsichtsgremium PCLOB, das die Einhaltung des DPF überwachen soll, ist seit der Abberufung mehrerer Mitglieder Anfang 2025 faktisch nicht mehr beschlussfähig.

Praktische Konsequenz: Wer das DPF als alleinige Grundlage für hochsensible Daten nutzt, baut auf eine Konstruktion mit messbarem Rest- und Wechselrisiko. Für unkritische Daten kann es tragen; für Geschäftsgeheimnisse und besondere Datenkategorien sollte es nicht das einzige Standbein sein.

Hinweis: Der DPF-/Schrems-Status ist volatil. Prüfen Sie den Stand vor jeder weitreichenden Entscheidung erneut.

Die vier Souveränitäts-Stufen im Vergleich

In der Praxis gibt es nicht „US vs. EU”, sondern ein Spektrum von vier Stufen. Jede hat ihren legitimen Platz — abhängig davon, wie schutzbedürftig Ihre Daten sind.

Stufe	Datenhoheit	CLOUD-Act-Restrisiko	Typische Kosten	Aufwand / Latenz	Geeignet für
1. US-Cloud-API (AVV + Zero Data Retention)	gering	hoch	niedrig (Pay-per-Token)	gering, sofort	öffentliche/unkritische Daten
2. EU-Region eines US-Anbieters (Azure EU, AWS Frankfurt)	mittel	mittel–hoch (US-Mutter)	niedrig–mittel	gering	mäßig sensible Daten, mit AVV
3. Sovereign Cloud (EU-Betreiber, EU-Recht)	hoch	niedrig	mittel	mittel	personenbezogene & vertrauliche Daten
4. On-Premise / lokal	vollständig	keines	hoch (CapEx)	hoch, eigene Wartung	Geschäftsgeheimnisse, besondere Kategorien

Die Tabelle zeigt das eigentliche Trade-off: Je höher die Souveränität, desto höher Aufwand und Kosten — aber desto geringer das rechtliche Restrisiko. Die Kunst besteht darin, nicht alles auf eine Stufe zu zwingen, sondern Datenklassen gezielt zuzuordnen (dazu unten der Entscheidungs-Leitfaden).

Das Souveränitäts-Spektrum: Mit jeder Stufe steigt die Kontrolle über Standort, Zugriff und anwendbares Recht — und sinkt das CLOUD-Act-Restrisiko. Die richtige Wahl ordnet jede Datenklasse der passenden Stufe zu, statt das ganze Unternehmen in eine zu pressen.

Welche LLMs sind in der EU gehostet oder europäisch?

Die europäische Modell-Landschaft hat zuletzt deutlich aufgeholt. Die wichtigsten Optionen:

• Mistral AI (Frankreich) — leistungsstarke Modelle, mehrere davon unter offener Lizenz (u. a. Apache 2.0) und damit self-hostbar; daneben eine EU-betriebene API.
• Aleph Alpha (Deutschland) — die Pharia-Modellfamilie ist auf Deutsch, Französisch und Spanisch optimiert und wird ausdrücklich für On-Premise- und Sovereign-Cloud-Betrieb ausgeliefert (Gewichte + Inferenz-Runtime).
• Teuken-7B (OpenGPT-X) — ein in 24 EU-Amtssprachen trainiertes, quelloffenes Forschungsmodell (Fraunhofer u. a.), frei über Hugging Face beziehbar. Das Förderprojekt endete im März 2025; das Modell bleibt nutzbar.
• DeepL, nele.ai, Black Forest Labs und weitere europäische Spezialanbieter für Teilaufgaben (Übersetzung, Assistenz, Bild).
• EU-gehostete US-Modelle über Azure-EU, AWS-Frankfurt oder Google-Cloud-DE — leistungsstark, aber mit dem CLOUD-Act-Caveat aus Stufe 2: EU-Region ≠ EU-Souveränität, solange der Betreiber US-jurisdiktioniert ist.

Ehrlich eingeordnet: Die stärksten US-Modelle sind in manchen Aufgaben noch voraus. Der Abstand ist für die meisten Geschäftsanwendungen aber kleiner geworden, als das Marketing vermuten lässt — und für viele Use-Cases (Zusammenfassen, Klassifizieren, RAG für Unternehmen über eigene Dokumente) reichen europäische oder lokale Modelle vollständig aus.

On-Premise / lokales LLM — wann lohnt es sich?

Was ist On-Premise-KI?

On-Premise-KI bedeutet, dass das Modell auf eigener Hardware im eigenen Netzwerk läuft — die Daten verlassen das Haus nie. Damit ist diese Variante compliant by design: Es gibt keinen Drittlandtransfer, keinen externen Betreiber und keine CLOUD-Act-Exposition. Aus juristischer Sicht ist das die sauberste Lösung, weil das Risiko nicht abgesichert, sondern strukturell ausgeschlossen wird.

Was kostet ein lokales LLM?

Ehrlich gesagt: Es hängt stark vom gewünschten Modell ab. Ein 7B- bis 14B-Modell läuft brauchbar auf einer einzelnen Server-GPU mit ausreichend VRAM (Größenordnung kleiner fünfstelliger Anschaffungsbetrag plus Strom und Wartung). Modelle in der 70B-Klasse und darüber brauchen mehrere High-End-GPUs und bewegen sich schnell im hohen fünf- bis sechsstelligen Bereich. Hinzu kommen laufende Kosten für Betrieb, Updates und Personal. Pauschale Garantien gibt es hier nicht — die seriöse Antwort ist eine Dimensionierung anhand von Modellgröße, Nutzerzahl und Antwortzeit-Anforderung.

Was lokale LLMs (noch) nicht können

On-Premise ist kein Allheilmittel. Die ehrlichen Grenzen: Offene Modelle erreichen Spitzenleistung nicht in jeder Disziplin, Sie tragen die Verantwortung für Wartung, Sicherheit und Updates selbst, und die Skalierung auf viele gleichzeitige Nutzer kostet Hardware. Wer nur „weil souverän” alles on-prem zwingt, zahlt unter Umständen für Kontrolle, die er gar nicht braucht.

Der Entscheidungs-Leitfaden: welches Modell für welchen Fall

Statt einer Pauschalantwort die Logik, nach der ich in der Beratung vorgehe. Vier Achsen bestimmen die Stufe:

1. Datenklasse — Sind die Daten öffentlich/unkritisch, personenbezogen, oder ein Geschäftsgeheimnis bzw. besondere Kategorie (Art. 9 DSGVO)?
2. Use-Case — Brainstorming und Texte vs. Verarbeitung echter Kunden-/Patienten-/Mandantendaten.
3. Latenz & Verfügbarkeit — Reicht eine API, oder muss es offline/garantiert verfügbar laufen?
4. Budget — CapEx-fähig (eigene Hardware) oder OpEx-orientiert (nutzungsbasiert)?

Daraus folgt fast immer ein Hybrid-Ansatz: Unkritische Aufgaben laufen kostengünstig auf einer (richtig konfigurierten) Cloud-API, während kernkritische Daten on-prem oder in einer Sovereign Cloud bleiben. Die Brücke dazwischen ist eine Datenschleuse — ein vorgeschaltetes Gateway, das personenbezogene oder geheime Inhalte erkennt, anonymisiert oder gar nicht erst nach außen lässt. So gewinnen Sie die Modellqualität, ohne die Souveränität aufzugeben.

Faustregel: Je näher die Daten am Kerngeschäft und an realen Personen liegen, desto weiter rückt die Wahl Richtung Stufe 3–4. Öffentliche Inhalte dürfen ruhig auf Stufe 1–2 bleiben.

Diese Architektur-Entscheidung — Stufen-Mix, Datenschleuse, Konfiguration — ist genau der Punkt, an dem sich juristische Pflicht und technische Umsetzung treffen. Bei dieser Weichenstellung berate und baue ich.

Souveränität ist auch AI-Act-Governance

Datensouveränität ist 2026 nicht mehr nur eine DSGVO-Frage. Die KI-Verordnung (EU AI Act) verlangt von Betreibern (Deployern) von KI-Systemen u. a. Daten-Governance, Transparenz und Nachvollziehbarkeit. Der Zeitplan ist real und läuft bereits: Seit dem 2. August 2025 gelten die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (GPAI) — ein Beleg dafür, dass die Verordnung schrittweise scharf gestellt wird und nicht abstrakt bleibt. Wer nicht kontrolliert, wo seine Daten verarbeitet werden und wer darauf zugreifen kann, kann diese Governance-Pflichten kaum belastbar erfüllen. Datensouveränität wird damit zum Baustein der AI-Act-Konformität — und nicht zu einem davon getrennten Thema. Mehr dazu im Überblick zur EU-KI-Verordnung für Unternehmen.

FAQ

Sind US-LLMs DSGVO-konform nutzbar?

Mit Einschränkungen ja. Für unkritische Daten lassen sich US-Modelle über einen sauberen Auftragsverarbeitungsvertrag, Zero-Data-Retention-Konfiguration und ggf. das DPF rechtmäßig einsetzen. Das CLOUD-Act-Restrisiko bleibt jedoch bestehen — für Geschäftsgeheimnisse und besondere Datenkategorien ist daher eine souveränere Stufe vorzuziehen.

Ist Azure OpenAI in der EU DSGVO-konform?

Azure OpenAI lässt sich über die EU Data Boundary und einen AVV datenschutzfreundlich konfigurieren; standardmäßig werden Prompts bis zu 30 Tage zur Missbrauchserkennung gespeichert. Berechtigte Enterprise-Kunden können per Zero-Data-Retention-Programm diese Speicherung abschalten. Da Microsoft US-jurisdiktioniert ist, bleibt aber die CLOUD-Act-Exposition (Stufe 2) — eine EU-Region ist keine vollständige Souveränität.

Brauche ich eine Datenschutz-Folgenabschätzung (DSFA)?

Häufig ja. Bei KI-Systemen, die personenbezogene Daten in größerem Umfang oder mit hohem Risiko verarbeiten, verlangt Art. 35 DSGVO eine DSFA. Drittlandtransfer und automatisierte Auswertung sind klassische Auslöser. Im Zweifel lieber eine kurze Schwellenwertprüfung dokumentieren als nachträglich nachweisen müssen.

Was ist eine Datenschleuse bzw. ein KI-Gateway?

Ein vorgeschaltetes System, das alle Eingaben an ein LLM filtert: Es erkennt personenbezogene oder geheime Inhalte, anonymisiert oder blockt sie und protokolliert den Datenfluss. So lassen sich starke (auch externe) Modelle nutzen, ohne dass sensible Rohdaten das Haus verlassen — die technische Brücke zwischen Modellqualität und Souveränität.

Was bedeutet Vendor Lock-in bei KI?

Die Abhängigkeit von einem Anbieter, dessen Modell, Format oder Preisgestaltung Sie nur mit hohem Aufwand wechseln können. Souveränität umfasst auch diese Dimension: Offene Modelle und portable Architekturen reduzieren das Lock-in-Risiko deutlich.

Stand und Einordnung

Stand: Dezember 2025. Der DPF-/Schrems-Status (anhängiges EuGH-Verfahren C-703/25 P) und die AI-Act-Fristen sind volatil; dieser Artikel wird im Review-Zyklus aktualisiert. Die Darstellung ersetzt keine Rechtsberatung im Einzelfall — die richtige Souveränitäts-Stufe hängt von Ihren konkreten Datenflüssen, Use-Cases und Ihrem Risikoappetit ab.

Wenn Sie diese Weichenstellung nicht dem Zufall überlassen wollen: Ich treffe die Souveränitäts- und Architektur-Entscheidung gemeinsam mit Ihnen — als Wirtschaftsjurist, der die Lösung anschließend auch baut. Mehr zu meinem Hintergrund finden Sie über mich.

---

Quellen — Stand 15.12.2025

• EU-Kommission — Angemessenheitsbeschluss EU-US-Datenverkehr (10.07.2023): https://germany.representation.ec.europa.eu/news/datenverkehr-zwischen-der-eu-und-den-usa-europaische-kommission-erlasst-neuen-2023-07-10_de
• Solidaris / PUBLICUS — EuG weist Latombe-Klage ab (03.09.2025), DPF gilt weiter: https://www.solidaris.de/aktuelles/angemessenheitsbeschluss-fuer-die-usa-haelt-der-ueberpruefung-des-eug-stand
• datenschutzticker.de — Rechtsmittel gegen DPF beim EuGH (Rs. C-703/25 P), Streit erneut vor EuGH: https://www.datenschutzticker.de/2025/11/streit-ueber-us-angemessenheitsbeschluss-erneut-vor-eugh/
• next-levels.de — EU-US Data Privacy Framework: Status 2026 (PCLOB-Beschlussfähigkeit): https://next-levels.de/wiki/eu-us-data-privacy-framework
• jentis / noyb — Schrems III in Vorbereitung: https://www.jentis.com/blog/noyb-will-challenge-the-new-data-privacy-framework
• EDSA/EDPB — Stellungnahme zu Art. 48 DSGVO & US CLOUD Act (CMS-Aufbereitung): https://cms.law/de/deu/legal-updates/Positionierung-des-EDSA-zum-CLOUD-Act-Datenuebermittlungen-an-US-Ermittlungsbehoerden-nur-in-engen-Grenzen
• datenschutzticker.de — EDSA: Datentransfer an Drittstaatenbehörden nach Art. 48 DSGVO (06/2025): https://www.datenschutzticker.de/2025/06/edsa-datentransfer-an-drittstaatenbehoerden-nach-art-48-dsgvo/
• Looming Tech — CLOUD Act / AWS EU Region & GDPR (“EU-Region ist keine Firewall”): https://www.looming.tech/post/cloud-act-aws-eu-region-gdpr
• kiteworks — EU Data Act, GDPR & US CLOUD Act Konflikt: https://www.kiteworks.com/gdpr-compliance/eu-data-act-gdpr-cloud-conflict/
• Fraunhofer IAIS — OpenGPT-X / Teuken-7B (24 EU-Sprachen, Open Source): https://www.iais.fraunhofer.de/en/industries_and_cross-sector_solutions/cross-sector_solutions/generative-ai/opengpt-x.html
• Aleph Alpha Docs — Pharia-1-LLM-7B (On-Premise-Auslieferung, DE/FR/ES): https://docs.aleph-alpha.com/products/pharia-1-llm/overview/
• Meetily — Azure OpenAI Data Retention Policy 2026 (ZDR, 30-Tage-Abuse-Monitoring, Region Pinning): https://meetily.ai/llm-privacy/azure
• EuGH — Schrems II (C-311/18, 16.07.2020): https://curia.europa.eu/juris/liste.jsf?num=C-311/18
• Baker McKenzie — GPAI-Pflichten des EU AI Act gelten ab 02.08.2025: https://www.bakermckenzie.com/en/insight/publications/2025/08/general-purpose-ai-obligations