KI aus der Cloud und DSGVO: Wie sauber ist das wirklich?

Das Grundproblem

KI-Integration in Webanwendungen ist zunächst ein technisches Problem: Modell auswählen, API anbinden, Prompt bauen, Response verarbeiten. Das lässt sich in wenigen Stunden umsetzen.

Das DSGVO-Problem beginnt genau dort: Mit dem ersten API-Aufruf verlierst du die Kontrolle darüber, wer verarbeitet – und unter welchen rechtlichen Bedingungen. Nutzeranfragen, Dokumentinhalte, interne Texte wandern durch externe Infrastruktur, externe Modelle, APIs in Konzernstrukturen, deren Datenschutzpraktiken weit außerhalb der eigenen Systemgrenzen liegen. Was zwischendurch mit den Daten passiert – ob Prompts geloggt werden, ob Sub-Processor beteiligt sind, ob Support-Mitarbeiter in anderen Jurisdiktionen Zugriff haben – ist ohne explizite Konfiguration und Vertragsprüfung unklar.

Für DSGVO-konforme Anwendungen ist das kein Randthema, sondern das eigentliche Designproblem.

Cloudflare macht hier einiges anders. Aber nicht alles.

Konkretes Szenario: Eine Supportanfrage mit E-Mail-Adresse

Um zu verstehen, wo DSGVO-Pflichten entstehen, hilft ein durchgespieltes Beispiel. Ein Nutzer stellt eine Supportfrage: „Meine Bestellung mit der Nummer 4711 ist noch nicht angekommen – meine E-Mail ist max@beispiel.de.”

Das Szenario zeigt: Selbst eine harmlose Supportanfrage kann mehrere personenbezogene Datenflüsse erzeugen. Die Frage ist nicht, ob DSGVO gilt – sie gilt. Die Frage ist, ob die Verarbeitungskette dokumentiert, konfiguriert und kontrolliert ist.

DSGVO-Rollen: Wer ist wofür verantwortlich?

Eine Verarbeitungskette mit Cloudflare Workers AI involviert mindestens drei Akteure. Die Rollen nach DSGVO sind nicht immer so klar verteilt, wie man es erwarten würde.

Betreiber = Verantwortlicher (Controller, Art. 4 Nr. 7 DSGVO). Wer die Applikation betreibt und entscheidet, zu welchem Zweck und auf welche Weise personenbezogene Daten verarbeitet werden. Das ist nicht Cloudflare – das ist die Agentur, das Unternehmen oder der Entwickler, der den Worker betreibt.

Cloudflare = Auftragsverarbeiter (Processor, Art. 4 Nr. 8 DSGVO). Cloudflare verarbeitet Daten im Auftrag des Betreibers. Das erfordert einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Cloudflare stellt diesen als Data Processing Addendum bereit.

Modellanbieter (Meta, Mistral, andere) = Sub-Processor. Workers AI stellt Modelle Dritter bereit. Diese Anbieter sind in der Verarbeitungskette als Sub-Processor von Cloudflare einzustufen – ihre Einbindung sollte in Cloudflares Sub-Processor-Liste dokumentiert sein. Die relevante Frage: Unter welchen Bedingungen läuft die Modell-Inferenz? Cloudflare agiert als Betreiber der Infrastruktur, aber die Modelle stammen von anderswo.

Sub-Processor-Faustregel: Wann brauche ich einen eigenen AVV?

Direkte API-Aufrufe im Worker begründen eigenständige Processor-Beziehungen. Als Orientierung:

• Workers AI (über Cloudflare): Cloudflare ist Processor, Modellanbieter wie Meta oder Mistral sind Sub-Processor von Cloudflare – kein separater AVV deinerseits nötig.
• OpenAI / Anthropic direkt im Worker aufgerufen: Diese Anbieter sind eigenständige Processor – du brauchst separate AVVs mit jedem davon.
• Externe Logging-Tools im Worker (Sentry, Logflare, Axiom): Jedes Tool, das Anfragedaten erhält, ist ein eigener Processor – auch wenn es „nur” Logs sind.

