SharePoint an RAG anbinden: Architektur, Microsoft Graph & Berechtigungen

In vielen Unternehmen ist SharePoint bereits das faktische Wissenssystem. Richtlinien, Projektdokumentation, Vorlagen, Präsentationen, technische Dokumente und Teamwissen liegen dort – aber nicht unbedingt so, dass Mitarbeiter die richtige Information schnell finden.

RAG kann daraus einen dialogorientierten Wissenszugang machen. Die eigentliche Herausforderung ist jedoch nicht das LLM, sondern SharePoint sauber an Retrieval anzubinden, ohne Berechtigungen, Aktualität und Quellenbezug zu verlieren.

Die Architekturentscheidung: direkt abfragen oder eigenen Index aufbauen?

Für SharePoint-RAG gibt es grundsätzlich zwei Muster.

Variante A: SharePoint zur Anfragezeit durchsuchen

Das Retrieval fragt SharePoint bzw. eine dafür vorgesehene Microsoft-Schnittstelle direkt ab. Inhalte werden nicht dauerhaft in einen eigenen Suchindex repliziert.

Vorteile:

• bestehendes Berechtigungsmodell bleibt näher an der Quelle,
• weniger Datenkopien,
• Änderungen sind schneller sichtbar,
• geringerer eigener Synchronisierungsaufwand.

Nachteile:

• stärkere Abhängigkeit von Microsoft-Schnittstellen und deren Fähigkeiten,
• weniger Kontrolle über Parsing, Chunking und Ranking,
• Einschränkungen bei Spezialformaten oder eigener Retrieval-Logik.

Microsoft beschreibt für aktuelle Azure-AI-Search-Szenarien eine remote SharePoint knowledge source, die SharePoint-Inhalte über die Copilot Retrieval API abfragt und das SharePoint-Berechtigungsmodell berücksichtigt. Das kann für Microsoft-zentrierte Architekturen ein sinnvoller Startpunkt sein. Details und aktueller Feature-Stand: Microsoft Learn – SharePoint in Microsoft 365 Indexer.

Variante B: SharePoint in einen eigenen Retrieval-Index synchronisieren

Die zweite Variante liest Inhalte über Microsoft Graph oder andere geeignete Schnittstellen aus und verarbeitet sie in einer eigenen Pipeline:

SharePoint → Graph/API → Parsing → Chunking → Metadaten → ACLs → Search/Vector Index

Vorteile:

• volle Kontrolle über Parser und Dokumenttypen,
• eigene Chunking- und Metadatenstrategie,
• freie Wahl von Suchindex, Vector Store, Embeddings und LLM,
• Hybrid Search und eigenes Reranking,
• besser für Multi-Source-RAG mit SharePoint + DMS + ERP + CRM.

Nachteile:

• Inhalte werden repliziert,
• Synchronisierung und Delete Propagation müssen selbst gelöst werden,
• Berechtigungen müssen korrekt materialisiert und aktuell gehalten werden,
• Betrieb und Monitoring werden Teil der eigenen Plattform.

Für eine technologieoffene oder souveräne Architektur ist diese Variante häufig interessanter – aber nur, wenn der zusätzliche Betrieb gerechtfertigt ist.

Microsoft Graph: mit Least Privilege beginnen

Ein häufiger Architekturfehler ist eine App-Registrierung mit zu breiten tenantweiten Rechten.

Für kontrollierte Integrationen sollte der Connector nur auf die SharePoint-Sites zugreifen können, die für den konkreten Use Case benötigt werden. Microsoft dokumentiert dafür unter anderem das Muster Sites.Selected.

Das Prinzip:

1. App in Microsoft Entra ID registrieren.
2. Nur die erforderlichen API-Rechte vergeben.
3. Zugriff explizit auf die benötigten Sites beschränken.
4. Inhalte und Metadaten über Microsoft Graph lesen.
5. Berechtigungen getrennt als Sicherheitsinformation behandeln.

Microsoft hat 2026 außerdem ein Referenzmuster veröffentlicht, bei dem Dokumentberechtigungen aus SharePoint in einen nachgelagerten Search-/RAG-Index übernommen und beim Query als Filter angewandt werden. Siehe Microsoft ISE – Propagating SharePoint Document Permissions to AI Search and RAG Pipelines.

Der wichtigste Punkt: SharePoint-Rechte dürfen im RAG nicht verschwinden

