Alle Notizen
23. Mai 202613 Min. Lesedauersharepointcopilot-studioragenterprise-aimicrosoft-365

SharePoint ist die Grounded-RAG-Schicht, die Sie längst besitzen

Der SharePoint-Tenant, den Ihr Unternehmen ohnehin bezahlt, ist eine Permission-Trim-gesicherte, fertig indexierte Grounding-Schicht für KI-Agents. Eine maßgeschneiderte Vector-Pipeline ist für interne Arbeit meist der falsche Default.

Kernaussagen

  • Der Tenant-Semantic-Index wird automatisch erzeugt, lässt sich nicht abschalten und benötigt keine Admin-Beteiligung. Sie bezahlen für eine Grounding-Schicht, ob Ihr Agent sie nutzt oder nicht.
  • Permission Trim wird aus den Quell-ACLs vererbt, nicht neu aufgebaut. Das Grounding liest nur Inhalte, auf die der aktuelle Nutzer ohnehin Zugriff hat.
  • Das Gegenargument trägt in den 20 %: Der Live-Connector-Pfad überspringt Vector-Embeddings, und Microsofts eigener Vergleich sagt, der synchronisierte Pfad liefert genauere Treffer.
  • Grounding verursacht keine Lecks. Es spielt Ihre bestehenden Berechtigungsfehler in Maschinengeschwindigkeit an jeden Mitarbeiter zurück, ein Governance-Problem, das Sie schon vor dem Agent hatten.
  • Ohne tenantinterne Copilot-Lizenz sind generative Antworten auf 7 MB pro SharePoint-Datei und 2.048 Listenzeilen gedeckelt. Governance-inklusive ist günstig, nicht sternchenfrei.

In diesem Artikel

SharePoint ist die Grounded-RAG-Schicht, die Sie längst besitzen

Jedes Projekt für interne Agents, das mir begegnet, startet gleich. Jemand skizziert eine Vector DB, wählt ein Embedding-Modell, debattiert über Chunk-Größen und budgetiert ein Quartal für Dokumentensynchronisation und Security Trimming. Dann stellt das Team fest, dass das eigentliche Unternehmenswissen längst in SharePoint liegt, hinter Berechtigungen, die die IT über ein Jahrzehnt feinjustiert hat, und dass Microsoft das Ganze die ganze Zeit still indexiert hat. Die Vector-Pipeline ist echtes Engineering. Für die meisten internen Agents ist sie zugleich der Nachbau einer Infrastruktur, die der Tenant bereits mitliefert. Die Frage, die vor jeder Provisionierung steht: Was leistet die Box schon umsonst, und ab welcher Stelle hört umsonst auf, gut genug zu sein? Das ist kein Microsoft-Verkaufspitch, sondern ein Default-Architektur-Argument: Default für einen internen Agent sollte die Grounding-Schicht sein, die Sie schon besitzen, und die Beweislast liegt beim Team, das eine neue bauen will.

Hier ist die Position. Der SharePoint-Tenant, den ein Unternehmen bereits besitzt, ist die günstigste Grounded-RAG-Wissensschicht inklusive Governance für KI-Agents, und eine maßgeschneiderte Vector-Pipeline ist als Default für interne Agents meist falsch. Nicht weil die DIY-Pipeline schlechtes Engineering wäre. Sondern weil sie dreimal bezahlt, was der Tenant ohnehin liefert: einen gepflegten Index, vererbtes Permission Trim und eine Rechnungszeile mit null zusätzlichen Euro. Bei rund vier von fünf internen Agents schlägt Governance-inklusive das Tunbare-aber-Ungoverncte. Das fünfte ist real, und ich benenne präzise, wo es liegt.

Warum dieses Argument jetzt zählt

Die Ökonomie änderte sich, als der Index nicht mehr optional war. Microsoft erzeugt nun einen Semantic-Index je Subscription auf Tenant- und Nutzerebene. Beschrieben wird er als „organisationsweiter Index, erzeugt aus textbasierten SharePoint Online-Dateien", und die Dokumentation ist klar zu zwei Eigenschaften, die hier zählen: „Der Indexierungsprozess erfordert keine administrative Beteiligung" und „Semantische Indexierung ist eine Verbesserung von Microsoft 365 Search und lässt sich nicht abschalten" (Microsoft Learn, semantic indexing). Lesen Sie das zweimal. Der Index existiert vor Ihrem Agent, Sie können ihn nicht ausschalten, und Sie bezahlen ihn bereits über die Subscription. Einen zweiten Index für denselben Job zu provisionieren ist der Teil, der Rechtfertigung braucht.

