RAG-Berechtigungen für Website-Chatbots: Dokumentzugriff sicher steuern

Ein Website-Chatbot kann Antworten aus FAQ-Seiten, Produktdokumenten und internen Wissensquellen zusammenführen. Das ist hilfreich - bis dieselbe Wissensbasis Inhalte enthält, die nicht für jede Person bestimmt sind. Dann entscheidet nicht allein die Qualität des Sprachmodells über eine sichere Antwort, sondern der Retrieval-Schritt davor: Welche Dokumente darf diese konkrete Anfrage überhaupt sehen?

RAG-Berechtigungen verbinden verifizierte Identitäten, Rollen oder Gruppen mit Metadaten an Dokumenten. Der Chatbot erhält nur bereits gefilterte Quellen. Das Ziel ist bewusst eng: Nicht ein Modell soll anhand des Prompts entscheiden, ob etwas vertraulich ist. Die Anwendung begrenzt den zugelassenen Kontext, dokumentiert diese Entscheidung und wählt bei Unsicherheit einen sicheren Fallback.

Warum Prompt-Regeln keine Zugriffskontrolle ersetzen

Eine Systemanweisung wie „Gib keine internen Informationen aus“ ist sinnvoll, aber keine Berechtigungsschicht. Wenn ein unzulässiges Dokument bereits in den Kontext gelangt, kann die Antwort es zusammenfassen, indirekt preisgeben oder auf Nachfrage rekonstruieren. Auch eine nachgelagerte Textprüfung ist zu spät und fehleranfällig. Sicherheit beginnt deshalb vor Generierung und idealerweise vor der Rangfolge der Treffer.

Azure AI Search beschreibt Security Trimming als Filtermuster: Dokumente tragen Identitäts- oder Gruppenwerte; die Abfrage enthält nur die Principals der anfragenden Person. Amazon Bedrock weist ähnlich darauf hin, dass ACL-bewusste Retrieval-Filter keine Authentifizierung ersetzen. Ihre Anwendung muss die Identität zuerst selbst zuverlässig prüfen und nur einen verifizierten Kontext übergeben.

Die vier Bausteine einer belastbaren Lösung

1. Identität und Session serverseitig verifizieren

Ein öffentliches Chatfenster hat normalerweise keine Dokumentenrechte. Es darf nur auf öffentliche Quellen zugreifen. Für ein Kundenportal oder Mitarbeiterbereich wird die Person dagegen über die bestehende Anmeldung identifiziert. Lesen Sie Rolle, Organisation und relevante Gruppen serverseitig aus der Session oder einem signierten Token. Verlassen Sie sich nie auf ein vom Browser frei gesendetes Feld wie role=admin oder auf eine Chatnachricht, die eine Zugehörigkeit behauptet.

2. Berechtigungsmetadaten mit jeder Quelle pflegen

Jeder Chunk benötigt neben Text, URL und Aktualitätsdatum eine nachvollziehbare Zugriffsinformation: etwa audience=public, eine Mandanten-ID, eine Liste zulässiger Gruppen oder eine Klassifikation. Diese Metadaten müssen aus derselben fachlichen Quelle wie die Dokumentberechtigung stammen. Ein separates Tabellenblatt, das nur gelegentlich gepflegt wird, erzeugt gefährliche Drift. Bei neuen Dokumenten und bei Änderungen von Gruppenrechten gehört die Metadaten-Synchronisierung deshalb in den Publishing- oder Crawl-Workflow.

3. Vor dem Ranking filtern

Die Query konstruiert einen Filter aus dem verifizierten Kontext. Erst danach werden semantische oder hybride Treffer bewertet. So kann ein vertrauliches Handbuch nicht als besonders passender Treffer gewinnen, um später wieder entfernt zu werden. Bei mehreren Mandanten ist die Mandanten-ID ein zwingender Filter, nicht bloß ein Ranking-Signal. Für personenbezogene oder besonders geschützte Daten empfiehlt sich zusätzlich ein eigener Datenbereich statt einer gemeinsamen, nur logisch gefilterten Sammlung.

4. Quellen und Entscheidung protokollieren

Für Support und Incident-Analyse reichen Chattranskripte allein nicht. Pro Anfrage sollte nachvollziehbar sein, welche nicht-sensiblen Identitätsattribute zur Filterbildung verwendet wurden, welche Filterklasse galt, wie viele Treffer nach dem Filter übrig blieben und welche Quellen tatsächlich in den Prompt gelangten. Speichern Sie keine unnötigen Vollinhalte oder Tokens. Ein datensparsames Audit-Event macht Fehler auffindbar, ohne aus dem Monitoring eine zweite Wissenslecke zu machen.

Ein praktischer Ablauf für Website-Teams

1. Ordnen Sie jede Wissensquelle einer klaren Zielgruppe zu: öffentlich, Kunde, Partner, internes Team oder ein konkreter Mandant.
2. Definieren Sie, welche Session-Claims diese Zielgruppe beweisen. Gruppen aus dem Identitätssystem sind robuster als frei wählbare Formulareingaben.
3. Übernehmen Sie diese Claims serverseitig in den Retrieval-Filter und erlauben Sie nur eine kleine, bekannte Menge von Filterfeldern.
4. Führen Sie bei jedem Crawl einen Abgleich durch: neue, geänderte und entfernte Dokumente brauchen auch aktualisierte Berechtigungsmetadaten.
5. Geben Sie dem Modell nur die gefilterten Treffer plus eine klare Anweisung, fehlende Informationen nicht zu erraten.
6. Leiten Sie bei keinem Treffer, widersprüchlichen Quellen oder unklarer Berechtigung zu einem sicheren Kontaktweg weiter.

