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

Ein interner Wissensassistent beantwortet Mitarbeiterfragen aus Ihren eigenen SharePoint-Dokumenten, indem zuerst eine Suche die passenden Textausschnitte findet (Retrieval) und ein Sprachmodell daraus die Antwort formuliert (Generation); das Prinzip heißt Retrieval-Augmented Generation, kurz RAG. Die SharePoint-Berechtigungen kommen dabei nicht von selbst mit: Eine Vektordatenbank findet ähnliche Abschnitte, prüft aber nicht, ob die fragende Person das Quelldokument öffnen dürfte.

Das unterscheidet einen selbst gebauten RAG-Wissensassistenten von einem fertigen Chat-Assistenten: Beim Eigenbau liegen Datenbestand und Zugriffsprüfung in Ihrer eigenen Verantwortung. Dieser Beitrag zeigt, an welcher Stelle die Berechtigung verloren geht, wie ein n8n-Workflow sie aus Microsoft Graph ausliest und worin sich der Eigenbau von Azure AI Search und einem Copilot-Agenten unterscheidet. Grundlage ist die Herstellerdokumentation von Microsoft und n8n, abgeglichen am 27. September 2026.

Was RAG technisch macht

Die n8n-Dokumentation beschreibt den Aufbau so: Vorgelagerte Nodes holen die Ausgangsdaten, ein Default Data Loader zerlegt sie mit einem Text Splitter in Abschnitte, ein Embedding-Modell wandelt jeden Abschnitt in einen Vektor um, und ein Vector-Store-Node legt diese Vektoren in einer Vektordatenbank durchsuchbar ab. Für die Abfrage kommt dasselbe Embedding-Modell zum Einsatz, das beim Einfügen verwendet wurde; 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: n8n holt die Dateien über den Microsoft-SharePoint-Node oder über HTTP-Request-Nodes direkt aus Microsoft Graph. Die Anmeldung dafür beschreibt unser Beitrag zur Entra-ID-Anmeldung und dem Zugriff auf Outlook, Teams und SharePoint. Neu hinzugefügte SharePoint-Nodes arbeiten laut n8n-Dokumentation ab n8n 2.37.0 in Version 2 über Microsoft Graph und bieten für Dateien die Operationen Download, Update und Upload (Doku-Stand 25. September 2026). Die heruntergeladenen Dateien gehen an den Data Loader, die Vektoren landen in einer angeschlossenen Vektordatenbank; n8n hat dafür unter anderem Vector-Store-Nodes für Pinecone, Qdrant und Supabase.

Wie Microsoft 365 Copilot mit Berechtigungen umgeht – und warum das nicht automatisch mitkommt

Microsoft 365 Copilot steht vor demselben Grundproblem und löst es über das Berechtigungsmodell von Microsoft 365: Laut Microsofts Dokumentation zu Datenschutz und Sicherheit von Copilot zeigt Copilot jeder Person nur Daten, auf die sie mit denselben Zugriffskontrollen wie in den übrigen Microsoft-365-Diensten zugreifen darf; Agenten verleihen laut derselben Seite keine neuen Berechtigungen (Seite vom 18. Juni 2026). Copilot erweitert also keine Zugriffsrechte. Im Umkehrschluss werden zu weit gefasste Freigaben in SharePoint standardmäßig genauso auffindbar wie korrekte; Microsofts Datenschutzseite zu Copilot rät deshalb, die Berechtigungsmodelle etwa in SharePoint so zu nutzen, dass die richtigen Personen die richtigen Inhalte sehen.

Ein selbst gebautes RAG-Projekt mit n8n erbt das nicht. Eine Vektordatenbank speichert Inhalte und ihre Vektoren für die Ähnlichkeitssuche; wer im Ursprungssystem zugreifen durfte, steht nur darin, wenn Sie es beim Einfügen als Metadaten mitgeben. Die n8n-Dokumentation sieht solche Metadaten je Abschnitt als optionalen Schritt vor, ausdrücklich für späteres Filtern. Genau diesen optionalen Schritt braucht ein Wissensassistent mit gestuften Rechten.

Wo der Bruch in einer selbst gebauten Pipeline konkret entsteht