Die zweite Verschiebung ist, dass Microsoft DIY-Indexierung selbst als Overhead rahmt. Die Copilot Retrieval API wird als RAG angepriesen, „ohne dass Sie Ihre Daten in einem separaten Index replizieren, indexieren, chunken und absichern müssen" (Retrieval API overview). Wenn der Plattformanbieter, auf dem Sie laufen, Ihnen sagt, dass das Replizieren und Chunken Ihrer eigenen Daten vermeidbare Arbeit ist, ist das eine Pause wert. Replizieren-Chunken-Absichern ist exakt der Projektplan, den ein Vector-Pipeline-Team an Tag eins schreibt.

Drittens hat die Agent-Oberfläche aufgeschlossen. SharePoint ist nun ein erstklassiges, katalogweit verfügbares Grounding-Ziel in Agent-Buildern, kein Aufsatz mit Custom-Code. In einer Microsoft-Power-Platform-Community-Session verkabelte ein Vortragender einen Copilot Studio-Agent über einen Out-of-the-box-Model-Context-Protocol-Connector mit einer SharePoint-Liste und ließ ihn extrahierte Daten ganz ohne Integrationscode in die Liste schreiben. Die Session zeigt die Schreibrichtung; die Leserichtung, also die Grounding-Seite, um die es hier geht, läuft auf derselben Oberfläche andersherum. Der Punkt ist nicht die Demo. Der Punkt ist, dass Microsoft SharePoint zur bidirektionalen No-Code-Agent-Oberfläche macht, was die Voraussetzung dafür ist, sie als Default-Wissensschicht zu behandeln und nicht als Datenablage.

Wer mein früheres Stück zu Structured Retrieval schlägt Vector RAG für Enterprise Agents gelesen hat, erkennt denselben Reflex eine Schicht höher angewandt. Dort ging es um typisierte Zeilen versus Cosinus-Scores. Hier geht es um besessene Infrastruktur versus nachgebaute Infrastruktur.

Governance ist das Feature, nicht der Dateispeicher

Der stärkste Grund, auf SharePoint zu grounden, ist die Berechtigungsschicht, die Sie nicht schreiben müssen. In einem DIY-Vector-Store ist Security Trimming Ihr Code. Jede Abfrage muss den fragenden Nutzer erneut gegen eine ACL prüfen, die Sie aus dem Quellsystem repliziert, synchron gehalten und damit für immer übernommen haben. Auf dem Tenant-Index wird diese Arbeit vererbt. Beim Indexieren von Inhalten sagt Microsoft, der Prozess „berücksichtigt weiterhin die identitätsbasierte Zugriffsgrenze des Nutzers, sodass das Grounding nur auf Inhalte zugreift, für die der aktuelle Nutzer berechtigt ist" (semantic indexing). Die Grenze bauen Sie nicht. Sie können sie nur fehlerhaft durchbrechen.

Der Mechanismus ist bis zur Datenstruktur dokumentiert. Jedes indexierte Element aus einem Connector „enthält Inhalt, Metadaten (wie Titel und URL) und eine Access Control List (ACL), die Berechtigungen durchsetzt", und „Search und Copilot zeigen Elemente nur Nutzern, die im Quellsystem Zugriff haben" (connectors overview). Synchronisierte Connectors „respektieren Quellberechtigungen"; föderierte sind „secure by design" gegenüber dem OAuth der Quelle. Der Semantic-Index selbst „respektiert alle organisatorischen Grenzen innerhalb Ihres Tenants", gesteuert durch rollenbasierte Zugriffskontrolle. Und entscheidend: Indexierung weitet die Exposition nicht aus: „Indexierung ändert keine Zugriffsberechtigungen auf Inhalte."

Vergleichen Sie die beiden Kostenstrukturen ehrlich.

