Berechtigungen in RAG-Systemen: Rollen, Mandanten und Dokumentzugriff

Eine RAG-gestützte Wissensdatenbank soll Fragen über den gesamten Dokumentenbestand eines Unternehmens beantworten – Personalrichtlinien, Kundenverträge, interne Protokolle, Projektunterlagen. Genau darin liegt das Risiko: Semantische Suche kennt von sich aus keine Abteilungsgrenzen. Sie findet den inhaltlich passendsten Textabschnitt, unabhängig davon, ob die fragende Person diesen Abschnitt sehen darf. Ohne eigenes Zugriffskonzept kann ein RAG-System damit Informationen sichtbar machen, die vorher durch Ordnerstrukturen, Laufwerksrechte oder Aktenzugriffe geschützt waren.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen, die ein RAG-System planen oder bereits betreiben und wissen wollen, wo Berechtigungen technisch ansetzen müssen, wie rollenbasierte Filter und Mandantentrennung funktionieren – und wo die Grenzen dieser Maßnahmen liegen. Er gehört zu unserem Themen-Cluster RAG und Wissensdatenbanken.

Vorab zur Einordnung, Stand Juli 2026: Dieser Artikel ist eine allgemeine technische und organisatorische Orientierung, keine Rechtsberatung. Ob dein konkretes Berechtigungskonzept datenschutzrechtlich ausreicht, ist eine Einzelfallprüfung – dafür gehören Datenschutzbeauftragte oder spezialisierte Kanzleien an den Tisch.

Begriffe und Abgrenzung

Damit die folgenden Abschnitte eindeutig sind:

• Referenzdokumente sind die Quelldokumente der Wissensbasis – Verträge, Wikis, Richtlinien, Protokolle.
• Chunks sind die Textabschnitte, in die diese Dokumente vor dem Embedding zerlegt werden.
• Vektordatenbank speichert die Chunks zusammen mit ihren Embeddings und wird vom Retriever bei jeder Anfrage durchsucht.
• Retriever ist die Komponente, die aus der Nutzeranfrage einen Anfragevektor erzeugt und damit die Vektordatenbank nach den inhaltlich ähnlichsten Chunks durchsucht.
• Rechte- und Rollenkonzept bezieht sich im RAG-Kontext auf Zugangsbeschränkungen zu Bereichen der Vektordatenbank und den Referenzdokumenten – wer welche Rolle hat und welche Bereiche diese Rolle sehen darf.
• Mandantentrennung/funktionale Trennung bedeutet, die Vektordatenbank technisch in getrennte Bereiche zu gliedern, etwa nach Abteilung, Kundenverhältnis oder Aktengruppe, sodass eine Abfrage nur den zugeordneten Bereich durchsuchen kann.

Wichtig zur Abgrenzung: Diese Mechanismen setzen alle vor oder während des Retrievals an – also bevor Chunks an das Sprachmodell übergeben werden. Im Sprachmodell selbst lässt sich nach Angaben der Datenschutzkonferenz nicht steuern, auf welche Informationen bestimmte Nutzende Zugriff haben dürfen und auf welche nicht. Berechtigungen sind deshalb ausschließlich eine Aufgabe des RAG-Subsystems – Referenzdokumente, Vektordatenbank und Retriever –, nicht des Sprachmodells.

Wo müssen Rechte geprüft werden?

Kurz beantwortet: An drei Stellen im RAG-Subsystem, nicht im Sprachmodell.

1. Bei der Aufbereitung der Referenzdokumente. Schon bevor ein Dokument in Chunks zerlegt und eingebettet wird, muss feststehen, welchem Mandanten, welcher Abteilung oder welchem Zugriffsbereich es zugeordnet ist. Diese Zuordnung wandert als Metadatum mit in die Vektordatenbank.

2. In der Vektordatenbank. Hier gilt dasselbe Schutzniveau wie für die Quelldokumente selbst – die Zugriffsbeschränkung muss sich auf Bereiche der Datenbank anwenden lassen, nicht nur auf die Datenbank als Ganzes. Ein System, das entweder alles oder nichts freigibt, erfüllt keine differenzierte Rechteprüfung.