Die Trennlinie: Wer weisungsgebunden im Auftrag des Betreibers verarbeitet, ist Processor oder Sub-Processor. Wer eigenständig Zweck und Mittel der Verarbeitung bestimmt, ist kein Sub-Processor mehr.

Drittlandtransfer: EU-Region ≠ kein Transfer

Das ist ein klassischer Denkfehler: Wenn der Worker in Frankfurt läuft, sind die Daten in der EU – also kein Drittlandtransfer.

Das stimmt nicht zwingend.

Auch bei EU-seitig ausgeführtem Code können Drittlandtransfers entstehen durch:

• Support-Zugriffe: Wenn Cloudflare-Mitarbeiter außerhalb der EU auf Infrastruktur oder Logs zugreifen, ist das ein Transfer – unabhängig davon, wo die Daten physisch liegen.
• Sub-Processor außerhalb der EU: Sofern Cloudflares Sub-Processor in Drittländern operieren, gelten die üblichen Anforderungen.
• Logging-Tools: Sentry, Logflare oder ähnliche externe Dienste, die im Worker eingebunden sind, können Drittlandtransfers erzeugen – auch wenn der Worker selbst in der EU läuft.

Cloudflare adressiert das durch EU Standardvertragsklauseln (SCCs) im DPA. Für eine vollständige DSGVO-Dokumentation sollte dennoch ein Transfer Impact Assessment (TIA) vorliegen, das bewertet, ob die SCCs im konkreten Fall ausreichenden Schutz bieten – insbesondere nach den Maßstäben aus dem Schrems-II-Urteil.

Das ist kein theoretisches Problem. Ein konkretes Szenario: Ein Worker gibt in einem Testlauf eine unerwartete Antwort zurück. Der Entwickler eröffnet ein Support-Ticket bei Cloudflare und fügt einen Beispiel-Prompt für die Diagnose ein – der zufällig die E-Mail-Adresse eines Testnutzers enthält. Ein Cloudflare-Support-Mitarbeiter in den USA öffnet das Ticket und liest die Daten, um das Problem nachzuvollziehen.

Das ist ein Drittlandtransfer – auch wenn der Worker in Frankfurt läuft, KV auf EU-Knoten konfiguriert ist und das AI Gateway auf EU-Region beschränkt wurde. Der Transfer entstand nicht durch technische Fehlkonfiguration, sondern durch normalen Infrastrukturbetrieb.

Was Cloudflare konkret anders macht

Edge-Infrastruktur mit geografischer Kontrolle

Cloudflare betreibt Workers in Frankfurt und anderen EU-Standorten — aber Anfragen laufen standardmäßig am Knoten mit der niedrigsten Latenz. Ohne explizite Konfiguration kann das bedeuten, dass ein Request außerhalb der EU verarbeitet wird.

Die Einstellung cf-worker-execution-region in der wrangler.toml erzwingt EU-only Ausführung:

[env.production]
workers_dev = false

[env.production.placement]
mode = "smart"        # ACHTUNG: Smart Placement kann EU verlassen (siehe unten)

Für harte EU-Bindung stattdessen die Data Localization Suite nutzen — das ist die Enterprise-Grade-Garantie, dass Worker-Ausführung, Vectorize-Indizes und R2-Buckets ausschließlich in der EU bleiben. Das ist eine technische Garantie, keine bloße Vertragszusage.

KV ist nicht EU-only. Workers KV repliziert Daten standardmäßig global — auch wenn der Worker in der EU läuft, können KV-Reads aus US-Knoten bedient werden. Für personenbezogene Daten, die in KV landen (z.B. gecachte Embeddings, Session-Daten), ist das datenschutzrechtlich relevant. Mit der Data Localization Suite lässt sich KV auf EU-Regionen beschränken.

Durable Objects akzeptieren einen locationHint (z.B. 'eeur' für Westeuropa), aber das ist ohne Enterprise-Plan nur ein Hinweis, keine Garantie. Wer Durable Objects für persistenten State nutzt, sollte das im Datenschutzkonzept dokumentieren.