Im oben beschriebenen Aufbau liest ein n8n-Workflow die Dateien mit der Credential, die im Node ausgewählt ist: entweder als angemeldete Person oder als App-Registrierung ohne Benutzer, nicht mit den Rechten der späteren Fragestellenden. Jeder Abschnitt bekommt seinen Inhalt, aber ohne zusätzlichen Schritt keine Information darüber, wer im Ursprungssystem darauf zugreifen durfte. Ohne Metadatenfilter zählt bei der Abfrage nur die inhaltliche Ähnlichkeit zur gestellten Frage. Fragen eine Werkstudentin und ein Geschäftsführer mit denselben Stichworten nach der Urlaubsregelung, bekommen beide aus einem so aufgebauten Index dieselben Treffer, auch wenn eine der beiden Personen in SharePoint selbst keinen Zugriff auf die zugrunde liegende Bibliothek hätte.

Ein zweiter, leiser Bruch kommt hinzu: Eine Berechtigungsänderung in SharePoint wirkt sich nicht von selbst auf einen bereits befüllten Index aus. Microsofts Dokumentation zu Azure AI Search hält für selbst befüllte Indizes fest, dass die betroffenen Dokumente neu eingelesen werden müssen; für den eigenen SharePoint-Indexer warnt sie, dass ein Index ohne Aktualisierung veraltete Berechtigungen ausliefert. Für einen n8n-Eigenbau gilt dasselbe Prinzip: Wird einer Mitarbeiterin der Zugriff auf ein Dokument entzogen, kennt der Assistent bis zum nächsten Abgleich den alten Stand.

So kommt die Berechtigung in den Index

Der erste Ansatzpunkt liegt 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. Für eine RAG-Pipeline gilt dasselbe Prinzip, nur hängt hier der gesamte künftige Index von diesem Zuschnitt ab. Eine Site, die der Ingest-Zugang nicht sieht, kann später auch niemand über den Assistenten herausbekommen.

Für den Teil danach, wenn mehrere Personen mit unterschiedlichen Rechten denselben Index abfragen, braucht der Eigenbau vier Schritte. Die Aufrufe stammen aus der Microsoft-Graph-Dokumentation:

1. Berechtigungen je Datei abrufen. GET /sites/{site-id}/drive/items/{item-id}/permissions (oder dieselbe Anfrage über /drives/{drive-id}/items/{item-id}/permissions) liefert die wirksamen Freigaben einer Datei, laut Graph-Dokumentation sowohl direkt vergebene als auch von übergeordneten Ordnern geerbte. Die Berechtigungen lassen sich nicht beim Abruf der Datei mitladen; es ist ein eigener Aufruf je Datei. Als niedrigste Anwendungsberechtigung nennt die Dokumentation Files.Read.All, Sites.Selected steht in dieser Tabelle nicht. Zwei Dinge prüfen Sie deshalb am ersten Testdokument: ob der Aufruf mit Ihrem eng geschnittenen Ingest-Zugang überhaupt funktioniert, und ob die Liste vollständig ist. Laut Graph-Dokumentation erhalten nur Eigentümer und Miteigentümer eines Elements alle Freigaben, andere Aufrufer nur die, die sie selbst betreffen.
2. Einträge nach Art trennen. Jeder Eintrag nennt in grantedToV2 (bei Freigabelinks in grantedToIdentitiesV2), wem eine Rolle wie read, write oder owner zusteht: user für eine Person, group für eine Gruppe, siteUser sowie siteGroup oder sharePointGroup für SharePoint-eigene Identitäten. Die ID einer siteGroup ist laut Graph-Dokumentation nur innerhalb ihrer Site eindeutig; speichern Sie sie deshalb zusammen mit der Site. Die ID einer sharePointGroup ist dagegen global eindeutig, die Doku empfiehlt sie statt siteGroup, wenn sie vorhanden ist. Die ID einer SharePoint-Identität kann eine Entra-ID oder eine SharePoint-ID sein. Welche Sie bekommen, sehen Sie am Testdokument. Einträge mit einem link-Facet sind Freigabelinks; legen Sie vor dem Bau fest, wie der Assistent sie behandelt.
3. Gruppen auflösen. Für Entra-Gruppen, also Sicherheitsgruppen und Microsoft-365-Gruppen, genügt es, die Gruppen-ID am Abschnitt zu speichern und bei der Abfrage die Gruppen der fragenden Person nachzuschlagen: GET /users/{id}/transitiveMemberOf liefert direkte und verschachtelte Mitgliedschaften, als Anwendungsberechtigung genügt laut Graph-Dokumentation User.Read.All. SharePoint-Websitegruppen (Besitzer, Mitglieder, Besucher und selbst angelegte Gruppen einer Site) sind dagegen keine Entra-Gruppen. Die Graph-Referenz v1.0 beschreibt Gruppen samt Mitgliederliste nur für SharePoint-Embedded-Container, nicht für gewöhnliche SharePoint-Sites (Stand der Graph-Dokumentation 27. August 2026). Für diese Gruppen braucht ein Eigenbau also einen eigenen Auflösungsweg; Azure AI Search nutzt dafür die SharePoint-REST-API.
4. Änderungen erkennen. Die Delta-Abfrage auf eine Bibliothek (GET /drives/{drive-id}/root/delta) meldet geänderte Elemente. Mit dem Header Prefer: deltashowremovedasdeleted, deltatraversepermissiongaps, deltashowsharingchanges kennzeichnet Graph die Elemente, die wegen einer Berechtigungsänderung in der Antwort stehen. Für die korrekte Verarbeitung von Berechtigungen verlangt die Graph-Dokumentation an dieser Stelle Sites.FullControl.All, deutlich mehr als ein Leserecht. Die Abwägung gehört vor den Bau: regelmäßiger vollständiger Neuabgleich mit schmalem Zugang oder gezielter Abgleich über Delta mit Vollzugriff.