3. Beim Retriever, vor jeder Anfrage. Der Retriever muss die Rolle der anfragenden Person kennen und darf nur Chunks aus den für diese Rolle freigegebenen Bereichen als Suchergebnis zurückgeben – nicht erst die Antwort nachträglich filtern. Wird erst nach der Texterzeugung gefiltert, sind die unzulässigen Informationen bereits Teil der erweiterten Anfrage an das Sprachmodell gewesen und potenziell in der generierten Antwort enthalten.

Diese drei Prüfpunkte sind zugleich der zentrale Vorteil von RAG gegenüber einem reinen LLM-Einsatz: In der Vektordatenbank lässt sich steuern, wer auf welche Information zugreift – im Sprachmodell nicht. Berechtigungen sind bei RAG also nicht nur möglich, sondern der wichtigste Hebel für Vertraulichkeit und Zweckbindung im gesamten System.

Wie funktionieren rollenbasierte Filter?

Ein rollenbasierter Filter besteht aus zwei Teilen: einer Rollenzuweisung und einem Abgleich beim Retrieval.

Rollenzuweisung. Mitarbeitende, die das RAG-System für unterschiedliche Zwecke nutzen, bekommen unterschiedliche Rollen zugewiesen – etwa nach Abteilung, Funktion oder Kundenverhältnis. Vor jeder Abfrage muss sichergestellt sein, dass die Person die für den jeweiligen Verarbeitungszweck korrekte Rolle innehat. Das ist bei mehrfach genutzten Systemen (dieselbe Person fragt teils im HR-Kontext, teils im Vertriebskontext ab) kein einmaliges Setup, sondern eine laufende Verwaltungsaufgabe.

Abgleich beim Retrieval. Der Retriever erzeugt aus der Anfrage einen Vektor und durchsucht die Vektordatenbank nach den ähnlichsten Chunks – dieser Schritt muss um einen Rollen- oder Bereichsfilter ergänzt werden, sodass nur Chunks aus für die Rolle freigegebenen Bereichen überhaupt als Suchergebnis in Frage kommen. Technisch heißt das meist: Metadaten-Filterung auf Ebene der Vektordatenbank, kombiniert mit der Ähnlichkeitssuche, statt einer nachgelagerten Prüfung der fertigen Antwort.

Ein praktischer Fallstrick, den ich in Beratungsgesprächen regelmäßig sehe: Teams bauen den Rollenfilter in die Anwendungsschicht (das Chat-Interface), nicht in den Retriever selbst. Sobald es einen zweiten Zugriffsweg auf die Vektordatenbank gibt – ein Batch-Job, eine zweite Anwendung, ein direkter API-Zugriff – greift der Filter dort nicht mehr. Die Regel lautet deshalb: Der Filter gehört so nah wie möglich an die Vektordatenbank, nicht an die Oberfläche.

Wie trennt man Mandanten?

Mandantentrennung (auch funktionale Trennung genannt) ist die technische Umsetzung dessen, was ein Rechte- und Rollenkonzept konzeptionell vorgibt. Sie lässt sich auf mehreren Ebenen realisieren, von strikt bis flexibel:

• Getrennte Vektordatenbanken pro Mandant. Die strengste Form: Jeder Mandant oder Bereich bekommt eine eigene Vektordatenbank-Instanz. Maximale Trennschärfe, aber höherer Betriebsaufwand bei vielen kleinen Mandanten.
• Namespaces oder Collections innerhalb einer Vektordatenbank. Die meisten Vektordatenbanken unterstützen logisch getrennte Bereiche innerhalb einer Instanz. Der Retriever durchsucht nur den Namespace, der zur Rolle passt.
• Metadaten-Filterung. Jeder Chunk trägt ein Mandanten- oder Bereichs-Tag als Metadatum; die Ähnlichkeitssuche wird mit einem Filter auf dieses Tag kombiniert. Flexibelste, aber auch fehleranfälligste Variante – ein vergessener Filter-Parameter hebt die Trennung faktisch auf.

Wichtig laut Datenschutzkonferenz: Die Mandantentrennung sollte bereits bei der Aufbereitung der Referenzdokumente geprüft werden, zum Beispiel durch eine bewusste Aufteilung der Dokumente nach Mandant oder Bereich – nicht erst nachträglich als Filter über eine bereits vermischte Datenbank gelegt. Wer heterogene Dokumente ungeprüft in eine gemeinsame Vektordatenbank einspielt und die Trennung erst später ergänzen will, arbeitet gegen die Architektur statt mit ihr.

Ein zweiter Punkt betrifft die Zweckbindung: Eine Bereitstellung bestimmter Dokumente für das Sprachmodell ermöglicht zielgerichtete Abfragen personenbezogener Daten, die strikt auf den definierten Verarbeitungszweck beschränkt bleiben müssen. Mandantentrennung ist damit nicht nur ein Zugriffsschutz, sondern auch eine Voraussetzung dafür, dass eine Verarbeitung überhaupt zweckgebunden bleibt.

Wie behandelt man Caches und Logs?

Dieser Punkt wird in Projekten am häufigsten übersehen, weil er nicht offensichtlich zur „Vektordatenbank” gehört: Caches, Protokolle der erweiterten Anfragen und Antwort-Archive enthalten dieselben Chunks – und damit dieselben Berechtigungsgrenzen – wie die Vektordatenbank selbst.

Konkret bedeutet das:

• Ein Antwort-Cache, der wiederkehrende Fragen schneller beantworten soll, speichert typischerweise die vollständige erweiterte Anfrage samt der darin enthaltenen Chunks. Ohne eigene Zugriffskontrolle kann ein Cache-Treffer einer Person Inhalte zeigen, für die sie über den regulären Retrieval-Pfad keine Berechtigung hätte.
• Prompt-Logs, die zu Debugging- oder Qualitätszwecken mitgeschrieben werden, enthalten dieselben Informationen im Klartext. Wer Zugriff auf die Logs hat (oft ein breiterer Personenkreis als auf die produktive Anwendung – IT-Betrieb, Support, externe Dienstleister), hat damit potenziell Zugriff auf alle Mandantenbereiche gleichzeitig.
• Antwort-Archive, die generierte Antworten zu Nachweiszwecken speichern, unterliegen denselben Anforderungen wie die Ausgabe selbst.

Die praktische Konsequenz: Zugriffskontrolle, die nur auf die Vektordatenbank angewendet wird, aber Caches und Logs rollenunabhängig oder mit weiterem Zugriffskreis aufbewahrt, ist nur zur Hälfte umgesetzt. Wer eine Cache-Schicht einführt, sollte sie entweder pro Rolle beziehungsweise Mandant getrennt aufbauen oder – wenn das technisch zu aufwendig ist – auf das Caching bei mandantenübergreifend sensiblen Bereichen verzichten. Für Logs gilt: Zugriffskreis auf das gleiche Berechtigungsniveau begrenzen wie den Zugriff auf die Vektordatenbank, und Aufbewahrungsfristen so kurz wie mit den Debugging-Anforderungen vereinbar setzen.

Wie testet man Zugriffe?

Ein Berechtigungskonzept, das nie unter Realbedingungen getestet wurde, ist eine Annahme, keine Kontrolle. Getestet werden sollte auf zwei Ebenen:

1. Funktionale Zugriffstests. Für jede definierte Rolle: gezielte Testanfragen gegen Dokumente stellen, auf die diese Rolle keinen Zugriff haben soll, und prüfen, ob wirklich nichts aus dem gesperrten Bereich auftaucht – weder als zitierter Chunk, noch als Quellenangabe, noch indirekt in der formulierten Antwort. Diesen Test für jede Rollenkombination durchzuführen ist Aufwand, aber der einzige Weg, verdeckte Lücken zu finden – etwa einen zweiten Zugriffspfad, der den Filter umgeht (siehe oben), oder einen Namespace, der versehentlich zu breit konfiguriert ist.

2. Sicherheitstests im engeren Sinn. Das BSI empfiehlt für Unternehmen, die KI-Systeme entwickeln oder KI-Schnittstellen integrieren, eigene AI-Security-Tests wie AI Penetration Testing als festen Bestandteil vor dem Produktivbetrieb. Für RAG-Systeme heißt das zusätzlich, gezielt auf die für RAG-Subsysteme typischen Angriffsvektoren zu prüfen: Membership-Inference-Angriffe, bei denen versucht wird herauszufinden, ob ein bestimmtes Dokument Teil der Wissensbasis ist, und Data-Poisoning-Angriffe, bei denen manipulierte Inhalte in die Wissensbasis eingeschleust werden, um Antworten gezielt zu verfälschen.

Beide Testebenen gehören vor den Go-Live, nicht danach – ein Berechtigungsproblem, das im produktiven Betrieb entdeckt wird, ist bereits ein Vorfall.

Umsetzung: in vier Schritten zum Berechtigungskonzept

So gehe ich vor, wenn ein RAG-Vorhaben ein belastbares Zugriffskonzept braucht:

1. Bereiche vor dem Aufbau definieren. Wer braucht Zugriff auf welche Dokumentgruppen, aus welchem Grund? Diese Übung – nicht die Technik – ist der eigentliche Aufwand und sollte vor der ersten Zeile Code stehen.
2. Referenzdokumente mit Mandanten-/Bereichs-Tag versehen, bevor sie eingebettet werden. Aufteilung nach Abteilung, Kundenverhältnis oder Aktengruppe – je nach dem, was in der Bereichsdefinition aus Schritt 1 festgelegt wurde.
3. Rollen- und Bereichsfilter so nah wie möglich am Retriever implementieren, nicht in der Anwendungsoberfläche. Jeder zusätzliche Zugriffsweg auf die Vektordatenbank (Batch-Jobs, zweite Anwendungen, direkte API-Zugriffe) muss denselben Filter durchlaufen.
4. Caches, Logs und Antwort-Archive in dasselbe Berechtigungskonzept einbeziehen – entweder mit eigener Zugriffskontrolle oder mit reduziertem Personenkreis und kurzen Aufbewahrungsfristen. Danach: funktionale Zugriffstests für jede Rolle und, je nach Kritikalität der Daten, ergänzende Sicherheitstests vor dem Go-Live.

Wenn du dabei Unterstützung willst: Im Rahmen der KI-Beratung prüfe ich Berechtigungskonzepte für RAG-Vorhaben genau entlang dieser vier Schritte, und in den Schulungen lernt dein Team, Rollen- und Bereichsfilter danach selbst zu pflegen. Für eine erste Einschätzung reicht ein kurzes Erstgespräch.

Risikomatrix: Berechtigungsrisiken und Gegenmaßnahmen

Die folgende Matrix ist mein Arbeitswerkzeug, wenn ich Berechtigungskonzepte für RAG-Projekte in KMU durchgehe. Die Einstufungen sind bewusst qualitativ – sie ersetzen keine Einzelfallprüfung, sortieren aber die Priorisierung:

Risiko	Wo es entsteht	Typische Eintrittswahrscheinlichkeit	Schadenspotenzial	Wichtigste Gegenmaßnahme
Semantische Suche findet Treffer über Berechtigungsgrenzen hinweg	Retriever ohne Rollenfilter	Hoch, wenn kein Filter existiert	Hoch	Rollen-/Bereichsfilter direkt am Retriever, nicht in der Oberfläche
Zweiter Zugriffsweg umgeht den Filter	Batch-Jobs, zweite Anwendung, direkter API-Zugriff	Mittel	Hoch	Alle Zugriffswege auf die Vektordatenbank inventarisieren und denselben Filter erzwingen
Cache liefert Inhalte außerhalb der Berechtigung	Antwort-Cache	Mittel	Hoch	Cache pro Rolle/Mandant trennen oder bei sensiblen Bereichen auf Caching verzichten
Logs mit breiterem Zugriffskreis als die Anwendung	Prompt-/Antwort-Logging	Hoch (Standardfehler)	Mittel bis hoch	Zugriffskreis auf Logs an Vektordatenbank-Berechtigung angleichen, Aufbewahrung kurz halten
Veraltete Rollenzuweisung nach Funktionswechsel	Rollenverwaltung, Organisationswechsel	Hoch bei manueller Pflege	Mittel	Rollenzuweisung an bestehende Nutzerverwaltung koppeln, regelmäßig prüfen
Mandantentrennung nachträglich über bereits vermischte Datenbank gelegt	Konzeption/Migration	Mittel	Hoch	Trennung schon bei Dokumentaufbereitung vorsehen, nicht nachträglich filtern
Membership-Inference- oder Data-Poisoning-Angriff auf die Vektordatenbank	RAG-Subsystem	Niedrig	Mittel bis hoch	Nur vertrauenswürdige Dokumentquellen, kontrollierter Einspeiseprozess, gezielte Sicherheitstests
Fehlender Testnachweis für Rollenkombinationen	Vor Go-Live	Hoch, wenn kein Test existiert	Hoch	Funktionale Zugriffstests je Rolle vor Produktivbetrieb, AI-Security-Tests ergänzend

Von oben nach unten gelesen entscheiden die ersten drei Zeilen in den meisten KMU-Projekten darüber, ob das Berechtigungskonzept in der Praxis hält oder nur auf dem Papier existiert.

Grenzen und offene Punkte

Zur ehrlichen Einordnung gehört auch, was Berechtigungskonzepte in RAG-Systemen nicht leisten:

• Das Sprachmodell selbst bleibt außen vor. Alle beschriebenen Maßnahmen wirken im RAG-Subsystem – Referenzdokumente, Vektordatenbank, Retriever. Was das Sprachmodell aus seinem eigenen Training an Wissen mitbringt, lässt sich damit nicht steuern; dafür braucht es andere Maßnahmen wie restriktive Systemprompts und die Kontrolle darüber, welche personenbezogenen Daten überhaupt in ein Training einfließen dürfen.
• Feingranulare Filter erzeugen Komplexität. Je mehr Rollen und Bereiche ein System unterscheiden muss, desto pflegeintensiver wird die Zuordnung von Dokumenten, Chunks und Rollen – und desto größer das Risiko, dass eine Zuordnung veraltet oder eine neue Rolle beim Aufbau eines neuen Bereichs vergessen wird.
• Kein vollständiger Schutz gegen gezielte Angriffe. Membership-Inference- und Data-Poisoning-Angriffe auf das RAG-Subsystem lassen sich mindern, nicht vollständig ausschließen. Ein Berechtigungskonzept reduziert die Angriffsfläche, ersetzt aber kein laufendes Sicherheitsmonitoring.
• Bewegliche Grundlage. Die zitierten Orientierungshilfen der Datenschutzkonferenz sind Version 1.0 (Oktober 2025 beziehungsweise Juni 2025) und werden voraussichtlich weiterentwickelt. Plane eine regelmäßige Überprüfung deines Berechtigungskonzepts ein – bei diesem Artikel steht der nächste Review-Termin nach drei Monaten im Kalender.

Checkliste: Berechtigungen in RAG-Systemen aufsetzen

Zum Abhaken vor dem Start und vor dem Go-Live:

Vor dem Aufbau

• Bereiche/Mandanten definiert: Wer braucht Zugriff auf welche Dokumentgruppen?
• Rollenmodell entworfen und mit bestehender Nutzerverwaltung verknüpft
• Entscheidung getroffen: getrennte Vektordatenbanken, Namespaces oder Metadaten-Filterung

Beim Aufbau

• Referenzdokumente vor dem Embedding mit Mandanten-/Bereichs-Tag versehen
• Rollen-/Bereichsfilter direkt am Retriever implementiert, nicht nur in der Oberfläche
• Alle Zugriffswege auf die Vektordatenbank inventarisiert und mit demselben Filter versehen
• Caches, Prompt-Logs und Antwort-Archive in das Berechtigungskonzept einbezogen

Vor dem Go-Live

• Funktionale Zugriffstests für jede Rolle durchgeführt und dokumentiert
• AI-Security-Tests bei kritischen oder sensiblen Datenbeständen ergänzt
• Zugriffskreis auf Logs an das Berechtigungsniveau der Vektordatenbank angeglichen
• Prozess für Rollenänderungen (Funktionswechsel, Austritt) definiert
• Review-Termin für das Berechtigungskonzept eingeplant

Wenn du dein Berechtigungskonzept vor dem Go-Live einmal strukturiert prüfen lassen willst – genau dafür ist der Erstcheck da.