Ein schlecht aufgesetztes RAG ist der schnellste Weg, Daten zu lecken, die niemals nach draußen dürften. Das klassische Muster: du indexierst „die ganze Dokumentation", ein User fragt etwas Harmloses, und das System gibt ihm ein Fragment aus einem Dokument zurück, auf das diese Person keinen Zugriff haben dürfte. Das ist kein exotischer Bug — es ist die Default-Architektur fast aller Demo-RAGs.
Berechtigungen vor Embeddings
Die Zugriffskontrolle ist kein Filter, den man am Ende dranklebt: sie lebt in der Retrieval-Schicht. Bevor das Modell irgendetwas sieht, hat das System bereits eingeschränkt, welche Fragmente dieser konkrete User abrufen darf. Die Identität gibt den Ton an; das Embedding kommt danach.
Partitioniere den Index nach Berechtigung
Wir werfen nicht alles in einen einzigen Index und beten. Wir segmentieren nach Zugriffsstufe und hängen jedem Fragment Berechtigungs-Metadaten an, sodass die Query nur das anfassen kann, was demjenigen zusteht, der fragt.
- Filterung nach Identität im Retrieval, nicht in der Antwort.
- Nach Zugriffsstufe segmentierte Indizes oder Partitionen.
- Berechtigungs-Metadaten an jedem indexierten Fragment.
- Query-Audit: wer hat was gefragt und was wurde ihm zurückgegeben.
Citation oder es taugt nichts
Jede Antwort verlinkt ihre Quelle. Ohne Citation gibt es weder Vertrauen noch Nachvollziehbarkeit: der User kann nicht verifizieren, und du kannst nicht auditieren. Im Enterprise ist eine Antwort ohne Quelle eine Antwort, die du nicht verteidigen kannst.
Was wir messen
- Retrieval-Präzision (bringt es das Relevante?).
- Zugriffslecks: das Ziel ist null, und es wird auditiert.
- Citation-Coverage: % der Antworten mit verifizierbarer Quelle.
- Uptime und Latenz der Pipeline.
Das ist es, was ein Senior AI Infrastructure Implementer macht: er „stöpselt" kein RAG an, er deployt ein Wissenssystem, das skaliert, zitiert und die Berechtigungen respektiert — denn im Enterprise ist ein geleaktes Datum kein technischer Vorfall, es ist eine Krise.