Workers Secrets sind verschlüsselt gespeichert, aber ebenfalls global in der Cloudflare-Infrastruktur — ohne Data Localization Suite keine EU-Einschränkung.

Kein Training mit Kundendaten

Cloudflare nutzt Anfragen an Workers AI nicht für das Training oder Fine-Tuning von Modellen. Die Inferenz-Infrastruktur ist von Trainingspipelines getrennt.

Das ist für den AVV-Abschluss relevant: Der Betreiber muss dokumentieren können, dass Nutzerdaten nicht für Modellverbesserungen verwendet werden. Cloudflare ermöglicht diese Aussage.

AI Gateway als zentraler Kontrollpunkt

Der AI Gateway ist mehr als ein Logging-Tool – er ist der Single Chokepoint für den gesamten KI-Traffic einer Applikation. Das hat architektonischen Wert über Datenschutz hinaus:

• Zentrales Logging: Alle Prompts und Responses laufen durch einen Punkt. Das ermöglicht konsistente Protokollierung und Auditierung.
• Policy Enforcement: Rate-Limiting, Caching und Zugriffssteuerung für KI-Anfragen an einer Stelle konfigurieren – nicht verteilt über mehrere API-Aufrufe.
• Anbieterwechsel ohne Codeänderung: Das Gateway abstrahiert den Modell-Endpoint. Wechsel von Workers AI zu OpenAI oder Mistral API erfordert keine Änderung im Worker-Code.

Datenschutztechnisch: Der AI Gateway ermöglicht es, Logging gezielt zu konfigurieren und zu begrenzen. Statt alle Prompts und Antworten unkontrolliert zu speichern, entscheidet der Betreiber was protokolliert wird, wie lange, und ob überhaupt. Das macht einen strukturellen Unterschied bei der Datenschutz-Dokumentation.

Technische Schutzmaßnahmen (TOMs) konkret

Art. 25 und Art. 32 DSGVO verlangen technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten. Im KI-Kontext bedeutet das konkret:

Pseudonymisierung vor dem AI-Aufruf. Statt die E-Mail-Adresse direkt in den Prompt zu schreiben, wird sie durch ein reversibles Token ersetzt. Das Modell arbeitet mit dem Token, der Betreiber kann zurückzuordnen:

// Pseudonymisierung im Worker
function pseudonymize(text, piiMap) {
  return text.replace(
    /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g,
    (email) => {
      const token = `[EMAIL_${Object.keys(piiMap).length + 1}]`;
      piiMap[token] = email;
      return token;
    }
  );
}

const piiMap = {};
const safePrompt = pseudonymize(userInput, piiMap);
// safePrompt enthält keine E-Mail-Adresse mehr

Redaction sensibler Daten. Für Fälle, wo die E-Mail-Adresse für den KI-Aufruf irrelevant ist, kann sie vor dem Weitersenden vollständig entfernt werden:

// Einfaches Regex-Redacting
const redacted = userInput
  .replace(/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g, '[REDACTED]')
  .replace(/\b\d{4,}\b/g, '[ID]'); // Bestellnummern etc.

Selektives Retrieval statt vollständiger Dokumente. In RAG-Szenarien: nicht das gesamte Dokument senden, sondern nur den relevanten Chunk. Statt ein komplettes Kundenticket inklusive Name und Kontaktdaten zu übergeben, wird nur der inhaltliche Teil extrahiert.

Clientseitige Vorverarbeitung. Wenn möglich: PII-Extraktion bereits im Browser oder Client, bevor Daten den Server erreichen. Das reduziert die Menge verarbeiteter personenbezogener Daten an allen nachgelagerten Stellen.

Prompt-Injection-Risiko einkalkulieren. Wenn Nutzereingaben direkt in Prompts eingebettet werden, können Angreifer Instruktionen einschleusen, die das Modell veranlassen, auf interne Daten zuzugreifen und diese in der Antwort zu exfiltrieren. In RAG-Setups mit umfangreichen Dokumenten kann das bedeuten, dass sensible Inhalte aus dem Retrieval-Kontext in der Antwort auftauchen. Gegenmittel: Nutzereingaben von System-Instruktionen strukturell trennen, Ausgaben auf definierte Formate beschränken, Output-Validierung einbauen.

