RAG datenschutzkonform aufbauen: Was die DSK-Orientierungshilfe für die Architektur bedeutet

Retrieval-Augmented Generation, kurz RAG, ist der praktische Weg, ein Sprachmodell über die eigenen Dokumente nützlich zu machen: Handbücher, Satzungen, Protokolle, Aktenbestände. Das Modell wird dabei nicht neu trainiert. Stattdessen sucht ein Retriever zur Laufzeit die passenden Textstellen aus einer Vektordatenbank und legt sie dem Modell als Kontext vor. Seit Oktober 2025 gibt es dazu eine eigene Orientierungshilfe der Datenschutzkonferenz (DSK), der gemeinsamen Runde der deutschen Datenschutzaufsichten. Sie ist kein juristischer Aufsatz, sondern eine Liste von Anforderungen, und jede davon ist zugleich eine Architekturentscheidung. Dieser Text liest sie von der Bauseite her.

Das Grundszenario der DSK ist bereits on-premise

Die Orientierungshilfe legt ausdrücklich ein RAG-System zugrunde, das vollständig im eigenen Haus betrieben wird, bestehend aus Retriever, Embedding-Modell, Vektordatenbank und generativem Sprachmodell:

„Es wird ein Einsatzszenario zugrundegelegt, in dem das gesamte RAG-System on-premise bei einem Verantwortlichen betrieben wird.”

Für die Architektur heißt das: lokal betriebene Modelle (etwa über Ollama für den Einstieg oder vLLM für produktive Mehrbenutzerlast), eine lokale Vektordatenbank, kein externer Modellanbieter im Datenpfad. Sobald das System auf mehrere Betreiber verteilt wird, kommen Auftragsverarbeitung oder gemeinsame Verantwortlichkeit als zusätzliche Fragen hinzu. Der einfachste datenschutzrechtliche Aufbau ist zugleich der, der die Daten im Haus behält.

RAG repariert kein schlecht trainiertes Modell

Ein verbreitetes Missverständnis räumt die DSK direkt ab:

„Ein rechtswidrig trainiertes KI-Modell bleibt auch in einem RAG-System ein rechtswidrig trainiertes KI-Modell.”

RAG verändert das Sprachmodell nicht. Die erweiterte Anfrage wird ihm nur vorgelegt, es findet kein Fine-Tuning und kein Nachtraining statt. Die Herkunft des Basismodells bleibt also getrennt zu bewerten. RAG kann die Risiken der laufenden Verarbeitung senken, aber es heilt nicht die Frage, auf welchen Daten das Modell ursprünglich trainiert wurde. Praktische Folge: ein Modell wählen, dessen Herkunft man vertreten kann, und die RAG-Schicht als das behandeln, was sie ist, eine risikomindernde Maßnahme, keine Absolution.

Der entscheidende Punkt für den kirchlichen Kontext: besonders sensible Daten

Kirchliche und diakonische Stellen verarbeiten Daten mit hohem Schutzbedarf: Seelsorge, Mitgliedschaft, Klientendaten der sozialen Arbeit, also Kategorien nach Art. 9 und Art. 10 DSGVO. Die zentrale Aussage der Orientierungshilfe dazu:

„Bei Erfüllung der datenschutzrechtlichen Anforderungen können daher auch personenbezogene Daten mit höherem Schutzbedarf, z. B. Daten nach Art. 9 und 10 DSGVO, verarbeitet werden, da diese nicht dauerhaft im LLM verbleiben, sofern kein gezieltes Training oder Nachtraining stattfindet, sondern in den Referenzdokumenten und der Vektordatenbank separat gespeichert sind.”

Daraus folgt eine klare Bauregel: Sensible Daten gehören ausschließlich in das kontrollierbare RAG-Subsystem, also in Referenzdokumente und Vektordatenbank, wo Rechte- und Rollenkonzept sowie Mandantentrennung greifen. Sie gehören niemals in ein Training des Modells, denn dort ist nicht mehr steuerbar, wer worauf zugreift. Diese Unterscheidung ist der Grund, warum sich ein sauber gebautes RAG für den kirchlichen Sektor überhaupt vertreten lässt.

Der teuerste Fehler: Berechtigungen gehen beim Import verloren

Hier liegt die häufigste stille Schwachstelle. Beim Import in die Vektordatenbank verlieren Dokumente ihre ursprünglichen Zugriffsrechte. Wenn der Retriever dann rein nach semantischer Ähnlichkeit sucht, liefert er auch Inhalte an Personen, die das Quelldokument nie hätten sehen dürfen. Zugriffskontrolle muss deshalb an der Retrieval- und Vektorebene sitzen, nicht erst in der Anwendung.

Die DSK verlangt genau das über Mandantentrennung, funktionale Trennung und ein Rechte- und Rollenkonzept, das Bereiche der Vektordatenbank und der Referenzdokumente absichert. Technisch wird das über Metadaten-Filter im Retrieval umgesetzt, sodass eine Abfrage nur Chunks aus dem für die Rolle freigegebenen Bereich erhält (siehe etwa Pinecone zu RAG mit Zugriffskontrolle und Zilliz zu permission-aware RAG). Ein zweiter Fallstrick dabei: Auch Metadaten können verraten, was der Inhalt gerade verbirgt, etwa Dateipfade oder Abteilungsnamen. Die Rechtezuweisung an die Nutzenden muss vor der Abfrage stehen, nicht danach.

