Ein Unternehmen entscheidet sich, ein LLM über internen Dokumenten einzusetzen. Die IT richtet einen API-Schlüssel ein, ein Entwickler schreibt einen Wrapper, die Mitarbeiter beginnen, Angebote, Verträge und Besprechungsprotokolle in das Modell einzuspeisen. In der ersten Woche sieht alles hervorragend aus. Dann kommt der DSB und stellt eine einzige Frage: „Wo landen diese Daten?" Und niemand kann antworten.
Dieses Szenario ist kein Einzelfall — es ist der Normalzustand in vielen EU-Unternehmen. DSGVO bei LLM-Deployments ist kein akademisches Problem. Es ist eine konkrete Checkliste, die Sie entweder haben oder nicht. Dieser Artikel schlüsselt sie praxisnah auf: wo genau Daten abfließen, was Sie unterschrieben haben müssen, wann eine DSFA angemessen ist und wie Entscheidungsträger auf ein strukturiertes Framework statt auf Bauchgefühl zurückgreifen können.
Wo Daten abfließen — eine Datenfluss-Übersicht
Bevor Sie irgendetwas rechtlich klären, müssen Sie verstehen, was technisch passiert. Ein LLM im Produktionseinsatz ist kein einzelnes System — es ist eine Kette von Komponenten, von denen jede ein potenzielles Leck darstellt.
Ein typischer Datenfluss bei einem Cloud-LLM sieht so aus:
- Eingabedokument (Vertrag, E-Mail, Bericht) → Chunking → Embedding → Vektordatenbank
- Benutzeranfrage → Retrieval aus der Vektordatenbank → Kontext + Anfrage werden an die LLM-API gesendet
- LLM-API (z. B. OpenAI, Anthropic, Google) → verarbeitet den Prompt → gibt die Antwort zurück
- Logs und Traces → Observability (Langfuse, LangSmith, eigenes Logging) → potenziell weiterer Speicherort
Jeder dieser Schritte kann personenbezogene Daten (Personal Identifiable Information — PII) enthalten: den Namen eines Kunden in einem Vertrag, die E-Mail-Adresse einer Kontaktperson, Gesundheitsinformationen in einem Bericht, IBAN auf einem Zahlungsbeleg. Verlassen diese Daten Ihren Perimeter — und bei einem Cloud-API verlassen sie ihn —, sind Sie Verantwortlicher im Sinne der DSGVO mit konkreten Pflichten.
Ein weiterer Datenfluss, der häufig übersehen wird: Training und Fine-tuning. Einige Cloud-Anbieter geben ausdrücklich an, dass über die API gesendete Daten nicht für das Training verwendet werden (OpenAI im Enterprise-Tier, Anthropic bei der API). Aber die Standardeinstellungen variieren — und was heute gilt, kann sich bei einer Aktualisierung der Nutzungsbedingungen ändern. Prüfen Sie stets die aktuellen Terms of Service und verankern Sie dies vertraglich.
Cloud-API vs. On-prem — eine Entscheidung mit DSGVO-Tragweite
Dies ist die wichtigste Architekturentscheidung aus Compliance-Sicht.
Cloud-API (OpenAI, Anthropic, Gemini, Azure OpenAI...)
Die Vorteile liegen auf der Hand: leistungsstärkste Modelle, keine eigene Infrastruktur, schneller Start. Die DSGVO-Probleme:
- Daten verlassen Ihren Perimeter — Sie sind verpflichtet, einen Data Processing Agreement (DPA) mit dem Anbieter als Auftragsverarbeiter abzuschließen
- Bei Transfers außerhalb des EWR (z. B. Daten auf US-Servern) benötigen Sie einen Transfermechanismus — Standardvertragsklauseln (SCC) oder einen gleichwertigen Rechtsrahmen
- Sie müssen wissen, wo die Server physisch stehen; die Antwort „in der Cloud" genügt weder dem DSB noch einer Aufsichtsbehörde
Die meisten großen Anbieter bieten einen DPA an — aber Sie müssen ihn aktiv abschließen, nicht nur eine Checkbox anklicken. Azure OpenAI verfügt über europäische Regionen, was den Datentransfer außerhalb des EWR vereinfacht. Prüfen Sie die aktuellen Bedingungen direkt beim jeweiligen Anbieter.
On-prem / Self-hosted LLM
Die Daten verlassen Ihren Perimeter nicht. Wenn das Modell auf Ihren eigenen Servern läuft (oder auf Servern im EWR mit klarer Vertragsgrundlage), ist die DSGVO-Exposition erheblich geringer. Diese Wahl ist besonders sinnvoll für regulierte Branchen — Gesundheitswesen, Recht, Finanzen —, in denen sensible personenbezogene Daten verarbeitet werden. Einen ausführlicheren Blick auf dieses Thema finden Sie in On-prem-LLM für regulierte Branchen.
Der Trade-off liegt bei Qualität und Kosten: Self-hosted Open-Weight-Modelle (Llama, Qwen, Mistral, DeepSeek in ihren Open-Weight-Varianten) erreichen heute Produktionsqualität für die meisten unternehmensinternen Use-Cases, erfordern aber GPU-Infrastruktur und Engineering-Kapazitäten für den Betrieb. Für die Inferenz eines 7B–14B-Modells mit vertretbarer Latenz genügt grob ein Server mit ausreichend VRAM; größere Modelle benötigen mehr.
DPA — was er enthalten muss und warum ein Klick nicht reicht
Ein Data Processing Agreement ist eine gesetzliche Anforderung nach Artikel 28 DSGVO, wenn Sie personenbezogene Daten zur Verarbeitung an eine externe Partei weitergeben. Ein LLM-Anbieter, dem Sie Dokumente mit personenbezogenen Daten senden, ist Auftragsverarbeiter. Sie sind der Verantwortliche. Ohne DPA verstoßen Sie gegen das Gesetz.
Was ein DPA enthalten muss (gemäß Art. 28 Abs. 3 DSGVO):
- Gegenstand und Dauer der Verarbeitung — konkret, nicht vage
- Art und Zweck der Verarbeitung — „Inferenz für einen internen Chatbot" ist konkreter als „KI-Dienste"
- Art der personenbezogenen Daten und Kategorien betroffener Personen — Kunden? Mitarbeiter? Patienten?
- Pflichten und Rechte des Verantwortlichen — einschließlich Auditrechts
- Technische und organisatorische Maßnahmen (TOM) — Verschlüsselung, Zugangskontrolle, Incident Response
- Verbot der Weitervergabe an Sub-Auftragsverarbeiter ohne Genehmigung oder generelle Genehmigung mit gesetzlichem Mechanismus
Achten Sie auf ein Detail, das Unternehmen oft unterschätzen: Der DPA muss auch die Sub-Auftragsverarbeiter des Anbieters abdecken — Cloud-Infrastruktur, Logging-Dienste, Monitoring-Tools. Die meisten großen Anbieter veröffentlichen Listen ihrer Sub-Auftragsverarbeiter; prüfen Sie diese.
Rechtsgrundlage — auf welcher Basis verarbeiten Sie
Die DSGVO verlangt, dass jede Verarbeitung personenbezogener Daten eine Rechtsgrundlage hat (Art. 6). Bei unternehmensinternen LLM-Deployments begegnen uns am häufigsten:
- Berechtigte Interessen (Art. 6 Abs. 1 lit. f) — häufigste Grundlage für interne Unternehmenstools; erfordert ein LIA (Legitimate Interest Assessment), in dem Sie dokumentieren, dass das Interesse des Unternehmens die Rechte der betroffenen Personen überwiegt
- Vertragserfüllung (Art. 6 Abs. 1 lit. b) — relevant, wenn das LLM direkt der Erfüllung eines Vertrags mit dem Kunden dient
- Einwilligung (Art. 6 Abs. 1 lit. a) — für die meisten internen Tools unpraktisch; die Einwilligung muss freiwillig, informiert und widerrufbar sein
Wenn Sie besondere Kategorien von Daten verarbeiten (Gesundheits-, Genetik-, Biometrie-, politische, religiöse, gewerkschaftliche Daten oder Angaben zur sexuellen Orientierung) — Art. 9 DSGVO — ist die Rechtsgrundlage strenger, und eine Einwilligung ist nahezu unumgänglich, oder Sie müssen eine andere Grundlage aus der abschließenden Liste in Art. 9 Abs. 2 nachweisen.
Praktisch gesprochen: Bei einem LLM über HR-Dokumentation, Gesundheitsberichten oder Gerichtsschriftsätzen kommen Sie ohne Rechtsbeistand nicht weiter. Andernfalls riskieren Sie nicht nur ein Bußgeld, sondern auch, dass das gesamte Projekt gestoppt und rückabgewickelt werden muss.
PII-Scrubbing — wann und wie
PII-Scrubbing (das Bereinigen personenbezogener Daten vor dem Senden an das LLM) ist eine technische Maßnahme, die die Exposition verringert. Es ersetzt keine korrekte Rechtsgrundlage oder keinen DPA, reduziert aber die Angriffsfläche erheblich.
Wo es sinnvoll ist:
- Dokumente, bei denen das LLM keinen konkreten Namen kennen muss — es soll den Kontext, die Struktur, den Inhalt verstehen
- Log-Einträge — PII hat in Logs nichts verloren; das ist sowohl eine gesetzliche Anforderung als auch technische Hygiene
- Trainingsdatensätze — wenn Sie ein Modell auf internen Daten fine-tunen, kann PII in den Trainingsdaten vom Modell „memorisiert" werden (Memorization-Problem) und später ausgegeben werden
Technische Funktionsweise:
- Regex-basierte Detektoren — E-Mails, Telefonnummern, IBAN, Sozialversicherungsnummern, IP-Adressen; schnell, deterministisch, geringe False-Negative-Rate bei strukturierten Formaten
- NER-basierte Detektoren (Named Entity Recognition) — Personennamen, Unternehmen, Adressen; erfassen unstrukturierten Text; erfordern ein Modell und haben eine höhere Fehlerrate
- Kombination — Regex für strukturierte Formate + NER für Fließtext; Produktionsstandard
Wichtiger Hinweis: Pseudonymisierung ist keine Anonymisierung im Sinne der DSGVO. Wenn Sie ein Datum durch ein Token ersetzen, aber ein Wiederherstellungsschlüssel existiert, handelt es sich weiterhin um personenbezogene Daten. Der EDPB (Europäischer Datenschutzausschuss) hat wiederholt bestätigt, dass LLMs den Standard echter Anonymisierung selten erfüllen. Scrubbing verringert das Risiko — es eliminiert es nicht.
Für Inspiration bei der Implementierung einer Bereinigungspipeline können Sie sich ansehen, wie diese Schicht beispielsweise in Guardrails für KI-Agenten gelöst wird, wo Eingabevalidierung und PII-Erkennung die erste Verteidigungsschicht vor dem LLM bilden.
Datensparsamkeit — nichts mehr als nötig
Datensparsamkeit ist eines der Kernprinzipien der DSGVO (Art. 5 Abs. 1 lit. c): Verarbeiten Sie nur die personenbezogenen Daten, die für den jeweiligen Zweck unbedingt erforderlich sind.
Bei LLMs bedeutet das in der Praxis:
- In den Prompt gehen nur relevante Chunks, nicht ganze Dokumente — eine korrekt auf präzise Suche eingestellte RAG-Pipeline ist direkt auch ein Compliance-Instrument
- Aufbewahrungsrichtlinie für Logs und Traces — wie lange speichern Sie den Gesprächsverlauf? 30 Tage? 90 Tage? Ohne definierte Richtlinie dauert es „für immer"
- Embedding-Vektoren — auch eine vektorielle Repräsentation eines Dokuments kann personenbezogene Daten darstellen, wenn aus ihr das Original rekonstruiert oder eine Person identifiziert werden kann; behandeln Sie sie wie die Quelldaten
- Systemlogs der Inferenz — wenn Sie den gesamten Prompt einschließlich der Benutzeranfrage loggen, loggen Sie potenziell personenbezogene Daten; führen Sie selektives Logging oder Log-Scrubbing ein
DSFA — wann sie Pflicht ist und was sie enthält
Eine Datenschutz-Folgenabschätzung (DSFA) ist bei Verarbeitungen Pflicht, die „voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen" mit sich bringen (Art. 35 DSGVO). Bei LLM-Deployments bedeutet das typischerweise:
- Systematische und umfangreiche Verarbeitung besonderer Datenkategorien (Gesundheit, Finanzen, HR)
- Automatisierte Entscheidungsfindung mit rechtlicher oder ähnlich weitreichender Wirkung auf Personen
- Umfangreiche Überwachung öffentlich zugänglicher Bereiche
Praktisch gesprochen: Wenn Ihr LLM bei Entscheidungen über Mitarbeiter, Kunden oder Patienten mitwirkt, ist eine DSFA angemessen. Bei einem internen Chatbot über technische Dokumentation ohne besondere Datenkategorien ist eine DSFA voraussichtlich nicht verpflichtend — wir empfehlen aber zumindest eine interne Risikobeurteilung.
Was eine DSFA enthalten muss:
- Beschreibung der Verarbeitungsvorgänge — was, warum, wer, wo
- Beurteilung der Notwendigkeit und Verhältnismäßigkeit — lässt sich das Ziel mit geringerem Eingriff in die Privatsphäre erreichen?
- Risikobeurteilung für die Rechte und Freiheiten der betroffenen Personen
- Maßnahmen zur Risikobehandlung — technisch und organisatorisch
- Wenn das Restrisiko weiterhin hoch ist → Konsultation mit der Aufsichtsbehörde (z. B. Bundesbeauftragter für den Datenschutz und die Informationsfreiheit)
EU AI Act und DSGVO — zwei Compliance-Schichten
Seit August 2025 gelten Pflichten für GPAI-Modelle (General Purpose AI) im Rahmen des EU AI Act. Für einsetzende Unternehmen (Deployers) gelten die Pflichten nach Artikel 26 — insbesondere bei Hochrisiko-KI-Systemen.
Wichtig: EU AI Act und DSGVO duplizieren sich nicht, sondern ergänzen sich. Die DSGVO schützt personenbezogene Daten. Der EU AI Act adressiert die Risiken von KI-Systemen — einschließlich Situationen, in denen KI Entscheidungen über Menschen trifft oder beeinflusst. Wenn Ihr LLM-System bei HR-, Kredit-, Dienstleistungszugangs- oder Sicherheitsklassifizierungsentscheidungen mitwirkt, kann es als Hochrisiko-KI eingestuft werden — und dann haben Sie gleichzeitig Pflichten aus beiden Verordnungen.
Einen tieferen Einblick in die konkreten Pflichten für Unternehmen finden Sie im Artikel über EU AI Act und Unternehmenspflichten.
Praktische Compliance-Checkliste
Zusammenfassung als Kontrollliste vor dem Einsatz eines LLM über Unternehmensdaten:
- DPA mit jedem LLM-Anbieter — unterschrieben, nicht nur angeklickt; deckt auch Sub-Auftragsverarbeiter ab
- Rechtsgrundlage dokumentiert — LIA für berechtigte Interessen, Einwilligung wenn erforderlich; gespeichert, nicht nur im Kopf
- Datentransfer außerhalb des EWR geregelt — SCC oder Äquivalent, sofern der Anbieter auf US-Servern betrieben wird
- PII-Scrubbing — mindestens für Logs implementiert; für Dokumente, wo technisch möglich
- Datensparsamkeitsrichtlinie — Aufbewahrungsfristen für Logs, Konversationen und Embeddings definiert und durchgesetzt
- DSFA — für Hochrisiko-Use-Cases durchgeführt; Ergebnisse dokumentiert
- Technische und organisatorische Maßnahmen — Verschlüsselung bei Übertragung und im Ruhezustand, Zugangskontrolle, Incident-Response-Plan
- Verarbeitungsverzeichnis (Art. 30 DSGVO) — das LLM-System muss im Records of Processing Activities erfasst sein
- EU AI Act-Bewertung — ist Ihr System ein Hochrisiko-System? Wenn ja, Pflichten gemäß Art. 26
Häufige Fragen
Brauchen wir dafür einen Anwalt, oder schaffen wir das intern?
Das hängt vom Umfang ab. Für einen einfachen internen Chatbot über öffentliche technische Dokumentation ohne personenbezogene Daten reicht eine interne Beurteilung mit dem DSB. Wenn Sie besondere Datenkategorien verarbeiten, Transfers außerhalb des EWR abwickeln oder Ihr System Entscheidungen über Menschen beeinflusst, lohnt sich ein externer Rechtsanwalt mit Schwerpunkt Datenschutz und KI — DSGVO-Bußgelder erreichen bis zu 4 % des weltweiten Jahresumsatzes oder 20 Millionen Euro.
Kann ich anonymisierte Daten verwenden und die DSGVO umgehen?
Wenn Sie echte Anonymisierung erreicht haben — d. h. die Daten können keiner natürlichen Person auch indirekt zugeordnet werden —, gilt die DSGVO nicht. In der Praxis ist das schwierig. LLMs erreichen selten den Standard echter Anonymisierung; Pseudonymisierung (Ersatz durch ein rekonstruierbares Token) reicht nicht aus. Fragen Sie Ihren DSB, ob Ihre Methode den Anonymisierungsstandard wirklich erfüllt.
Müssen wir für jedes LLM-Projekt eine DSFA durchführen?
Nicht für jedes. Eine DSFA ist bei hohem Risiko für die Rechte von Personen Pflicht — typischerweise bei besonderen Datenkategorien, automatisierten Entscheidungen mit Auswirkungen auf Menschen oder umfangreicher Überwachung. Für einen internen Helpdesk über technische Handbücher ohne personenbezogene Daten ist eine DSFA nicht verpflichtend. Wir empfehlen jedoch zumindest eine kurze interne Risikobeurteilung und die Dokumentation der Entscheidung.
Was passiert, wenn der LLM-Anbieter seine Bedingungen ändert und beginnt, unsere Daten für das Training zu verwenden?
Das ist ein reales Risiko. Deshalb muss der DPA ein Verbot der Verwendung Ihrer Daten für das Training und ein Auditrecht enthalten. Beobachten Sie Änderungen in den Terms of Service und richten Sie einen Review-Prozess mindestens einmal jährlich ein. Ändert der Anbieter die Bedingungen entgegen dem DPA, haben Sie das Recht, den Vertrag zu kündigen und die Löschung der Daten zu verlangen.
Ist ein On-prem-LLM automatisch DSGVO-konform?
Nicht automatisch. On-prem beseitigt das Risiko der Datenübertragung an einen Drittauftragsverarbeiter, aber Sie müssen weiterhin eine definierte Rechtsgrundlage, eine Datensparsamkeitsrichtlinie, Aufbewahrungsfristen und technische Maßnahmen vorweisen. Der Unterschied besteht darin, dass Sie Probleme intern lösen — und nicht über einen DPA mit einem externen Anbieter.
*DSGVO und LLM über Unternehmensdaten ist kein Wochenendprojekt, aber auch kein Grund, den Start zu blockieren. Die meisten Unternehmen, mit denen wir arbeiten, brauchen vor allem einen strukturierten Überblick darüber, was bereits geregelt ist und was nicht — keine zig Stunden Rechtsberatung. Wenn Sie diese Checkliste für ein konkretes Deployment in Ihrem Unternehmen durcharbeiten möchten, stehen wir für ein erstes Gespräch zur Verfügung.*