Consulting Briefing · 13.08.2026 · boddenberg.de

Microsoft 365 Copilot: Neue Enterprise-Datenquellen-Integration

Executive Summary

Microsoft hat den Katalog der Copilot Connectors auf über einhundert vorgefertigte Anbindungen aufgebohrt und dabei ziemlich unauffällig die Architektur gewechselt. Es gibt nicht mehr nur den klassischen Weg, bei dem Inhalte in den Microsoft-Graph-Index kopiert werden. Daneben stehen jetzt federierte Connectors, die über das Model Context Protocol live im Quellsystem nachsehen und gar nichts indizieren. Und als dritte Variante schleichen sich persönliche Sync-Connectors in den Tenant, mit denen sich deine Anwender ihr Confluence oder Jira selbst anklemmen – ohne dich vorher zu fragen.

Die gute Nachricht: Die Antwortqualität von Copilot steigt spürbar, sobald das Wissen aus ServiceNow, Confluence, Salesforce, SAP oder dem alten Fileshare mit im Index liegt. Das ist kein Marketing, das ist Mechanik – ein Retrieval-System kann nur finden, was es sieht. Die schlechte Nachricht: Du multiplizierst damit jedes Berechtigungsproblem, das du in diesen Systemen seit fünfzehn Jahren erfolgreich verdrängst. Copilot ist kein Sicherheitsproblem. Copilot ist ein ausgesprochen effizienter Suchscheinwerfer für die Sicherheitsprobleme, die du längst hast.

Und ein Detail, das dich heute Nacht beschäftigen sollte: Von Microsoft veröffentlichte federierte Connectors sind im Tenant standardmäßig aktiv. Du hast genau sieben Kalendertage Vorsprung, in denen ein neuer Connector ausschließlich für Administratoren sichtbar ist. Wer dieses Fenster verpennt, erfährt vom neuen Datenabfluss nicht aus dem Admin Center, sondern aus dem Betriebsrat.

Worum geht es im Detail?

Fangen wir beim Hintergrund an, sonst verstehst du nicht, warum das Ding so gebaut ist, wie es gebaut ist. Copilot ist im Kern kein Modell, das dein Unternehmen kennt. Copilot ist ein Retrieval-System mit einem Sprachmodell obendrauf. Die Qualität der Antwort hängt fast vollständig davon ab, was das Retrieval findet – und das Retrieval schaut in den Microsoft Graph. Was nicht im Graph liegt, existiert für Copilot schlicht nicht.

Genau deshalb waren die ersten Copilot-Piloten in vielen Häusern so ernüchternd. Das halbe Unternehmenswissen liegt in Confluence, ServiceNow, Salesforce, SAP oder auf einem Fileserver, den seit 2014 niemand mehr angefasst hat. Copilot hat dann brav geantwortet, dass es dazu leider keine Informationen findet, und der Vorstand hat gefragt, wofür man eigentlich bezahlt. Die Connectors sind Microsofts Antwort auf genau diese Frage.

Inzwischen musst du drei Bauarten sauber auseinanderhalten, weil sie sich in Betrieb, Lizenz und Risiko fundamental unterscheiden.

Synchronisierte Connectors mit Tenant-Konfiguration sind der klassische Weg. Ein Administrator richtet die Verbindung einmal ein, ein Crawler läuft nach Zeitplan gegen das Quellsystem und schiebt jedes Element mitsamt Metadaten und einer Zugriffssteuerungsliste in den Microsoft Graph. Danach ist der Inhalt volltextindiziert, wird vom semantischen Index verarbeitet und taucht in Copilot Chat, Copilot Search und Microsoft Search auf – mit Quellenkennzeichnung und Sprung ins Ursprungssystem. Das funktioniert auch für Quellen im eigenen Rechenzentrum, dafür gibt es den Graph Connector Agent, der die Brücke nach innen baut.

Synchronisierte Connectors mit persönlicher Konfiguration sind neu und stehen aktuell als Vorschau für einen begrenzten Kundenkreis bereit. Hier gibt der Administrator den Connector nur frei, verbunden wird mit den Zugangsdaten des Anwenders. Unterstützt werden bislang Confluence Cloud und Jira Cloud. Der Zuschnitt ist bewusst schmal: der komplette persönliche Bereich plus alles, was in den letzten 90 Tagen in geteilten Bereichen erstellt oder geändert wurde. Die Erstindizierung dauert 30 Minuten bis einige Stunden, danach läuft etwa alle 15 Minuten ein inkrementeller Abgleich und rund alle sieben Tage eine Vollsynchronisation. Trennt der Anwender die Verbindung oder schaltet der Administrator ab, verschwinden die indizierten Inhalte wieder.

