Zum Hauptinhalt springen
Startseite / Blog / Compliance Guide
Compliance Guide

DSGVO-konforme KI hosten: So wählen Sie den richtigen Anbieter

RRogue AI··8 Min. Lesezeit
Ein Ton-Roboter liest Papiernotizen in einem offenen Serverschrank mit goldenem Schloss, während verlorene Notizen in einem Papierkorb landen

DSGVO-konformes KI-Hosting hängt von vier Faktoren ab: wer den Dienst betreibt und welches Recht für diesen gilt, wo Prompts verarbeitet und gespeichert werden, ob Daten für das Training genutzt werden und der Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Die Auswahl einer EU-Region bei einem US-Anbieter löst nur die Frage nach dem Verarbeitungsort und potenziell der Speicherung. Die rechtliche Reichweite der US-Regierung oder die Abhängigkeit von schwankenden Angemessenheitsbeschlüssen bleiben bestehen.

Was macht KI-Hosting DSGVO-konform?

Vier Fragen entscheiden darüber:

  1. Wer betreibt den Dienst? Dies bestimmt, welche nationalen Gesetze den Anbieter zur Herausgabe von Daten zwingen können.
  2. Wo werden Prompts verarbeitet und gespeichert? Dies definiert den physischen Standort der Daten und ob diese den EWR verlassen.
  3. Werden Ihre Daten für das Training genutzt? Sie müssen sicherstellen, dass der Anbieter Ihre Eingaben oder Ausgaben nicht zur Verbesserung seiner Modelle verwendet.
  4. Liegt ein gültiger AVV nach Art. 28 DSGVO vor? Sie benötigen eine rechtsverbindliche Vereinbarung, die den Auftragsverarbeiter auf Ihre dokumentierten Weisungen beschränkt.

Löst eine EU-Region bei einem US-Anbieter das CLOUD-Act-Problem?

Nein. Der CLOUD Act (18 U.S.C. § 2713) verpflichtet einen US-Anbieter von elektronischen Kommunikations- oder Remote-Computing-Diensten zur Offenlegung von Daten in seinem Besitz, seiner Verwahrung oder Kontrolle, unabhängig davon, ob sich diese Informationen innerhalb oder außerhalb der Vereinigten Staaten befinden. Wenn ein US-Unternehmen den Dienst betreibt, bleiben die Daten auch dann in Reichweite US-amerikanischer Rechtsprozesse, wenn die Server in Frankfurt oder Paris stehen.

Die aktuelle Rechtsgrundlage für die Datenübermittlung in die USA ist das EU-US Data Privacy Framework (DPF), ein Angemessenheitsbeschluss der Kommission vom Juli 2023. Am 3. September 2025 wies das Gericht der Europäischen Union die Nichtigkeitsklage Latombe v Commission (T-553/23) ab. Gegen das Urteil wurde am 31. Oktober 2025 jedoch ein Rechtsmittel (C-703/25 P) eingelegt, über das der Gerichtshof der EU entscheidet. Prüfen Sie den Stand, bevor Sie sich auf das DPF stützen. Die Antwort durch Selbst-Hosting haben wir in EU-Datensouveränität für KI behandelt.

Historisch wurden die beiden Vorgänger des DPF, Safe Harbor und Privacy Shield, 2015 und 2020 vom Gerichtshof der EU gekippt. Während das DPF heute eine gültige Rechtsgrundlage ist, besteht ein bekanntes Widerrufsrisiko. Der praktische Ansatz ist, diese Dienste bei Bedarf zu nutzen, aber einen Exit-Plan bereitzuhalten, den Sie ausführen können, falls das DPF fällt.

Welche Hosting-Optionen gibt es?

OptionWer betreibt esWo werden Prompts verarbeitetSpeicherung und TrainingWas Sie weiterhin tragen
US-Anbieter mit EU-Datenresidenz (z. B. OpenAI Europe Projekte)US-UnternehmenEuropa für neue ProjekteZero Data Retention bei berechtigten API-Endpunkten, standardmäßig kein TrainingZugriff über den CLOUD Act, DPF-Abhängigkeit
KI mit EU-Hosting über API (z. B. STACKIT, OVHcloud, Scaleway, IONOS)EU-UnternehmenEU-Rechenzentren (Scaleway: nur Paris)STACKIT und OVHcloud: keine Speicherung der Prompts (OVHcloud: nur Abrechnungsdaten), kein Training; bei den anderen im Vertrag prüfenTrade-off bei Modellqualität, AVV nach Art. 28
Selbst gehostetes Open-Weight-ModellSie selbstWo Sie es platzierenSie entscheidenPatching, Zugriffskontrolle, Logging, GPU-Kosten

US-Anbieter mit EU-Datenresidenz

