SharePoint on DR.365

Team Knowledge Base in SharePoint: Copilot kompiliert das Wissen, Agents lesen es

Wed, 14 Oct 2026 07:00:00 +0200

Microsoft hat am 14. Oktober 2026 im SharePoint-Blog eine „Team Knowledge Base“ vorgestellt. Copilot stellt dabei aus den Inhalten eines Teams eine eigene Wissensbasis zusammen: eine Bibliothek aus verlinkten Markdown-Dateien, die Menschen lesen können und die Agents als Grounding dient. Das Ganze startet als Frontier Preview und läuft über usage-based billing.

Für mich ist das die spannendste SharePoint-Ankündigung seit Längerem, weil sie verändert, worauf ein Agent seine Antworten stützt. Aus demselben Grund habe ich dazu auch die meisten Fragen.

Was ist eigentlich neu?

Bisher lief das Grounding in Microsoft 365 über Retrieval. Copilot oder ein Agent sucht zur Frage passende Stellen in den Originaldokumenten und formuliert daraus die Antwort. Der Knowledge Agent in SharePoint hat diese Dokumente zwar aufgewertet, mit Metadaten und Struktur. Die Grundlage der Antwort blieb aber immer das Original.

Die Team Knowledge Base schiebt eine Schicht dazwischen. Copilot liest die Teaminhalte und kompiliert daraus eine eigene Wissensbasis. Technisch ist das eine spezielle Bibliothek, deren Markdown-Dateien untereinander verlinkt und so aufgebaut sind, dass Agents gut damit arbeiten können. Erzeugt wird sie von der „Knowledge Compilation Engine“, die zu Work IQ gehört. Was Work IQ sonst umfasst, habe ich im Beitrag zu RAG und Foundry IQ kurz eingeordnet.

Beim Retrieval entsteht das Wissen bei jeder Anfrage neu aus den Rohdaten. In der Knowledge Base liegt es vorab aufbereitet als eigenes Artefakt, das man öffnen, lesen und korrigieren kann. Ein Agent muss sich seine Antwort dann nicht mehr aus zwanzig Versionen derselben Präsentation zusammensuchen.

So funktioniert’s

Am Anfang steht eine bewusste Entscheidung im Team: Die Mitglieder steuern gezielt E-Mails, Chats, Meetings und Inhalte der Site bei. Die Knowledge Compilation Engine macht daraus die verlinkten Markdown-Dateien. Danach hält Copilot den Bestand aktuell. Anlegen, ergänzen und kuratieren können sowohl Copilot als auch Agents, die Wissensbasis ist also kein einmaliger Export.

Hängen lässt sie sich an jede SharePoint-Site, ausdrücklich auch an Sites hinter Teams-Kanälen und Microsoft-365-Gruppen. Das sind in den meisten Tenants genau die Orte, an denen die eigentliche Teamarbeit liegt.

Genutzt wird die Wissensbasis über Copilot in SharePoint und über den Autopilot in der neuen Copilot-App. Über den Autopilot kommt man auch aus Teams heran oder schreibt ihm einfach eine E-Mail. Der Autopilot wird allerdings separat ausgerollt. Nur weil die Knowledge Base im Tenant aktiv ist, steht er also nicht automatisch zur Verfügung.

Zur Leistung nennt Microsoft Zahlen aus eigenen internen Tests vom Oktober 2026: Agent-Antworten seien mit der Wissensbasis bis zu viermal schneller und 30 % tokeneffizienter. Das sind Herstellerangaben. Ich würde sie erst einplanen, wenn ich sie mit eigenen Inhalten nachvollzogen habe.

Als Beispiele skizziert Microsoft Szenarien aus drei Bereichen. Im Legal-Team bündelt die Wissensbasis das Wissen rund um Verträge. In der Entwicklung liefert sie Kontext für Coding-Agents und hilft beim Onboarding neuer Teammitglieder. Im Vertrieb entstehen Account-Snapshots. Das Engineering-Szenario finde ich am interessantesten: Ein Coding-Agent, der die Architekturentscheidungen aus dem Teams-Kanal kennt, schreibt vermutlich brauchbareren Code als einer, der nur das Repository sieht.

Verfügbarkeit und Lizenzierung

Stand heute gibt es die Team Knowledge Base nur in der Frontier Preview und nur für User mit usage-based billing. Gesteuert wird sie im Microsoft 365 Admin Center. Microsoft weist ausdrücklich darauf hin, dass sich die Abrechnungsbedingungen bis zur allgemeinen Verfügbarkeit noch ändern können.

