RAG auf eigenen Dokumenten DSGVO-konform: Was die DSK verlangt

Wer RAG auf eigenen Dokumenten DSGVO-konform betreiben will, muss vor allem eines prüfen: den Vektorindex. Die Datenschutzkonferenz (DSK) hat im Oktober 2025 eine 18-seitige Orientierungshilfe zu RAG-Systemen veröffentlicht, die genau dort ansetzt – Datenminimierung vor der Indexierung, Rechtekonzept in der Vektordatenbank, Löschbarkeit einzelner Einträge, Betroffenenrechte. Dieser Artikel übersetzt die Vorgaben in technische Schritte und eine Prüfliste.

Warum RAG auf eigenen Dokumenten unter der DSGVO anders zu prüfen ist als ein Chatbot

Ein RAG-System besteht nach der Definition der DSK im Kern aus vier Komponenten: Retriever, Embedding-Modell, Vektordatenbank und generativem Sprachmodell. Vor dem Betrieb werden die Referenzdokumente in Textabschnitte (Chunks) zerlegt, in Vektoren überführt und zusammen mit den Chunks abgelegt; bei jeder Anfrage sucht der Retriever die semantisch nächsten Chunks und hängt sie an den Prompt. Das Modell steuert im Idealfall die Sprachfähigkeit bei, das Faktenwissen kommt aus den Dokumenten.

Beim reinen Modellzugriff sind Prompt, Antwort und Modell der Prüfgegenstand. Bei RAG kommt ein zweiter, von Ihnen betriebener Datenbestand hinzu. Die DSK hält fest, dass sich die Informationen in der Vektordatenbank im Gegensatz zum antrainierten Wissen des Modells „einfach aktualisieren, löschen und beauskunften“ lassen. Das ist Erleichterung und Pflicht zugleich: Die Aufsicht erwartet, dass Sie diesen Bestand wie jede andere Datenbank mit Personenbezug betreiben – mit Rechtsgrundlage, Rechtekonzept, Löschfristen und Nachweis.

Zur Einordnung: Die DSK hat seit Mai 2024 drei Papiere zu KI veröffentlicht – die Orientierungshilfe „Künstliche Intelligenz und Datenschutz“ (6. Mai 2024), die Orientierungshilfe zu technischen und organisatorischen Maßnahmen bei KI-Systemen (Juni 2025) und am 17. Oktober 2025 die zu generativen KI-Systemen mit RAG-Methode. Letztere legt ein Szenario zugrunde, in dem das System vollständig on premise läuft; bei Auslagerung ergeben sich laut DSK „weitere Aspekte“.

Was ein RAG-System in der technischen Dokumentation leistet und wo die Methode fachlich an Grenzen stößt, steht in KI für technische Dokumentation. Hier geht es um die datenschutzrechtliche Seite von Retrieval Augmented Generation im Unternehmen.

Welche personenbezogenen Daten in technischen Dokumenten stecken

Der Satz „Wir haben nur Technikdokumente, da ist kein Personenbezug drin“ stimmt in der Praxis fast nie. Technische Dokumente werden von Menschen erstellt, geprüft, freigegeben und kommentiert – diese Spuren bleiben im Dokument. Die DSK empfiehlt, vor dem Chunking Kopf- und Fußzeilen sowie Seitennummern zu bereinigen; genau dort stehen Prüfername, Freigabestempel und Unterschrift. Ein realistisches Inventar sieht so aus:

Zwei Fundstellen werden regelmäßig übersehen. Erstens die Dateimetadaten: PDF-Eigenschaften enthalten den Autor, DOCX-Dateien eine Änderungshistorie mit Namen – beides landet ohne Bereinigung im extrahierten Text. Zweitens der Freitext: Ein Störeintrag wie „Müller hat die Klemme nachgezogen“ ist ein Beschäftigtendatum. Die Faustregel für die Erforderlichkeitsprüfung nach Art. 5 Abs. 1 lit. c DSGVO: Der Assistent beantwortet, was passiert ist und wie es behoben wurde – nicht, wer es war.