Ein internes RAG-System darf nicht aus einem sauber berechtigten SharePoint ein flaches Wissensarchiv machen, in dem jeder alles finden kann.

Beispiel:

• HR sieht Personalrichtlinien und vertrauliche HR-Dokumente.
• Vertrieb sieht Angebots- und Kundendokumentation.
• Geschäftsführung sieht zusätzliche Management-Unterlagen.
• Ein Projektteam sieht nur seine freigegebenen Projekträume.

Wenn alle Dokumente ohne ACL-Kontext in einem Vektorindex landen, ist das Berechtigungsmodell faktisch verloren.

Deshalb gehören zu jedem indexierten Dokument oder Chunk Sicherheitsmetadaten, beispielsweise:

• erlaubte Nutzer,
• erlaubte Gruppen,
• explizit verweigerte Principals,
• Site-/Library-Kontext,
• Mandant oder Organisationseinheit.

Beim Retrieval muss der aktuelle Nutzerkontext vor dem Modellkontext greifen. Genau dieses Thema vertieft der Artikel RAG-Berechtigungen & Security Trimming.

Dokumentidentität: Dateiname reicht nicht

Ein Dokument kann in SharePoint umbenannt oder verschoben werden, ohne fachlich ein neues Dokument zu sein.

Verwenden Sie deshalb stabile Quell-IDs und speichern Sie mindestens:

| Feld | Zweck | |---|---| | Site ID | Quellkontext | | Drive/Library ID | Dokumentbibliothek | | Item ID | stabile Dokumentidentität | | Web URL | Rücksprung zur Quelle | | Modified Date | Change Detection | | Version | Aktualität und Nachvollziehbarkeit | | Content Hash | echte Inhaltsänderung erkennen | | ACL/Principals | Security Trimming | | Titel/Dateityp | Darstellung und Filter |

Ohne stabile Identität entstehen beim Reindex schnell Dubletten und Zombie-Versionen.

Synchronisierung: Polling, Delta oder Event?

Für einen kleinen Pilot kann ein regelmäßiger Batch reichen. Im produktiven Betrieb sollten Änderungen gezielter erkannt werden.

Je nach Quellsystem und Schnittstelle kommen infrage:

• Delta-Abfragen,
• Änderungszeitstempel,
• Webhooks,
• Queue-/Event-basierte Verarbeitung,
• periodische Kontrollläufe.

Wichtig ist nicht, möglichst „realtime“ zu sein, sondern eine explizite Freshness-Anforderung zu definieren.

Eine interne Richtlinie muss vielleicht innerhalb weniger Minuten aktualisiert sein. Ein archiviertes Projektdokument darf dagegen auch mit einer Stunde Verzögerung erscheinen.

Delete Propagation: gelöschte Dokumente müssen verschwinden

Bei RAG wird häufig nur über neue und geänderte Dokumente gesprochen.

Ebenso wichtig:

Was passiert, wenn ein Dokument gelöscht wird oder ein Nutzer seine Berechtigung verliert?

Der Retrieval-Index muss beide Ereignisse nachvollziehen können.

Sonst entstehen:

• veraltete Inhalte,
• widerrufene Dokumente,
• nicht mehr gültige Richtlinien,
• oder Informationen, auf die ein Nutzer inzwischen keinen Zugriff mehr haben dürfte.

Delete Propagation und Permission Revocation gehören deshalb in die Definition of Done eines SharePoint-RAG-Connectors.

Parsing von Word, PowerPoint, Excel und PDF

SharePoint ist kein reines PDF-Archiv. Typischerweise finden sich:

• Word-Dokumente,
• PowerPoint,
• Excel,
• PDFs,
• Text-/Markdown-Dateien,
• SharePoint-Seiten,
• teilweise Scans und Bilder.

Ein Universal-Parser kann für einen Pilot reichen, aber produktive Qualität verlangt Tests pro Dokumentklasse.

Besonders kritisch:

PowerPoint

Folien brauchen Reihenfolge, Titel und Kontext. Einzelne Textboxen ohne Folienbezug erzeugen schlechte Chunks.

Excel

Tabellen sind selten sinnvoll als flacher Fließtext. Je nach Use Case ist eine strukturierte Query besser als Embedding.

PDF