Praktisch heißt das: Es gibt keinen festen Preis pro Lizenz, die Kosten hängen von der Nutzung ab, und die Regeln dafür sind noch nicht final. Für einen Pilot würde ich mir deshalb ein Team mit überschaubarem, gut gepflegtem Inhalt suchen. Die Abteilungs-Site mit zehn Jahren Altlasten ist dafür der falsche Startpunkt.

Roadmap

Für die Zeit nach der Preview hat Microsoft mehrere Ausbaustufen angekündigt, allerdings ohne Termine:

Knowledge Bases auch in Cowork, in Copilot in Teams und in Agents aus Copilot Studio
engere Integration mit Microsoft-365-Gruppen, inklusive Bootstrapping der Wissensbasis aus Kanälen und Mail
automatische Kuratierung über Agent Flows in Copilot Studio
Skalierung auf größere Bestände über einen Ansatz namens „Corpus Map“
Anbindung an CLIs und Coding-Agents über Work IQ

Im selben Zug gab es eine Reihe weiterer SharePoint-Neuigkeiten. Copilot in SharePoint ist jetzt allgemein verfügbar, die SharePoint-Tools in Work IQ sind nutzbar, und dazu kommen ein SharePoint Admin Agent, Catalog Management, ein Berechtigungsreport für EEEU („Everyone except external users“) auf Dateiebene, Insights zum Zugriff von Agents und ein Governance Hub für Site Owner. Den EEEU-Report und die Insights zum Agent-Zugriff würde ich mir als Erstes ansehen. Mit ihnen findet man Oversharing, bevor zu weit geteilte Inhalte in eine Wissensbasis wandern.

Einordnung und offene Fragen

Viele meiner Kunden arbeiten in regulierten Umgebungen, bei KRITIS-Betreibern oder unter NIS2. Dort entscheidet sich ein Feature wie dieses an Fragen, die die Ankündigung nicht beantwortet. Ich formuliere sie bewusst als offene Fragen, weil ich die Antworten nicht kenne.

Berechtigungen. Die Markdown-Dateien sind neue Dateien in einer Bibliothek. Erben sie die Berechtigungen der Quellen oder die der Bibliothek? Was passiert, wenn eine Mail einfließt, die nur ein Teil des Teams lesen durfte? Sieht dann das ganze Team die daraus abgeleitete Zusammenfassung?

Sensitivity Labels. Übernimmt eine Datei, die aus einem als vertraulich gelabelten Dokument entsteht, dieses Label? Und welches Label gilt, wenn eine Datei Inhalte aus mehreren Quellen mit unterschiedlichen Labels zusammenführt? Bei Mails und Chats ist das besonders heikel, weil dort Labels oft anders gesetzt werden als in Dokumentbibliotheken.

Retention. Mails, Chats und Site-Inhalte unterliegen häufig unterschiedlichen Aufbewahrungsrichtlinien. Wird ein abgeleiteter Inhalt entfernt, wenn das Original nach Ablauf der Frist gelöscht wird? Oder lebt er in der Wissensbasis nach den Regeln der Bibliothek weiter? Für Löschpflichten und eDiscovery macht das einen erheblichen Unterschied.

Kostenkontrolle. Wenn Copilot die Wissensbasis laufend aktuell hält, wie viel Verbrauch entsteht dann, auch wenn gerade niemand eine Frage stellt? Lässt sich der Verbrauch pro Site oder Team begrenzen, und wie gut sieht man vorab, was ein Pilot kosten wird?

Ein Werkzeug dafür gibt es schon: Im Microsoft 365 Admin Center lassen sich unter Copilot > Cost Management Ausgabenrichtlinien mit Limits für die Organisation und pro User festlegen (Microsoft Learn). Die Einstellung „Auto-apply new services“ ist dort standardmäßig aktiv, neue unterstützte Dienste fallen also automatisch unter bestehende Richtlinien. Ob die Knowledge Base dort als eigener Dienst auftaucht, geht aus der Ankündigung nicht hervor. Wer neue Features vor der Freigabe prüfen will, sollte die Einstellung in den betroffenen Richtlinien abschalten.

Solange diese Punkte nicht geklärt sind, würde ich die Knowledge Base an keine Site hängen, auf der regulierte oder personenbezogene Daten liegen. Für einen Pilot mit unkritischem Inhalt spricht dagegen nichts.

Fazit

Die Team Knowledge Base ist ein echter Architekturwechsel: Agents antworten auf Basis einer gepflegten, lesbaren Zwischenschicht statt direkt auf Rohdokumenten. Wie gut das in der Praxis trägt, hängt an der Vererbung von Berechtigungen, Labels und Aufbewahrung. Darauf würde ich in der Preview zuerst schauen, noch vor den Performance-Zahlen.