| Eigenschaft | SharePoint-grounded | DIY Vector RAG | |---|---|---| | Index-Provisionierung | Auto-generiert, nicht abschaltbar, keine Admin-Arbeit (Quelle) | Neuer Azure-AI-Search- oder Qdrant/Pinecone-Tier muss aufgebaut werden | | Zusatzkosten | In der Subscription enthalten | Neue wiederkehrende Position, pro Search-Unit abgerechnet | | Permission Trim | Aus Quell-ACLs vererbt | Ihr Code, Ihre Synchronisation, Ihre Haftung | | Datenaktualität | Aktualisierte Dokumente „sofort indexiert"; neue täglich (Quelle) | Was immer Ihr Sync-Job schafft | | Chunker / Embeddings / Ranker | Microsofts Wahl, intransparent | Ihre Tuning-Hoheit | | Speicherort | Isolierter In-Region-Tenant-Container | Wo Sie es hinlegen, von Ihnen abgesichert |

Schauen Sie auf die unteren zwei Zeilen, denn dort sitzt der Tausch. Sie geben Chunker, Embedding-Modell und Ranker auf. Sie bekommen einen gepflegten Index, kostenfreies Trimming und Aktualität im Bereich „sofort" für Updates zurück. Für einen HR-Policy-Bot, einen Beschaffungsassistenten, einen IT-Hilfe-Agent oder jeden Agent, der aus Dokumenten antwortet, die Ihre Kolleginnen und Kollegen ohnehin öffnen können, ist dieser Tausch zugunsten der Box schief. Die Governance, die Sie ein Quartal lang neu bauen würden, ist eingeschaltet ausgeliefert.

Das benachbarte Argument heißt Observability, das ich in Microsoft 365 liefert Agent-Inventar, keine Observability behandelt habe. Governance-inklusive Grounding und Governance-inklusive Inventory sind dieselbe Wette: Die Plattform erledigt das langweilige, haftungsschwere Klempnern besser, als Sie es tun werden, und Ihre Aufgabe ist, es korrekt zu nutzen statt es neu zu erfinden.

Es gibt einen unangenehmeren Einwand, und er ist nicht technisch: Grounding verstärkt den Berechtigungswildwuchs, den Sie ohnehin haben. Microsoft ist zur Wurzel klar: „Das meiste interne Oversharing entsteht aus Konfigurationsproblemen, nicht aus böser Absicht" (mitigate oversharing). Der Agent schafft das Leck nicht. Er spielt Ihre bestehenden Fehlkonfigurationen in Maschinengeschwindigkeit an jeden Mitarbeiter zurück. Ein vor fünf Jahren zu breit geteiltes Dokument war ein latentes Risiko; hinter einem grounded Agent ist es eine Anfrage entfernt.

Das ist real, und es ist der Fehlermodus, für den Sie planen müssen. Aber sehen Sie, wofür es tatsächlich argumentiert. Nicht für einen DIY-Vector-Store, denn ein DIY-Store erbt bei sauberem Trimming genau dieselben Quellberechtigungen, und bei schlampigem Trimming schlechtere. Das Oversharing-Problem liegt oberhalb der Retrieval-Architektur. Es ist eine Eigenschaft Ihrer ACLs, nicht Ihres Index. Es ist also kein Grund, ein eigenes RAG zu bauen. Es ist ein Grund, Berechtigungen zu reparieren, bevor Sie irgendeinen Agent skalieren, auf welcher Architektur auch immer.

Microsoft positioniert genau dafür spezifisches Tooling, eingerahmt als Voraussetzung, nicht als Nice-to-have: SharePoint Advanced Management für Berechtigungsreports und Site-Access-Reviews, plus Restricted Content Discovery und Purview DSPM for AI für Expositions-Monitoring. SharePoint Advanced Management ist in der Microsoft-365-Copilot-Lizenz enthalten, das heißt das Remediations-Toolkit liefert dieselbe Lizenz mit, die das bessere Grounding freischaltet. Admins können eine Site auch komplett ausschließen, indem sie „Diese Site darf in Suchergebnissen erscheinen" auf Nein setzen; Microsoft warnt jedoch, das „sollte nur für sensible Daten wie Lohn-, HR- oder Finanzinformationen in Betracht gezogen werden", und merkt an, „es gibt keine Option, Ergebnisse nur aus Microsoft Search oder nur aus dem Semantic-Index auszuschließen".