Was n8n dafür mitbringt: Die Operationsliste des SharePoint-Nodes enthält weder Berechtigungen noch Delta-Abfragen. Die Aufrufe laufen deshalb über HTTP-Request-Nodes. Laut n8n-Dokumentation lässt sich dort eine bereits angelegte Credential als „Predefined Credential Type“ wiederverwenden; prüfen Sie im Node, ob Ihre Microsoft-Credential in der Auswahl erscheint und ob die App-Registrierung die oben genannten Berechtigungen hat.

Beim Abfragen gilt dann: Jeder Abschnitt trägt die Berechtigungsliste seines Dokuments als Metadatenfeld, und die Suche selbst wird auf die Abschnitte beschränkt, die die fragende Person oder eine ihrer Gruppen sehen darf. Filtert man erst die fertigen Treffer, bleiben im ungünstigen Fall keine übrig. Prüfen Sie dabei, ob der Filter Ihres Vector-Store-Nodes „Person oder eine ihrer Gruppen“ abbilden kann. Der Qdrant-Node etwa nimmt den Filter laut Quellcode (n8n, Stand 27. September 2026) als JSON in der Qdrant-Syntax entgegen (Option „Search Filter“); mit should verknüpfen Sie Bedingungen laut Qdrant-Dokumentation mit ODER, mit must mit UND. Die n8n-Dokumentation beschreibt dort noch einen allgemeinen Metadatenfilter als UND-Abfrage, bei dem alle Filterfelder zutreffen müssen; prüfen Sie im Node, welche Variante Ihre Version zeigt, und testen Sie den Filter vor dem Bau. Die Identität der fragenden Person muss der Workflow dafür kennen; ein offener Chat ohne Anmeldung kann nicht filtern.

Drei Wege im Vergleich

Neben dem Eigenbau bietet Microsoft unter anderem zwei fertige Wege, bei denen die Berechtigungsprüfung eingebaut ist; die Tabelle stellt diese beiden dem Eigenbau gegenüber. Die folgende Gegenüberstellung beruht auf einem Abgleich der Dokumentationen von Microsoft Graph, Azure AI Search, Microsoft 365 Copilot und n8n am 27. September 2026. Preise sind bewusst nicht enthalten.

	Eigenbau mit n8n	Azure AI Search mit SharePoint-Indexer	Copilot-Agent mit SharePoint als Wissensquelle