Zweckbindung und die unsichtbare Verkettung

RAG kann die Zweckbindung stärken, indem gezielt nur bestimmte Dokumente bereitgestellt werden. Es kann sie aber auch bedrohen. Wenn personenbezogene Daten aus der Vektordatenbank an das Sprachmodell übergeben werden, warnt die DSK vor

„eine[r] Verkettung [mit den im LLM enthaltenen Daten], die ggf. nicht in der Ausgabe des RAG-Systems erkennbar ist.”

Das ist ein Entwurfsproblem, kein Betriebsdetail: Es gehört in die Konzeption, welche Daten überhaupt in den Kontext des Modells gelangen dürfen.

Datenminimierung und der Löschvorteil

Gegenüber einem reinen Sprachmodell hat RAG einen handfesten Vorteil: Referenzdokumente und Einträge der Vektordatenbank sind direkt adressierbar und gezielt löschbar, klassische Löschfristen sind also anwendbar. Was nicht gebraucht wird, wird schon beim Chunking entfernt oder anonymisiert. Das Problem bleibt nur beim Modell selbst:

„Ungeachtet der Vorteile bleiben die Probleme bei der Datenlöschung im Sprachmodell bestehen.”

Deshalb die Empfehlung der DSK, ein eher kleineres Sprachmodell zu wählen, das weniger Fakten memoriert, und die Eignung dieser Wahl zu dokumentieren.

Qualität ist eine Datenschutzfrage

Richtigkeit personenbezogener Ausgaben ist eine Anforderung aus Art. 5 DSGVO, und RAG verbessert sie, garantiert sie aber nicht. Die konkreten Stellschrauben sind technisch:

• Deutschsprachiges Embedding-Modell. Für deutsche Dokumente ein Embedding-Modell verwenden, das auf deutschsprachigen Texten trainiert wurde. Sonst leidet die Retrieval-Qualität.
• Saubere Aufbereitung. Kopf- und Fußzeilen bereinigen, sinnvolle Chunk-Größe und Überlappung wählen. Schlechtes Chunking zerstört den Sinnzusammenhang.
• Systemprompt mit Quellenbindung. Das System anweisen, „ausschließlich mithilfe der referenzierten Quellen zu antworten.” Das reduziert Halluzinationen.
• Keine Websuche. Zur Einbindung externer Quellen ist die DSK deutlich: Deren Anforderungen an Rechtmäßigkeit und Richtigkeit „werden regelmäßig bei Einbindung einer Websuche nicht erfüllt.”

Sicherheit und die Grenzen der Transparenz

Die üblichen technisch-organisatorischen Maßnahmen gelten auch für die Vektordatenbank. Als Angriffsvektoren nennt die DSK ausdrücklich Membership-Inference-Angriffe und Data Poisoning und verweist dabei auf PoisonedRAG und die OWASP-Risikoliste LLM04:2025. Umgekehrt kann ein kuratierter RAG-Bestand selbst gegen vergiftete Trainingsdaten wirken.

Bei der Transparenz ist ehrlich zu bleiben: Die genutzten Quellen lassen sich dokumentieren, das macht den Input des Modells nachvollziehbar. Das Modell selbst wird dadurch nicht erklärbar:

„Eine Erhöhung der datenschutzrechtlichen Transparenz in Bezug auf das eingesetzte LLM kann hingegen nicht erreicht werden.”

Ebenso sind Betroffenenrechte auf der Ebene von Prompt, Ausgabe, Referenzdokument und Vektordatenbank in der Regel umsetzbar, während sie gegenüber dem Modell selbst „weitgehend ungelöst” bleiben.

Bezug zum kirchlichen Datenschutzrecht

Für die katholischen und evangelischen Träger gelten mit KDG und DSG-EKD eigene, der DSGVO nachgebildete Datenschutzgesetze mit eigenen Aufsichten. Beide Aufsichten verweisen ihre Stellen auf die DSK-Orientierungshilfen als sachlichen Leitfaden, ohne sie förmlich für bindend zu erklären. Der EKD-Datenschutzbeauftragte etwa hält die KI-Orientierungshilfe für einen Leitfaden, der „auch in Kirche und Diakonie” dienen kann. Die Aussage der RAG-Orientierungshilfe zu Art.-9- und Art.-10-Daten stützt dabei genau das, was der Sektor ohnehin braucht: ein rein im Haus betriebenes RAG ohne externe Datenanbindung. Denn nur so greifen Rollenkonzept und Mandantentrennung, und nur so lässt sich, in den Worten der DSK, vermeiden,

„dass personenbezogene Daten an Online-Betreiber großer Sprachmodelle übertragen werden.”

Die Orientierungshilfe macht RAG nicht komplizierter. Sie macht die Architekturentscheidungen explizit, die man ohnehin treffen muss.

Quellen

• DSK, Orientierungshilfe „Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode”, Oktober 2025: PDF
• DSK, Orientierungshilfe „Künstliche Intelligenz und Datenschutz”, 06.05.2024: PDF
• DSK, Orientierungshilfe zu TOMs bei KI-Systemen, Juni 2025: PDF
• Lewis et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, arXiv:2005.11401: Link
• Pinecone, „RAG with Access Control”: Link
• OWASP GenAI, „LLM04:2025 Data and Model Poisoning”: Link