Federierte Connectors sind der eigentliche Architekturbruch. Sie indizieren nichts. Sie sprechen über das Model Context Protocol mit einem entfernten Server, holen die Daten zur Laufzeit und werfen sie nach der Antwort wieder weg. Der Zugriff erfolgt mit der Identität des angemeldeten Anwenders über OAuth 2.0, die Verbindungen sind ausschließlich lesend und lassen sich in Microsoft Purview auditieren. Der Katalog liest sich wie ein Branchenverzeichnis: FactSet, LSEG, Moody's, Morningstar, PitchBook und S&P Global für Finanzdienstleister, Harvey und BoardWise im Rechtsbereich, Linear, Hugging Face und Context7 für Entwickler, dazu Notion, HubSpot, Canva, Wolfram und ein gutes Dutzend weiterer.

Abbildung 1: Synchronisierte und federierte Connectors im Vergleich – und die Governance-Punkte, an denen du tatsächlich eingreifen kannst.

Der wichtigste Satz zu federierten Connectors steht im Kleingedruckten: Sie wirken nur in drei Oberflächen. Microsoft 365 Copilot Chat, Copilot in Excel und der Researcher-Agent. Wenn dein Fachbereich erwartet, dass die Live-Marktdaten auch in Word oder in einem selbstgebauten Agenten auftauchen, wird das ein unangenehmes Gespräch. Führe es lieber vor dem Pilotbetrieb als danach.

Eingerichtet wird alles im Microsoft 365 Admin Center unter Copilot und Connectors. Die dafür nötige Rolle heißt AI Administrator – nicht Global Administrator, nicht SharePoint Administrator. Für die vorgefertigten synchronisierten Connectors brauchst du zusätzlich administrative Rechte im Quellsystem, also etwa Google Workspace Super Admin oder Confluence Admin. Wer glaubt, das nebenbei mit einem Dienstkonto aus dem Betrieb zu erledigen, hat noch nie versucht, von einem Fachbereich ein Konto mit Vollzugriff zu bekommen.

Im Standardablauf wählst du die Quelle aus der Galerie, vergibst einen Namen, hinterlegst Adresse und Authentifizierung, rollst optional auf eine Testgruppe aus und lässt den Connector loslaufen. Interessant wird es erst unter dem benutzerdefinierten Setup. Dort entscheidest du in drei Registern über Erfolg oder Desaster.

Im Register für Benutzer legst du fest, ob indizierte Inhalte nur für Berechtigte sichtbar sind oder für jeden in der Organisation. Diese eine Auswahlmöglichkeit ist die gefährlichste Schaltfläche im gesamten Copilot-Umfeld. Sie ist bequem, sie beschleunigt jeden Machbarkeitsnachweis, und sie hebelt mit einem Klick das Berechtigungskonzept eines kompletten Fachsystems aus. Die Zuordnung der Identitäten erfolgt standardmäßig über den Abgleich der Mailadresse mit UserPrincipalName oder Mail in Entra ID – wer historisch gewachsene Adressen im Quellsystem hat, sollte das vorher prüfen und notfalls eine eigene Zuordnungsformel hinterlegen.

Im Register für Inhalte definierst du das Schema. Jede Eigenschaft kann durchsuchbar, abfragbar, abrufbar und filterbar sein, dazu vergibst du semantische Bezeichnungen wie Titel, Adresse, Ersteller, letzter Bearbeiter, Autoren sowie Erstell- und Änderungsdatum. Die Bezeichnung Titel ist die wichtigste – ohne sie nimmt deine Verbindung nicht an der Ergebnisgruppierung teil. Und jetzt der Teil, den man einmal im Leben schmerzhaft lernt: Das Attribut für Filterbarkeit lässt sich nach dem Setup weder hinzufügen noch entfernen, die Abrufbarkeit lässt sich nicht mehr zurücknehmen, und wer die Werte von Schema-Eigenschaften wie der Zugriffsadresse nachträglich anpassen will, muss die Verbindung komplett neu anlegen. Ein Connector ist keine Einstellung, ein Connector ist eine Entscheidung.

