Kurz gesagt: Behandeln Sie jeden abgerufenen Chunk als Zugriffsentscheidung, nicht als harmlosen Kontext. Ein produktives RAG-System muss vor dem Retrieval entscheiden, was ein Aufrufer lesen darf, verbotene Inhalte vom Modell fernhalten und die Entscheidung nachvollziehbar protokollieren. Eine Vektordatenbank leistet das nicht automatisch.
Der Fehler liegt in der Architektur
Unternehmens-Wissensbasen verbinden HR-Richtlinien, Kundenunterlagen, technische Runbooks und Verträge. Ein Chatbot kann eine überzeugende Antwort formulieren und dabei einen Satz aus einem Dokument preisgeben, das der Nutzer nie öffnen durfte. Das Entfernen von Quellen nach der Generierung kommt zu spät: Das Modell hat den Inhalt bereits erhalten.
OWASP nennt die Offenlegung sensibler Informationen sowie Schwächen bei Vektoren und Embeddings als Risiken von LLM-Anwendungen. NIST AI 600-1 ordnet Datenschutz, Governance und dokumentierte Kontrollen ebenfalls dem Betriebsmodell generativer KI zu. Das sind Anforderungen an die Umsetzung, kein Grund, RAG zu vermeiden.
Die produktive Kontrollschicht: klassifizieren, autorisieren, abrufen, nachweisen
1. Klassifizieren Sie beim Ingest. Erfassen Sie Quellsystem, Eigentümer, Fachbereich, Schutzbedarf, Aufbewahrungsklasse, Legal Hold und zulässige Gruppen. Speichern Sie Dokument-ID und Version neben jedem Chunk. Leiten Sie keine Berechtigung aus einem Embedding ab.
2. Autorisieren Sie vor der Vektorsuche. Lösen Sie die Nutzer- oder Service-Identität in stabile Gruppen- und Attributansprüche auf. Wenden Sie diese Ansprüche als Metadatenfilter in der Retrieval-Anfrage an. Kann der Vector Store Filter nicht verlässlich durchsetzen, benötigen Sie einen autorisierungsbewussten Retrieval-Service davor oder einen anderen Store.
3. Redigieren Sie gezielt. Bewahren Sie eine Originalkopie unter der ursprünglichen Richtlinie auf und erzeugen Sie eine Retrieval-Repräsentation ohne Zugangsdaten, personenbezogene Kennungen oder gesperrte Felder, wenn der Anwendungsfall sie nicht benötigt. Prüfen Sie die Redaktionsqualität stichprobenartig; Mustererkennung allein übersieht Kontext.
4. Weisen Sie jede Antwort nach. Protokollieren Sie Identität oder datensparsamen Subjektbezug, Policy-Version, Retrieval-Filter, zurückgegebene Chunk-IDs, Quellversionen, Modellbereitstellung und Entscheidung. Begrenzen Sie den Zugriff auf diese Logs und definieren Sie deren Aufbewahrung; auch Audit-Logs können sensibel sein.
Entscheidungsmatrix: Wo jede Kontrolle hingehört
| Ingest | klassifizieren, labeln, redigieren, Eigentümer- und Aufbewahrungsmetadaten anfügen | verhindert ungesteuerte Inhalte im Index. |
|---|---|---|
| Retrieval | Dokument- und Chunk-Filter aus Identitätsansprüchen erzwingen | verhindert, dass unzulässiger Kontext das Modell erreicht. |
| Generierung | Tools begrenzen, Quellen ausgeben, offensichtliche sensible Muster erkennen | senkt Restrisiken, ersetzt aber keine Retrieval-Kontrolle. |
| Betrieb | Policy-Version, Chunk-IDs und Ausnahmen protokollieren; Entzug testen | macht Vorfälle untersuchbar und Löschung überprüfbar. |
Löschung und Berechtigungsentzug sind der Härtetest
Wenn Mitarbeitende ein Projekt verlassen, ein Dokument unter Legal Hold fällt oder ein Lieferantenportal stillgelegt wird, muss sich der Zugriff schnell ändern. Entwerfen Sie dafür ein explizites Widerrufsereignis: Quelldatensätze, Chunks und Embeddings entfernen oder invalidieren, Caches leeren und den Abschluss protokollieren. „Der nächtliche Re-Index wird es irgendwann korrigieren“ ist für sensible Daten keine ausreichende Kontrolle.
Prüfen Sie vier Pfade: Retrieval durch unberechtigte Nutzer, geänderte Gruppenmitgliedschaft, gelöschtes Dokument und indirekte Prompt Injection über abgerufene Inhalte. Führen Sie sie in CI für Policy-Code und vor Connector-Änderungen auf einem repräsentativen Staging-Index aus.
Pragmatische Umsetzung in 30 Tagen
Woche 1: Inventarisieren Sie Connectoren und wählen Sie einen abgegrenzten Korpus mit benanntem Eigentümer. Woche 2: Definieren Sie den Metadatenvertrag und ordnen Sie Identitätsgruppen Retrieval-Filtern zu. Woche 3: Ergänzen Sie Trace-Datensätze und die vier Negativtests. Woche 4: Führen Sie eine Übung zum Berechtigungsentzug durch und prüfen Sie Stichproben der Redaktionen mit dem Dokumenteigentümer. Skalieren Sie erst, wenn die Übung messbar bestanden ist.
Was damit nicht gelöst ist
Diese Kontrollen machen ein KI-System nicht automatisch rechtskonform und beseitigen weder Prompt Injection noch überbreite Quellberechtigungen oder einen kompromittierten Identity Provider. Rechtliche Klassifizierung, Aufbewahrungspflichten und Datenschutzpflichten müssen qualifizierte Rechts- und Datenschutzfachleute prüfen. Die Technik sollte die Nachweise für diese Prüfung liefern.
Quellen
NIST, AI RMF: Generative AI Profile (NIST AI 600-1), 2024: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
OWASP, RAG Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html
OWASP Top 10 for LLM Applications 2025: https://owasp.org/www-project-top-10-for-large-language-model-applications/
Bauen Sie die Kontrollschicht vor dem Skalieren des Index
Wenn Sie einen Wissensassistenten vom Pilotbetrieb in die Produktion überführen, unterstütze ich Sie dabei, bestehende Identitäts-, Dokumenten- und Logging-Systeme in eine autorisierungsbewusste RAG-Architektur zu überführen – mit abgegrenztem Pilot, Negativtests und Betriebsübergabe.