Datenminimierung vor der Indexierung: was das technisch heißt

Die DSK formuliert die Anforderung im Abschnitt zur Datenaufbereitung eindeutig: „Soweit personenbezogene Daten nicht erforderlich sind, sind personenbezogene Daten zu entfernen oder zu anonymisieren.“ Der Ort dieser Aussage ist entscheidend – sie steht bei der Aufbereitung, also vor Chunking und Embedding. Art. 5 Abs. 1 lit. c DSGVO verlangt Daten „auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt“. Die Ingest-Pipeline braucht also einen Redaction-Schritt, bevor das Embedding-Modell den Text sieht.

1. 01

   Dokumentklassen inventarisieren und Ausschlussliste festlegen

   Jede Quelle (DMS-Ordner, Fileserver-Share, CMMS-Export) wird einer Dokumentklasse zugeordnet. Klassen ohne RAG-Zweck – Personalunterlagen, Bewerbungen, arbeitsmedizinische Berichte – kommen auf eine Ausschlussliste, die der Crawler technisch durchsetzt und nicht nur organisatorisch.

2. 02

   Erforderlichkeit je Klasse begründen

   Für jede zugelassene Klasse wird schriftlich festgehalten, welche Personenfelder der Zweck braucht. In der technischen Dokumentation ist das fast immer: keine. Diese Begründung ist Ihr Nachweis nach Art. 5 Abs. 2 DSGVO.

3. 03

   Bereinigen: Kopf- und Fußzeilen, Metadaten, Signaturbilder

   Der Extraktionsschritt entfernt Kopf- und Fußzeilen, Seitenzahlen, Dokumenteigenschaften und eingebettete Unterschriftsbilder. Das deckt sich mit der Qualitätsempfehlung der DSK und verbessert nebenbei die Trefferqualität.

4. 04

   Personenbezug erkennen und ersetzen

   Eine Kombination aus Mustererkennung (Personalnummern, E-Mail-Adressen, Telefonnummern) und Named-Entity-Recognition für Namen ersetzt Personenfelder durch Rollen-Platzhalter wie [PRUEFER] oder [INSTANDHALTER]. Der fachliche Inhalt bleibt, der Personenbezug verschwindet aus dem Chunk.

5. 05

   Berechtigungs- und Herkunftsmetadaten anheften

   Jeder Chunk erhält Dokument-ID, Version, Quellpfad, Dokumentklasse und die Berechtigungsgruppen aus dem Quellsystem. Ohne diese Felder sind Rechtefilter, Löschpfad und Auskunft später nicht umsetzbar.

6. 06

   Erst jetzt chunken und einbetten – mit Stichprobe

   Chunking und Embedding laufen auf dem bereinigten Text. Eine Stichprobe pro Dokumentklasse prüft, ob Personenbezug durchgerutscht ist; das Ergebnis wird als Zähler je Kategorie protokolliert, nicht als Liste der entfernten Namen.

Dass ein Chunk als Vektor gespeichert ist, macht ihn nicht unbedenklich. OWASP führt unter LLM08:2025 („Vector and Embedding Weaknesses“) Embedding-Inversion-Angriffe auf, mit denen sich Quellinformationen aus Vektoren zurückgewinnen lassen. Hinzu kommt die Zweckbindung: Die DSK warnt, dass Daten aus der Vektordatenbank im Sprachmodell mit dort enthaltenen Daten verkettet werden können, ohne dass dies in der Ausgabe erkennbar ist. Was nicht im Index ist, kann nicht verkettet werden.

Rechtekonzept im Vektorindex – der am häufigsten übersehene Punkt

Ein Vektorindex ohne Berechtigungsfilter macht jedes indexierte Dokument für jeden Fragenden auffindbar – die semantische Suche kennt keine Ordnerrechte. Die DSK verlangt für das RAG-Subsystem ein Rechte- und Rollenkonzept, das sich „auf Zugangsbeschränkungen zu Bereichen der Vektordatenbank und den Referenzdokumenten“ bezieht, sowie eine Mandantentrennung. OWASP beschreibt dasselbe Problem unter LLM08:2025 als Informationsabfluss zwischen Nutzergruppen und empfiehlt „permission-aware vector and embedding stores“. Drei Umsetzungswege:

