Interner Wissensassistent auf SharePoint-Daten: Was RAG leistet – und wo Berechtigungen brechen

Ein interner Wissensassistent beantwortet Mitarbeiterfragen aus Ihren eigenen SharePoint-Dokumenten, indem ein Sprachmodell zunächst die passenden Textausschnitte sucht (Retrieval) und daraus die Antwort formuliert (Generation) – das Prinzip heißt Retrieval-Augmented Generation, kurz RAG. Der technische Teil davon ist mit n8n gut dokumentiert und schnell gebaut; der Teil, der in Eigenbau-Projekten regelmäßig übersehen wird, ist die Frage, ob die Vektordatenbank beim Antworten noch weiß, wer überhaupt fragen darf.

Das unterscheidet ein RAG-Projekt von den beiden Kategorien, die wir an anderer Stelle bereits gegenübergestellt haben: Ein Chat-Assistent wie ChatGPT Business arbeitet ohne eigenen Datenbestand, ein RAG-Wissensassistent bringt genau diesen Datenbestand mit – und mit ihm eine Frage, die ein reiner Chat-Zugang nie stellen muss: Wer darf welchen Ausschnitt davon sehen?

Was RAG technisch macht

Eine RAG-Pipeline besteht laut n8n-Dokumentation aus vier Schritten, die beim Aufbau des Index einmal durchlaufen werden und beim Beantworten einer Frage ein zweites Mal in verkürzter Form: Ein Document Loader zieht die Ausgangsdokumente ein, ein Text Splitter zerlegt sie in Abschnitte, ein Embedding-Modell wandelt jeden Abschnitt in einen Vektor um, und eine Vektordatenbank speichert diese Vektoren durchsuchbar ab. Stellt jemand eine Frage, wird sie über dasselbe Embedding-Modell ebenfalls in einen Vektor verwandelt; die Datenbank liefert die inhaltlich ähnlichsten Abschnitte zurück, und das Sprachmodell formuliert aus diesen Abschnitten die Antwort.

Für SharePoint als Quelle heißt das konkret: n8n zieht die Dateien über den SharePoint-Node oder die Microsoft-Graph-Schnittstelle ein – dieselbe Anbindung, die wir in unserem Beitrag zur Entra-ID-Anmeldung und dem Zugriff auf Outlook, Teams und SharePoint beschrieben haben –, reicht sie an den Data-Loader-Knoten weiter und legt die entstehenden Vektoren in einer angeschlossenen Datenbank ab, etwa Pinecone, Qdrant oder Supabase. Ein Beispiel aus der n8n-Community zeigt, wie ein solcher Aufbau aussehen kann: Ein Workflow listet täglich alle Dateien eines SharePoint-Ordners samt Unterordnern auf, lädt sie herunter und befüllt darüber die Vektordatenbank neu – einmal eingerichtet, läuft der Abgleich automatisch.

Wie Microsoft 365 Copilot das Berechtigungsproblem löst – und warum das nicht automatisch mitkommt

Microsoft 365 Copilot steht vor demselben Grundproblem und löst es auf eine bestimmte Weise: Laut der offiziellen Copilot-Connectors-Dokumentation zeigen Suche und Copilot einer Person nur Inhalte, für die im Quellsystem bereits eine Berechtigung besteht – jeder indexierte Eintrag trägt eine eigene Zugriffsliste, und diese wird bei jeder Anfrage neu geprüft. Copilot erweitert also keine Zugriffsrechte; es zeigt, was die fragende Person ohnehin schon sehen dürfte.

Das ist der Punkt, den ein selbst gebautes RAG-Projekt mit n8n nicht automatisch erbt: Eine Vektordatenbank speichert – wie oben beschrieben – Inhalte und ihre Vektoren für die Ähnlichkeitssuche, aber ohne zusätzliche Vorkehrung keine Information darüber, wer im Ursprungssystem darauf zugreifen durfte. Wie sich das für ein konkretes Produkt schließen lässt, beschreibt eine technische Analyse der Databricks-Community am Beispiel der eigenen Vektorsuche Mosaic AI Vector Search: Erst ein zusätzliches Metadatenfeld mit der Zugriffsliste und ein Filter beim Abruf stellen sicher, dass eine Anfrage nur die Abschnitte zurückbekommt, für die die fragende Person auch im Quellsystem berechtigt wäre.