Mehrspaltige Layouts, Scans, Tabellen und Kopf-/Fußzeilen brauchen saubere Extraktion. Prüfen Sie den tatsächlich indexierten Text.

Word

Überschriftenhierarchie, Tabellen und Listen sollten für semantisches Chunking erhalten bleiben.

Chunking: SharePoint-Struktur nutzen

Nicht jedes Dokument sollte in gleich große Textblöcke geschnitten werden.

Nützliche Signale sind:

• Überschriften,
• Seiten,
• Abschnitte,
• Tabellen,
• Dokumenttyp,
• Ordner-/Library-Kontext,
• Metadaten aus SharePoint.

Das verbessert sowohl Retrieval als auch Quellenanzeige.

Für das Gesamtbild aus Chunking, Hybrid Search und Evaluation siehe RAG-System entwickeln & richtig aufbauen.

Quellenbezug: Antwort muss zurück nach SharePoint führen

Eine gute interne RAG-Antwort sollte nicht nur behaupten, sondern verifizieren lassen.

Idealerweise zeigt die Anwendung:

• Dokumenttitel,
• SharePoint-Link,
• relevante Passage,
• Änderungsdatum oder Version,
• gegebenenfalls Seite/Abschnitt.

Damit kann der Nutzer direkt im Original prüfen, ob die KI den Inhalt korrekt interpretiert hat.

SharePoint Search ersetzen? Meist nein

RAG und klassische Suche lösen unterschiedliche Aufgaben.

SharePoint Search eignet sich gut, wenn Nutzer ein konkretes Dokument suchen.

RAG ist stärker, wenn eine Frage mehrere Dokumente zusammenführen oder eine konkrete Antwort mit Quellen liefern soll.

Ein gutes System kann beides kombinieren:

• Keyword Search für exakte Namen, IDs und Begriffe,
• semantische Suche für Bedeutung,
• Metadatenfilter,
• Reranking,
• LLM für Synthese.

Das ist meist robuster als „alles nur Vector Search“.

Wann SharePoint-RAG sinnvoll ist

Gute Einsatzfelder:

• interne Richtlinien und Policies,
• technischer Support,
• Projektwissen,
• Produkt- und Prozessdokumentation,
• Qualitätsmanagement,
• Wissenszugang für Fachabteilungen.

Weniger geeignet:

• hochtransaktionale Echtzeitdaten,
• Daten, deren Owner und Rechte ungeklärt sind,
• komplett unbereinigte Altarchive,
• Use Cases ohne konkrete Nutzerfragen.

Praktische Architektur-Checkliste

Vor dem Build sollten diese Punkte beantwortet sein:

1. Welche Sites und Libraries sind im Scope?
2. Welche Nutzer und Gruppen verwenden das System?
3. Bleibt Retrieval remote oder werden Inhalte repliziert?
4. Wie werden ACLs übernommen?
5. Welche Dateitypen müssen unterstützt werden?
6. Wie werden Änderungen erkannt?
7. Wie werden Löschungen und entzogene Rechte propagiert?
8. Welche Metadaten bleiben erhalten?
9. Wie wird Quellenbezug dargestellt?
10. Welche realen Fragen bilden das Eval-Set?
11. Welche Freshness wird benötigt?
12. Wer betreibt Connector, Index und Monitoring?

Wenn mehrere Antworten fehlen, ist die Vector Database noch nicht die nächste Entscheidung.

SharePoint-RAG produktiv umsetzen

SharePoint ist häufig nur die erste Datenquelle. Später kommen DMS, Confluence, ERP, CRM, SQL oder APIs dazu. Deshalb sollte die Architektur nicht als einmaliger SharePoint-Connector gedacht werden, sondern als wiederverwendbarer Ingestion- und Retrieval-Layer.

Der Überblick RAG-Datenquellen anbinden zeigt dieses Multi-Source-Muster.

Wenn Sie SharePoint oder Microsoft 365 mit einem eigenen RAG-System verbinden wollen, unterstütze ich bei RAG-Implementierung & KI-Integration – inklusive Datenpfad, Berechtigungen, Retrieval, Evaluation und Integration in bestehende Anwendungen.

Sie haben bereits SharePoint-Daten und einen konkreten Wissens-Use-Case?
→ RAG-Architektur und Integrationsweg prüfen

Technische Hinweise zu Datenschutz und Compliance ersetzen keine Rechtsberatung.