Dieser Ablauf ergänzt die in unserem Beitrag zu RAG-Chunking beschriebene Strukturierung: Gute Abschnitte verbessern Treffer, ersetzen aber keine Zugangskontrolle. Ebenso bleiben frische Quellen wichtig; ein veralteter Berechtigungsstand ist ein Qualitäts- und Sicherheitsproblem zugleich.

Fehlerbild: Filter nach dem Retrieval

Ein häufiger Fehlentwurf lautet: Das System ruft die zehn besten Treffer ab, prüft danach deren Labels und entfernt problematische Dokumente. Das wirkt zunächst ausreichend, scheitert aber an Nebenwirkungen. Der unzulässige Treffer kann schon in Logs, Caches oder einer Debug-Ausgabe auftauchen. Außerdem verändert sein Score die Auswahl der übrigen Treffer. Besser ist ein Filter im Retrieval-Request, der nur berechtigte Dokumente als Kandidaten zulässt.

Ein zweites Fehlerbild ist das pauschale Vertrauen in eine ACL-Funktion eines Anbieters. Herstellerdokumentation kann klar sagen, dass ein Dienst ACLs beim Abruf berücksichtigt, aber nicht selbst die Echtheit des übergebenen Benutzerkontexts prüft. Prüfen Sie deshalb präzise: Wer authentifiziert die Person? Woher kommen Gruppen? Wann werden Rechte ins Retrieval-System synchronisiert? Was passiert, wenn Metadaten fehlen?

Fail closed: Was bei Unsicherheit passieren soll

Bei einem fehlenden Claim, einer nicht synchronisierten Quelle oder einem Retrieval-Fehler sollte der Chatbot keine breitere Suche versuchen. Nutzen Sie eine neutrale Antwort: Der angefragte Inhalt steht im aktuellen Zugriffskontext nicht zur Verfügung; ein menschlicher Ansprechpartner kann den Zugang prüfen. Das ist keine Schwäche der Conversational UX, sondern eine ehrliche Grenze. Der Beitrag zum Human Handoff zeigt, wie eine solche Übergabe konkret und ohne Sackgasse gestaltet werden kann.

Für öffentliche Inhalte gilt dieselbe Idee kleiner skaliert: Wenn die Quellenlage nicht reicht, sollte der Bot Unsicherheit benennen, verifizierte Links anbieten oder einen Kontaktweg nennen - statt plausible Details zu erfinden. Das reduziert Halluzinationen und verhindert, dass eine vermeintlich hilfreiche Antwort zur falschen Freigabe auffordert.

Testfälle, die vor dem Rollout gehören

Ein Berechtigungstest ist kein einmaliger Admin-Check. Legen Sie ein kleines Golden Set mit identischen Fragen für mehrere Rollen an: Gast, registrierter Kunde, berechtigter Partner, gesperrter Nutzer und Administrator. Definieren Sie für jede Kombination die erwarteten Quellen, nicht nur den erwarteten Antworttext. Testen Sie außerdem Gruppenwechsel, abgelaufene Sessions, gelöschte Dokumente, fehlende ACL-Metadaten und einen Ausfall des Retrieval-Dienstes.

Kontrollieren Sie in den Ergebnissen mindestens vier Dinge: Keine unzulässige URL oder Dokument-ID gelangt in den Kontext; erlaubte Quellen bleiben erreichbar; die Antwort nennt keine Inhalte aus ausgefilterten Dokumenten; und der Fallback bleibt verständlich. Ergänzen Sie diese Prüfungen zu Ihren Antwortqualitäts-Tests, damit Sicherheit und fachliche Qualität gemeinsam gemessen werden.

Datenschutz und Transparenz pragmatisch umsetzen

Berechtigungsdaten sind selbst schützenswert. Verwenden Sie möglichst stabile technische IDs statt Klartextnamen in Retrieval-Metadaten. Begrenzen Sie Audit-Logs auf Zweck, Zeitraum und notwendige Attribute. Informieren Sie Nutzer verständlich, wenn ein Chatbot auf den angemeldeten Bereich zugreift, und bieten Sie einen menschlichen Weg für Zugriffsfragen. Dieser Artikel ersetzt keine individuelle Rechtsberatung; konkrete Aufbewahrungsfristen und Rechtsgrundlagen hängen vom Einsatzkontext ab.

Technisch lohnt sich eine klare Verantwortlichkeit: Content-Owner pflegen Zielgruppen, das Identity-Team verantwortet Claims und Session-Prüfung, das Produktteam hält Filter und Fallbacks getestet. So wird die Wissensbasis nicht zu einem unkontrollierten Datenpool, sondern zu einer Quelle, deren Reichweite nachvollziehbar bleibt.

Checkliste vor dem Livegang

• Ist jede nicht öffentliche Quelle einer Rolle, Gruppe oder Mandanten-ID zugeordnet?
• Stammt der Abfragekontext aus einer serverseitig verifizierten Identität?
• Wirkt der Filter vor Retrieval und Ranking?
• Werden Rechteänderungen und Crawls zusammen synchronisiert?
• Gibt es rollenbasierte Regressionstests mit erwarteten Quellen?
• Führt jeder unbekannte oder fehlerhafte Zustand zu einem sicheren Handoff?
• Sind Logs datensparsam und für Fehleranalyse ausreichend?

Fazit

Ein guter Website-Chatbot beantwortet nicht jede Frage für jede Person. Er zeigt nur Quellen, die zum verifizierten Zugriffskontext passen, und bleibt bei Unsicherheit bewusst zurückhaltend. Beginnen Sie mit einer kleinen Quellenmatrix, einem serverseitigen Filter und wenigen klaren Testrollen. Danach können Sie Berechtigungsmetadaten, Audits und Synchronisierung schrittweise ausbauen - ohne die Sicherheit an Prompt-Formulierungen auszulagern.

Quellen

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls