Berechtigungen in RAG-Systemen: Rollen, Mandanten und Dokumentzugriff

Das Wichtigste in Kürze: Wo Zugriffsrechte in RAG-Systemen geprüft werden müssen, wie rollenbasierte Filter und Mandantentrennung funktionieren, mit Risikomatrix.

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 passendsten Textabschnitt, egal ob die fragende Person ihn sehen darf.

Ein RAG-System ohne eigenes Zugriffskonzept macht so Dinge sichtbar, die vorher geschützt waren, etwa durch Ordner, Laufwerksrechte oder Aktenzugriffe.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen. Sie planen ein RAG-System oder betreiben bereits eines und wollen wissen, wo Berechtigungen technisch ansetzen müssen. Wie funktionieren rollenbasierte Filter und Mandantentrennung, und wo liegen die Grenzen dieser Maßnahmen? 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 6 Mechanismen setzen alle vor oder während des Retrievals an. Sie greifen also, bevor Chunks an das Sprachmodell übergeben werden. Im Sprachmodell selbst lässt sich laut Datenschutzkonferenz nicht steuern, welche Nutzenden auf welche Informationen Zugriff haben dürfen. 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. Er darf nur Chunks aus den für diese Rolle freigegebenen Bereichen zurückgeben. Er darf nicht erst die Antwort nachträglich filtern. Wird erst nach der Texterzeugung gefiltert, waren die unzulässigen Informationen schon Teil der Anfrage an das Sprachmodell. Sie stecken dann potenziell in der Antwort.

Diese 3 Prüfpunkte sind zugleich der zentrale Vorteil von RAG gegenüber reinem LLM-Einsatz. In der Vektordatenbank lässt sich steuern, wer auf welche Information zugreift. Im Sprachmodell geht das nicht. Berechtigungen sind bei RAG also nicht nur möglich, sondern der wichtigste Hebel für Vertraulichkeit im ganzen System.

Wie funktionieren rollenbasierte Filter?

Ein rollenbasierter Filter besteht aus 2 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: Hat die Person die richtige Rolle für diesen Zweck?

Manche Systeme werden mehrfach genutzt. Dieselbe Person fragt teils im HR-Kontext, teils im Vertriebskontext ab. Das ist dann kein einmaliges Setup, sondern eine laufende Verwaltungsaufgabe.

Abgleich beim Retrieval. Der Retriever erzeugt aus der Anfrage einen Vektor. Er durchsucht damit die Vektordatenbank nach den ähnlichsten Chunks. Dieser Schritt muss um einen Rollen- oder Bereichsfilter ergänzt werden.

Nur Chunks aus für die Rolle freigegebenen Bereichen kommen dann als Suchergebnis infrage. Technisch heißt das meist: Metadaten-Filterung auf Ebene der Vektordatenbank, kombiniert mit der Ähnlichkeitssuche. Nicht eine nachgelagerte 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. Manchmal entsteht ein zweiter Zugriffsweg auf die Vektordatenbank: ein Batch-Job, eine zweite Anwendung, ein direkter API-Zugriff. Dann 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 3 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. Manche Teams spielen heterogene Dokumente ungeprüft in eine gemeinsame Vektordatenbank ein und wollen die Trennung erst später ergänzen. Das 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. Diese müssen strikt auf den definierten Verarbeitungszweck beschränkt bleiben. Mandantentrennung ist damit nicht nur ein Zugriffsschutz. Sie ist 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 wie die Vektordatenbank selbst. Damit gelten dieselben Berechtigungsgrenzen.

Konkret bedeutet das für diese 3 Speicherarten:

• 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. Inhalte, 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. Der Zugriffskreis auf Logs ist oft breiter als auf die produktive Anwendung: IT-Betrieb, Support, externe Dienstleister. Damit besteht potenziell Zugriff auf alle Mandantenbereiche gleichzeitig.

• Antwort-Archive, die generierte Antworten zu Nachweiszwecken speichern, unterliegen denselben Anforderungen wie die Ausgabe selbst.

Die praktische Konsequenz: Wer die Zugriffskontrolle nur auf die Vektordatenbank anwendet, aber Caches und Logs rollenunabhängig aufbewahrt, hat sie 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. 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. Es ist 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. Etwa AI Penetration Testing als festen Bestandteil vor dem Produktivbetrieb. Für RAG-Systeme heißt das zusätzlich: gezielt auf typische Angriffsvektoren prüfen. Membership-Inference-Angriffe versuchen herauszufinden, ob ein bestimmtes Dokument Teil der Wissensbasis ist. Data-Poisoning-Angriffe schleusen manipulierte Inhalte in die Wissensbasis ein, 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 4 Schritte. 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 mit 8 Risiken 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. Hält das Berechtigungskonzept in der Praxis, oder existiert es nur auf dem Papier?

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: 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 wird das Risiko: eine Zuordnung veraltet, oder eine neue Rolle wird beim Aufbau eines neuen Bereichs vergessen.

• 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, in 3 Phasen:

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.