--- title: "RAG-Systeme DSGVO-konform aufbauen: Praxis-Leitfaden" description: "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." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-dsgvo-konform-aufbauen" category: "KI Agenten" topic: "RAG-Systeme erklärt" updated: "2026-07-29T08:22:41.738Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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. ## Kernaussagen - Embeddings sind nicht anonym: Text-Embedding-Inversion (Morris et al. 2023) und Membership-Inference-Angriffe ermöglichen Re-Identifikation. CNIL und die Hamburger Aufsicht behandeln Embeddings als pseudonyme personenbezogene Daten. - Datenminimierung greift vor dem Embedding: PII-Erkennung (z. B. Presidio, NER) und Pseudonymisierung der Quell-Chunks, bevor sie indexiert werden, plus minimale Kontext-Payloads pro Query. - Recht auf Löschung (Art. 17) erfordert, Quelldokument und Embedding gemeinsam zu löschen (Hard Delete). Soft Delete birgt Leakage-Risiko über die Ähnlichkeitssuche. - Mandantentrennung über filterbare Metadaten (tenant_id, ACL) mit Defense-in-Depth: Auth, Pre-Filter, Re-Check, Audit-Log. Die DSK-Orientierungshilfe RAG fordert Mandantentrennung und ein Rechte-/Rollenkonzept. - EU-Hosting für LLM und Vektor-Store senkt das Drittlandrisiko: souveräne Optionen wie Qdrant (Berlin), Weaviate (NL), Aleph Alpha (Heidelberg), Mistral (FR) sowie STACKIT/IONOS. - Für jeden Anbieter braucht es einen Auftragsverarbeitungsvertrag (Art. 28) mit klarer Sub-Prozessor-Kette, No-Training-Zusage und konfigurierbarer Aufbewahrung. Ein [DSGVO](/de/glossar/dsgvo)-konformes [RAG](/de/glossar/rag)-System verarbeitet personenbezogene Daten in Quelldokumenten, Vektor-Index und Embeddings nur auf gesicherter Rechtsgrundlage, mit Datenminimierung, [EU-Hosting](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/eu-datenresidenz-fuer-llms), 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](/de/glossar/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 sind Pflicht-Bausteine,** nicht Kür: souveräne Vektor-DB plus [LLM](/de/glossar/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](/de/glossar/prompt) ein. Personenbezogene Daten entstehen dabei an mehreren Stellen gleichzeitig: in den Quelldokumenten ([CRM](/de/glossar/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](https://gdpr-info.eu/). 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](https://www.nist.gov/itl/ai-risk-management-framework) (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**. 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. 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)](/de/glossar/standardvertragsklauseln) plus Transfer-Impact-Assessment (TIA) zu prüfen. Souveräne DACH-/EU-Optionen vermeiden diese Frage weitgehend: | Komponente | Souveräne Option (Stand 2026) | Sitz | | --- | --- | --- | | Vektor-DB | Qdrant (Apache 2.0, Filterable HNSW) | Berlin (DE) | | Vektor-DB | Weaviate | Amsterdam (NL/EU) | | Vektor-DB | pgvector / pgvectorscale | überall, wo PostgreSQL läuft | | RAG-Framework | Haystack / deepset | Berlin (DE) | | Embedding (kommerziell) | Aleph Alpha (Pharia-1-Embed, on-prem-fähig) | Heidelberg (DE) | | Embedding (OSS, DACH) | jina-embeddings-v3 / Reranker v2 | Berlin (DE) | | Embedding (OSS, Fallback) | BGE-M3 | BAAI (China), Apache 2.0 | | LLM | Mistral, Aleph Alpha Pharia, Teuken-7B | EU | | Cloud/Hosting | STACKIT, IONOS, OVHcloud, Open Telekom Cloud | DACH/EU | 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](/de/glossar/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](/de/glossar/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 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)](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/auftragsverarbeitung-art-28-ki-anbieter) 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](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de) den Aufbau [DSGVO-konformer RAG- und KI-Agenten-Systeme](/de/services/ki-agent-integration) von der DSFA bis zur produktiven Lösch-Pipeline. Diese Inhalte ersetzen keine Rechtsberatung; die finale rechtliche Bewertung trifft deine Datenschutz- oder Rechtsabteilung. ## FAQ ### Darf ich personenbezogene Daten überhaupt in eine Vektordatenbank embedden? Technisch ja, rechtlich nur mit Rechtsgrundlage (typisch Art. 6 Abs. 1 lit. b oder f DSGVO) und technisch-organisatorischen Maßnahmen: Pseudonymisierung vor dem Embedding, Zugriffsschutz und Löschbarkeit. Embedding selbst gilt nach herrschender Aufsichtspraxis nicht als sichere Anonymisierung, da aus Embeddings Inhalte rekonstruierbar sind. Dies ist eine fachliche Einordnung, keine Rechtsberatung. ### Sind Embeddings anonym oder personenbezogen? Sie gelten als pseudonyme personenbezogene Daten, solange der zugrunde liegende Text auf identifizierbare Personen verweist. Text-Embedding-Inversion (Morris et al. 2023) und Membership-Inference-Angriffe zeigen, dass Embeddings re-identifizierbar sind. CNIL und die Hamburger Aufsicht behandeln sie daher standardmäßig als personenbezogen. ### Wie setze ich das Recht auf Vergessen im Vektorindex um? Beim Löschen einer Person Quelldokument und Embedding gemeinsam entfernen (Hard Delete). Soft Delete, das den Vektor behält, birgt Leakage über die Ähnlichkeitssuche. Eine vollständige Re-Indexierung ist nur bei einem Wechsel des Embedding-Modells nötig; das gezielte Löschen einzelner Records sollte über stabile IDs ohne Komplett-Neuaufbau funktionieren. ### Reicht eine EU-Region beim US-Anbieter für DSGVO-Konformität? EU-Region-Hosting senkt das Risiko, beseitigt aber bei US-Anbietern nicht automatisch das CLOUD-Act-Restrisiko. Bei Drittlandbezug sind Standardvertragsklauseln plus Transfer-Impact-Assessment zu prüfen. Souveräne EU-/DACH-Optionen wie Qdrant, Aleph Alpha oder STACKIT vermeiden diese Frage weitgehend. ### Welche Mandantentrennung verlangt die Aufsicht bei RAG? Die DSK-Orientierungshilfe RAG fordert Mandantentrennung sowie ein Rechte- und Rollenkonzept. Praktisch: tenant_id und ACL als filterbare Metadaten (Filterable HNSW), Filter bei jeder Query plus Defense-in-Depth aus Authentifizierung, Pre-Filter, Re-Check und Audit-Log, damit kein Chunk von Mandant A bei Mandant B erscheint. ### Brauche ich für RAG eine Datenschutz-Folgenabschätzung? KI-Systeme lösen nach DSK-Praxis fast immer eine DSFA aus, etwa wegen großflächiger Verarbeitung, innovativer Technologie oder Profiling. Bei RAG mit personenbezogenen Quelldokumenten ist eine DSFA daher der Regelfall. Die DSK-Orientierungshilfe RAG adressiert dabei zusätzlich Risiken wie Membership Inference und Data Poisoning. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-dsgvo-konform-aufbauen). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.