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 aus personenbezogenen Texten sind dabei als pseudonyme personenbezogene Daten zu behandeln, 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). Behandle 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 gehören von Anfang an ins Design, nicht als Kür obendrauf: 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ärst du mit deiner 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 wichtigste deutsche Referenz ist die Orientierungshilfe der Datenschutzkonferenz (DSK) zu RAG-Systemen vom Oktober 2025. Sie nennt Mandantentrennung und ein Rechte- und Rollenkonzept als Schutzmaßnahmen für die Vektordatenbank und hält fest, dass sich Einträge in Vektordatenbank und Referenzdokumenten gezielt löschen lassen. In Österreich ist die Datenschutzbehörde (DSB) zuständig, auch für datenschutzrechtliche Fragen bei KI-Systemen. Die DSK ist das Gremium der deutschen Datenschutzaufsichtsbehörden von Bund und Ländern; für die österreichische DSB sind ihre Papiere daher nicht verbindlich, sie taugen dort aber als Auslegungshilfe. 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: Behandle Embeddings aus personenbezogenen Texten als pseudonyme personenbezogene Daten. Das Diskussionspapier des Hamburgischen Datenschutzbeauftragten vom Juli 2024 sieht zwar in den Embeddings innerhalb eines LLM keinen Personenbezug, bewertet aber ausdrücklich nur das Modell selbst. Für Datenbankabfragen im übrigen KI-System gelten die Betroffenenrechte weiter. Die Vektoren einer RAG-Datenbank, die jeweils einem Chunk mit Personendaten zugeordnet sind, deckt das Papier damit nicht ab. Pseudonymisierte Daten bleiben für den Verantwortlichen, der die Zuordnung herstellen kann, personenbezogen (Erwägungsgrund 26 DSGVO). Für einen Empfänger ohne realistische Zuordnungsmöglichkeit sind sie nach dem EuGH-Urteil C-413/23 P vom 4. September 2025 nicht zwingend personenbezogen. Am Ergebnis für deinen eigenen Vektor-Store ändert das nichts. Embedding allein ist nach herrschender Auffassung keine sichere Pseudonymisierung. Vermarkte oder dokumentiere 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.

Für die technische Umsetzung verweist die DSK in ihrer Orientierungshilfe zu technischen und organisatorischen Maßnahmen bei KI-Systemen (Juni 2025) auf das Standard-Datenschutzmodell (SDM V3.1). Es übersetzt die Anforderungen der DSGVO über Gewährleistungsziele wie Datenminimierung und Nichtverkettung in technische und organisatorische Maßnahmen.

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. Jina und BGE-M3 in der Tabelle sind offene Modelle für den Eigenbetrieb, aber keine souveränen DACH-Anbieter:

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. Tagge 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 von der deutschen DSK genannte Mandantentrennung lässt sich technisch so umsetzen:

• 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. Achte 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 und genehmigt (Art. 28 Abs. 2 und 4 DSGVO). Häufigster Auditfund: nicht abgedeckte Observability- oder MCP-Flows.
• Aufbewahrung: Konfigurierbare Retention bis hin zu Zero-Data-Retention. Anbieter-Defaults (Stand 2026): Die OpenAI API und die Anthropic API bewahren Ein- und Ausgaben höchstens 30 Tage auf.
• 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 (laut der Orientierungshilfe KI der DSK ist sie beim Einsatz von KI-Anwendungen „vielfach“ erforderlich; in Österreich nennt die DSFA-V Verarbeitungen, für die jedenfalls eine DSFA nötig ist), 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 deine Datenschutz- oder Rechtsabteilung.