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: bleibt SharePoint Retrieval-System oder übernehmen Sie es selbst?

Bei SharePoint-RAG ist nicht die API-Anbindung die wichtigste Entscheidung. Entscheidend ist, ob Retrieval direkt auf dem Quellsystem bleibt oder ob Inhalte in einen eigenen Index repliziert werden. Beide Wege können production-ready sein – sie verlagern Verantwortung für ACLs, Aktualität, Deletes, Latenz und Search Quality aber an unterschiedliche Stellen.

Pfad A: Remote Retrieval

Hier bleibt SharePoint mit einer geeigneten Microsoft-Schnittstelle im Query-Pfad. Die Quelle bleibt Source of Truth und wird nicht dauerhaft in einen eigenen Index kopiert.

Remote Retrieval: Quelle bleibt Retrieval-System

1. 01

   User & Authorization

   Die App übergibt Anfrage und Nutzerkontext; sie muss nicht selbst aus einem replizierten ACL-Modell entscheiden.

2. 02

   SharePoint / Graph Retrieval

   Source Search und Source ACLs begrenzen Ergebnisse nahe an SharePoint; die Quelle bleibt führend.

3. 03

   Authorized Results

   Änderungen und Deletes sind ohne eigenen Index schneller sichtbar; Query- und Ranking-Verhalten bleiben von API und Search abhängig.

4. 04

   Context Assembly & LLM

   Die App assembliert erlaubte Evidenz, trägt aber API-Latenz, Rate Limits und Availability im Query-Pfad mit.

Remote Retrieval ist oft plausibel, wenn die SharePoint-Suche die relevanten Query-Typen ausreichend abdeckt, ACL-Semantik möglichst nah an der Quelle bleiben soll, Datenreplikation minimiert werden soll und Freshness wichtiger ist als maximale Ranking-Kontrolle. Query-Volumen, Latenz sowie API-Limits müssen dafür zum Use Case passen.

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.

Pfad B: Replizierter eigener Retrieval-Index

Hier liest ein Connector ausgewählte Inhalte über Microsoft Graph oder eine andere geeignete Schnittstelle aus und überführt sie in einen eigenen Search-, Vector- oder Hybrid-Index. Damit übernehmen Sie den Retrieval-Pfad selbst.

Eigener Index: Retrieval wird eigene Verantwortung

1. 01

   SharePoint & Change Detection

   Connector erkennt fachlich relevante Änderungen; Source bleibt führend, der Index ist eine abgeleitete Kopie.

2. 02

   Identity & ACL Mapping

   Stabile IDs und Berechtigungen werden repliziert; Permission Changes und Revokes müssen zeitnah in den Index gelangen.

3. 03

   Parsing & eigener Index

   Chunking, Metadaten, Hybrid Search und Reranking liegen unter eigener Kontrolle – ebenso Datenkopie und Indexqualität.

4. 04

   ACL-aware Retrieval

   Die Anwendung erzwingt Security Trimming, kontrolliert Query-Latenz und überwacht Sync, Stale-Status, Deletes und Retrieval.

Ein eigener Index ist oft plausibel, wenn mehrere Quellen zusammengeführt werden, Hybrid Search oder Reranking nötig ist, proprietäre Rankinglogik gebraucht wird oder Suchqualität mit eigener Evaluation messbar optimiert werden soll. Auch zusätzliche Normalisierung, Chunking und Metadata Enrichment können den Aufwand rechtfertigen. Für die Retrieval-Entscheidung selbst hilft Hybrid Search vs. Vector Search.

Architecture View: nicht automatisch alles kopieren

Ich würde nicht automatisch jeden SharePoint-Bestand in einen eigenen Vector Store kopieren. Wenn Source Search, Berechtigungen und Latenz ausreichen, kann Remote Retrieval die robustere Architektur sein.

Ein eigener Index lohnt sich dann, wenn zusätzliche Retrieval-Kontrolle den zusätzlichen Lifecycle- und Security-Aufwand messbar rechtfertigt. Hybrid ist möglich, aber kein automatischer Default: Er braucht eine klare Aufteilung, welche Queries und Inhalte remote bleiben und welche bewusst repliziert werden.

Microsoft Graph und Least Privilege im replizierten Pfad

Ein häufiger Architekturfehler ist eine App-Registrierung mit zu breiten tenantweiten Rechten. Ein Connector sollte nur auf die Sites zugreifen können, die für den konkreten Use Case nötig sind; Microsoft dokumentiert dafür unter anderem Sites.Selected.

Das ist keine Graph-Anleitung, sondern eine Architekturgrenze: Inhalte und Berechtigungsinformationen werden nur im erforderlichen Scope gelesen und getrennt als Sicherheitsdaten behandelt. 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. Bei Remote Retrieval bleiben Source ACLs näher am Retrieval. Wer Inhalte in einen eigenen Index repliziert, repliziert damit auch Verantwortung für Berechtigungen.

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.

Im eigenen Index gehören deshalb zu jedem 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:

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

Freshness und Deletes: nur beim eigenen Index wird daraus ein Lifecycle

Remote Retrieval folgt in der Regel dem aktuellen Zustand der Quelle. Beim eigenen Index müssen create, update, move, rename, permission change, delete und restore kontrolliert bis zu allen betroffenen Indexeinträgen propagieren. Eine Permission Revocation ist dabei genauso relevant wie eine Inhaltsänderung.

Definieren Sie dafür eine fachliche Freshness-Anforderung: Eine interne Richtlinie muss vielleicht innerhalb weniger Minuten aktualisiert sein, ein archiviertes Projektdokument darf möglicherweise eine Stunde Verzögerung haben. Sync, Reconciliation, Stale-Status und Delete Propagation sind keine Nebenthemen, sondern Teil der Betriebsverantwortung. Das übergreifende Ingestion-/Lifecycle-Muster behandelt RAG-Datenquellen anbinden, ohne dass jeder Connector es neu erfinden sollte.

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.