Wo der Bruch in einer selbst gebauten Pipeline konkret entsteht

Im oben beschriebenen Aufbau liest ein n8n-Workflow die Dateien eines Ordners über einen einzigen, im Workflow hinterlegten Zugang aus und befüllt damit die Vektordatenbank – ein n8n-Node arbeitet grundsätzlich mit genau einem ausgewählten Zugang, nicht mit den wechselnden Rechten der späteren Fragestellenden. Jeder Abschnitt bekommt dabei zwar seinen Inhalt, aber keine Information darüber, wer im Ursprungssystem darauf zugreifen durfte. Bei der Abfrage zählt für die Vektordatenbank ausschließlich die inhaltliche Ähnlichkeit zur gestellten Frage. Eine Werkstudentin, die nach der Urlaubsregelung fragt, und ein Geschäftsführer, der nach denselben Stichworten sucht, bekommen aus einem so aufgebauten Index dieselben Treffer – auch wenn einer der beiden in SharePoint selbst nie Zugriff auf die zugrunde liegende Bibliothek hätte.

Ein zweiter, leiser Bruch kommt hinzu: Ein Beitrag aus dem Microsoft-eigenen ISE-Entwicklerblog zu genau diesem Thema hält fest, dass sich eine Berechtigungsänderung in SharePoint nicht von selbst auf einen bereits befüllten Such- oder RAG-Index auswirkt. Wird einer Mitarbeiterin der Zugriff auf ein Dokument entzogen, bleibt der zuvor indexierte Inhalt bestehen, bis ein erneuter Abgleich oder eine erneute Indexierung ihn entfernt. Der Assistent kennt in der Zwischenzeit den alten Stand, nicht den aktuellen.

Zwei Wege, die Prüfung nachzubauen

Der erste Ansatzpunkt liegt schon beim Einlesen: Wer die Anbindung enger schneidet, verhindert, dass zu viel überhaupt in den Index gelangt. In unserem Beitrag zur Microsoft-365-Anbindung beschreiben wir, wie sich der SharePoint-Zugriff über Sites.Selected auf einzelne Sites begrenzen lässt, statt eine breite Leseberechtigung über den gesamten Tenant zu erteilen – dasselbe Prinzip gilt für eine RAG-Pipeline, nur dass hier nicht ein Workflow, sondern der gesamte künftige Index von diesem Zuschnitt abhängt. Eine Bibliothek, die der Ingest-Zugang gar nicht sieht, kann später auch niemand fälschlich über den Assistenten herausbekommen.

Das löst aber nur den Teil des Problems, der vor dem Indexieren liegt. Für den Teil danach – mehrere Personen mit unterschiedlichen Berechtigungen fragen denselben Index ab – braucht es eine Prüfung beim Abruf selbst. Microsoft beschreibt für die eigene Suchplattform Azure AI Search ein Verfahren dafür: Jeder indexierte Abschnitt trägt eine Berechtigungsliste in Form von Entra-ID-Objekt-IDs als Metadatenfeld, und jede Abfrage wird zusätzlich nach den Objekt-IDs der anfragenden Person gefiltert, bevor ein Ergebnis zurückkommt. Übertragen auf eine n8n-Pipeline heißt das konkret: Beim Einlesen eines Dokuments wird dessen SharePoint-Berechtigungsliste als zusätzliches Feld mit in der Vektordatenbank abgelegt; bevor eine Antwort an das Sprachmodell geht, filtert ein zusätzlicher Schritt im Workflow die gefundenen Abschnitte gegen die Identität der fragenden Person. Metadatenfilter beim Abruf sind dafür das Werkzeug – dieselbe Technik, die Microsoft für Azure AI Search beschreibt. Automatisch eingebaut ist sie in einer n8n-Pipeline deshalb noch nicht, gebaut werden muss sie in jedem Fall selbst.

