Permission-Aware RAG: Was es wirklich kostet, es richtig zu machen

Permission-aware RAG bedeutet, dass Ihr Retrieval-Schritt danach filtert, wer fragt – nicht nur was gefragt wird –, und dieser Filter muss in der Vektorabfrage selbst verankert sein, nicht als zweiter Durchlauf, den der LLM im Nachhinein erledigt. Die meisten Teams lernen das auf die harte Tour: Ihr RAG-Demo funktioniert hervorragend auf einer gemeinsamen Wissensbasis, aber sobald jemand dokumentenbasierte Zugriffsrechte pro Nutzer durchsetzen will, muss die gesamte Retrieval-Schicht neu gebaut werden.

Warum „einfach einen Berechtigungscheck hinzufügen" nicht funktioniert

Der naheliegende Ansatz: die bestehende Retrieval-Pipeline beibehalten und am Ende einen Check anhängen – die Top-k-Chunks abrufen und dann einen LLM (oder eine Regelmaschine) fragen: „Darf dieser Nutzer das sehen?" – bevor der Kontext an den Antwortschritt übergeben wird. Das scheitert auf zwei Arten:

• Es ist nicht deterministisch. Ein LLM, der die Zugriffskontrolle überwachen soll, liegt gelegentlich falsch – und „gelegentlich falsch" ist keine akzeptable Zugriffskontroll-Policy, erst recht nicht bei Patientenakten, juristischen Dokumenten oder HR-Unterlagen.
• Die Datenpanne ist bereits passiert. Sobald Sie post-retrieval filtern, wurden die eingeschränkten Inhalte bereits in ein Context-Window gezogen und irgendwohin übertragen. Logging, Caching oder ein versehentlicher Debug-Trace können sie leaken, bevor Ihr Filter überhaupt greift.

Die Lösung besteht darin, Berechtigungen in die Abfrage zu verlagern – so wie Sie eine WHERE user_id = ?-Klausel in eine SQL-Abfrage schreiben würden, anstatt alles abzurufen und im Anwendungscode zu filtern. Wir haben dasselbe Prinzip in unserem eigenen Tooling erlebt: In einer internen Outreach-Engine, die wir gebaut haben, war ein einziger Call, der in einem Schritt filtert und extrahiert, einer mehrstufigen Chain, die breit abruft und im Nachhinein über Relevanz urteilt, durchgängig überlegen – günstiger, schneller und mit weniger Fehlerquellen. Permission-aware RAG ist die sicherheitskritische Variante dieser Lektion: am Ursprung filtern, nicht hinterher.

Was sich in Ihrer Architektur tatsächlich ändert

Wenn Sie Postgres mit pgvector oder einem verwalteten Vektorspeicher betreiben, erfordert permission-aware Retrieval typischerweise:

1. Berechtigungs-Metadaten an jedem Chunk. Nicht nur eine document_id – Sie müssen bereits zur Indexierungszeit wissen, welche Rollen, Teams oder User-IDs den jeweiligen Chunk sehen dürfen. Das bedeutet in der Regel, Ihren gesamten Bestand neu zu chunken und neu zu embedden – kein nachträgliches Metadata-Patch.
2. Row-Level Security oder einen gleichwertigen Filter im Query-Pfad. Postgres unterstützt dies nativ über Row-Level Security Policies, und Supabase baut direkt darauf auf für mandantenfähiges RLS. Ähnlichkeitssuche und Zugriffsfilter laufen als eine einzige Abfrage – eine Vektorsuche eines Nutzers kann buchstäblich keine Zeilen zurückgeben, auf die er keinen Zugriff hat.
3. Ein Berechtigungsmodell, das sich im Laufe der Zeit ändert. Dokumente werden geteilt, Rollen werden entzogen, Teams werden umstrukturiert. Wenn Ihre Embeddings und Ihre Berechtigungen in verschiedenen Systemen liegen, die sich nach Zeitplan synchronisieren, gibt es ein Zeitfenster, in dem die Session eines entlassenen Mitarbeiters noch Dokumente abrufen kann, auf die er vor einer Stunde keinen Zugriff mehr hatte. Echtzeitprüfung von Berechtigungen ist nicht verhandelbar, sobald regulierte Inhalte ins Spiel kommen.
4. Re-Indexierungsstrategie, nicht nur Retrieval-Logik. Das ist der Teil, der Schätzungen sprengt. ACLs zu einem RAG-System hinzuzufügen, das bereits 50.000 indexierte Dokumente enthält, bedeutet: Sie schreiben keine neue Abfrage – Sie verarbeiten das gesamte Korpus mit Berechtigungs-Tags neu und validieren anschließend, dass die Tags korrekt sind, bevor Sie dem System sensible Inhalte anvertrauen.

