RAG Vector Database Leakage Screening
Definition: RAG Vector Database Leakage Screening ist ein strukturierter Prüfprozess für Retrieval-Augmented-Generation-Systeme. Er erkennt, bewertet und unterbindet ungewollte Inhaltsabflüsse aus Vektordatenbanken, indem er Indexstrukturen, Embedding-Abfragen und Antwortpfade auf vertrauliche Daten und Rechteverletzungen analysiert. Das Vorgehen ergänzt klassische Datenschutz-Audits um die semantische Abfrageebene und die Retrieval-Logik.
Hinweis: Dies ist ein neuartiges Prüfverfahren (EMERGING) und kein etablierter Standard. Die folgende Methodik basiert auf allgemeinen Sicherheits- und Datenschutzpraktiken für RAG-Systeme.
Was das Screening leistet
Ein Retrieval-Augmented-Generation-System (RAG) erweitert ein Sprachmodell um eine externe Wissensbasis. Diese Wissensbasis liegt in Form einer Vektordatenbank vor, in der Textabschnitte als numerische Embeddings gespeichert sind. Der Retriever ermittelt anhand der Ähnlichkeit zwischen Anfrage-Embedding und Dokument-Embedding die relevantesten Chunks. Dabei kann es zu Datenabflüssen kommen, die klassische Zugriffskontrollen nicht abfangen. Das RAG Vector Database Leakage Screening prüft, ob und wie solche Abflüsse entstehen. Es beantwortet die Fragen: Welche Inhalte sind für das Retrieval erreichbar? Welche Nutzerrollen dürfen sie abrufen? Und welche Quellen gelangen in die Generierung? Entscheidend ist die semantische Erreichbarkeit – nicht nur der technische Zugriff auf den Speicher.
Stellen Sie sich einen offenen Zettelkasten vor: Jeder Zettel trägt eine Koordinate, aber keine Sichtbarkeitsgrenze. Das Screening ergänzt die Koordinaten um eine Sichtbarkeitskarte, bevor das Sprachmodell einen Zettel hervorholt.
Typische Leakage-Pfade in RAG-Systemen
Leakage entsteht selten durch einen einzelnen Fehler. Häufig greifen mehrere Schwachstellen ineinander. Häufig beobachtete Leakage-Pfade sind (Beispiele illustrativ, nicht abschließend):
| Leakage-Pfad | Schwachstelle | Beispiel |
|---|---|---|
| Unkontrollierter Import | Inhaltsfilter und Berechtigungsprüfung fehlen beim Einspielen | Interner Personalbericht wird ohne Kennzeichnung indexiert |
| Metadaten im Chunk | Dokumenttrennung ist unvollständig | E-Mail-Adresse gelangt in die generierte Antwort |
| Fehlende Nutzerfilterung | Retriever kennt keine Rollen oder Mandanten | Vertrieb erreicht Kennzahlen aus der Finanzabteilung |
| Prompt-Injektion | Anfrage manipuliert die Retrieval-Logik | Extraktion vertraulicher Quelltexte durch speziellen Prompt |
Methodik des Screenings
Ein belastbares Screening kombiniert statische Indexanalyse mit dynamischen Retrieval-Tests. Die folgenden vier Schritte haben sich als Orientierung bewährt – sie sind nicht als normatives Verfahren zu verstehen:
- Inventur: Datenquellen, Chunking-Regeln, Embedding-Modell und Rechtekontext erfassen.
- Index-Audit: Metadaten, Löschmechanismen und veraltete Vektoren prüfen.
- Retrieval-Test: Testprompts nutzen, die typische Nutzerfragen und Angriffsmuster abbilden.
- Antwortanalyse: Zurückverfolgen, welche Chunks in die Generierung geflossen sind.
Durch gezieltes Priming der Testprompts lassen sich auch latente Schwachstellen sichtbar machen.
Abgrenzung zu klassischen Datenschutz-Audits
Klassische Datenschutz-Audits fokussieren Zugriffskontrollen, Verschlüsselung und Protokollierung. Diese Kontrollen sind notwendig, aber unzureichend für RAG-Systeme. Der Grund liegt in der Datenzerlegung: Dokumente werden in Chunks geteilt und als Embeddings abgelegt. Ein Audit, das nur Dateisysteme betrachtet, übersieht, wie Chunks aus verschiedenen Quellen kombiniert werden. Das Leakage Screening ergänzt das klassische Modell um die semantische Abfrageebene und die Retrieval-Logik.
Umsetzung in Compliance-Programmen
Ein einmaliges Screening genügt nicht. Neue Dokumente, veränderte Rollen und aktualisierte Embedding-Modelle verschieben das Risiko. Unternehmen sollten das Screening vor der Inbetriebnahme, nach wesentlichen Änderungen und in regelmäßigen Abständen durchführen. Sinnvolle Kennzahl ist die Leakage-Rate: der Anteil der Retrieval-Tests, die zu nicht freigegebenen Quellen führen. Liegt dieser Wert über Null, sind Gegenmaßnahmen wie Zugriffsfilter, Chunk-Überarbeitung oder Metadaten-Kennzeichnung erforderlich.
« Back to Glossary Index