Eine Mitarbeiterin aus dem Verkauf fragt den internen Chatbot: „Welche Rabattregeln gelten für Hotelkunden?“ Die Suche findet drei passende Dokumente. Zwei sind normale Verkaufsrichtlinien. Das dritte ist eine vertrauliche Datei der Geschäftsleitung mit Einkaufsmargen und Sonderkonditionen.
Semantisch ist dieses Dokument perfekt relevant. Organisatorisch darf die Mitarbeiterin es nicht sehen.
Genau dort scheitert ein naiv gebautes RAG-System. Retrieval sucht nach Relevanz und reicht die besten Treffer an das Modell. Wenn die Berechtigungsprüfung erst nachher kommt — oder gar nicht — hat das Modell den vertraulichen Inhalt bereits im Kontext.
Permission-aware RAG setzt deshalb eine einfache Regel durch: Der Chatbot darf nur aus Dokumenten abrufen, auf die der aktuelle Nutzer oder die aktuelle Rolle tatsächlich Zugriff hat. Relevanz wird erst innerhalb dieses erlaubten Bestands optimiert.
RAG Berechtigungen trennen «passt zur Frage» von «darf verwendet werden»
Zero-Trust-Architekturen gehen grundsätzlich davon aus, dass Zugriff nicht allein deshalb erlaubt ist, weil sich jemand „im internen Netzwerk“ befindet. Entscheidungen sollen Identität, Ressource und Kontext berücksichtigen. Für RAG ist das sehr gut übertragbar.
Der Retrieval-Schritt braucht mindestens zwei Informationen: Was sucht die Person? Und welche Dokumente sind für diese Person zulässig?
Das kann über bestehende Gruppen, Rollen, ACLs oder dokumentbasierte Sicherheitsattribute passieren. Wichtig ist weniger das konkrete Produkt als die Reihenfolge: Erst Kandidaten auf den zulässigen Zugriffsbereich begrenzen, dann semantisch ranken.
Identitäts- und ressourcenbezogene Modelle der Zugriffskontrolle sind ein Kernbestandteil von Zero-Trust-Architekturen.
Empfehlung: Lassen Sie das Sprachmodell nicht selbst entscheiden, ob ein bereits geladenes vertrauliches Dokument „wohl okay“ ist. Die Zugriffskontrolle gehört vor die Kontextübergabe.
Was in einer gemeinsamen Wissensbasis schiefgehen kann
Viele KMU starten pragmatisch. Man exportiert SharePoint, Drive, Notion oder einen Dateiordner, erzeugt Embeddings und hat schnell eine gute Demo. Genau diese Geschwindigkeit kann später teuer werden.
Ein Hotel könnte in derselben Ablage öffentliche Frühstückszeiten, interne Personaleinsatzpläne, Beschwerden, Lieferantenpreise und Management-Berichte haben. Ein Chatbot mit globalem Index findet bei einer Frage nach „Kosten Frühstück“ vielleicht eine interne Kalkulation statt der Gästeinformation.
Ein weiteres Problem sind geerbte Rechte. Im ursprünglichen Dateisystem dürfen Team A und Team B verschiedene Ordner sehen. Beim Export in eine Vector Database gehen diese ACL-Metadaten verloren. Die neue Suchschicht ist dann „flacher“ als die Quelle.
Auch Caches sind relevant. Wenn ein Nutzer eine erlaubte Antwort erzeugt und das System den gesamten Kontext für spätere Anfragen global cached, kann ein anderer Nutzer indirekt Informationen aus diesem Kontext bekommen.
Das Ziel lautet deshalb nicht nur „Dokument schützen“, sondern Berechtigung über Indexierung, Retrieval, Cache und Antworttrace hinweg erhalten.
Ein permission-aware RAG Flow in sechs Schritten
Die erste Version muss nicht komplex sein, aber die Sicherheitslogik sollte sichtbar sein.
- Dokumente klassifizieren. Öffentlich, intern, teambezogen, vertraulich oder besonders eingeschränkt.
- ACL-Metadaten bei der Indexierung erhalten. Dokument oder Chunk braucht eine Referenz auf die erlaubten Gruppen/Rollen.
- Nutzerkontext authentifiziert mitgeben. Nicht der Prompt „Ich bin Chef“, sondern eine echte Session-/Identity-Information bestimmt die Rolle.
- Retrieval vor dem Ranking filtern. Nur erlaubte Chunks sind Kandidaten für semantische Relevanz.
- Quelle und Berechtigungsentscheidung loggen. Bei einem Vorfall muss nachvollziehbar sein, welches Dokument warum verwendet wurde.
- Explizite Tests verweigerter Zugriffe durchführen. Ein Nutzer ohne HR-Recht fragt bewusst nach Löhnen, Mitarbeiterbeurteilungen oder internen Margen.
Bei sehr kleinen Betrieben können Rollen einfacher sein: all_staff, sales, management. Entscheidend ist, dass „alle im Unternehmen“ nicht automatisch die Standardberechtigung für jeden Wissensbestand wird.
Ausnahmen und die schwierige Frage nach abgeleiteten Informationen
Access Control ist nicht nur eine Dateifrage. Ein Modell kann aus mehreren erlaubten Dokumenten etwas ableiten, das geschäftlich trotzdem sensibel ist.
Beispiel: Ein Vertriebsmitarbeiter darf Einzelpreise und Liefermengen sehen. Aus vielen Antworten könnte sich eine Marge rekonstruieren lassen, obwohl das Management diese Kennzahl nicht direkt freigeben wollte.
Das lässt sich nicht mit einer einzigen ACL perfekt lösen. Für besonders sensible Bereiche sollte der Betrieb deshalb zusätzliche Antwortregeln oder ganz getrennte Knowledge Spaces verwenden. Eine HR- oder Finanz-RAG-Instanz kann sinnvoller sein als ein universeller „Frag alles“-Bot.
Übergabe an Menschen kommt dort ins Spiel, wo die Information zwar vielleicht zugänglich, aber die Interpretation heikel ist. „Welche Kündigungsfrist hat dieser Mitarbeiter?“ ist etwas anderes als „Was soll ich in dieser arbeitsrechtlichen Situation tun?“ Der Chatbot kann eine Quelle zeigen; die Entscheidung gehört möglicherweise zu HR oder externer Beratung.
Minimaler Pilot: nicht zuerst «gute Antworten», sondern «gute Ablehnungen» testen
Nehmen Sie zwei Gruppen und zwei Dokumentklassen. Zum Beispiel Verkauf und Geschäftsleitung, jeweils mit öffentlichen Verkaufsunterlagen plus einer vertraulichen Margendatei.
Bauen Sie zehn normale Fragen und zehn verbotene Fragen. Die verbotenen Fragen sollten nicht plump sein. Fragen Sie indirekt, kombinieren Sie Begriffe und lassen Sie einen Benutzer behaupten, er sei berechtigt. Prüfen Sie, ob die Retrieval-Logs tatsächlich null unzulässige Chunks zeigen.
Messen Sie Rate unzulässiger Retrieval-Treffer, Anteil unberechtigter Ablehnungen bei berechtigten Nutzern, Anteil Antworten mit nachvollziehbarer Quelle, Zeit bis zur Berechtigungsänderung im RAG nach ACL-Änderung, Anzahl manueller Übergaben wegen Zugriffsunklarheit und Abdeckung der sensiblen Dokumentklassen durch Tests verweigerter Zugriffe.
Eine gute Demo beantwortet schwierige Fragen. Ein guter interner Chatbot kann zusätzlich sauber sagen: „Darauf habe ich in Ihrem Zugriffskontext keine freigegebene Quelle.“
Permission-aware RAG ist keine Zusatzfunktion für grosse Konzerne. Sobald ein KMU unterschiedliche Dokumentrechte hat, muss die RAG-Suche dieselbe Grenze respektieren. Sonst baut man neben dem bestehenden Berechtigungssystem eine zweite Tür — und lässt sie offen.
Die indirekte Prompt Injection ist ein Inhaltsrisiko. Eigene technische Identitäten klären, in wessen Namen der Zugriff erfolgt. Beides muss zusammenpassen.
Quellen
FAQ
Reicht es, vertrauliche Ordner nicht zu indexieren?
Für manche Piloten ja. Sobald unterschiedliche Benutzer unterschiedliche interne Bereiche nutzen sollen, brauchen Sie feinere Berechtigungen.
Kann das Modell selbst prüfen, ob eine Quelle sensibel ist?
Es kann helfen zu klassifizieren, sollte aber nicht die einzige Zugriffsbarriere sein. Autorisierung gehört in die Systemlogik.
Muss jeder Chunk eigene ACL-Metadaten haben?
Das hängt von der Architektur ab. Die Berechtigungsinformation muss jedenfalls beim Retrieval zuverlässig auf den verwendeten Inhalt anwendbar sein.
Was passiert, wenn jemand die Rolle im Prompt fälscht?
Prompt-Text darf keine echte Identität ersetzen. Die Rolle sollte aus einer authentifizierten Session oder einem vertrauenswürdigen Identity-System kommen.
Soll HR im gleichen RAG wie allgemeine Betriebsdokumente liegen?
Das kann funktionieren, erhöht aber Komplexität und Risiko. Für hochsensible Bereiche ist eine stärkere Trennung oft einfacher zu kontrollieren.