Wer prüft beim Abruf die Berechtigung?	Ihr Workflow, über einen selbst gebauten Metadatenfilter	der Suchdienst, anhand des Tokens der fragenden Person	Microsoft 365, anhand der bestehenden Berechtigungen
Entra-Gruppen	selbst auflösen (transitiveMemberOf)	bei der Abfrage über Microsoft Graph aufgelöst, verschachtelte Mitgliedschaften eingeschlossen	laut Doku: bestehende Berechtigungen werden beachtet
SharePoint-Websitegruppen	selbst auflösen, eigener Weg nötig	ab API-Version 2026-05-01-preview; eine Entra-Gruppe innerhalb einer SharePoint-Gruppe wird nicht aufgelöst	laut Doku: bestehende Berechtigungen werden beachtet
Entzogene Rechte	wirksam nach Ihrem nächsten Abgleich	Elemente mit eigenen Berechtigungen beim nächsten erfolgreichen Indexer-Lauf; vererbte Änderungen erst nach einem Berechtigungs-Resync der gesamten Datenquelle mit anschließendem Indexer-Lauf oder einem Reset der betroffenen Dokumente	in den gelesenen Microsoft-Seiten nicht gesondert beschrieben
Stand	hängt an Ihrem Workflow	Preview (REST-API 2026-08-01-preview, Doku-Stand 8. August 2026)	Doku-Stand 25. September 2026
Voraussetzung	n8n, Vektordatenbank, App-Registrierung mit Graph-Berechtigungen	Azure AI Search ab Tarif Basic; App-Registrierung, für Websitegruppen mit Federated Credential	Microsoft-365-Copilot-Lizenz der fragenden Person; ob nutzungsbasierte Abrechnung (Copilot Credits) genügt, beantwortet die Microsoft-Doku widersprüchlich
Was Sie selbst bauen	Berechtigungen auslesen, Gruppen auflösen, Filter, Abgleich	Index, Indexer und Abfrage mit Nutzertoken konfigurieren	den Agenten konfigurieren, keine eigene Pipeline

Azure AI Search liest mit seinem SharePoint-Indexer die Berechtigungen je Dokument mit ein und filtert bei jeder Abfrage selbst. Indexer und Berechtigungsübernahme sind laut Microsoft Preview-Funktionen; das Azure-Portal unterstützt die Berechtigungsübernahme nicht, eingerichtet wird sie über die REST-API oder ein Preview-SDK. Mit der API-Version 2026-05-01-preview kamen unter anderem zwei Punkte hinzu, die vorher fehlten: SharePoint-Websitegruppen werden mit dem Präfix spg: eingelesen und bei der Abfrage für die fragende Person über die SharePoint-REST-API aufgelöst, und Berechtigungsänderungen an Elementen mit eigenen Berechtigungen übernimmt jeder erfolgreiche Indexer-Lauf. Weitere Grenzen laut Doku: Freigabelinks für „Jeder“ oder „Personen in Ihrer Organisation“ sowie Gastbenutzer werden nicht unterstützt. Bei der Abfrage gilt ein Dokument als freigegeben, sobald einer der Filter greift, Person oder Gruppe, also genau die ODER-Logik, die Sie im Eigenbau selbst herstellen müssen. Scheitert die Berechtigungsprüfung, liefert der Dienst einen Fehler statt einer teilweise gefilterten Trefferliste. Wer Dokumente in Abschnitte zerlegt, muss die Berechtigungsfelder laut Doku auf jeden Abschnitt übertragen; dieselbe Regel gilt im n8n-Eigenbau. Für Fälle, die das volle SharePoint-Berechtigungsmodell samt Vertraulichkeitsbezeichnungen brauchen, verweist Microsoft in derselben Doku auf einen weiteren Weg: eine Remote-SharePoint-Wissensquelle, die SharePoint zur Abfragezeit direkt über die Copilot Retrieval API abfragt, statt einen eigenen Index aufzubauen. Sie ist ebenfalls Preview und setzt eine Microsoft-365-Copilot-Lizenz voraus (Doku-Stand 3. September 2026).

Ein Copilot-Agent kann SharePoint-Dateien, -Ordner, -Listen und -Sites als Wissensquelle nutzen. Laut Microsoft durchsucht Copilot dabei nur Inhalte, auf die die fragende Person Zugriff hat, und beachtet bestehende Berechtigungen und Vertraulichkeitsbezeichnungen. Bei der Voraussetzung ist die Microsoft-Dokumentation nicht einheitlich: Die Seite zu den Voraussetzungen nennt eine Microsoft-365-Copilot-Lizenz der fragenden Person oder eine im Tenant aktivierte nutzungsbasierte Abrechnung in Copilot Credits, deren Abrechnungsrichtlinie mit dem SharePoint-Agents-Dienst verbunden ist (Doku-Stand 9. Juli 2026). Die Seite zu den Wissensquellen verlangt in einem Hinweis eine aktive Copilot-Lizenz der angemeldeten Person; ohne sie scheitern Anfragen (Doku-Stand 25. September 2026). Klären Sie das vor der Entscheidung im eigenen Tenant. Im Agent Builder lassen sich bis zu 100 SharePoint-Dateien je Agent auswählen. Eine eigene Pipeline bauen Sie hier nicht.

