RAG-Systeme DSGVO-konform aufbauen: Praxis-Leitfaden

Ein DSGVO-konformes RAG-System verarbeitet personenbezogene Daten in Quelldokumenten, Vektor-Index und Embeddings nur auf gesicherter Rechtsgrundlage, mit Datenminimierung, EU-Hosting, Mandantentrennung und einer Lösch-Pipeline, die Chunks und Embeddings gemeinsam entfernt. Embeddings gelten dabei nach Aufsichtspraxis als pseudonyme personenbezogene Daten, nicht als anonym. Dieser Leitfaden ordnet die technischen Bausteine den Datenschutz-Anforderungen zu und liefert eine abhakbare Checkliste.

Drei Schnellantworten:

• Embeddings sind nicht anonym. Aus Vektoren lassen sich Inhalte rekonstruieren (Text-Embedding-Inversion). Behandeln Sie sie als pseudonyme personenbezogene Daten.
• Löschen heißt Chunk plus Embedding. Wer nur das Quelldokument entfernt, lässt den Vektor zurück, der über die Ähnlichkeitssuche weiterhin Inhalte preisgibt.
• EU-Hosting und Mandantentrennung sind Pflicht-Bausteine, nicht Kür: souveräne Vektor-DB plus LLM in EU-Region, ACL-Filter bei jeder Query.

Hinweis: Dieser Beitrag ist eine fachliche Einordnung und stellt keine Rechtsberatung dar. Konkrete Rechtsfragen klären Sie mit Ihrer Datenschutz- oder Rechtsabteilung.

Wo personenbezogene Daten in einem RAG-System entstehen

RAG (Retrieval-Augmented Generation) ruft vor der Antwortgenerierung gezielt Wissen aus einer externen Quelle ab und bettet es in den Prompt ein. Personenbezogene Daten entstehen dabei an mehreren Stellen gleichzeitig: in den Quelldokumenten (CRM-, HR-, Kunden-Records), in den indexierten Chunks, in den Embedding-Vektoren, in der Query selbst, in der generierten Antwort und in Logs sowie Traces. Jede dieser Stationen ist eine eigene Verarbeitung im Sinne der DSGVO.

Die maßgebliche DACH-Referenz ist die Orientierungshilfe der Datenschutzkonferenz (DSK) zu RAG. Sie betont drei Pflicht-Bausteine: Mandantentrennung, ein Rechte- und Rollenkonzept sowie eine Lösch-Pipeline, die sich auf Chunks und Embeddings erstreckt. Ergänzend gelten die DSGVO-Grundsätze des Art. 5 (Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung) auch für Vektor-Repräsentationen, sobald sie einem Betroffenen zugeordnet werden können.

Der zentrale Irrtum: Embeddings sind keine Anonymisierung

Ein verbreiteter Fehler ist, Vektor-Caches als "anonymisierte Features" zu deklarieren. Das widerspricht der Forschungslage. Text-Embedding-Inversion-Angriffe (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, 2023, sowie Folgearbeiten 2024–2025) zeigen, dass sich aus Embeddings große Teile des Originaltexts rekonstruieren lassen. Hinzu kommen Membership-Inference-Angriffe und die Re-Identifikation über die Ähnlichkeitssuche: Wer einen ähnlichen Text besitzt, findet die indexierte Person.

Konsequenz: CNIL und die Hamburger Aufsicht behandeln Embeddings standardmäßig als pseudonyme personenbezogene Daten. Pseudonymisierte Daten bleiben nach Erwägungsgrund 26 DSGVO personenbezogen. Embedding allein ist nach herrschender Auffassung keine sichere Pseudonymisierung. Vermarkten oder dokumentieren Sie Embeddings deshalb nie als anonym, es sei denn, ein Verfahren mit Differential Privacy und belastbaren Tests weist das ausnahmsweise nach.

Datenminimierung: PII erkennen und vor dem Embedding pseudonymisieren

Datenminimierung (Art. 5 Abs. 1 lit. c) ist im RAG-Kontext eine Pipeline-Frage, kein nachträglicher Filter. Die wirksamsten Hebel:

• PII-Erkennung vor der Indexierung: NER- oder regelbasierte Pipelines (etwa Microsoft Presidio oder interne NER) markieren Namen, Adressen, Ausweisnummern in den Chunks, bevor diese embedded werden.
• Pseudonymisierung der Quell-Chunks: Identifikatoren durch stabile Pseudonyme ersetzen; die Zuordnungstabelle in einem separaten, rollenbasiert geschützten Store halten.
• Kontext-Engineering pro Query: Nur abrufen und in den Prompt geben, was die Aufgabe braucht, nicht den ganzen Dokumentensatz. Re-Ranking auf top_k = 5–10 reduziert sowohl Kosten als auch die Menge offengelegter Daten.
• Log-Redaktion: Prompt- und Output-Logs vor der dauerhaften Speicherung redigieren; pseudonyme IDs für Joins über Systeme hinweg.