Entwicklerfehler: Shadow Logging

Ein häufiger und unterschätzter DSGVO-Fallstrick in Workers:

// Das sollte NICHT in Production-Code stehen
console.log("User request:", userMessage); // enthält möglicherweise PII
console.log("AI response:", response);     // kann Rückschlüsse auf Nutzer erlauben

console.log in Cloudflare Workers landet im Cloudflare Dashboard (Logs-Tab) und in externen Log-Drains. Das ist faktisch ein unkontrollierter Datenexport – ohne definierte Befristung, ohne Zweckbindung, ohne Transparenz darüber, wer Zugriff hat oder in welche Systeme Logs weitergeleitet werden. Ähnliches gilt für:

• Sentry: Wenn der Fehler-Kontext den kompletten Request enthält, landen Prompts mit PII im Sentry-Event.
• Logflare / Axiom: Logging-Integrationen loggen oft mehr als beabsichtigt, wenn nicht explizit gefiltert wird.
• Tail Workers: Cloudflares eigene Log-Weiterleitung kann Prompts erfassen, wenn nicht gezielt konfiguriert.

Die Regel: In Production-Code läuft kein Logging von Nutzerinhalten ohne explizite Zweckbindung, Befristung und Prüfung, ob diese Daten überhaupt geloggt werden dürfen.

Was trotzdem geklärt werden muss

Cloudflares Infrastruktur-Entscheidungen ersetzen keine eigene Datenschutz-Prüfung. Folgende Punkte bleiben Betreiber-Verantwortung:

AVV abschließen: Cloudflare stellt ein Data Processing Addendum bereit. Ohne unterschriebenen AVV fehlt die rechtliche Grundlage für Auftragsverarbeitung nach Art. 28 DSGVO.

Datenklassifizierung: Was geht in die KI-Pipeline? Enthält das, was Nutzer eingeben oder was aus Dokumenten extrahiert wird, personenbezogene Daten? Das bestimmt, welche Schutzmaßnahmen notwendig sind.

Logging-Konfiguration: Welche Daten speichert der AI Gateway, in welchem Umfang, wie lange? Standard-Einstellungen sind nicht automatisch DSGVO-konform – sie müssen geprüft und angepasst werden.

Drittanbieter-Modelle: Workers AI bezieht Modelle von Drittanbietern (Meta, Mistral, andere). Wessen Bedingungen gelten für die Modell-Inferenz? Cloudflare agiert als Betreiber der Infrastruktur, aber die Modelle selbst kommen von anderswo.

Nutzer-Transparenz: Wenn Nutzeranfragen KI-Systeme durchlaufen, muss die Datenschutzerklärung das abdecken – Art der Verarbeitung, involvierte Dienstleister, Zweck.

Transfer Impact Assessment: Für eine vollständige Drittlandtransfer-Dokumentation – insbesondere bei Support-Zugriffen und Sub-Processoren – ist ein TIA empfehlenswert, auch wenn Cloudflare SCCs bereitstellt.

Wann Cloudflare nicht reicht

Cloudflare ist eine solide Basis für datenschutzkonforme KI-Integration – aber nicht für jeden Anwendungsfall ausreichend.

Besondere Datenkategorien nach Art. 9 DSGVO (Gesundheitsdaten, biometrische Daten, Daten über politische Überzeugungen) erfordern eine Datenschutzfolgenabschätzung (DSFA) nach Art. 35 DSGVO. Dazu kommen in Deutschland zusätzliche Anforderungen aus dem BDSG. Cloud-KI-Infrastruktur ist für diese Fälle nur nach expliziter Rechtsprüfung einsetzbar – unabhängig vom Anbieter.

Finanzdienstleister und BaFin-Anforderungen unterliegen zusätzlichen regulatorischen Pflichten, die über DSGVO hinausgehen. Outsourcing-Regelungen und Anforderungen an kritische Infrastruktur schränken den Einsatz von Cloud-KI ein.