Die Berechtigung wird nicht im RAG-System neu erfunden: Sie kommt aus den Zugriffslisten des Quellsystems und wird beim Ingest an den Chunk geschrieben. Ändert sie sich dort, muss der Index per Ereignis oder Delta-Lauf nachziehen – ein Abteilungswechsel muss innerhalb dieser Frist wirken, geprüft mit Negativtests. Das Rechtekonzept trägt auch die Zweckbindung: Die DSK verlangt, dass Mitarbeitende „vor der Abfrage die für den Verarbeitungszweck korrekte Rolle“ erhalten.

Löschung, Berichtigung und Auskunft bei Embeddings

Löschen im Vektorindex ist machbar, weil jeder Eintrag direkt adressierbar ist – die DSK nennt das als Vorteil gegenüber dem Sprachmodell: „Diese Einträge sind direkt adressierbar und damit auch personenbezogene Daten gezielt löschbar.“ Voraussetzung ist eine harte Zuordnung: Jeder Chunk kennt Quelldokument, Version und Speicherort; ohne sie wird die Löschung zum Ratespiel.

• —Löschung heißt: alle Chunks mit der Dokument-ID entfernen und das Quelldokument aus dem Referenzbestand nehmen – in einem protokollierten Lauf.
• —Berichtigung wird zur Reindexierung: Dokument korrigieren, alte Chunks löschen, neue Version einbetten.
• —Zwischenartefakte – extrahierter Text, OCR-Ausgaben, Chunk-Dateien, Embedding-Caches – gehören mit eigener Frist in das Löschkonzept.
• —Antwort-Caches und Prompt-Logs enthalten Kopien von Chunks und gehören in den Löschpfad, sonst lebt der gelöschte Absatz im Cache weiter.
• —Backups löschen nicht sofort. Dokumentieren Sie, nach welcher Rotationsfrist ein gelöschter Eintrag auch dort verschwunden ist.
• —Test vor dem Produktivgang: ein Testdokument mit erfundenem Namen einspielen, löschen, danach gezielt danach fragen – im Assistenten und direkt gegen den Index.

Für Auskunftsersuchen gilt laut DSK, dass Betroffenen die Rechte aus Art. 15 ff. „in Bezug auf den Eingabeprompt und die Ausgabe, die Referenzdokumente und die Vektordatenbank“ zustehen. Beantworten können Sie: in welchen Dokumenten und Chunks die Person vorkommt – per Volltextsuche über Chunk-Text und Metadaten, nicht per Vektorsuche –, zu welchem Zweck, wer Empfänger ist und wie lange gespeichert wird. Was ein einzelner Vektor aussagt, lässt sich laut DSK nicht nachvollziehen; deshalb muss der Chunk-Text über die Dokument-ID auflösbar sein.

{
  "chunk_id": "c7f3…",
  "document_id": "DOC-2024-01187",
  "document_version": 3,
  "source_uri": "dms://werk2/instandhaltung/wartungsbericht-2024-01187.pdf",
  "doc_class": "wartungsbericht",
  "acl_groups": ["instandhaltung-werk-2", "technik-leitung"],
  "pii_redacted": true,
  "ingested_at": "2026-09-14T06:12:00Z",
  "retention_until": "2036-09-14"
}

Ein Nebeneffekt sauberer Metadaten ist Transparenz: Die DSK zählt die Dokumentation der genutzten Quellen – „Referenzen auf Chunks oder Dokumente“ – zu den Maßnahmen, die Nachvollziehbarkeit herstellen. Wie eine Quellenangabe in der Antwort aussieht, zeigt Chatbot für technische Handbücher.

Protokollierung ohne neues Datenschutzproblem