Für den Mittelstand heißt das

Prüfen Sie vor dem ersten produktiven Einsatz drei Dinge an Ihrer eigenen Pipeline: Läuft der Ingest-Workflow mit einem einzelnen, breiten Zugang, der mehr sieht als jede einzelne Nutzerin und jeder einzelne Nutzer später sehen darf? Filtert die Abfrage nur nach inhaltlicher Ähnlichkeit, oder zusätzlich nach der Identität der fragenden Person? Und würde ein entzogener SharePoint-Zugriff im Assistenten sofort verschwinden, oder erst beim nächsten geplanten Durchlauf?

Ein interner Wissensassistent, der jede Frage aus dem gesamten indexierten Bestand beantwortet, wirkt in unseren Projekten in den ersten Wochen zunächst eindrucksvoller als einer mit sauberer Zugriffsprüfung – bis zum ersten Mal, in dem er auch das beantwortet, was er nicht hätte beantworten sollen. In unseren Projekten ist die Abrufprüfung deshalb kein Ausbauschritt für später, sondern Teil des ersten funktionierenden Workflows, bevor mehr als eine Testperson mit unterschiedlichen Rechten darauf zugreift. Wie ein erster n8n-Workflow generell Schritt für Schritt aufgebaut wird, beschreibt unser Leitfaden zur n8n-Einführung im Detail.

FAQ

Was ist RAG, und was hat das mit einem internen Wissensassistenten zu tun?

RAG steht für Retrieval-Augmented Generation: Statt aus seinem Trainingswissen zu antworten, sucht ein Sprachmodell zuerst die passenden Textausschnitte aus Ihren eigenen Dokumenten und formuliert die Antwort daraus. Ein interner Wissensassistent auf SharePoint-Daten ist eine konkrete Anwendung davon – die Dokumente, aus denen gesucht wird, liegen in Ihren SharePoint-Bibliotheken.

Ist das dasselbe Berechtigungsmodell wie bei Microsoft 365 Copilot?

Nein. Jeder von Copilot durchsuchte Eintrag trägt laut Microsoft eine eigene, aus dem Quellsystem übernommene Zugriffsliste, die bei der Anfrage geprüft wird – eine Person sieht nur, wofür sie dort bereits berechtigt ist. Eine selbst gebaute RAG-Pipeline mit n8n und einer Vektordatenbank hat diesen Mechanismus nicht von Haus aus – er muss eigens eingebaut werden.

Warum reicht es nicht, nur den Ingest-Zugang einzuschränken?

Ein eng geschnittener Ingest-Zugang verhindert, dass zu viel überhaupt indexiert wird – das ist die halbe Miete. Er sagt aber nichts darüber, wer aus dem bereits indexierten Bestand welche Antwort bekommt. Dafür braucht es zusätzlich eine Prüfung beim Abruf, die die anfragende Person gegen die ursprüngliche Berechtigung des jeweiligen Dokuments abgleicht.

Was passiert, wenn einer Mitarbeiterin der Zugriff auf ein Dokument entzogen wird?

In der Vektordatenbank bleibt der bereits indexierte Inhalt zunächst unverändert bestehen – die Berechtigungsänderung wirkt sich nicht von selbst auf einen zuvor befüllten Index aus. Erst ein erneuter Abgleich oder eine erneute Indexierung entfernt den Inhalt beziehungsweise aktualisiert die hinterlegte Berechtigung.

Reicht es, nur unkritische Dokumente zu indexieren?

Als Ausgangspunkt ja, solange klar definiert ist, was „unkritisch“ heißt und wer das entscheidet. Das verkleinert den möglichen Schaden, löst aber nicht das eigentliche Problem: Sobald auch nur eine Bibliothek mit gestuften Berechtigungen dazukommt, brauchen Sie die Abrufprüfung ohnehin.