Wo die Kosten tatsächlich anfallen

Teams kalkulieren für das Modell und die Retrieval-Logik. Bei demselben Korpus von 50.000 Dokumenten entstehen die realen Kosten hier:

• Daten-Audit. Jemand muss bestimmen, wer welche Inhalte eigentlich sehen darf – und bei 50.000 Dokumenten ist das keine Tabelle, die an einem Nachmittag ausgefüllt wird. Es geht darum, Zugriffsrechte Abteilung für Abteilung zu klären, oft anhand von implizitem Wissen, das nie schriftlich festgehalten wurde – bevor auch nur ein einziger Berechtigungs-Tag vergeben wird.
• Re-Embedding im großen Maßstab. 50.000 Dokumente neu zu chunken und neu zu embedden ist kein Job, den Sie über Nacht anstoßen und am nächsten Morgen abnicken. Wenn das Berechtigungsmodell verändert, was als eine abrufbare Einheit gilt (etwa ein geteiltes Verzeichnis in teamspezifische Abschnitte aufzuteilen), ändern sich auch die Chunk-Grenzen selbst – das ist ein vollständiger Re-Processing-Durchlauf über den gesamten Korpus, kein Metadata-Update obendrauf.
• Tests für Negativfälle. Zu testen, dass das System korrekt abruft, ist einfach. Zu testen, dass es niemals etwas abruft, das ein Nutzer nicht sehen darf – über alle Rollenkombinationen hinweg –, ist der Teil, der echte QA-Zeit kostet. Das fällt in dieselbe Kategorie wie eine AI Agent Security Checklist und verdient dieselbe Sorgfalt, die Sie auf Authentifizierungscode verwenden würden – nicht „wir haben ein paar Prompts ausprobiert und es schien zu funktionieren."
• Audit-Logging. Im Gesundheitswesen oder in Behörden müssen Sie im Nachhinein nachweisen können, was ein Nutzer genau abgerufen hat und warum – das bedeutet, die gefilterte Abfrage zu loggen, nicht nur die endgültige Antwort. Das überschneidet sich direkt mit dem, was wir über gerichtsfeste Architektur für Healthcare-AI geschrieben haben: Das Log muss belastbar sein, nicht nur vorhanden.

Wann sich Eigenentwicklung lohnt – und wann nicht

Wenn Ihr Zugriffsmodell einfach ist – ein Mandant, eine gemeinsame Wissensbasis, alle sehen alles –, bauen Sie kein permission-aware Retrieval. Das ist unnötige Komplexität für ein Problem, das Sie nicht haben. Starten Sie mit den Grundlagen in RAG erklärt für Gründer und gehen Sie weiter.

Bauen Sie es selbst, wenn:

• Ihr Berechtigungsmodell zentraler Bestandteil des Produkts ist (mandantenfähige SaaS, Patientenakten, interne Wissensbasen mit vertraulichen HR- oder Rechtsinhalten).
• Sie Echtzeitentzug benötigen – Zugriffsänderungen müssen sofort wirksam sein, nicht beim nächsten Sync.
• Sie sich in einem regulierten Bereich befinden, in dem „wir haben nach dem Retrieval gefiltert" eine Prüfung nicht übersteht.

Ziehen Sie eine verwaltete Schicht in Betracht (viele Enterprise-Such- und RAG-Plattformen liefern ACL-aware Retrieval mittlerweile ab Werk), wenn Ihr Berechtigungsmodell sauber auf Standard-Rollen-/Gruppenstrukturen abbildbar ist und Sie die Filterlogik nicht anpassen müssen. Wie auch immer Sie sich entscheiden: Prüfen Sie die Retrieval-Garantien des Anbieters mit derselben Sorgfalt, die Sie auf jeden KI-Anbietervertrag verwenden würden – was dabei konkret zu fordern ist, lesen Sie in Evals in AI-Anbieterverträgen.

Die Kurzfassung

Übertragen Sie die Zugriffskontrolle nicht dem LLM nach dem Retrieval – setzen Sie sie in der Abfrage durch, die das Retrieval durchführt, und kalkulieren Sie für die Re-Indexierung Ihres Korpus, nicht nur für neuen Retrieval-Code.

Wenn Sie ein RAG-System mit echten Berechtigungsgrenzen planen – Patientenakten, mandantenfähige SaaS, interne Dokumente mit vertraulichen Bereichen –, sprechen Sie uns an.