Die RAG-Orientierungshilfe selbst schreibt keine bestimmte Protokollierung vor. Die TOM-Orientierungshilfe der DSK vom Juni 2025 zählt Protokollierung zu den klassischen IT-Sicherheitsmaßnahmen gegen Manipulation und stellt bei den Betroffenenrechten klar, dass Protokolldaten „wie herkömmliche Daten zu behandeln“ sind. Daraus folgt für die Praxis: Logs brauchen wie jede andere Datenbank einen Zweck, eine Frist und ein Zugriffskonzept. Wer jeden Prompt dauerhaft speichert, baut einen zweiten Personenbestand auf – über die eigenen Beschäftigten.

Trennen Sie zwei Logs mit zwei Fristen. Das Nachweislog – Ingest- und Löschläufe, Rechteänderungen, Konfigurationsstände – dient der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO und enthält keine Prompts. Das Betriebslog – Anfragen, Retrieval, Modellaufrufe – dient Sicherheit und Fehleranalyse und bekommt eine kurze, im Löschkonzept festgeschriebene Frist. Die DSK verlangt schon 2024 Transparenz gegenüber Beschäftigten über eine gespeicherte Eingabe-Historie und weist auf Mitbestimmungstatbestände hin.

Betriebsort: on premise, EU-Cloud oder Hyperscaler

Der Betriebsort ändert nicht, was zu tun ist, sondern wer es tut und an wen Daten übermittelt werden. Die DSK legt ihrer Bewertung den vollständig lokalen Betrieb zugrunde und hebt hervor, dass RAG ein Sprachmodell mit weniger Faktenwissen erlaubt: „Dadurch kann vermieden werden, dass personenbezogene Daten an Online-Betreiber großer Sprachmodelle übertragen werden.“ Das Mittelstand-Digital Zentrum Chemnitz hebt denselben Punkt hervor: Mit kleineren, lokal betriebenen Modellen entfällt die „sicherheitskritische Datenübertragung an Dritte“. Lokaler Betrieb verlagert aber Betriebslast, nicht Verantwortung.

Die EU-Cloud ist die vernünftigere Wahl, wenn GPU-Betriebskompetenz fehlt, die Last stark schwankt oder es um einen Piloten geht. Dann gelten drei Bedingungen: ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO – in der DSK-Orientierungshilfe von 2024 agiert der externe Anbieter als „verlängerter Arm im Auftrag des Verantwortlichen“ –, Redaction vor der Übermittlung statt danach, und die geprüfte Zusage, dass der Anbieter Prompts und Dokumente weder speichert noch zum Training nutzt. Was der lokale Betrieb an Hardware erfordert, steht in LLM on premise im Industriebetrieb.

Prüfliste vor dem Produktivgang

Die folgenden 14 Punkte fassen die Anforderungen der DSK-Orientierungshilfe und der beiden vorangegangenen DSK-Papiere als abhakbare Liste in zwei Blöcken zusammen. Sie ersetzt weder die Prüfung durch Ihre Datenschutzbeauftragte noch eine Rechtsberatung, stellt aber sicher, dass beide etwas Belastbares vorfinden.

Fazit

RAG auf eigenen Dokumenten ist datenschutzrechtlich besser beherrschbar als ein Sprachmodell allein – genau das sagt die DSK. Der Grund ist der Index: Er lässt sich bereinigen, mit Rechten versehen, gezielt löschen und beauskunften. Dieselbe Eigenschaft macht ihn zum Prüfgegenstand. Wer Datenminimierung in die Ingest-Pipeline verlegt, Berechtigungen aus dem Quellsystem übernimmt, jeden Chunk an sein Dokument bindet und die Protokollierung mit Fristen versieht, hat die technische Seite abgedeckt.

Beginnen Sie mit dem Inventar aus Tab. 01 und der Erforderlichkeitsprüfung – alles Weitere baut darauf auf. Wenn Sie dafür einen technischen Sparringspartner suchen, der Ingest-Pipeline, Rechtekonzept und Löschpfad gemeinsam mit Ihrer Datenschutzbeauftragten aufsetzt, finden Sie die Leistung unter KI-Lösungen für technische Dokumente.