Die ehrliche Zusammenfassung: Das Trimming ist real und kostenlos, spiegelt aber nur die ACLs wider, die Sie pflegen. Schlechte Berechtigungen rein, schnelle Lecks raus. Die Governance-inklusive-Aussage stimmt auf der Retrieval-Schicht und ist auf der Konfigurationsschicht bedingt. Wer Ihnen SharePoint-Grounding verkauft, ohne das zu sagen, verkauft Ihnen einen künftigen Vorfall.

Die Blackbox, die Sie nicht tunen können

Hier verliert die These, und sie verliert aus realen Gründen. Wenn Sie auf dem Live-SharePoint-Connector grounden, sitzen Sie in einem Retrieval-System, das Sie nicht justieren können. Der Praktiker Harry Traynor brachte den Mechanismus klar auf den Punkt: Der Connector-Pfad „speichert keine Dateien in Dataverse, baut keine Vector-Embeddings", und „die Retrieval-Qualität ist anders, weil der Inhalt nicht semantisch indexiert ist" (why your agent's knowledge breaks on import). Sie wählen weder den Chunker noch das Embedding-Modell noch den Ranker. Wenn Recall stimmt nicht, ist Ihr einziger Hebel das Quelldokument, nicht der Retrieval-Stack.

Es wird schärfer. Die Qualität ist nicht einmal innerhalb von Microsofts eigenem Stack einheitlich. Traynor zitiert: „Microsofts eigener Vergleich zeigt, dass die eingespielten/synchronisierten Dateien genauere, kontextuell gegroundete Antworten" liefern als der Live-Connector-Pfad. Es gibt also zwei SharePoint-Pfade, und sie zu vermischen ist der häufigste Analysefehler, den ich sehe. Pfad (a) ist die Connector-basierte Wissensquelle: durchsucht Inhalte live, baut keine Embeddings, ist freundlich zum Application Lifecycle Management. Pfad (b) ist der Unstructured-Data-Upload-Pfad: kopiert Dateien nach Dataverse und fährt eine verwaltete Chunk-and-Embed-Pipeline, die hochwertigere Option. Wer den falschen wählt, degradiert Retrieval still und glaubt dabei, er habe „SharePoint" gewählt.

Wie halte ich also die Default-Position? Indem ich sie eingrenze. Die These ist „üblicherweise" und „für interne Agents", nicht „immer". Die DIY-Pipeline gewinnt klar, wenn Sie hohen Recall auf großem, rauschendem Korpus brauchen, wo ein verfehlter Chunk ein echtes Versagen ist; wenn domänenspezifisches Chunking zählt, etwa Splits an Klausel- oder Codeblockgrenzen; wenn Sie einen getunten Reranker brauchen; oder wenn Ihr Korpus gar nicht in SharePoint liegt. Das sind die 20 %. Für einen kundennahen Legal-Research-Agent über zehntausend Verträgen bauen und tunen Sie die Vector-Pipeline. Für den HR-Bot nicht.

💡 Die Wahl ist nicht SharePoint gegen Vector DB. Sie ist Connector-Live gegen Dataverse-synchron gegen DIY, und die meisten Teams degradieren ihr Retrieval, weil sie ohne Wissen, dass es drei Pfade gibt, den falschen der drei wählen.

Die ehrliche Rahmung ist: Sie tauschen Tunability gegen Governance, und die einzige Sünde ist nicht zu wissen, was Sie gekauft haben. Wenn Sie wirklich den tunbaren Pfad brauchen, kauft Ihnen die Dataverse-synchronisierte Option innerhalb von Microsofts eigenem Stack den größten Teil der Qualität zurück, bevor Sie überhaupt zu einem Drittanbieter-Vector-Store wechseln, und sie behält das vererbte Trimming. Der vollständige Ausstieg, gespeist von einem SharePoint-Indexer oder einem Graph-Export in Azure AI Search, ist als reales Muster dokumentiert (Brian Loves Azure AI RAG over SharePoint), und er führt jede Kosten wieder ein, die der Tenant-Index für Sie aufgefangen hatte.

Ein durchgespieltes Beispiel: Copilot Studio über einer SharePoint-Liste

Der konkrete Aufbau ist kleiner, als die Architekturdiagramme suggerieren. Nehmen Sie den Agent aus jener Microsoft-Power-Platform-Community-Session und betreiben Sie ihn als Grounding-Fall. Der Vortragende legte ein Word-Dokument in einen Copilot Studio-Agent, und der Agent verweigerte es. Bei GPT-4.1 schalten Sie in den Einstellungen des Agent den Code-Interpreter-Toggle an, damit Word nativ gelesen wird; bei einem neueren Modell wie GPT-5 liest der Agent das Dokument direkt ohne Toggle, und das Ergebnis „sieht besser aus", wie der Vortragende sagt. Genau dieser Mikrodetail, GPT-4.1 braucht Code Interpreter, während GPT-5 Word nativ liest, ist die Art versionsspezifischer Stolperfalle, die darüber entscheidet, ob ein Pilot beim ersten Versuch funktioniert.

Anschließend schrieb der Agent die extrahierten Felder über den Work-IQ-SharePoint-MCP-Connector in eine SharePoint-Liste, hinzugefügt aus dem Tools-Katalog per Filter auf „model context protocol", nur mit der Listen-URL als Eingabe. Der Connector erkannte Site und Listenschema automatisch. Das ist die Schreibrichtung. Drehen Sie sie um, und dieselbe Oberfläche ist Ihre Lese-Grounding-Schicht: Ein Copilot Studio-Agent, der auf derselben Liste gegroundet ist, beantwortet Fragen gegen Live-Zeilen.

Für den Lesepfad konfigurieren Sie eine Wissensquelle, und die Authentifizierung ist das gesamte Tor. Die manuelle Konfiguration verlangt nur zwei Scopes:

knowledge_source:
  type: sharepoint
  site_url: "https://contoso.sharepoint.com/sites/policies"
  scopes:
    - Sites.Read.All     # site content for grounding lesen
    - Files.Read.All     # documents for generative answers lesen
  # list grounding is a real-time connection to the source;
  # users authenticate with their own SharePoint credentials

Diese Scopes (knowledge-add-sharepoint) sind nur lesend, und List-Grounding öffnet „eine Echtzeitverbindung zur Quelle, sodass für Anfragen und Reasoning die aktuellsten Daten genutzt werden", wobei Nutzer „mit ihren SharePoint-Credentials authentifiziert" werden. Keine replizierte Kopie, kein veralteter Snapshot, kein separates Anmeldesystem. Der bestehende Zugriff des Tenants ist das Tor.

Nun die Sternchen, mit Zahlen. Ohne tenantinterne Copilot-Lizenz können „generative Antworten nur SharePoint-Dateien unter 7 MB nutzen"; mit Copilot-Lizenz plus Work IQ steigt diese Decke auf „Dateien bis 200 MB" (quotas and limits). Listenabfragen „geben nur Daten aus den ersten 2.048 Zeilen zurück", Sie können „bis zu 15 Listen gleichzeitig auswählen", und der unstrukturierte Sync läuft im Takt von „vier bis sechs Stunden". Die generelle Upload-Grenze liegt laut derselben Quotas-Seite bei „512 MB" pro Datei. Allein die 2.048-Zeilen-Decke disqualifiziert einen listengrounded Agent über jedem größeren Datensatz, und das ist exakt der Fall, in dem der strukturierte oder DIY-Pfad seine Kosten verdient. Die Zahlen sagen Ihnen, wo das kostenlose Mittagessen endet.

Wie wenden Sie das an? Default auf die Box, dann den Bedarf zu verlassen beweisen. Konkret:

  1. Machen Sie SharePoint zum Default, verlangen Sie Begründung für eine Abweichung. Für jeden Agent, der aus Dokumenten antwortet, die Ihre Kolleginnen und Kollegen ohnehin öffnen können, grounden Sie zuerst auf dem Tenant-Index. Die Beweislast liegt beim Team, das einen separaten Vector-Store will, nicht beim Team, das nutzt, was im Lieferumfang ist.

  2. Wählen Sie den Pfad bewusst. Entscheiden Sie explizit zwischen Connector-Live (keine Embeddings, lifecycle-freundlich), Dataverse-synchron (verwaltete Chunk-and-Embed-Pipeline, bessere Qualität) und vollem DIY (volle Kontrolle, volle Kosten). Der teuerste Fehler ist die unbeabsichtigte Wahl. Das Qualitätsgefälle zwischen Connector und Dataverse ist real und still.

  3. Auditieren Sie Berechtigungen vor dem Skalieren, nicht danach. Fahren Sie SharePoint-Advanced-Management-Reports und einen Purview-DSPM-for-AI-Review, bevor der Agent breit ausgerollt wird. Grounding bringt jede Sharing-Fehlkonfiguration an die Oberfläche, also behandeln Sie Berechtigungshygiene als Release-Blocker.

  4. Prüfen Sie Ihre Zahlen zuerst gegen die Caps. Wenn Ihr Korpus Dateien über 7 MB enthält und Sie keine tenantinterne Copilot-Lizenz haben, oder wenn eine Liste mehr als 2.048 Zeilen hat, sind Sie schon außerhalb des kostenlosen Mittagessens. Bestätigen Sie Lizenz und Limits, bevor Sie den Build skopen.

  5. Reservieren Sie die Vector-Pipeline für die 20 %. Hoher Recall über große, rauschende Korpora, Chunking auf Klausel- oder Code-Ebene, ein getunter Reranker, oder ein Korpus, der gar nicht in SharePoint liegt. Trifft nichts davon auf Ihren Agent zu, vergolden Sie.

Das ist das Grounding-Pendant zu meinem Stück warum die meisten Copilot-Studio-Agent-Probleme Integrationsprobleme sind. Dort argumentierte ich, dass die Oberfläche vor dem Modell scheitert. Hier argumentiere ich, dass die Grounding-Schicht meist eine Wahl ist, für die Sie bereits gezahlt haben, und der Fehler ist, sie aus Reflex nachzubauen.

Offene Fragen

Ein paar Dinge, die ich weiter beobachte und im Bewegen der Plattform aktualisieren werde.

Das Qualitätsgefälle zwischen Connector und Dataverse ist derzeit eine qualitative Aussage, die aus Microsofts eigenem Vergleich übernommen wurde. Ich habe noch keinen unabhängigen, anbieterneutralen Benchmark zu Precision und Recall des SharePoint-Groundings gegen eine getunte Qdrant- oder Pinecone-Pipeline gefunden, und ich hätte gern einen. Bis es ihn gibt, ist „der synchronisierte Pfad ruft besser ab" eine Richtungsaussage, keine gemessene.

Auch die Kostenseite ist weicher, als ich gern hätte. Microsofts Azure-AI-Search-Tier-Seite nennt nur ein „hypothetisches Abrechnungsbeispiel von 100 US-Dollar pro Monat", und die kursierenden festeren Zahlen, Basic um 75 und Standard S1 um 245 US-Dollar pro Search-Unit und Monat, stammen von Drittanbieter-Aggregatoren, nicht von Microsoft. Die Richtungsaussage hält: Ein DIY-Tier ist eine neue wiederkehrende Position und der Tenant-Index ist es nicht. Das genaue Delta verdient eine echte Messung.

Ich erwarte auch, dass die Caps sich bewegen. Die 7-MB- und 2.048-Zeilen-Limits lesen sich wie Speicherbudget-Artefakte, nicht wie dauerhafte Designentscheidungen, und Work IQ hebt die Dateigrenze mit einer Lizenz bereits auf 200 MB. Lockern sich diese Zahlen, schrumpft der 20-%-Fall für DIY weiter. Die Quotas-Seite jedes Quartal zu prüfen lohnt sich.

Wenn Sie interne Agents betreiben und Ihre Pfadwahl oder Ihre Zahlen anders aussehen als meine, will ich die Korrektur. Ich erwarte, dass Teile dieses Stücks altern, insbesondere die Caps und die Kostenzahlen. Der schnellste Weg, mich umzustimmen, ist ein konkretes Gegenbeispiel, in dem die DIY-Pipeline den Tenant-Index auf einer Last schlug, die nach den 80 % aussah. Erreichen Sie mich über marcus-duwe.de/contact. Wenn Ihr Problem in den 20 % liegt und Sie den tunbaren Pfad skopen, ist der Rest des Archivs frei, und ich vergleiche gern Notizen.