OpenAI kündigte Data Residency in Europa am 5. Februar 2025 für die API Platform, ChatGPT Enterprise und ChatGPT Edu an. Bei API-Anfragen über ein Projekt mit gewählter Region Europa wickelt OpenAI Anfragen an berechtigte Endpunkte in der Region mit Zero Data Retention ab. Das bedeutet, dass Anfragen und Antworten nicht dauerhaft auf ihren Servern gespeichert werden. Dies kann nur für neue Projekte konfiguriert werden. Am 16. Januar 2026 fügte OpenAI in-region GPU-Inferenz in Europa für berechtigte ChatGPT Enterprise, Edu und Healthcare-Kunden hinzu. Diese Option eignet sich, wenn Sie die stärksten Reasoning-Modelle brauchen und die rechtlichen Risiken des CLOUD Act akzeptieren.

KI mit EU-Hosting über API

Dies sind Dienste europäischer Unternehmen auf eigener Infrastruktur. Der deutsche Cloud-Anbieter STACKIT bietet AI Model Serving in der Region EU01 an und gibt an, dass Daten und Abfragen weder gespeichert noch zum Training von Modellen verwendet werden. Verfügbare Modelle umfassen Google Gemma 4 31B, gpt-oss-120b, gpt-oss-20b, Llama 3.3 70B und Qwen3 VL 235B. Beispielsweise kostet Gemma 4 31B 0,45 Euro Input und 0,65 Euro Output pro Million Token.

OVHcloud AI Endpoints werden in der EU gehostet und betrieben. Sie verfügen über ISO 27001, SOC 2 Type II und HDS-Zertifizierungen für Gesundheitsdaten. Sie bieten Zero Data Retention außer für die Abrechnung und mehr als 20 Open-Weight-Modelle an. Scaleway Generative APIs werden in einem sicheren Rechenzentrum nur in Paris gehostet und bieten Modelle wie Llama 3.3 70B und Mistral Small 3.2. Der IONOS AI Model Hub wird in Rechenzentren der IONOS Cloud betrieben und stellt Modelle wie Mistral Nemo und Qwen3.5-Varianten bereit. Diese Optionen eignen sich, wenn Sie einen EU-Betreiber statt eines US-Anbieters wollen und sich die Hardwareverwaltung sparen möchten. Unserer Erfahrung nach hinken Open-Weight-Modelle auf EU-Clouds bei komplexen Reasoning-Aufgaben hinter den Frontier-Modellen hinterher. Für Entwürfe, Extraktionen und Zusammenfassungen spielt diese Lücke kaum eine Rolle. Wie wir ein Modell für solche Aufgaben auswählen, beschreiben wir in lokales LLM für Business-Texte auswählen.

Open-Weight-Modelle selbst hosten

Hierbei werden Modelle auf eigener Hardware oder gemietetem Bare Metal betrieben. Sie haben die volle Kontrolle darüber, wo die Daten liegen und wie sie protokolliert werden. Kein Modellanbieter sieht den Prompt. Bei gemieteten Servern hat das Hosting-Unternehmen weiterhin physischen Zugriff, daher ist auch dessen Vertrag relevant. Die Kostenaspekte finden Sie in selbst gehostete KI vs. Cloud-APIs, die Absicherung in selbst gehostete KI-Infrastruktur absichern. Dies ist sinnvoll, wenn Sie hochregulierte Daten verarbeiten oder die interne Engineering-Kapazität besitzen, um den GPU-Stack und das Patching zu verwalten.

Wie wähle ich nach Datenklasse aus?

DatenklasseBeispielAngemessene Option
Öffentliche oder Marketing-TexteWebsite-Texte, öffentliche DokumenteBeliebig, inklusive US-Anbieter
Intern, keine personenbezogenen DatenCode ohne Geheimnisse, interne AnleitungenUS-Anbieter mit EU-Datenresidenz und Zero Retention oder EU-API
Personenbezogene Daten von Kunden oder MitarbeiternSupport-Tickets, HR, CRM-NotizenEU-Hosting über API oder selbst gehostet, AVV nach Art. 28, DSFA-Prüfung
Besondere Kategorien, Geschäftsgeheimnisse, regulierte SektorenGesundheitsdaten, F&E, kritische InfrastrukturSelbst gehostet oder EU-Betreiber mit Sektorzertifizierungen (z. B. HDS)

Sie sollten die Hosting-Stufe pro Anwendungsfall entscheiden, statt eine einzige Regel für das gesamte Unternehmen anzuwenden. Die meisten Setups, die wir bauen, nutzen zwei Stufen. Sie verwenden Frontier-Modelle für nicht sensible interne Aufgaben und EU-Hosting oder selbst gehostete Modelle für Kunden- und Mitarbeiterdaten.

Die Vertrags-Checkliste vor der Unterschrift

AGB eines Standard-API-Dienstes sind kein AVV nach Art. 28 DSGVO. Sie müssen sicherstellen, dass die Vereinbarung zur Auftragsverarbeitung explizit die folgenden acht Pflichten abdeckt:

  1. Verarbeitung nur auf Basis Ihrer dokumentierten Weisungen.
  2. Sicherstellung, dass alle Mitarbeiter zur Vertraulichkeit verpflichtet sind.
  3. Implementierung der in Art. 32 erforderlichen Sicherheitsmaßnahmen.
  4. Strikte Bedingungen für etwaige Unterauftragsverarbeiter.
  5. Unterstützung bei der Beantwortung von Betroffenenanfragen.
  6. Hilfe bei der Sicherheit, der Meldung von Datenpannen und den DSFA-Pflichten gemäß Art. 32 bis 36.
  7. Löschung oder Rückgabe aller Daten am Ende des Dienstes.
  8. Bereitstellung von Informationen zum Nachweis der Compliance und Zulassung von Audits.

