Alle Artikel
19. Oktober 202514 Min. Lesezeit • Aktualisiert 4. Dez.

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

EntwicklungStatusRelevanz
DSK Orientierungshilfe KIMai 2024, Update Juni 2025Checkliste für Auswahl und Betrieb
DSK Orientierungshilfe RAGOktober 202518-seitiger Leitfaden für RAG-Systeme
noyb vs. OpenAI (1. Beschwerde)April 2024, laufendHalluzinationen = DSGVO-Verstoß?
noyb vs. OpenAI (2. Beschwerde)März 2025Falsche "Kindermörder"-Behauptung
DeepSeek-PrüfverfahrenMärz 20257 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?

RechtsgrundlageGeeignet fürEinschränkungen
Einwilligung (6.1.a)Consumer-Apps mit Opt-inWiderrufbar, dokumentationspflichtig
Vertragserfüllung (6.1.b)Wenn LLM für Vertragsleistung nötigNur für tatsächlich erforderliche Daten
Berechtigtes Interesse (6.1.f)Enterprise-Chatbots, interne ToolsInteressenabwä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):

ProviderConsumerEnterprise
OpenAI (ChatGPT)30 Tage (API), Training möglichKeine Speicherung, kein Training
Anthropic (Claude)30 Tage (API)Keine Speicherung (Team/Enterprise)
Microsoft (Azure OpenAI)30 TageOpt-out verfügbar
Google (Vertex AI)VariabelKeine 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:

DokumentPflichtInhalt
Verzeichnis der Verarbeitungstätigkeiten (Art. 30)JaAlle LLM-Systeme mit Zweck, Rechtsgrundlage, Kategorien
Datenschutz-Folgenabschätzung (Art. 35)Bei High-RiskRisikobewertung, Maßnahmen
AVV mit Providern (Art. 28)JaSiehe unten
Technische und organisatorische MaßnahmenJaPII-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-TypBerichtigungsmöglichkeit
RAGQuelldaten korrigieren (machbar)
Fine-TunedModel neu trainieren (aufwändig)
Base ModelNicht 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:

KomponenteLöschung möglich?Aufwand
Prompts/LogsJaGering
RAG-DokumenteJaGering
Fine-Tuning-DatenJa (Re-Training nötig)Hoch
Base ModelNein

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

ProviderAVV/DPAEU-HostingTraining 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

AspektCloud-LLMSelf-Hosted
Drittland-TransferJa (meist US)Nein
AVV nötigJaNein
Kontrolle über DatenEingeschränktVollständig
Training mit Ihren DatenProvider-abhängigSie entscheiden
LöschungEingeschränktVollstä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

ModellHerkunftLizenzDSGVO-relevant
Llama 3.xMeta (US)PermissiveKein Drittland-Transfer beim Betrieb
MistralMistral AI (FR)Apache 2.0EU-Anbieter
MixtralMistral AI (FR)Apache 2.0EU-Anbieter
QwenAlibaba (CN)PermissiveHerkunft dokumentieren

Privacy by Design: Architektur-Patterns

Pattern 1: PII-Redaction

PII-Redaction Pattern

User Input

"Erstelle einen Bericht für [email protected], Bestellung #12345 von Max Müller"

PII Redaction

#12345[ORDER_ID]
Max Müller[NAME]

Mapping lokal gespeichert (verschlüsselt)

LLM Call

Keine PII zum Provider
"Erstelle einen Bericht für [EMAIL], Bestellung [ORDER_ID] von [NAME]"

PII Restoration

[ORDER_ID]#12345
[NAME]Max Müller

Output

Vollständig wiederhergestellt
"Bericht für [email protected], Bestellung #12345 von Max Müller..."

Vorteil: Personenbezogene Daten verlassen nie Ihre Infrastruktur. Der LLM-Provider sieht nur Platzhalter.

Pattern 2: Need-to-Know RAG

Need-to-Know RAG Pattern

RAG Query

User:"Was ist der Status der Bestellung von Kunde X?"
Role:support-agent-team-nord

Access Control Check

User darf Kundendaten Team Nord sehen?
Kunde X gehört zu Team Nord?
Bestellungen sind nicht restricted?

Filtered RAG Retrieval

  • Nur Dokumente, die User sehen darf
  • Keine Cross-Team-Daten
  • Keine restricted Dokumente

LLM + Output

Berechtigter Output
"Die Bestellung von Kunde X ist in Bearbeitung..."

Ohne 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üfpunktAktion 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ßnahmeVerantwortlichPriorität
Enterprise-Pläne für alle geschäftlichen AnwendungenIT/ProcurementHoch
PII-Redaction evaluieren/implementierenEngineeringHoch
Verarbeitungsverzeichnis um LLM-Systeme erweiternDSBMittel
Datenschutzhinweise aktualisierenLegal/DSBMittel

Mittelfristig aufbauen

MaßnahmeVerantwortlichPriorität
DSFA für High-Risk-KI-SystemeDSB + EngineeringHoch
Prozesse für Betroffenenrechte bei LLMsDSB + EngineeringMittel
Privacy by Design als StandardCTO/EngineeringMittel
Self-Hosted-Optionen für sensitive DatenInfrastructureNiedrig

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

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.

Einmal pro Monat Jederzeit abbestellbar Kein Spam, versprochen