Im Register für die Synchronisation planst du die Crawls. Vollständige Durchläufe verarbeiten alles, inkrementelle nur Neues und Geändertes, die Frequenz reicht von 15 Minuten bis 12 Stunden bei täglicher, wöchentlicher, zweiwöchentlicher oder monatlicher Wiederholung. Und hier lauert die Falle, die dir in jedem Audit um die Ohren fliegt: Inkrementelle Durchläufe verarbeiten keine Berechtigungsänderungen. Wenn der Mitarbeiter aus der Konzernentwicklung in den Vertrieb wechselt, weiß dein Index das erst nach dem nächsten vollständigen Durchlauf. Bis dahin beantwortet Copilot ihm ausgesprochen freundlich Fragen zur Portfoliostrategie.

Die Lizenzlage ist erfreulich klar und trotzdem ein zuverlässiger Projektstopper. Mit reinen Microsoft-365-Lizenzen bekommst du Connector-Inhalte ausschließlich in Microsoft Search – kein Grounding in Copilot. Erst das Microsoft 365 Copilot Add-on oder Microsoft 365 E7 schaltet sowohl das Grounding als auch die federierten Connectors frei. Mit einer Copilot-Studio-Lizenz oder dem nutzungsbasierten Copilot-Modell bekommst du Agenten, aber kein Grounding im Standard-Copilot und definitiv keine federierten Connectors. Letztere verlangen zwingend für jeden abfragenden Anwender eine Add-on-Lizenz.

Beim Indexvolumen hat Microsoft die früheren 500 Elemente pro Lizenz beerdigt. Heute gilt eine Berechtigung auf Tenant-Ebene in der Größenordnung von 50 Millionen Elementen, und für Tenants mit Microsoft-365-Lizenzen entstehen durch das Indizieren über synchronisierte Connectors keine zusätzlichen Kosten. Wer trotzdem gegen die Grenze läuft, hat kein Lizenzproblem, sondern ein Kurationsproblem.

Auf der Netzwerkseite bleibt Handarbeit. Wenn dein Quellsystem hinter einer Firewall mit IP-Regeln steht, musst du die Adressbereiche des Connector-Dienstes freigeben, in Europa 20.54.41.208/30 und 51.105.159.88/30. Das klingt banal, kostet aber verlässlich zwei Wochen, weil die Freigabe über drei Abteilungen läuft, von denen zwei gerade Urlaubssperre haben.

Was sind Chancen? Was sind Risiken?

Der Nutzen ist real und er ist größer, als die übliche Skepsis vermuten lässt. Ein mittelständischer Maschinenbauer hat seine Servicetechniker jahrelang zwischen drei Systemen pendeln lassen: Störungsbeschreibungen in ServiceNow, Reparaturanleitungen in Confluence, Ersatzteilstamm in SAP. Nach der Anbindung von zwei dieser Quellen beantwortet Copilot Fragen wie „Welche Maßnahmen gab es bei Fehlercode 4711 an der Baureihe X?“ in einem Rutsch – mit Zitat und Sprung ins Ursprungssystem. Die eingesparte Zeit pro Vorgang ist unspektakulär. Die Summe über 120 Techniker und ein Jahr ist es nicht.

Der zweite große Hebel sind eigene Agenten. Ein Connector ist die Wissensquelle, aus der ein Agent im Copilot Studio schöpft. Damit baust du in wenigen Tagen einen Servicedesk-Agenten, der aus der echten Wissensdatenbank antwortet, statt zu fabulieren – und der über Power-Platform-Connectors sogar Tickets anlegen kann. Federierte Connectors wiederum erlauben dir, hochsensible oder hochvolatile Daten anzubinden, ohne dass eine einzige Zeile davon in Microsoft 365 landet. Für Preise, Bestände und Marktdaten ist das genau die richtige Bauform.

Abbildung 2: Entscheidungsmatrix – welche Quelle welchen Connector-Typ bekommt und welche du besser gar nicht erst anbindest.

