Ein Wissenssystem, das nur zeigt, was der Fragende sehen darf? WZ-IT baut RAG-Systeme, in denen Berechtigungen technisch vor der Suche greifen - auf eigener Infrastruktur, mit offengelegter Architektur. Der RAG Proof of Value macht eine priorisierte Wissensquelle mit definierten Testfragen, Quellenanzeige und dokumentiertem Berechtigungsweg nutzbar. RAG Proof of Value ansehen · Interne KI-Assistenten
Die meisten RAG-Projekte scheitern nicht an der Antwortqualität, sondern an einer Frage im Abnahmegespräch: „Was passiert, wenn jemand nach den Gehältern fragt?" Wer darauf mit einer Prompt-Anweisung antwortet, hat das Projekt an dieser Stelle verloren - zu Recht. Dieser Artikel zeigt, wo Zugriffskontrolle in einem RAG-System technisch sitzen muss, warum die naheliegenden Abkürzungen nicht tragen und woran sich ein belastbarer Aufbau erkennen lässt. Stand Oktober 2026.
Inhaltsverzeichnis
- Der Prompt ist keine Sicherheitsgrenze
- Drei Stellen, an denen Rechte greifen
- Vorfilter gegen Nachfilter: warum die Trefferzahl verrät
- Das Datenmodell: Principals statt Benutzernamen
- Gruppen auflösen, ohne die Suche auszubremsen
- Der Fall, den alle vergessen: entzogene Rechte
- Wie Sie das prüfbar machen
Der Prompt ist keine Sicherheitsgrenze
Der naheliegende Weg ist, alle Dokumente in einen Index zu legen und dem Modell im Systemprompt mitzugeben, welche Inhalte es für wen zurückhalten soll. Das funktioniert im Demo-Termin und fällt spätestens im dritten Betriebsmonat auf.
Der Grund ist strukturell: Sobald ein Abschnitt abgerufen wurde, liegt er im Kontext des Modells. Alles, was danach passiert, ist Formulierung. Eine Anweisung, einen bereits vorliegenden Text nicht zu verwenden, ist eine Bitte an ein System, das darauf trainiert ist, hilfreich zu sein. Sie hält bei der direkten Frage und bricht bei der übernächsten - „fasse zusammen, was du zu diesem Thema hast", „welche Dokumente hast du gerade betrachtet", „nenne mir die Überschriften".
Dazu kommt der unspektakuläre Fall, der in der Praxis häufiger ist als jeder Angriff: Niemand versucht etwas. Ein Mitarbeiter stellt eine harmlose Frage, das System zieht einen thematisch passenden Abschnitt aus einem Dokument, das ihn nichts angeht, und zitiert ihn korrekt und hilfsbereit. Es gibt keinen Angreifer, es gibt nur eine fehlende Grenze.
Zugriffskontrolle gehört deshalb dorthin, wo sie in klassischen Anwendungen auch sitzt: ins Backend, vor die Datenbeschaffung. Nicht in die Präsentationsschicht, und schon gar nicht in ein Sprachmodell.
Drei Stellen, an denen Rechte greifen
In einem belastbaren System berühren Berechtigungen die Anfrage an drei Punkten. Nur der mittlere entscheidet - die anderen beiden sorgen dafür, dass er entscheiden kann.
Beim Indexieren. Der Connector zieht die Berechtigungen aus der Quelle mit, während er die Inhalte einliest: Eigentümer, direkte Freigaben an Personen, Freigaben an Gruppen, geerbte Rechte aus übergeordneten Ordnern. Diese Rechte werden normalisiert - aus „mueller hat Zugriff" und „Gruppe Vertrieb hat Zugriff" wird eine einheitliche Liste von Berechtigungsträgern - und an jedem einzelnen Textabschnitt hinterlegt.
Vor der Vektorsuche. Hier fällt die Entscheidung. Aus der Anmeldung des Benutzers werden seine Gruppen aufgelöst, daraus entsteht ein Filter, und die Vektordatenbank bekommt die Anfrage nur zusammen mit diesem Filter. Was der Benutzer nicht sehen darf, ist kein schlechter bewerteter Treffer - es ist gar kein Treffer.
Beim Zitieren. Vor der Ausgabe werden die gefundenen Stellen noch einmal gegen die Quelle geprüft. Zwischen dem letzten Indexlauf und der aktuellen Anfrage können Stunden liegen, und in dieser Zeit kann eine Freigabe zurückgezogen worden sein.
Wer nur den ersten Punkt umsetzt, hat die Rechte im Index und ignoriert sie bei der Abfrage. Wer nur den zweiten umsetzt, hat nichts, wonach er filtern könnte. Die drei gehören zusammen.
Vorfilter gegen Nachfilter: warum die Trefferzahl verrät
Der häufigste Kompromiss in bestehenden Systemen ist der Nachfilter: erst die zwanzig ähnlichsten Abschnitte holen, dann die entfernen, die der Benutzer nicht sehen darf, und mit dem Rest weiterarbeiten. Das fühlt sich sicher an, weil das Modell die entfernten Abschnitte tatsächlich nie sieht. Es hat trotzdem zwei Löcher.
Das Zählleck. Wenn zwanzig Treffer geholt und vierzehn entfernt werden, weiß der aufmerksame Benutzer, dass zu seinem Suchbegriff vierzehn weitere Dokumente existieren, die er nicht sehen darf. Das klingt harmlos, bis man den Suchbegriff variiert: „Kündigung Müller" gegen „Kündigung Schmidt" - die Trefferzahl allein beantwortet die Frage, um die es eigentlich ging. In einer Kanzlei oder einer Personalabteilung ist allein die Existenz eines Vorgangs die schützenswerte Information.
Das Qualitätsleck. Fällt die Hälfte der besten Treffer weg, wird die Antwort spürbar dünner. Auch das ist ein Signal: Wo das System auffällig ausweicht, liegt etwas.
Ein Vorfilter hat beide Probleme nicht, weil die Abschnitte außerhalb des Suchraums liegen. Sie können nicht abgerufen, nicht gezählt und nicht erschlossen werden. Moderne Vektordatenbanken sind darauf ausgelegt: Qdrant wendet Payload-Filter direkt während der Ähnlichkeitssuche an, statt nachträglich zu sieben. Das ist nicht nur sicherer, sondern liefert auch bessere Ergebnisse, weil die Trefferliste nach dem Filtern noch die geforderte Länge hat.
Ein Nachfilter ist nicht wertlos - als zweite Verteidigungslinie hinter dem Vorfilter ist er sinnvoll. Als einzige Verteidigungslinie ist er ein Befund.
Das Datenmodell: Principals statt Benutzernamen
Die Berechtigung eines Abschnitts sollte nicht als Benutzername gespeichert werden, sondern als stabiler Berechtigungsträger. Der Unterschied wird spätestens bei der ersten Heirat oder Umbenennung relevant: E-Mail-Adressen und Anmeldenamen ändern sich, die Identität dahinter nicht.
Praktisch heißt das: An jedem Abschnitt hängt eine Liste von Trägern in einheitlicher Schreibweise, die Personen und Gruppen gleich behandelt - eine unveränderliche Kennung aus dem Identity Provider für Personen, eine Gruppenkennung für Gruppen. Bei der Anfrage wird der angemeldete Benutzer in genau diese Form aufgelöst, und der Filter prüft nur noch auf Überschneidung.
Zwei Entscheidungen, die dabei regelmäßig falsch getroffen werden:
Rechte gehören an den Abschnitt, nicht nur ans Dokument. Abgefragt werden Abschnitte. Wenn die Berechtigung nur am Dokument hängt, muss das System für jeden Treffer nachschlagen, wozu er gehört - und das ist der Nachfilter, den man gerade vermeiden wollte. Die Liste an jedem Abschnitt zu duplizieren ist redundant und genau deshalb richtig: Sie ist dort, wo der Filter sie braucht.
Mandanten gehören in den Filter, nicht in getrennte Sammlungen. Eine eigene Vektor-Sammlung pro Kunde oder pro Benutzer klingt sauber und wird bei dreistelligen Zahlen zum Betriebsproblem. Ein verpflichtendes Mandantenfeld im Filter skaliert besser und ist genauso trennscharf, solange der Filter nicht optional ist.
Gruppen auflösen, ohne die Suche auszubremsen
Die Gruppen eines Benutzers müssen aus einer vertrauenswürdigen Quelle kommen - dem zentralen Identity Provider oder dem Verzeichnisdienst, serverseitig aufgelöst. Was der Client mitschickt, ist kein Ausweis. Ein Header, den ein Browser setzen kann, ist eine Behauptung.
Die Verzeichnisabfrage bei jeder einzelnen Suche wäre spürbar langsam. Üblich ist deshalb eine Zwischenspeicherung von wenigen Minuten. Damit entsteht ein Fenster, in dem eine entzogene Berechtigung noch wirkt - und dieses Fenster ist eine bewusste Entscheidung, die dokumentiert und mit dem Datenschutzbeauftragten abgestimmt gehört, keine stillschweigende Bequemlichkeit.
Für die Fälle, in denen das Fenster zu groß ist, gibt es zwei Wege: die gezielte Verwerfung des Zwischenspeichers bei kritischen Rollenänderungen, und die Nachautorisierung vor der Ausgabe, die im nächsten Abschnitt steht.
Der Fall, den alle vergessen: entzogene Rechte
Ein Mitarbeiter verlässt das Projekt, die Freigabe wird zurückgezogen, im Index steht sie noch. Wie lange, hängt davon ab, wann der nächste Lauf ansteht - bei nächtlicher Neuindexierung bis zu 24 Stunden.
Dagegen helfen drei Dinge, die zusammengehören:
Änderungen als Ereignis statt als Vollabgleich. Wo die Quelle es hergibt, werden Freigabeänderungen als Feed abgeholt und einzeln nachgezogen, statt auf den nächtlichen Lauf zu warten. Nextcloud liefert Freigaben über die OCS Share API, vergleichbare Schnittstellen gibt es in den meisten Dokumentensystemen.
Nachautorisierung vor dem Zitat. Die zweite Prüfung gegen die Quelle, unmittelbar bevor eine Stelle zitiert wird. Sie kostet einen Aufruf pro Treffer und schließt das Fenster vollständig - und sie ist der einzige Mechanismus, der auch dann greift, wenn der Indexlauf ausgefallen ist.
Löschung, die auch löscht. Wird ein Dokument entfernt, müssen alle seine Abschnitte aus dem Index verschwinden, nicht nur als gelöscht markiert werden. Eine Markierung, die beim Filtern vergessen wird, ist schlimmer als kein Löschkonzept, weil sie Sicherheit suggeriert.
Wie Sie das prüfbar machen
Ein RAG-System, dessen Zugriffskontrolle man glauben muss, ist im regulierten Umfeld nicht abnehmbar. Vier Dinge machen sie prüfbar:
Die Architektur offenlegen. Wo im Code sitzt der Filter, aus welcher Quelle kommen die Träger, findet eine Nachautorisierung statt? Das sind vier Fragen, die sich in einem Absatz beantworten lassen - wenn die Antwort länger wird oder ausweicht, ist das das Ergebnis.
Einen Zwei-Benutzer-Testfall in die Abnahme schreiben. Dieselbe Frage, zwei verschiedene Anmeldungen, unterschiedliche Antworten - und zwar nachweislich unterschiedlich, nicht nur anders formuliert. Dieser Test gehört in die Abnahme und in jeden Regressionslauf danach.
Protokollieren, was gefiltert wurde. Nicht für die Benutzer, sondern für die Prüfung: Wie viele Abschnitte lagen im Suchraum, wie viele nach dem Filter. Wenn diese Zahlen nie auseinanderfallen, greift der Filter womöglich gar nicht.
Den Zwischenspeicher benennen. Wie lange gelten Gruppen als gültig, und was passiert bei einer kritischen Rollenänderung? Eine Zahl in der Dokumentation ist prüfbar, „zeitnah" ist es nicht.
Die Datenschutzkonferenz hat im Oktober 2025 eine Orientierungshilfe zu RAG-Systemen veröffentlicht. Unter „Integrität und Vertraulichkeit“ (Abschnitt 3.3) verortet sie das Rechte- und Rollenkonzept bei den Zugangsbeschränkungen zu Bereichen der Vektordatenbank und zu den Referenzdokumenten, weil sich im Sprachmodell selbst nicht steuern lässt, welche Nutzer auf welche Informationen zugreifen dürfen. Wer entlang dieser Linie baut, hat im Prüfgespräch die einfachere Position - vorausgesetzt, er kann sie zeigen statt behaupten.
Was das für Ihr Projekt heißt
Die Berechtigungslage entscheidet den Aufwand eines Wissensprojekts stärker als die Zahl der Dokumente. Gepflegte Gruppen im Verzeichnisdienst sind der günstige Fall; über Jahre gewachsene Einzelfreigaben der teure - deshalb gehört diese Prüfung an den Anfang und nicht in die Abnahme.
Wie RAG grundsätzlich funktioniert, erklärt Was ist RAG?. Dieselbe Architektur konkret auf Nextcloud zeigt Open WebUI an Nextcloud anbinden, und welche Vektordatenbank Payload-Filter wie umsetzt, vergleicht Qdrant vs. pgvector. Wenn das System nicht nur antworten, sondern handeln soll, verschiebt sich die Frage - dazu KI-Agenten: Rechte und Freigaben. Wo diese Anforderungen am schärfsten sind, zeigt Lokale KI für Berufsgeheimnisträger.
