Federated Copilot Connectors sind eine Methode, mit der Microsoft Copilot in Echtzeit auf externe Datenquellen außerhalb des Microsoft-Ökosystems zugreifen kann, ohne diese Daten vorher zu indexieren oder zu kopieren. Statt Inhalte in den Microsoft Graph zu übertragen, werden Anfragen direkt an das Quellsystem weitergeleitet und die Ergebnisse dynamisch zurückgespielt. Dieser Artikel beantwortet die wichtigsten Fragen rund um federated Connectors: von der technischen Funktionsweise über die Einbindung externer Daten bis hin zu Sicherheitsaspekten und der richtigen Wahl zwischen federated und Graph-Connectors.
Wie unterscheiden sich federated Connectors von nativen Microsoft-Datenquellen?
Federated Copilot Connectors unterscheiden sich von nativen Microsoft-Datenquellen dadurch, dass sie keine vorab indexierten Daten im Microsoft Graph verwenden, sondern Anfragen zur Laufzeit direkt an externe Systeme weiterleiten. Native Quellen wie SharePoint, OneDrive oder Teams-Chats sind tief in den Microsoft Graph integriert und stehen Copilot ohne zusätzliche Konfiguration zur Verfügung. Externe Systeme erfordern hingegen einen eigenen Connector.
Bei nativen Datenquellen verarbeitet Copilot Inhalte, die bereits im Microsoft-Ökosystem gespeichert und indiziert sind. Das bedeutet: Wenn du in einem Declarative Agent SharePoint-Dokumente oder Outlook-E-Mails als Wissensquellen einbindest, greift Copilot auf den Microsoft Graph zu, der diese Inhalte bereits kennt und strukturiert hat. Die Reaktionszeiten sind kurz, die Berechtigungssteuerung erfolgt über bestehende Microsoft-365-Mechanismen.
Federated Connectors funktionieren nach einem anderen Prinzip. Sie agieren als Brücke zwischen Copilot und einem externen System wie Confluence, ServiceNow oder GitHub. Statt Daten vorab in den Graph zu übertragen, leitet der Connector eine Nutzeranfrage in Echtzeit an das Zielsystem weiter, ruft dort die relevanten Informationen ab und gibt sie strukturiert an Copilot zurück. Das hat Vorteile, bringt aber auch Anforderungen mit sich, vor allem auf der Seite der Authentifizierung und der Systemverfügbarkeit.
Welche externen Datenquellen lassen sich über federated Copilot Connectors einbinden?
Über federated Copilot Connectors lässt sich eine Vielzahl externer Drittsysteme einbinden, sofern Administrierende die entsprechenden Konnektoren bereitstellen. Zu den unterstützten Plattformen zählen unter anderem Confluence, Jira, ServiceNow, GitHub, Google Drive und Azure DevOps. Welche Systeme konkret verfügbar sind, hängt von der jeweiligen Unternehmensumgebung und den freigeschalteten Konnektoren ab.
Aus Nutzerperspektive ist diese Einbindung besonders dann wertvoll, wenn unternehmensrelevantes Wissen nicht in Microsoft-365-Systemen liegt. Viele Organisationen führen technische Dokumentationen in Confluence, verwalten IT-Tickets in ServiceNow oder speichern Quellcode und Issues in GitHub. Wenn Copilot auf diese Quellen zugreifen kann, wird aus einem auf Microsoft beschränkten Assistenten ein echter unternehmensweiter Wissensassistent.
Wichtig zu verstehen: Die Verfügbarkeit dieser Konnektoren ist nicht automatisch gegeben. Administrierende müssen sie im Microsoft 365 Admin Center oder in Copilot Studio explizit aktivieren und konfigurieren. Erst dann können Nutzende sie beim Erstellen von Agenten als Wissensquellen auswählen. Wer also in einem Copilot Agent auf externe Systeme zugreifen möchte, braucht zunächst die Unterstützung der IT-Administration.
Wie funktioniert die technische Einbindung eines federated Connectors?
Die technische Einbindung eines federated Connectors erfolgt in mehreren Schritten: Administrierende aktivieren und konfigurieren den Connector im Admin Center, stellen Authentifizierungsdaten bereit und legen Zugriffsberechtigungen fest. Danach können Nutzende den Connector als Wissensquelle in einem Copilot-Agenten auswählen. Die eigentliche Kommunikation mit dem Zielsystem läuft dann zur Laufzeit ab.
Konfiguration durch Administrierende
Der erste Schritt liegt immer auf der Administrationsebene. Im Microsoft 365 Admin Center oder direkt in Copilot Studio werden die verfügbaren Konnektoren verwaltet. Für jeden Connector müssen Zugangsdaten, API-Endpunkte und Authentifizierungsmethoden hinterlegt werden. OAuth-basierte Authentifizierung ist dabei der Standard, um sicherzustellen, dass nur berechtigte Personen auf die externen Systeme zugreifen können.
Einbindung durch Nutzende im Agent Builder
Sobald ein Connector administrativ freigegeben ist, erscheint er im Copilot Studio Agent Builder als auswählbare Wissensquelle. Wer einen Declarative Agent erstellt oder bearbeitet, kann den Connector dort hinzufügen, ähnlich wie SharePoint-Bibliotheken oder öffentliche Webseiten. Der Agent Builder speichert diese Konfiguration und leitet bei jeder Nutzeranfrage die relevante Abfrage an das externe System weiter. Für komplexere Automatisierungen oder Aktionen, die über das reine Abrufen von Informationen hinausgehen, ist Copilot Studio erforderlich, da der Agent Builder selbst keine weitergehenden Prozessautomatisierungen unterstützt.
Welche Berechtigungen und Sicherheitsaspekte sind bei federated Connectors zu beachten?
Bei federated Copilot Connectors gelten die Zugriffsberechtigungen des jeweiligen Quellsystems. Copilot gibt einer Person nur Informationen zurück, auf die sie auch im externen System direkt Zugriff hätte. Dieses Prinzip der respektierten Quellberechtigungen ist zentral für die Datensicherheit und verhindert, dass Copilot als unbeabsichtigter Kanal für unautorisierten Datenzugriff dient.
Konkret bedeutet das: Wenn eine Person in Jira nur bestimmte Projekte sehen darf, liefert Copilot auch nur Ergebnisse aus diesen Projekten, selbst wenn der Connector technisch auf das gesamte System zugreifen könnte. Die Berechtigungslogik des Quellsystems bleibt also erhalten und wird nicht durch den Connector ausgehebelt.
Darüber hinaus sind beim Teilen von Agenten, die federated Connectors nutzen, einige Punkte zu beachten. Wer einen solchen Agenten mit anderen teilt, muss sicherstellen, dass die Empfangenden ebenfalls über die notwendigen Zugriffsrechte im externen System verfügen. Andernfalls erhalten sie möglicherweise keine oder unvollständige Antworten, ohne dass eine Fehlermeldung den Grund klar kommuniziert. Administrierende sollten daher beim Einrichten von Connectors klare Richtlinien für Berechtigungen und Freigaben definieren, um solche Situationen zu vermeiden. Fragen rund um Governance und Datenschutz lassen sich im Rahmen einer strukturierten Copilot-Einführung frühzeitig klären.
Wann sollte man federated Connectors statt Graph-Connectors einsetzen?
Federated Connectors sind die bessere Wahl, wenn Daten in Echtzeit abgerufen werden müssen, sich häufig ändern oder nicht im Microsoft Graph indexiert werden sollen. Graph-Connectors eignen sich dagegen besser für Inhalte, die stabil sind, umfangreich durchsucht werden sollen und bei denen eine schnelle Antwortzeit durch vorab indexierte Daten wichtiger ist als Aktualität.
Die Entscheidung hängt von mehreren Faktoren ab:
- Aktualität der Daten: Wenn sich Inhalte im Quellsystem laufend ändern, zum Beispiel IT-Tickets in ServiceNow oder Code-Repositories in GitHub, liefert ein federated Connector immer den aktuellen Stand. Graph-Connectors indexieren Inhalte periodisch und können veraltete Informationen zurückgeben.
- Datenmenge und Durchsuchbarkeit: Für große, stabile Wissensbasen, die umfassend durchsucht werden sollen, sind Graph-Connectors effizienter. Sie ermöglichen eine tiefere semantische Suche über indexierte Inhalte.
- Datensensibilität: Wenn Daten das Unternehmen nicht verlassen oder nicht im Microsoft Graph gespeichert werden sollen, ist ein federated Connector vorzuziehen, da keine Kopie der Daten erstellt wird.
- Technische Infrastruktur: Graph-Connectors erfordern eine regelmäßige Indexierung und entsprechende Ressourcen. Federated Connectors sind abhängig von der Verfügbarkeit und Performance des externen Systems zur Laufzeit.
In der Praxis werden beide Ansätze oft kombiniert: stabile Dokumentationen über Graph-Connectors indexiert, dynamische Systemdaten über federated Connectors in Echtzeit abgerufen. Für entwicklungsorientierte oder besonders individuelle Anforderungen bietet sich zudem Azure AI Foundry als Alternative zu Copilot Studio an, wenn Standardkonnektoren nicht ausreichen.
Communardo Smart Work unterstützt Unternehmen dabei, federated Copilot Connectors strategisch einzusetzen und externe Datenquellen sicher in ihre Copilot-Umgebung zu integrieren. Als zertifizierter Microsoft-Partner begleiten wir den gesamten Prozess: von der technischen Konfiguration über Governance und Datenschutz bis hin zur Befähigung der Nutzenden. Konkret helfen wir bei:
- der Bewertung, welche externen Systeme sich für federated oder Graph-Connectors eignen
- der administrativen Einrichtung und Absicherung von Konnektoren gemäß DSGVO-Anforderungen
- dem Aufbau von Declarative Agents und Copilot Agents, die externe Daten sinnvoll einbinden
- Change-Management und Enablement, damit Mitarbeitende die neuen Möglichkeiten produktiv nutzen
Wenn du wissen möchtest, welche Connectors für deine Umgebung sinnvoll sind und wie du den Einstieg strukturiert angehen kannst, melde dich direkt bei uns.