DSGVO und LLM Compliance
Wann verarbeiten LLMs personenbezogene Daten? Rechtsgrundlagen, Betroffenenrechte, AVV mit Anbietern. Privacy by Design für KI-Systeme.
Die DSGVO ist 7 Jahre alt. LLMs sind 2 Jahre Mainstream. Die Kombination? Rechtlich und technisch herausfordernd.
Das Recht auf Löschung bei trainierten Modellen? Technisch kaum umsetzbar. Die Frage, ob ein LLM selbst "personenbezogene Daten" enthält? Von deutschen Aufsichtsbehörden unterschiedlich bewertet. Und trotzdem brauchen Sie pragmatische Lösungen – die noyb-Beschwerden gegen OpenAI zeigen, dass Enforcement kommt.
Aktuelle Entwicklungen 2025
| Entwicklung | Status | Relevanz |
|---|---|---|
| DSK Orientierungshilfe KI | Mai 2024, Update Juni 2025 | Checkliste für Auswahl und Betrieb |
| DSK Orientierungshilfe RAG | Oktober 2025 | 18-seitiger Leitfaden für RAG-Systeme |
| noyb vs. OpenAI (1. Beschwerde) | April 2024, laufend | Halluzinationen = DSGVO-Verstoß? |
| noyb vs. OpenAI (2. Beschwerde) | März 2025 | Falsche "Kindermörder"-Behauptung |
| DeepSeek-Prüfverfahren | März 2025 | 7 deutsche Aufsichtsbehörden aktiv |
Was die noyb-Beschwerden bedeuten: OpenAI konnte auf Auskunftsanfragen nicht vollständig antworten und falsche Daten nicht berichtigen. Wenn das zu Bußgeldern führt (bis 4% des globalen Umsatzes), hat das Signalwirkung für jeden LLM-Betreiber.
Die Kernfrage: Wann ist ein LLM "personenbezogen"?
Die deutschen Aufsichtsbehörden sind sich nicht einig – das ist für Ihre Compliance relevant.
Position Hamburg (HmbBfDI)
"Ein LLM stellt keine personenbezogenen Daten im Sinne des Art. 4 Nr. 1 DSGVO dar. In LLMs werden keine personenbezogenen Daten gespeichert."
Interpretation: Das Modell selbst ist nicht personenbezogen – nur Input/Output können es sein.
Position Baden-Württemberg (LfDI BW)
"Ein Personenbezug kann durch Interaktionen entstehen – etwa bei schlecht anonymisierten Trainingsdaten oder 'Model Attacks', mit denen personenbezogene Daten generiert werden."
Interpretation: Unter bestimmten Umständen kann das Modell selbst personenbezogen sein.
Für Ihre Praxis: Gehen Sie vom konservativeren Ansatz aus. Behandeln Sie LLM-Systeme so, als könnten sie personenbezogene Daten verarbeiten – dann sind Sie auf der sicheren Seite.
Wo entstehen personenbezogene Daten?
Im Prompt
Offensichtlich:
"Schreibe eine E-Mail an [email protected] bezüglich seiner Bestellung #12345"
→ Name, E-Mail, Bestellnummer = personenbezogene Daten im Prompt
Weniger offensichtlich:
"Fasse die Beschwerde zusammen: 'Ich habe seit 3 Monaten Rückenschmerzen...'"
→ Gesundheitsdaten (Art. 9 – besondere Kategorie!)
Noch weniger offensichtlich:
"Analysiere diese Verkaufszahlen: Region Nord, Team Müller, Q3 2024"
→ "Team Müller" kann eine identifizierbare Person sein
Im Training/RAG
Wenn Sie ein LLM fine-tunen oder RAG mit Unternehmensdaten aufbauen:
- Kundendaten in Dokumenten
- E-Mails von Mitarbeitern
- CRM-Einträge
- Support-Tickets
Die neue DSK-Orientierungshilfe zu RAG (Oktober 2025) adressiert genau diese Risiken.
Im Output
LLMs generieren manchmal personenbezogene Daten:
- Halluzination: Falsche Informationen über echte Personen (noyb-Fall)
- RAG-Retrieval: Echte Kundendaten im Output ohne Berechtigung
- Context Leakage: Informationen aus vorherigen Konversationen
Die 7 DSGVO-Prinzipien für LLM-Betreiber
1. Rechtmäßigkeit (Art. 6)
Die Frage: Welche Rechtsgrundlage haben Sie für die Verarbeitung?
| Rechtsgrundlage | Geeignet für | Einschränkungen |
|---|---|---|
| Einwilligung (6.1.a) | Consumer-Apps mit Opt-in | Widerrufbar, dokumentationspflichtig |
| Vertragserfüllung (6.1.b) | Wenn LLM für Vertragsleistung nötig | Nur für tatsächlich erforderliche Daten |
| Berechtigtes Interesse (6.1.f) | Enterprise-Chatbots, interne Tools | Interessenabwägung dokumentieren! |
Für besondere Kategorien (Art. 9): Gesundheit, Biometrie, Religion → Ausdrückliche Einwilligung oder andere Art. 9-Grundlage nötig.
2. Zweckbindung (Art. 5.1.b)
Das Problem:
- Kundendaten für Bestellabwicklung gesammelt
- Jetzt für LLM-Training verwendet
- Ist das der gleiche Zweck? Nein.
Lösung:
- Neue Einwilligung einholen, oder
- Anonymisieren (echte Anonymisierung, nicht nur Pseudonymisierung), oder
- Nicht für Training verwenden
3. Datenminimierung (Art. 5.1.c)
LLMs sind "datenmaximierend" – mehr Kontext = bessere Antworten. Das steht im Konflikt mit DSGVO-Minimierung.
Praktische Umsetzung:
# Schlecht: Alle verfügbaren Daten
prompt = f"""Der Kunde {name} (geb. {geburtsdatum}, Steuer-ID {steuer_id})
hat eine Beschwerde über Produkt X eingereicht."""
# Besser: Nur das Nötige
prompt = f"""Ein Kunde hat eine Beschwerde über Produkt X eingereicht."""
Technische Lösung: PII-Redaction vor dem LLM-Call (siehe Architektur-Pattern unten).
4. Richtigkeit (Art. 5.1.d)
Das noyb-Problem: ChatGPT halluzinierte falsche Informationen über reale Personen – falsches Geburtsdatum, im zweiten Fall sogar "Kindermörder"-Behauptung.
Ihre Pflicht als Betreiber:
- Human Oversight für personenbezogene Outputs
- Keine automatisierten Entscheidungen basierend auf LLM-Output allein
- Fact-Checking-Prozesse für kritische Anwendungen
5. Speicherbegrenzung (Art. 5.1.e)
Provider-Vergleich (Stand Dezember 2025):
| Provider | Consumer | Enterprise |
|---|---|---|
| OpenAI (ChatGPT) | 30 Tage (API), Training möglich | Keine Speicherung, kein Training |
| Anthropic (Claude) | 30 Tage (API) | Keine Speicherung (Team/Enterprise) |
| Microsoft (Azure OpenAI) | 30 Tage | Opt-out verfügbar |
| Google (Vertex AI) | Variabel | Keine Speicherung (Enterprise) |
Consumer-Versionen (ChatGPT Free, Claude Free, Gemini):
- Daten können für Training verwendet werden
- Nicht für Unternehmensdaten geeignet
6. Integrität und Vertraulichkeit (Art. 5.1.f)
Risiken bei Cloud-LLMs:
- Transit-Sicherheit (meist TLS – OK)
- Speicherung beim Provider (Enterprise-Pläne prüfen)
- Provider-Mitarbeiter-Zugriff (SOC 2 Reports prüfen)
- Subprocessors (AVV prüfen)
7. Rechenschaftspflicht (Art. 5.2)
Dokumentation, die Sie nachweisen können müssen:
| Dokument | Pflicht | Inhalt |
|---|---|---|
| Verzeichnis der Verarbeitungstätigkeiten (Art. 30) | Ja | Alle LLM-Systeme mit Zweck, Rechtsgrundlage, Kategorien |
| Datenschutz-Folgenabschätzung (Art. 35) | Bei High-Risk | Risikobewertung, Maßnahmen |
| AVV mit Providern (Art. 28) | Ja | Siehe unten |
| Technische und organisatorische Maßnahmen | Ja | PII-Redaction, Logging, Access Control |
Betroffenenrechte: Das LLM-Dilemma
Recht auf Auskunft (Art. 15)
Die Anforderung: "Welche Daten verarbeiten Sie über mich?"
Das Problem: Können Sie alle Prompts mit dieser Person finden? Alle RAG-Dokumente? Alle Outputs?
Technische Lösung:
- Logging mit Suchfunktion (Metadaten, nicht volle Prompts)
- Tagging nach Betroffenen-Kategorien
- Retention Policy mit definierten Löschfristen
Recht auf Berichtigung (Art. 16)
Das noyb-Problem: OpenAI sagte, Berichtigung sei "technisch nicht möglich".
| System-Typ | Berichtigungsmöglichkeit |
|---|---|
| RAG | Quelldaten korrigieren (machbar) |
| Fine-Tuned | Model neu trainieren (aufwändig) |
| Base Model | Nicht möglich (nicht Ihr Problem) |
Workaround: Output-Filter für bekannte Fehler ("Erwähne Person X nicht mehr").
Recht auf Löschung (Art. 17) – Der Problemfall
Die Anforderung: "Löschen Sie alle Daten über mich."
Was technisch möglich ist:
| Komponente | Löschung möglich? | Aufwand |
|---|---|---|
| Prompts/Logs | Ja | Gering |
| RAG-Dokumente | Ja | Gering |
| Fine-Tuning-Daten | Ja (Re-Training nötig) | Hoch |
| Base Model | Nein | — |
Position des HmbBfDI:
"Eine Löschung aus dem trainierten Model ist nicht erforderlich, wenn technisch nicht möglich. Aber: Outputs filtern, um die Person nicht mehr zu erwähnen."
Ihre Dokumentation sollte enthalten: Warum vollständige Löschung technisch nicht möglich ist, welche Ersatzmaßnahmen Sie ergreifen.
AVV mit LLM-Anbietern
Wenn Sie Cloud-LLMs nutzen: Sie sind Verantwortlicher, der Provider ist Auftragsverarbeiter.
Was der AVV enthalten muss (Art. 28)
- Gegenstand und Dauer der Verarbeitung
- Art und Zweck der Verarbeitung
- Art der personenbezogenen Daten
- Kategorien betroffener Personen
- Weisungsgebundenheit
- Vertraulichkeit
- Unterauftragsverarbeiter (Subprocessors)
- Unterstützung bei Betroffenenrechten
- Löschung nach Ende
- Audit-Rechte
Provider-Vergleich
| Provider | AVV/DPA | EU-Hosting | Training mit Ihren Daten |
|---|---|---|---|
| OpenAI Enterprise | ✓ | ✓ (Option) | ✗ Nein |
| Azure OpenAI | ✓ | ✓ EU | ✗ Nein |
| Anthropic Enterprise | ✓ | ✓ EU | ✗ Nein |
| AWS Bedrock | ✓ | ✓ EU | ✗ Nein |
| Google Vertex AI | ✓ | ✓ EU | ✗ Nein |
Consumer-Versionen: Kein echter AVV möglich, Daten können für Training verwendet werden. Nicht für Unternehmensdaten.
Self-Hosted: DSGVO-Vereinfachung
Warum Self-Hosted einfacher sein kann
| Aspekt | Cloud-LLM | Self-Hosted |
|---|---|---|
| Drittland-Transfer | Ja (meist US) | Nein |
| AVV nötig | Ja | Nein |
| Kontrolle über Daten | Eingeschränkt | Vollständig |
| Training mit Ihren Daten | Provider-abhängig | Sie entscheiden |
| Löschung | Eingeschränkt | Vollständig |
Wann Self-Hosted?
- Besondere Kategorien (Gesundheit, Biometrie)
- Regulierte Branchen (Finanzen, kritische Infrastruktur)
- Volle Kontrolle über Datenflüsse erforderlich
- Compliance-Anforderungen, die Cloud ausschließen
Optionen
| Modell | Herkunft | Lizenz | DSGVO-relevant |
|---|---|---|---|
| Llama 3.x | Meta (US) | Permissive | Kein Drittland-Transfer beim Betrieb |
| Mistral | Mistral AI (FR) | Apache 2.0 | EU-Anbieter |
| Mixtral | Mistral AI (FR) | Apache 2.0 | EU-Anbieter |
| Qwen | Alibaba (CN) | Permissive | Herkunft dokumentieren |
Privacy by Design: Architektur-Patterns
Pattern 1: PII-Redaction
User Input
PII Redaction
Mapping lokal gespeichert (verschlüsselt)
LLM Call
Keine PII zum ProviderPII Restoration
Output
Vollständig wiederhergestelltVorteil: Personenbezogene Daten verlassen nie Ihre Infrastruktur. Der LLM-Provider sieht nur Platzhalter.
Pattern 2: Need-to-Know RAG
RAG Query
support-agent-team-nordAccess Control Check
Filtered RAG Retrieval
- Nur Dokumente, die User sehen darf
- Keine Cross-Team-Daten
- Keine restricted Dokumente
LLM + Output
Berechtigter OutputOhne Access Control: Ein Query über Produkte könnte Kundendaten retrieven, für die der User keine Berechtigung hat. Row-Level-Security von Anfang an implementieren.
Maßnahmen für CTOs/CISOs
Sofort prüfen
| Prüfpunkt | Aktion bei Lücke |
|---|---|
| Welche LLMs sind im Einsatz? | Inventar erstellen (Consumer vs. Enterprise) |
| Gehen PII in Prompts? | Data Flow Mapping durchführen |
| Existieren AVVs mit Providern? | Fehlende AVVs einfordern |
| Consumer-Versionen für Geschäftsdaten? | Sofort stoppen |
Kurzfristig umsetzen
| Maßnahme | Verantwortlich | Priorität |
|---|---|---|
| Enterprise-Pläne für alle geschäftlichen Anwendungen | IT/Procurement | Hoch |
| PII-Redaction evaluieren/implementieren | Engineering | Hoch |
| Verarbeitungsverzeichnis um LLM-Systeme erweitern | DSB | Mittel |
| Datenschutzhinweise aktualisieren | Legal/DSB | Mittel |
Mittelfristig aufbauen
| Maßnahme | Verantwortlich | Priorität |
|---|---|---|
| DSFA für High-Risk-KI-Systeme | DSB + Engineering | Hoch |
| Prozesse für Betroffenenrechte bei LLMs | DSB + Engineering | Mittel |
| Privacy by Design als Standard | CTO/Engineering | Mittel |
| Self-Hosted-Optionen für sensitive Daten | Infrastructure | Niedrig |
Die Frage für Ihr nächstes Audit
"Wenn ein Betroffener nach Art. 15 Auskunft verlangt: Können Sie alle Verarbeitungen in LLM-Systemen nachweisen, die diese Person betreffen?"
Wenn die Antwort nicht "Ja" ist, haben Sie eine Lücke in Ihrer Dokumentation.
Weiterführend
- EU AI Act Umsetzung – Regulatorischer Rahmen
- NIS2 und KI – Überschneidung mit Cybersecurity-Compliance
- Shadow AI bekämpfen – DSGVO-Risiken durch unkontrollierte Nutzung
- Data Privacy Architecture – Technische Patterns im Detail
AI Security Insights
Einmal im Monat. Kein Spam.
Was passiert in der Welt der KI-Security? Welche Risiken sollten Sie kennen? Ich fasse das Wichtigste zusammen - verständlich, pragmatisch, ohne Buzzwords.