Die beiden verglichenen fertigen Wege setzen auf den Berechtigungen auf, die in SharePoint vergeben sind. Zu weit gefasste Freigaben an Personen oder Gruppen korrigieren sie nicht; die Prüfung, wer in SharePoint was sehen darf, ersetzen sie also nicht.

Für den Mittelstand heißt das

Prüfen Sie vor dem ersten produktiven Einsatz vier Dinge an Ihrer eigenen Umgebung. 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 ihren Gruppen? Würde ein entzogener SharePoint-Zugriff im Assistenten sofort verschwinden oder erst beim nächsten geplanten Durchlauf? Und welche Freigabearten kommen in Ihren Bibliotheken vor: nur Entra-Gruppen, auch SharePoint-Websitegruppen, Freigabelinks oder Gäste? Von der letzten Frage hängt ab, welcher der verglichenen Wege Ihre Struktur im heutigen Stand überhaupt abdeckt.

Ein interner Wissensassistent, der jede Frage aus dem gesamten indexierten Bestand beantwortet, wirkt zunächst eindrucksvoller als einer mit sauberer Zugriffsprüfung, bis er zum ersten Mal auch das beantwortet, was er nicht hätte beantworten sollen. Bauen Sie die Abrufprüfung deshalb in den ersten funktionierenden Workflow ein, bevor mehr als eine Testperson mit unterschiedlichen Rechten darauf zugreift, und testen Sie sie mit zwei Konten: dieselbe Frage einmal mit und einmal ohne Leserecht auf das Quelldokument. Wiederholen Sie den Test mit einem Dokument, das nur über eine SharePoint-Websitegruppe freigegeben ist, denn diese Gruppen löst der Eigenbau über einen eigenen Weg auf, und Azure AI Search löst eine Entra-Gruppe innerhalb einer SharePoint-Gruppe nicht auf. Wie ein erster n8n-Workflow generell Schritt für Schritt aufgebaut wird, beschreibt unser Leitfaden zur n8n-Einführung im Detail.

FAQ

Wie liest ein n8n-Workflow die Berechtigungen einer SharePoint-Datei aus?

Über den Microsoft-Graph-Aufruf „List permissions“ für ein driveItem: Er liefert die wirksamen Freigaben einer Datei, direkt vergebene und von übergeordneten Ordnern geerbte. Der SharePoint-Node von n8n bietet dafür keine Operation, der Aufruf läuft über einen HTTP-Request-Node. Gruppen in der Antwort lösen Sie anschließend selbst auf: Entra-Gruppen über die Gruppenmitgliedschaften der fragenden Person, SharePoint-Websitegruppen über einen eigenen Weg.

Ist das dasselbe Berechtigungsmodell wie bei Microsoft 365 Copilot?

Nein. Laut Microsoft zeigt Copilot einer Person nur Daten, auf die sie selbst zugreifen darf. Eine selbst gebaute RAG-Pipeline mit n8n und einer Vektordatenbank hat diesen Mechanismus nicht von Haus aus. Sie bauen ihn entweder selbst ein oder nutzen einen Dienst wie Azure AI Search, dessen SharePoint-Indexer die Berechtigungen im derzeitigen Preview-Stand mit einliest.

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

Ein eng geschnittener Ingest-Zugang verhindert, dass zu viel überhaupt indexiert wird. 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 einer selbst befüllten Vektordatenbank bleibt der indexierte Inhalt bestehen, bis ein erneuter Abgleich oder eine erneute Indexierung ihn entfernt oder die hinterlegte Berechtigung aktualisiert. Auch Azure AI Search übernimmt eine solche Änderung erst beim nächsten Indexer-Lauf, eine an einer übergeordneten Ebene vererbte Änderung erst nach einem Berechtigungs-Resync der gesamten Datenquelle mit anschließendem Indexer-Lauf oder einem Reset der betroffenen Dokumente (Doku-Stand 8. August 2026).

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.