Retrieval-Augmented Generation. Ein Sprachmodell beantwortet Fragen auf Basis von Dokumenten, die zur Laufzeit aus einem Index gesucht werden, statt nur aus seinem Trainingswissen.

Reicht es, dem Modell im Prompt zu sagen, welche Daten es nicht verwenden darf?

Nein. Ein Prompt ist keine Zugriffskontrolle. Dokumente, die ein Nutzer nicht sehen darf, dürfen gar nicht erst im Kontext des Modells landen.

Muss ich für RAG auf sensiblen Daten selbst Modelle hosten?

Nicht zwingend. Entscheidend sind Datenklassifizierung, Vertragslage und Region. Je nach Schutzbedarf passen ein Cloud-Dienst in einer EU-Region oder ein selbst gehostetes Modell.

RAG auf sensiblen Daten: 7 Punkte vor dem Produktivstart

Ein RAG-Prototyp ist an einem Nachmittag gebaut: Dokumente in eine Vektordatenbank, ein LLM davor, fertig. Der Weg in die Produktion ist bei sensiblen Daten deutlich länger. Diese sieben Punkte prüfe ich, bevor ein RAG-System mit internen Daten live geht.

1. Berechtigungen beim Retrieval durchsetzen

Das wichtigste Prinzip: Das Modell darf nur sehen, was der anfragende Nutzer sehen darf. Die Berechtigungen aus den Quellsystemen gehören deshalb als Metadaten in den Index und werden bei jeder Suche als Filter angewendet. Eine Anweisung im Prompt wie „verwende keine vertraulichen Dokumente“ ist keine Zugriffskontrolle.

2. Daten klassifizieren, bevor sie in den Index gehen

Nicht jedes Dokument gehört in einen RAG-Index. Klären Sie vorab, welche Schutzklassen es gibt, welche Quellen angebunden werden und wer die Freigabe erteilt. Das spart später aufwendiges Entfernen aus Index und Logs.

3. Modell und Hosting nach Schutzbedarf wählen

Aus der Datenklassifizierung folgt die Modellwahl: ein Cloud-Dienst wie Azure OpenAI in einer EU-Region, ein Modell auf eigener Infrastruktur auf Google Cloud, AWS oder Azure oder ein lokal betriebenes Modell, etwa mit Ollama. Vertragslage, Datenresidenz und Logging-Verhalten des Anbieters gehören in diese Entscheidung.

4. Prompt Injection einplanen

Dokumente im Index sind Eingaben, die das Modell als Anweisungen missverstehen kann. Begrenzen Sie, was das System mit einer Antwort tun darf, trennen Sie Systemanweisungen klar von abgerufenem Inhalt und behandeln Sie Tool-Aufrufe aus dem Modell wie unvalidierte Nutzereingaben.

5. Ausgaben automatisiert testen

Jede Änderung an Prompt, Modell, Chunking oder Index kann Antworten verschlechtern. Eine automatisierte Testsuite mit festen Fragen, erwarteten Quellen und Prüfkriterien macht diese Änderungen messbar. Im Bankenumfeld habe ich dafür eine eigene Testing-Suite für LLM-Ausgaben aufgebaut.

6. Logging und Observability mit Datenschutz

Sie brauchen Einblick in Anfragen, abgerufene Dokumente, Latenzen und Kosten. Gleichzeitig enthalten genau diese Logs sensible Daten. Legen Sie fest, was gespeichert wird, wie lange und wer Zugriff hat.

7. Die Plattform härten

Ein RAG-System ist auch nur eine Anwendung mit APIs, Containern und Identitäten. Gehärtete Container, Single Sign-on über OAuth2/OIDC, minimale IAM-Rechte und Security Scanning in der CI/CD-Pipeline gelten hier genauso wie überall sonst.

Fazit

Die eigentliche Arbeit bei RAG auf sensiblen Daten steckt nicht im Modell, sondern in Berechtigungen, Datenflüssen, Tests und Betrieb. Wer diese Punkte von Anfang an in die Architektur aufnimmt, kommt schneller und sicherer in Produktion.