Behörden und öffentlicher Sektor mit Anforderungen an IT-Grundschutz oder spezifischen Geheimhaltungsstufen benötigen in der Regel On-Premise-Lösungen oder EU-native Anbieter ohne US-Konzernstruktur.

Für diese Szenarien ist der realistische Stack: lokale Modelle (Ollama, vLLM), lokale Vektordatenbanken (Chroma, Weaviate on-premise), keine Daten außerhalb eigener Infrastruktur. Das ist technisch möglich, aber operativ deutlich aufwändiger.

Wann bewusst keine KI – unabhängig vom Stack. Manche Datenkategorien sollten grundsätzlich nicht durch externe KI-Systeme verarbeitet werden – unabhängig davon, ob konfiguriert, lokal oder in der Cloud:

• Sehr sensible Support-Inhalte: Anfragen mit Angaben zu Gesundheitszustand, Finanzkrise oder persönlichen Notlagen
• HR-Prozesse: Bewerbungsunterlagen, Performance-Beurteilungen, Gehalts- und Abfindungsverhandlungen
• Gesundheitsdaten im Direktkontakt: Symptombeschreibungen, diagnostische Anfragen, Patientenkommunikation

Hier ist die Frage nicht, wie KI konfiguriert wird – sondern ob KI in diesem Kontext verhältnismäßig und mit einer klaren Rechtsgrundlage nach Art. 9 DSGVO eingesetzt wird.

Typische Fragen und Antworten

Werden Prompts gespeichert? Kommt auf die AI-Gateway-Konfiguration an. Standardmäßig ja – für Debugging und Analyse. Das lässt sich einschränken oder deaktivieren.

Wo werden Vektoren in Vectorize gespeichert? In Cloudflares Infrastruktur. Mit Data Localization Suite: ausschließlich in der EU.

Wer hat Zugriff auf R2-Daten? Cloudflare als Auftragsverarbeiter, Zugriff durch Cloudflare-Personal nur bei Support-Vorgängen mit definierter Genehmigung. Details im DPA.

Gibt es eine Sub-Processor-Liste? Ja, Cloudflare veröffentlicht eine Liste der Sub-Processor. Diese muss bei der Datenschutz-Dokumentation berücksichtigt werden und sollte regelmäßig auf Änderungen geprüft werden.

Fließen Daten in Modell-Training ein? Nein – Workers AI-Inferenz ist laut Cloudflare-Bedingungen von Trainingspipelines getrennt. Das schließt aber andere Verarbeitungsrisiken nicht aus.

Checkliste: Cloudflare AI und DSGVO

Einordnung

Cloudflare löst das DSGVO-Problem nicht. Es verschiebt es von „unsichtbar und unkontrolliert” zu „konfigurierbar und dokumentierbar”. Das ist ein echter Unterschied – aber nur für diejenigen, die aktiv konfigurieren.

Wer Workers AI integriert und die Standardeinstellungen belässt, betreibt weiterhin eine Blackbox: Logging unkonfiguriert, Sub-Processor ungeprüft, Drittlandtransfer unbewertet. Die Plattform ermöglicht DSGVO-Konformität – sie erzwingt sie nicht.

Was das konkret bedeutet: Ein Worker, der Nutzereingaben ohne Pseudonymisierung an Workers AI weitergibt, kein AI Gateway verwendet und console.log für Debugging einsetzt, ist datenschutzrechtlich problematisch – auch wenn er auf EU-Knoten läuft und Cloudflares AVV unterzeichnet ist.

Die Verantwortung für Datenklassifizierung, AVV, Logging-Konfiguration, Drittlandtransfer-Prüfung, Nutzer-Transparenz und Sub-Processor-Dokumentation bleibt beim Betreiber. Cloudflare liefert die Werkzeuge. Die Prüfung, ob und wie sie eingesetzt werden, ist Entwickler- und Rechtsaufgabe.

Die DSGVO-Frage ist eine von mehreren, die bei der Stack-Entscheidung eine Rolle spielt. Die andere: Wie viel Aufwand spart Cloudflare wirklich – und für welche Projekte lohnt sich das?

Das ist Thema des letzten Teils der Serie.