Quellen

RAG für Agents: wo ein einfacher Agent an Grenzen stößt und was Foundry IQ daran ändert

Mon, 12 Oct 2026 07:00:00 +0200

Diese Woche (12. bis 14. Oktober 2026) sitze ich in der Schulung zu AI-103, Developing AI Apps and Agents on Azure. Eine Folie hat einen einfachen Agent mit einem RAG-Agent verglichen: links fünf Grenzen, rechts fünf Lösungen. Die Folie stimmt. Als Service Owner für M365 Collaboration und Copilot bei einem IT-Dienstleister mit Kunden aus regulierten Branchen (KRITIS, NIS2) lese ich sie aber mit SharePoint, Berechtigungen und Governance im Hinterkopf, und dann sehen einige der Lösungen nach neuer Arbeit für die Leute aus, die die Daten verantworten.

Kurz gesagt

Mit RAG ist ein Agent nur so aktuell, korrekt und sicher wie die Inhalte und Berechtigungen dahinter. Oversharing und veraltete Dokumente in SharePoint werden direkt zu schlechten Antworten.

Foundry IQ bietet eine gemeinsame Knowledge Base für viele Agents, aufgebaut auf Agentic Retrieval in Azure AI Search. Damit muss nicht mehr jedes Team seine eigene Pipeline bauen.

Stand Oktober 2026 sind genau die Teile, die du für SharePoint in einem regulierten Tenant brauchst (beide SharePoint-Knowledge-Sources, LLM-Query-Planning, Rechteprüfung), noch in Preview.

RAG in wenigen Sätzen

Ein Sprachmodell kennt nur seine Trainingsdaten. Retrieval Augmented Generation (RAG) schiebt vor die Antwort einen Suchschritt: Der Agent durchsucht angebundene Quellen nach passenden Textstellen, gibt sie dem Modell mit in den Prompt und lässt es auf dieser Grundlage antworten, idealerweise mit Verweis auf die Quelle jeder Aussage. Das Modell bleibt dasselbe, nur das Material, mit dem es arbeitet, ändert sich.

Fünf Grenzen eines einfachen Agents

Grenze eines einfachen Agents	Was ohne RAG passiert	Was RAG ändert
Knowledge Cutoff	Antworten spiegeln den Stand der Trainingsdaten, Richtlinien und Produkte können Monate oder Jahre veraltet sein.	Aktuelle Dokumente werden zum Zeitpunkt der Frage aus angebundenen Quellen geholt.
Kein Zugriff auf interne Daten	Der Agent liefert nur Allgemeinwissen, nicht deinen Prozess, deinen Vertrag, dein System.	Interne Wissensbasen werden für den Agent durchsuchbar.
Fehlender Unternehmenskontext	Ratschläge ignorieren Freigabeketten, Workflows und Security-Policies.	Antworten stützen sich auf die abgerufenen Richtlinien und Abläufe.
Erfundene Antworten	Plausible, aber falsche Aussagen werden zum Compliance-Risiko.	Antworten verweisen auf ihre Quelle und lassen sich prüfen.
Skalierung	Jedes Team baut und betreibt eine eigene RAG-Pipeline mit eigenem Index, Chunking und eigener Rechtelogik.	Eine gemeinsame Wissensplattform bedient viele Agents, zum Beispiel Foundry IQ.

Wo die Folie zu optimistisch ist

„Immer aktuell“ heißt „so aktuell wie der Index“

Foundry IQ unterscheidet zwei Arten von Knowledge Sources. Indizierte Quellen kopieren Inhalte in einen Azure-AI-Search-Index: Chunking, Embeddings, Metadaten, optional Berechtigungen. Sie sind so frisch wie der letzte Indexer-Lauf, und den Zeitplan legst du selbst fest. Remote-Quellen speichern nichts und fragen das Quellsystem zum Zeitpunkt der Suche ab. Die Inhalte sind damit per Design aktuell.

Für Berechtigungen gilt dieselbe Logik, und da würde ich genauer hinschauen als beim Inhalt. Für indiziertes SharePoint mit ACL-Ingestion (Preview) dokumentiert Microsoft: Rechteänderungen auf Elementebene werden beim nächsten Indexer-Lauf übernommen. Änderungen auf übergeordneter Ebene (Site, Bibliothek, Ordner) nicht, dafür braucht es einen expliziten Resync. Bis dahin liefert der Index veraltete Berechtigungen. Wenn dein Offboarding oder dein Need-to-know-Prinzip darauf beruht, jemanden aus einer Site zu entfernen, gehört diese Lücke in die Risikobewertung.