Die DSK verweist hierfür auf das Standard-Datenschutzmodell (SDM v3.0) als Kontrollkatalog, der Pseudonymisierung über alle Gewährleistungsziele abbildet.

EU-Hosting für LLM und Vektor-Store

Datenresidenz ist ein direkter Risikohebel. EU-Region-Hosting senkt das Drittlandrisiko, beseitigt bei US-Anbietern aber nicht automatisch das CLOUD-Act-Restrisiko. Bei Drittlandbezug sind Standardvertragsklauseln (SCC) plus Transfer-Impact-Assessment (TIA) zu prüfen. Souveräne DACH-/EU-Optionen vermeiden diese Frage weitgehend:

Für deutschsprachige Korpora ist zusätzlich die Modellwahl relevant: Multilinguale Modelle wie Cohere Embed v4, Voyage-3 oder Gemini Embedding 002 liegen vorn; deutschspezifische Modelle (GBERT, GELECTRA, GermanDPR) bleiben in eng begrenzten On-Prem-Domänen konkurrenzfähig. BGE-M3 ist ein quelloffener, mehrsprachiger Fallback aus China (BAAI) und damit kein souveränes DACH-Modell, aber on-prem betreibbar.

Löschkonzept und Recht auf Vergessen: das Re-Indexing-Problem

Das Recht auf Löschung (Art. 17) ist im RAG-Stack der schwierigste Anspruch. Wichtig ist die Trennung von zwei Ebenen:

1. Inference-Layer (Managed API): Auf Modellebene gibt es keine produktionsreife, verifizierbare Löschung einzelner Personendaten ohne vollständiges Neutraining. Hier stützt man sich auf die No-Training-Zusage im AVV plus Output-Filter, die die Wiedergabe bestimmter Inhalte unterdrücken.
2. Deployer-kontrollierte Ebenen: Vektor-Store, Agenten-Memory, Logs und etwaige Fine-Tuning-Datensätze sind vollständig löschbar und tragen die Hauptlast der Compliance.

Im Vektor-Store gilt: Hard Delete entfernt Vektor und Quell-Metadaten und ist der bevorzugte Default. Soft Delete markiert nur und behält den Vektor; das birgt Leakage über die Ähnlichkeitssuche und ist allenfalls bei sehr kurzer Aufbewahrung vertretbar. Operative Faustregel: Beim Löschen einer Person Quelldokument und Embedding gemeinsam entfernen.

Das "Re-Indexing-Problem" wird oft missverstanden. Eine vollständige Re-Indexierung ist nur bei einem Wechsel des Embedding-Modells nötig (Embedding-Drift macht Indices sonst unvergleichbar). Das gezielte Löschen einzelner Personen sollte hingegen über stabile Doc-IDs als idempotentes Upsert/Delete funktionieren, ohne den gesamten Index neu aufzubauen. Taggen Sie jeden Memory- und Index-Eintrag mit subject_id; ein DSAR-Endpoint findet darüber alle betroffenen Records.

Zugriffskontrolle und Mandantentrennung

Der Privacy-Leak-Klassiker im RAG ist, dass ein Chunk von Mandant A für Mandant B abgerufen wird. Die DSK-Orientierungshilfe RAG fordert Mandantentrennung und ein Rechte-/Rollenkonzept. Technisch umsetzbar mit:

• Filterbare Metadaten: tenant_id, ACL, source, Zeitstempel je Chunk; Filterable HNSW (Qdrant, Weaviate, pgvector mit Row-Level Security).
• Defense-in-Depth: Authentifizierung und Tenant-Resolution vor der Query, Pre-Filter auf tenant_id, ein Re-Check nach dem Retrieval und ein Audit-Log über jeden Zugriff.
• Pro-Tenant-Collection oder -Namespace als Alternative zum reinen Metadaten-Filter, wenn die Isolation stärker garantiert werden muss.

Rechtsgrundlage und AVV mit Anbietern

Für das Einbetten personenbezogener Dokumente braucht es eine Rechtsgrundlage nach Art. 6, typisch Art. 6 Abs. 1 lit. b (Vertrag) oder lit. f (berechtigtes Interesse, mit dokumentierter Interessenabwägung). Besondere Kategorien personenbezogener Daten (Art. 9, etwa Gesundheits- oder Gewerkschaftsdaten) sind grundsätzlich verboten und nur über einen Ausnahmetatbestand verarbeitbar; im Zweifel aus dem Index ausschließen.

Jeder externe Baustein ist datenschutzrechtlich einzuordnen. Modellanbieter und Cloud agieren meist als Auftragsverarbeiter; dann ist ein Auftragsverarbeitungsvertrag (AVV, Art. 28) Pflicht. Achten Sie auf:

• No-Training-Zusage: Eingaben, Ausgaben, Embeddings und Fine-Tuning-Daten werden nicht zum Training der Anbietermodelle genutzt. Bei Enterprise-Tarifen von Microsoft Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral und Aleph Alpha ist das (Stand 2026) vertraglich der Default; Verbraucher-Tarife weichen ab.
• Sub-Prozessor-Kette: Modellanbieter, Cloud, Vektor-Store, ggf. MCP-Server und Observability lückenlos benannt (Art. 28 Abs. 4). Häufigster Auditfund: nicht abgedeckte Observability- oder MCP-Flows.
• Aufbewahrung: Konfigurierbare Retention bis hin zu Zero-Data-Retention. Anbieter-Defaults (Stand 2026) liegen z. B. bei maximal 30 Tagen (OpenAI API) bzw. 7 Tagen (Anthropic API, seit 14. September 2025).
• Datenresidenz verbindlich auf EU/CH festlegen und Failover-Routing in Drittländer ausschließen.

Praxisbeispiel: Support-RAG über Kunden-Tickets

Eine DACH-Agentur baut für einen B2B-Kunden ein RAG über 80.000 Support-Tickets. Vorgehen mit Zahlen:

1. Ingestion: Presidio-NER pseudonymisiert Namen, E-Mail-Adressen und Vertragsnummern in den Chunks; die Mapping-Tabelle liegt in einem separaten, RBAC-geschützten Store.
2. Chunking und Embedding: Layout-aware Parsing, dann ~512-Token-Chunks; Embedding mit einem EU-/DACH-Modell; Upsert in Qdrant (EU-Region) mit tenant_id, ticket_id, source, ts als Metadaten.
3. Query: Auth + Tenant-Resolution, Hybrid Retrieval top_k = 50, Re-Ranking auf top_k = 8, Antwort mit Quellen-Zitaten (Chunk-IDs).
4. Löschung: DSAR auf einen Kunden führt einen Hard Delete aller Vektoren mit dessen subject_id aus und löscht die Quell-Chunks gemeinsam. Pseudo-Code:

```
on dsar_erasure(subject_id):
ids = vector_db.query(filter={"subject_id": subject_id}, only_ids=True)
vector_db.delete(ids) # Embedding + Metadaten (Hard Delete)
source_store.delete(subject_id) # Quelldokument
audit_log.write("erasure", subject_id, count=len(ids))
```

5. Governance: DSFA vor Go-live (KI-Systeme lösen nach DSK-Praxis fast immer eine DSFA aus), AVV mit Cloud- und Modellanbieter, 30-Tage-Retention auf Logs mit Redaktion.

Abhakbare DSGVO-Checkliste für RAG

• Rechtsgrundlage je Verarbeitung dokumentiert (Art. 6; bei lit. f mit Interessenabwägung)
  
• Besondere Kategorien (Art. 9) identifiziert und, wo ohne Tatbestand, aus dem Index ausgeschlossen
  
• PII-Erkennung und Pseudonymisierung der Chunks vor dem Embedding
  
• Embeddings als pseudonyme personenbezogene Daten klassifiziert, nicht als anonym
  
• EU-Region-Hosting für LLM und Vektor-Store; bei Drittland SCC + TIA
  
• Mandantentrennung über tenant_id/ACL; Filter bei jeder Query plus Re-Check und Audit-Log
  
• Lösch-Pipeline: Hard Delete von Quelldokument und Embedding gemeinsam, über stabile IDs
  
• DSAR-Endpoint findet subject_id über Vektor-Store, Memory und Logs
  
• Retention-Policy mit Redaktion für Prompts, Outputs, Logs
  
• AVV mit jedem Anbieter (No-Training, Sub-Prozessor-Kette, Datenresidenz, Retention)
  
• Quellen-Zitate in jeder Antwort (Chunk-IDs) für Nachvollziehbarkeit
  
• DSFA durchgeführt; Membership-Inference- und Data-Poisoning-Risiken adressiert
  

Für Agenturen und B2B-Entscheider

Datenschutz ist bei RAG kein nachgelagertes Audit, sondern eine Architektur-Entscheidung: souveräne EU-Bausteine, eine saubere Lösch-Pipeline und Mandantentrennung lassen sich am günstigsten ab Tag eins einplanen, nicht nachrüsten. Agenturen, die DSGVO-Konformität als Standard-Liefermerkmal verankern, reduzieren das Haftungsrisiko ihrer Kunden und differenzieren sich im DACH-Markt. Als Wiener Agentur begleitet Blck Alpaca den Aufbau DSGVO-konformer RAG- und KI-Agenten-Systeme von der DSFA bis zur produktiven Lösch-Pipeline. Diese Inhalte ersetzen keine Rechtsberatung; die finale rechtliche Bewertung trifft Ihre Datenschutz- oder Rechtsabteilung.