Ergänzen Sie das Minimum aus Art. 28 DSGVO um KI-spezifische Klauseln:

  • Eine schriftliche No-Training-Klausel. Diese muss festhalten, dass Ihre Daten nicht zur Verbesserung des Modells verwendet werden. Eine Standardeinstellung in einer Datenschutzerklärung kann sich ändern; eine Vertragsklausel nur mit Ihrer Zustimmung. Was „wir können nicht ausschließen“ in der Praxis bedeutet.
  • Spezifische Aufbewahrungsfristen. Definieren Sie, wie lange Prompts, Ausgaben und Logs zur Missbrauchsüberwachung gespeichert werden.
  • Eine vollständige Liste der Unterauftragsverarbeiter. Diese sollte den spezifischen GPU-Anbieter oder den Modellhersteller enthalten, falls der Host nur ein Wrapper ist.
  • Klarheit über den Datenzugriff. Bei Open-Weight-Modellen in einer EU-Cloud sieht der Modellhersteller die Daten nicht. Stellen Sie sicher, dass dies dokumentiert ist.
  • Löschung von Backups. Stellen Sie sicher, dass das Vertragsende die Löschung aus Backups und Snapshots einschließt.
  • Zeitpunkt der Meldung von Datenpannen. Legen Sie ein konkretes Zeitfenster fest, innerhalb dessen Sie über ein Leak benachrichtigt werden müssen.

Wenn Sie Mitarbeiter- oder Kundendaten in großem Umfang verarbeiten, ist oft eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO erforderlich.

Wo die Daten tatsächlich abfließen: die Logs rund um das Modell

In den Systemen, die wir bauen, ist die Modell-API der einfachste Teil der Absicherung. Der eigentliche Leak-Pfad ist selten der API-Aufruf selbst. Die Gefahr liegt in den Observability- und Speicherschichten rund um das Modell.

Ein typischer Stack kopiert die Daten an vier Stellen:

  1. Observability-Stacks: Prompt- und Antwort-Logs werden oft in Logging-Tools zur Fehlersuche und Überwachung gespeichert. Diese Logs umgehen häufig die Zero-Retention-Einstellungen der Modell-API.
  2. Vektordatenbanken: Bei der Nutzung von RAG speichern Sie Embeddings und Chunks Ihrer Dokumente in einer Vektordatenbank. Dies ist eine permanente Kopie Ihrer Daten und eine eigene Angriffsfläche, siehe RAG-Pipelines absichern.
  3. Frontend-Historie: Chat-Oberflächen speichern Verläufe oft in einer Datenbank, damit Nutzer frühere Gespräche sehen können.
  4. Debugging-Exporte: Entwickler exportieren Logs während der Entwicklungsphase oft in lokale Dateien oder externe Tools.

Jede dieser Komponenten benötigt dieselben Aufbewahrungsregeln und Zugriffskontrollen wie der Modell-Aufruf. Wenn Sie einen EU-Anbieter für die API wählen, aber die Prompt-Logs in einem US-basierten Logging-Tool speichern, haben Sie das Compliance-Problem nicht gelöst. Selbst-Hosting des Modells behebt dies nicht automatisch, da Sie immer noch entscheiden müssen, wohin die Logs fließen.

In welcher Reihenfolge gehen Sie vor?

Gehen Sie zur Implementierung in diesen fünf Schritten vor:

  1. Klassifizieren Sie Ihre Daten in die oben genannten vier Klassen.
  2. Wählen Sie für jede Datenklasse eine Hosting-Stufe aus.
  3. Unterzeichnen Sie den AVV unter Verwendung der Art. 28 und KI-spezifischen Checkliste.
  4. Konfigurieren Sie die Aufbewahrungs- und Zugriffsregeln für Logs, Vektordatenbank und Frontend.
  5. Dokumentieren Sie den Fluss in Ihrem Verzeichnis von Verarbeitungstätigkeiten und der DSFA.

Ihr Datenschutzbeauftragter oder Rechtsbeistand gibt das Ergebnis frei. Die Arbeit davor, das Klassifizieren der Daten und das Aufräumen der Logs, ist Engineering, und hier hinken die meisten Projekte, die wir sehen, hinterher.

Weiterführende Lektüre

Weitere Artikel

Compliance Guide

KI-Verordnung Artikel 50: So kennzeichnen Sie Chatbots und KI-Inhalte

7 Min. Lesezeit

Compliance Guide

EU AI Act Compliance für Entwickler: Was Sie wissen müssen

10 Min. Lesezeit

← Alle Artikel