Eine Quellenangabe macht eine Antwort nicht richtig

Ein Quellenverweis belegt, dass eine Textstelle gefunden wurde. Er belegt nicht, dass es die richtige war, dass sie noch gilt oder dass das Modell sie korrekt wiedergegeben hat. RAG reduziert Halluzinationen, es beseitigt sie nicht. Das Modell kann zwei richtige Textstellen zu einem falschen Schluss verbinden oder die Fassung einer Richtlinie von 2023 zitieren, weil sie höher gerankt wurde als die von 2026. Quellen machen Fehler leichter auffindbar, nachsehen muss trotzdem jemand.

RAG macht SharePoint-Hygiene zur Agent-Qualität

Mit RAG hängen die Antworten des Agents direkt davon ab, was in den Quellen liegt. Alles, was dich in SharePoint ohnehin stört, landet in den Antworten:

Oversharing: Zu breit geteilte Inhalte werden gefunden und zitiert, denn die Rechteprüfung arbeitet mit den Berechtigungen, die existieren, nicht mit denen, die du gemeint hast.
Veraltete Dokumente: Eine alte Richtlinie, die niemand archiviert hat, konkurriert mit der aktuellen.
Dubletten: Drei Kopien derselben Prozessbeschreibung in drei Versionen geben der Retrieval-Engine drei Optionen zur Auswahl.

Berechtigungen und Sensitivity Labels werden damit zum Steuerungsinstrument für Qualität. Eine Knowledge Source auf die richtigen Sites eingrenzen, Freigaben an „Jeder außer externen Benutzern“ entfernen und veraltete Inhalte archivieren verbessert direkt die Antworten.

Ein Agent kennt nur die Freigabekette, die aufgeschrieben ist

RAG kann Antworten nur auf Freigabeketten und Security-Policies stützen, die irgendwo dokumentiert sind, wo der Agent sie findet. In vielen Organisationen existiert die tatsächliche Freigabekette in den Köpfen der Beteiligten oder in einem Teams-Chat von 2022. In der Praxis beginnt ein RAG-Projekt deshalb oft als Dokumentationsprojekt.

Foundry IQ kurz erklärt

Foundry IQ ist die verwaltete Wissensschicht in Microsoft Foundry (früher Azure AI Foundry). Sie besteht aus drei Bausteinen, die alle auf Azure AI Search laufen:

Knowledge Base: das Objekt auf oberster Ebene. Es bündelt eine oder mehrere Knowledge Sources und steuert das Retrieval-Verhalten. Mehrere Agents können sich eine Knowledge Base teilen.
Knowledge Sources: Verbindungen zu indizierten oder Remote-Inhalten. Stand Oktober 2026 listet Microsoft Learn unter anderem Suchindex, Azure Blob, OneLake, Azure SQL, Datei-Upload, indiziertes und Remote-SharePoint, Fabric Data Agents und Ontologien, MCP-Server, Work IQ und Web-Grounding über Bing.
Agentic Retrieval: die Retrieval-Engine. Mit einem optionalen LLM zerlegt sie eine Frage in Teilabfragen (Query Planning), wählt die passenden Quellen, sucht parallel, rankt die Ergebnisse neu und liefert extrahierte Inhalte mit Quellenverweisen. Wie viel LLM-Arbeit dabei anfällt, steuert der Retrieval Reasoning Effort: minimal ohne LLM (bis zu 10 Quellen), low mit drei Quellen und drei Teilabfragen, medium mit je fünf plus einem iterativen Durchlauf.

Agents binden die Knowledge Base über ihren MCP-Endpunkt an: im Foundry Agent Service (als MCP-Tool), mit dem Microsoft Agent Framework oder in jeder eigenen App über REST und SDKs. Copilot Studio erreicht eine Knowledge Base indirekt: Du verbindest einen Foundry-Agent, der die Knowledge Base nutzt, mit deinem Copilot-Studio-Agent (Preview).

Foundry IQ ist einer von drei „IQ“-Workloads. Work IQ liefert Kontext aus der Zusammenarbeit in Microsoft 365 (Dokumente, Meetings, Chats). Fabric IQ modelliert Geschäftsdaten in Microsoft Fabric. Foundry IQ verbindet Unternehmenswissen aus Azure, SharePoint, OneLake und dem Web. Die drei sind unabhängig, lassen sich aber kombinieren; Work IQ gibt es sogar als Knowledge Source in Foundry IQ.

SharePoint als Knowledge Source

Für SharePoint gibt es zwei Wege, Stand Oktober 2026 beide in Preview:

Indiziertes SharePoint erzeugt eine Indexer-Pipeline und kopiert die Inhalte nach Azure AI Search. Berechtigungen greifen nur, wenn du ACL-Ingestion konfigurierst und zur Abfragezeit das Token des Benutzers mitgibst. Die dokumentierten Einschränkungen solltest du vorher lesen: Freigabelinks für „Jeder“ oder „Personen in Ihrer Organisation“ werden nicht unterstützt, Entra-Gruppen innerhalb von SharePoint-Gruppen werden nicht aufgelöst, und laut Dokumentation des SharePoint-Indexers werden Tenants mit aktiviertem Conditional Access nicht unterstützt. Für die meisten regulierten Tenants, die ich kenne, ist allein der letzte Punkt ein K.-o.-Kriterium.

Remote-SharePoint nutzt die Copilot Retrieval API und fragt SharePoint live im Namen des Benutzers ab. Kopiert wird nichts; die Retrieval API setzt SharePoint-Berechtigungen und Microsoft-Purview-Sensitivity-Labels selbst durch. Microsoft empfiehlt diesen Weg für eigene RAG-Apps auf SharePoint. Die Kehrseite: Jeder Benutzer braucht eine Microsoft-365-Copilot-Lizenz oder Retrieval-API-Pay-as-you-go (Preview, setzt mindestens eine Copilot-Lizenz im Tenant voraus). Es gilt ein Limit von 200 Anfragen pro Benutzer und Stunde und maximal 25 Ergebnissen pro Abfrage, OneDrive-Inhalte sind nicht enthalten, und abgerufen wird nur Text.

Wenn deine Benutzer ohnehin Copilot-Lizenzen haben, würde ich Remote-SharePoint zum Standard machen: keine zweite Kopie der Daten, kein zweites Berechtigungsmodell, das synchron bleiben muss.

Was das für regulierte Umgebungen heißt

Rechte-bewusstes Retrieval passiert nicht automatisch. Die Doku ist da eindeutig: Ohne das Token des Benutzers in der Anfrage liefern Quellen mit Rechteprüfung ihre Ergebnisse ungefiltert. Ruft ein Agent die Knowledge Base mit seiner eigenen Managed Identity auf, bekommt jeder Benutzer dieselbe Ergebnismenge. Die Token-Weitergabe gehört vor den ersten Pilot gebaut und getestet, nicht danach.
Nachvollziehbarkeit ist ein echter Gewinn. Verweise mit URLs und Informationen zum Sensitivity Label zeigen, auf welchen Dokumenten eine Antwort beruht. Bei Audit-Fragen ist das deutlich besser als „das Modell hat es so gesagt“, vorausgesetzt, dein Logging hält es fest.
Den Preview-Status Zeile für Zeile prüfen. Mit der stabilen API-Version 2026-04-01 sind nur die Knowledge Sources Suchindex, Azure Blob, OneLake und Web allgemein verfügbar, und das mit Reasoning Effort minimal. Beide SharePoint-Quellen, LLM-Query-Planning, Answer Synthesis und die Berechtigungsfunktionen sind Preview, ohne SLA und nicht für den Produktivbetrieb empfohlen. Im Foundry-Portal und im Azure-Portal stehen alle Agentic-Retrieval-Funktionen nur als Preview zur Verfügung. Für einen KRITIS-Kunden ist das ein Pilot, kein produktiver Service.

In meinem Beitrag zum Vier-Phasen-Modell für verantwortungsvolle generative KI ist Grounding zusammen mit der Systemnachricht die dritte von vier Schutzschichten. Foundry IQ ist ein konkreter Weg, diese Schicht zu bauen. Die anderen drei ersetzt es nicht.

Fazit

Erst aufräumen, dann anbinden. Oversharing, veraltete Dokumente und Dubletten in SharePoint werden zu Fehlern des Agents. Eine Bereinigung auf Site-Ebene ist die günstigste Qualitätsverbesserung, die du bekommst.
Remote-SharePoint bevorzugen, wenn die Benutzer Copilot-Lizenzen haben. Keine zweite Kopie, Berechtigungen und Labels werden an der Quelle durchgesetzt, kein ACL-Sync zu überwachen.
Den Token-Pfad gezielt testen. Ohne ihn liefern Quellen mit Rechteprüfung ungefilterte Ergebnisse, und jeder Benutzer sieht dieselben Inhalte.
Foundry IQ auf SharePoint vorerst als Pilot behandeln. Den Produktivbetrieb planen, sobald die SharePoint-Knowledge-Sources und die Berechtigungsfunktionen allgemein verfügbar sind.