Jetzt die Risiken, und die sind unangenehm konkret. Erstens die Überfreigabe. In Confluence liegt in jedem zweiten Unternehmen ein Bereich mit dem Namen „Reorganisation“, dessen Berechtigung 2019 auf „Alle angemeldeten Benutzer“ gesetzt wurde, weil es schnell gehen musste. Solange das Ding nur über die Confluence-Suche auffindbar war, hat es niemand gefunden. Nach dem Crawl formuliert Copilot daraus auf Zuruf eine höfliche Zusammenfassung. Der Connector hat dabei keinen Fehler gemacht. Er hat exakt getan, was du ihm gesagt hast.

Zweitens die Verzögerung beim Rechteabgleich, die oben schon erwähnt wurde. Drittens: Bei federierten Connectors verlassen Anfragen und Kontext deinen Tenant und laufen an einen fremden MCP-Server. Technisch sauber über OAuth abgesichert – datenschutzrechtlich aber eine Übermittlung, die du mit Auftragsverarbeitungsvertrag, Verzeichnis von Verarbeitungstätigkeiten und einer ehrlichen Antwort auf die Frage nach dem Serverstandort belegen musst. Viertens: Der Auslieferungszustand ist „aktiv“. Von Microsoft veröffentlichte federierte Connectors sind eingeschaltet, sofern du sie nicht abschaltest, und neue kommen laufend dazu.

Und fünftens ein Risiko, das kein Sicherheitsthema ist, sondern ein Reputationsthema. Wenn du 400.000 Elemente ungefiltert in den Index kippst, darunter zehn Jahre alte Entwürfe, doppelte Handbuchversionen und Tickets mit dem Inhalt „test test“, dann sinkt die Antwortqualität messbar. Copilot wird davon nicht dümmer – aber deine Anwender schließen genau das daraus, und danach bekommst du sie nicht mehr zurück.

Was müssen wir jetzt schon vorbereiten?

Die Reihenfolge der Maßnahmen entscheidet über den Projekterfolg, deshalb der Fahrplan als Bild. Der wichtigste Punkt steht ganz vorn und kostet dich einen Nachmittag: Entscheide bewusst über den mandantenweiten Schalter für federierte Connectors. Du kannst per PowerShell alle auf einmal deaktivieren und danach gezielt einzelne freigeben. Diese Einstellung wirkt auch auf alle künftig veröffentlichten Connectors – sie ist der einzige Hebel, der dich vor der nächsten Katalogerweiterung schützt, ohne dass du wöchentlich das Admin Center kontrollieren musst.

Abbildung 3: 90-Tage-Fahrplan – die Reihenfolge ist wichtiger als das Tempo.

Parallel dazu brauchst du eine Inventur, und zwar keine technische, sondern eine fachliche. Für jede Kandidatenquelle gilt: Wer ist Datenowner? Auf welcher Rechtsgrundlage? Und welche Frage soll Copilot damit beantworten können, die er heute nicht beantworten kann? Wenn die letzte Frage nur mit „allgemein mehr Transparenz“ beantwortet wird, ist die Quelle nicht reif. Ein Connector ohne konkreten Anwendungsfall erzeugt Indexrauschen und Governance-Aufwand, sonst nichts.

Danach kommt der unbeliebteste Teil: die Sanierung der Berechtigungen im Quellsystem. Nicht in Microsoft 365 – im Quellsystem. Verwaiste Gruppen, offene Bereiche, Freigaben an jedermann, Dienstkonten mit Vollzugriff. Der Copilot-Index übernimmt exakt das Modell, das er vorfindet, inklusive aller Sünden. Parallel richtest du Microsoft Purview aus: Vertraulichkeitsbezeichnungen, eine DLP-Richtlinie für den Copilot-Standort und die Datenrisikobewertungen aus DSPM for AI, die dir Überfreigaben systematisch aufzeigen und inzwischen auch die Massenkorrektur von Freigabelinks erlauben.

Für den Pilotbetrieb gilt: ein Connector, eine Entra-Gruppe, gestaffelter Rollout. Nutze die Beschreibungsfelder ernsthaft – Microsoft wertet aus, welche Inhalte die Verbindung enthält und wie Anwender darüber sprechen, um die Trefferwahrscheinlichkeit zu erhöhen. Ein Wort wie „ServiceNow“ hilft niemandem, „Freigegebene IT-Wissensartikel zu Arbeitsplatz, VPN und Druckern, im Alltag Servicedesk-Artikel genannt“ dagegen sehr.

