DSGVO und LLM Compliance

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/2026

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.

Was die EDPB-Leitlinien bedeuten: Der Europäische Datenschutzausschuss hat am 8. Juli 2026 zwei Leitlinien vorgestellt. Beide sind Konsultationsfassungen, Stellungnahmen sind bis zum 30. Oktober 2026 möglich, Änderungen also noch zu erwarten. Die Scraping-Leitlinien stellen klar: Die DSGVO gilt, sobald beim Scraping personenbezogene Daten erhoben, gespeichert, geordnet oder abgerufen werden. Das berechtigte Interesse (Art. 6.1.f) bleibt die übliche Rechtsgrundlage privater Anbieter, verlangt aber eine dokumentierte Abwägung mit Schutzmaßnahmen: Quellen mit erkennbarem Widerspruch (etwa per robots.txt) ausschließen, Datenkategorien filtern, Risiken durch Memorisierung und Extraktion begrenzen. Für besondere Kategorien ist zusätzlich eine Ausnahme nach Art. 9 Abs. 2 nötig, eine pauschale Befreiung gibt es nicht.

Für Ihre Anbieterprüfung: Die Leitlinien richten sich an die Entwickler der Modelle. Sie liefern Ihnen aber den Fragenkatalog für die Beschaffung, denn laut EDPB-Stellungnahme 28/2024 kann ein mit rechtswidrig verarbeiteten Daten entwickeltes Modell die Rechtmäßigkeit seines Einsatzes beeinträchtigen, sofern es nicht wirksam anonymisiert wurde. Fragen Sie Anbieter deshalb nach Herkunft der Trainingsdaten, Rechtsgrundlage, Filter- und Ausschlussmechanismen sowie Maßnahmen gegen Memorisierung, und dokumentieren Sie die Antworten.

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?

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; die EDPB-Leitlinien zur Anonymisierung vom Juli 2026 prüfen dafür drei Kriterien: kein Herausgreifen einzelner Datensätze, keine Verknüpfbarkeit, keine Inferenz), 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):

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:

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".

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:

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

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

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

Privacy by Design: Architektur-Patterns

Pattern 1: PII-Redaction

Pattern 2: Need-to-Know RAG

Maßnahmen für CTOs/CISOs

Sofort prüfen

Kurzfristig umsetzen

Mittelfristig aufbauen

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