Und schließlich der Betrieb, den in der Planung immer alle vergessen. Ein Connector ist kein Projekt mit Enddatum. Du brauchst einen Crawl-Kalender mit mindestens einem vollständigen Durchlauf pro Woche, damit Berechtigungsänderungen ankommen. Du brauchst jemanden, der auf fehlgeschlagene Synchronisationen reagiert, bevor der Fachbereich es merkt. Und du brauchst einen Feedbackweg, über den Anwender schlechte Antworten melden können – denn in neun von zehn Fällen ist die Ursache nicht das Modell, sondern eine schlecht gepflegte Quelle.

Konkret gehst du in dieser Reihenfolge vor:

Mandantenweiten Schalter für federierte Connectors bewerten und per PowerShell setzen – er wirkt auch auf alle künftig veröffentlichten Connectors.

Rolle „AI Administrator“ sauber besetzen und dokumentieren, wer sie warum hat.

Quelleninventar mit Datenowner, Rechtsgrundlage und konkretem Anwendungsfall je Quelle anlegen.

Berechtigungen im Quellsystem sanieren – vor dem ersten Crawl, nicht danach.

Purview scharf stellen: Vertraulichkeitsbezeichnungen, DLP für Copilot, Datenrisikobewertungen über DSPM for AI.

Firewall-Freigaben für die IP-Bereiche des Connector-Dienstes beantragen – früh, das dauert.

Pilotbetrieb mit genau einem Connector und einer Entra-Gruppe über gestaffelten Rollout.

Crawl-Kalender festlegen: inkrementell für Aktualität, mindestens wöchentlich vollständig für die Berechtigungen.

Betriebsverantwortung und Feedbackweg für schlechte Antworten festlegen.

Häufig gestellte Fragen

Braucht jeder Anwender eine Copilot-Lizenz, damit Inhalte aus Connectors in den Antworten auftauchen?

Für die Nutzung in Microsoft Search reicht eine normale Microsoft-365-Lizenz aus. Sobald die Inhalte aber als Grundlage für Copilot-Antworten dienen sollen, braucht der Anwender das Microsoft 365 Copilot Add-on oder Microsoft 365 E7 – und bei federierten Connectors gilt diese Add-on-Pflicht ausnahmslos für jeden, der die Quelle abfragt.

Kostet das Indizieren externer Daten zusätzliches Geld?

Nein. Für Tenants mit Microsoft-365-Lizenzen entstehen durch das Indizieren über synchronisierte Connectors keine zusätzlichen Kosten, und das früher geltende Kontingent von 500 Elementen pro Lizenz wurde durch eine deutlich großzügigere Berechtigung auf Tenant-Ebene ersetzt. Kosten entstehen über die Lizenzen der Anwender und über den Betriebsaufwand, nicht über das Indexvolumen.

Kann ein Anwender über Copilot Dokumente sehen, die er im Quellsystem gar nicht sehen darf?

Grundsätzlich übernimmt der Connector die Berechtigungen aus der Quelle, und Copilot zeigt nur, was der Anwender ohnehin öffnen dürfte. Riskant wird es in zwei Fällen: wenn bei der Einrichtung bewusst die Sichtbarkeit für alle in der Organisation gewählt wurde, und wenn ausschließlich inkrementell synchronisiert wird – denn Berechtigungsänderungen kommen erst mit dem nächsten vollständigen Durchlauf im Index an.

Wann nehme ich einen synchronisierten und wann einen federierten Connector?

Synchronisiert nimmst du für stabiles Wissen, das viele Menschen finden sollen: Wikis, Handbücher, Wissensdatenbanken, Tickets. Federiert nimmst du für Daten, die sich ständig ändern oder die dein Haus aus rechtlichen Gründen nicht kopieren will, etwa Preise, Bestände und Marktdaten. Dafür musst du akzeptieren, dass diese Inhalte nur in Copilot Chat, Copilot in Excel und im Researcher-Agenten zur Verfügung stehen.

Wie verhindere ich, dass neue Connectors automatisch in meinem Tenant aktiv werden?

Von Microsoft veröffentlichte federierte Connectors sind standardmäßig aktiviert und nur sieben Kalendertage lang ausschließlich für Administratoren sichtbar. Mit dem mandantenweiten Schalter beziehungsweise dem entsprechenden PowerShell-Befehl deaktivierst du alle auf einmal, und diese Einstellung greift auch für alle künftig veröffentlichten Connectors.