Welches Copilot-Feature für welche Aufgabe: eine Landkarte in vier Stufen mit Agent-Governance

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

Copilot Chat, Copilot in Word, Agent Builder, SharePoint-Agents, Copilot Studio, Cowork: Das ist nur die Liste für dieses Quartal. Jeden Monat kommt ein neuer Einstiegspunkt dazu, und jeder löst bei Anwendern und Stakeholdern dieselbe Frage aus: „Sollen wir jetzt also das hier nehmen?“ Um sie zu beantworten, musst du wissen, welches Werkzeug zu welcher Aufgabe passt, und dafür sorgen, dass die Agents von heute nicht die verwaisten Power-Automate-Flows von morgen werden.

Kurz gesagt

Denk Copilot in vier Stufen: Ad-hoc-Chat → Copilot in den Apps → Agents → Copilot Studio und Automatisierung im Cowork-Stil.

Vier Fragen entscheiden über die Stufe: Kommt es öfter als einmal pro Woche vor? Sind Quellen oder Tonalität immer gleich? Ist es regelbasiert? Sind mehrere Systeme und Freigaben beteiligt? Je mehr „Ja“, desto höher die Stufe.

Je höher die Stufe, desto mehr Governance. Eine Regel gilt aber überall: kein Agent ohne Owner. Stand Oktober 2026 zeigt dir die Agent-365-Registry im Microsoft 365 admin center, welchen Agents einer fehlt.

Kurz zu den Namen

Microsoft hat wieder umbenannt: Aus Microsoft 365 Copilot wird Microsoft Copilot, aus Microsoft 365 Copilot Chat wird Microsoft Copilot Chat, und die App zieht nach copilot.cloud.microsoft um. Lizenzen, Portale und Doku zeigen eine Weile beide Namen. Ich verwende im Folgenden die neuen. Wenn deine Anwender verwirrt sind, ist das ein Grund mehr, ihnen eine Landkarte statt einer Produktliste zu geben.

Die Landkarte: vier Stufen

Die Idee stammt aus der Session von Patrick Kelbch auf der M365 Con D-A-CH, und sie gefällt mir, weil sie nach Art der Arbeit sortiert und nicht nach Produkt. So würde ich sie mit dem füllen, was heute tatsächlich verfügbar ist:

Stufe	Was es ist	Typische Aufgabe	Lizenz / Kosten (vereinfacht)	Wer steuert
1 – Chat	Copilot Chat in der Copilot-App, in Edge, Teams, Outlook	Spontane Fragen, Entwürfe, Zusammenfassung von eingefügten oder hochgeladenen Inhalten	In berechtigten Microsoft-365-Plänen enthalten (webbasiert); arbeitsdatenbasierter Chat braucht eine Copilot-Lizenz	Copilot-Einstellungen im Microsoft 365 admin center
2 – In den Apps	Copilot in Word, Excel, PowerPoint, Outlook, Teams	Meeting-Zusammenfassung, Posteingang sortieren, erster PowerPoint-Entwurf aus einem Dokument	Grundfunktionen in den Apps für berechtigte Nutzer; voller Umfang mit Microsoft-Copilot-Lizenz	Wie oben, plus deine Datenbasis (Berechtigungen, Labels)
3 – Agents	Agents aus Agent Builder, SharePoint-Agents, Agents aus dem Agent Store	Wiederverwendbarer Assistent mit festen Anweisungen und Wissen, z. B. Projekt-FAQ	Mit Copilot-Lizenz enthalten; ohne über Pay-as-you-go (reine Web-Agents kostenlos)	Agent-Registry im Microsoft 365 admin center
4 – Automatisierung	Copilot-Studio-Agents (Flows, Trigger, Autonomie) und Copilot Cowork	Mehrstufige Prozesse über Systeme hinweg, mit Freigaben	Copilot Studio: Copilot-Lizenz oder Copilot Credits; Cowork: Copilot-Lizenz plus nutzungsbasierte Abrechnung	Power Platform admin center + Agent 365 + Cost Management

Die Grenze zwischen Stufe 1 und 2 ziehen inzwischen eher die Lizenzen als die Technik. Auch Nutzer ohne Copilot-Lizenz bekommen Copilot-Grundfunktionen in Word, Excel und PowerPoint, und Copilot Chat in Outlook und Teams kann mit dem gerade geöffneten Inhalt arbeiten. Für Anwender sieht das alles nach „Copilot in der App“ aus. Für dich ist der Unterschied wichtig: Er entscheidet, ob Copilot selbstständig auf Postfach, Chats und Dateien zugreifen kann oder nur sieht, was man ihm gibt.

Stufe 4 hat zwei sehr unterschiedliche Äste. Copilot Studio ist prozesszentriert: Ein Maker baut einen Agent mit Topics, Agent Flows und Event-Triggern, der für viele Nutzer läuft, teils ohne dass ihn jemand anstößt. Cowork ist personenzentriert: Ein Nutzer delegiert ein Ergebnis („bereite die Unterlagen für den Lenkungskreis aus den Mails der letzten Woche und der Projektseite vor“), Cowork plant die Schritte, arbeitet über Outlook, Teams, OneDrive und SharePoint hinweg und fragt vor sensiblen Aktionen nach Freigabe. Microsoft bezeichnet Cowork als agentisches System statt als Agent, und gesteuert wird es über Spending Policies statt über die Agent-Registry.

Vier Fragen für die richtige Stufe

Wenn ein neuer Use Case oder ein neues Feature auftaucht, lass ihn durch vier Fragen laufen:

Kommt es öfter als einmal pro Woche vor? Wenn nicht, bleib auf Stufe 1 oder 2. Für eine Einmalaufgabe etwas Wiederverwendbares zu bauen, lohnt sich nicht.
Sind Quellen oder Tonalität jedes Mal gleich? Wenn ja, bist du bei einem Agent (Stufe 3): Anweisungen plus feste Wissensbasis schlagen das ständige Neu-Tippen desselben Prompts.
Ist es regelbasiert? Wenn die Schritte vorhersehbar sind („wenn X kommt, prüfe Y, dann mach Z“), brauchst du deterministische Logik: einen Copilot-Studio-Agent mit Topics oder Agent Flows (Stufe 4).
Sind mehrere Systeme beteiligt und braucht es Freigaben? Dann bist du auf Stufe 4 mit echtem Prozessdesign: Connectoren, Human-in-the-Loop-Schritte und jemand, der sich Gedanken über die Anmeldedaten macht, mit denen der Agent läuft.

Je mehr „Ja“, desto höher geht es. Wenn du nicht Ja sagen kannst, steig nicht auf: Auch ein Agent, den niemand nutzt, muss inventarisiert, überprüft und irgendwann stillgelegt werden.

Ich ergänze eine eigene Frage, und in regulierten Umgebungen ist sie meine erste: Wem gehört das, wenn es kaputtgeht? Meldet sich niemand, bleibt der Use Case auf Stufe 1 oder 2, egal wie gut die Idee ist.

Governance pro Stufe und ein Owner für jeden Agent

Auf Stufe 1 und 2 geht es bei Governance vor allem um deine Datenbasis: Oversharing, Sensitivity Labels, Berechtigungen. Copilot zeigt Nutzern nur, worauf sie ohnehin Zugriff haben, und genau deshalb fallen unaufgeräumte Berechtigungen in dem Moment auf, in dem Copilot eingeschaltet wird.

Ab Stufe 3 verwaltest du Objekte, die weiterleben: Agents mit Wissen, Aktionen und teils eigener Identität. Die Session hatte dafür eine Checkliste; so lässt sich jeder Punkt auf heutige Werkzeuge abbilden:

Ein Owner für jeden Agent. Die Agent-Registry im Microsoft 365 admin center (Agents > All agents > Registry) listet Agents plattformübergreifend auf (Copilot Studio, Agent Builder, Partner- und Microsoft-Agents) und zeigt Agents without owners als Kennzahl ganz oben. Für die Inventarsicht brauchst du keine Zusatzlizenz, nur die passende Rolle; AI Reader ist die Variante mit den geringsten Rechten. Einen neuen Owner zuweisen kann nur AI Administrator (oder Global Administrator).

Owner vs. Sponsor. Für Agents mit einer Microsoft Entra Agent ID trennt Entra zwei Rollen: Der Owner kümmert sich um den technischen Betrieb, der Sponsor ist die fachlich verantwortliche Person, die entscheidet, ob der Agent noch gebraucht wird und welche Zugriffe er bekommt. Jede Agent-Identität braucht mindestens einen Sponsor, und verlässt ein Sponsor das Unternehmen, geht die Sponsorschaft automatisch an seine Führungskraft über. Nutze beide Rollen. „Die IT hat ihn gebaut“ ist nicht dasselbe wie „der Fachbereich braucht ihn“.

Freigabe für Aktionen. Cowork fragt vor sensiblen Aktionen nach Freigabe. In Copilot Studio gestaltest du das selbst: Human-in-the-Loop-Schritte in Agent Flows für alles, was große Wirkung hat oder sich nicht rückgängig machen lässt. Ein Detail, das man kennen sollte: Event-Trigger in Copilot Studio authentifizieren sich mit den Anmeldedaten des Makers. Nutzer eines veröffentlichten Agents können so über die Zugriffe des Makers an Daten kommen. Least Privilege gilt also auch für Maker.

Eine Registry. Microsoft führt die Agent-Ansichten aus Entra und dem Microsoft 365 admin center in Agent 365 zusammen, sodass du am Ende ein Inventar statt drei hast. Agents anderer Plattformen lassen sich ebenfalls in die Registry synchronisieren.

Entra-ID-Wildwuchs im Griff. Jeder Agent mit eigener Identität bringt neue Objekte ins Verzeichnis: Blueprints, Agent-Identitäten, eventuell Agent-User. Behandle sie wie jede andere nicht-menschliche Identität: Conditional Access, Access Packages mit Ablaufdatum und Lifecycle Workflows, die Sponsor-Wechsel abfangen.

Lifecycle, Lizenzen und Kosten. Agents lassen sich im admin center blockieren, löschen (mit 30 Tagen Wiederherstellungsfrist) und neu zuweisen. Auf der Kostenseite laufen Cowork und andere nutzungsbasiert abgerechnete Dienste über Copilot Credits und werden unter Copilot > Cost Management verwaltet.

Schnelles Inventar mit Microsoft Graph

Wenn du die Registry im Skript brauchst, etwa für einen Monatsbericht oder ein Review mit dem Fachbereich, gibt es in Microsoft Graph die Package Management API. Sie ist unter v1.0 verfügbar, braucht CopilotPackages.Read.All (delegiert oder als Anwendungsberechtigung) und setzt eine Microsoft-Agent-365-Lizenz voraus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Requires: Microsoft.Graph.Authentication, permission CopilotPackages.Read.All
Connect-MgGraph -Scopes "CopilotPackages.Read.All" -NoWelcome

# Only packages that surface in Copilot, i.e. agents
$uri = "https://graph.microsoft.com/v1.0/copilot/admin/catalog/packages?`$filter=supportedHosts/any(h:h eq 'Copilot')"
$agents = while ($uri) {
 $page = Invoke-MgGraphRequest -Method GET -Uri $uri
 $page.value
 $uri = $page.'@odata.nextLink' # follow paging until no nextLink is returned
}

$agents |
 Select-Object displayName, type, platform, publisher, isBlocked, availableTo, deployedTo, lastModifiedDateTime |
 Sort-Object lastModifiedDateTime |
 Export-Csv -Path .\agent-inventory.csv -NoTypeInformation -Encoding utf8

Die Sortierung nach lastModifiedDateTime ist ein günstiger erster Lifecycle-Check: Agents, die sich seit einem Jahr nicht verändert haben, kommen als Erste auf den Prüfstand. Für die Owner-Frage ist die Ansicht Agents without owners im admin center weiterhin der schnellste Einstieg.

Worauf du achten solltest

Eine Spending Policy ist Zugriffssteuerung und Budget zugleich. Bei Cowork bekommt jeder Zugriff, der im Geltungsbereich einer Policy mit Cowork liegt, selbst wenn das Limit bei einem einzigen Credit liegt. Wer draußen bleiben soll, gehört nicht in die Policy.
„Auto-apply new services“ ist standardmäßig aktiv. Neue nutzungsbasierte Dienste können so automatisch mit abgedeckt werden. Wenn du jeden neuen Dienst erst prüfen willst (eine vernünftige Haltung bei Change-Prozessen im NIS2-Umfeld), schalte es ab.
Setz Limits pro Nutzer. Sonst verbraucht ein begeisterter Anwender die Credits des ganzen Monats.
Agent 365 ist gestaffelt lizenziert. Registry-Inventar und Basisaktionen (blockieren, löschen, Owner neu zuweisen) sind in Microsoft 365 Enterprise, Business, Education und Frontline enthalten. Policy-Vorlagen, Observability, mandantenweite Tool-Steuerung und die Graph API brauchen Microsoft 365 E7 oder Agent 365. Prüf die Service Description, bevor du ein Feature zusagst.
Namen und Admin-Pfade ändern sich laufend. Die Umbenennung zu Microsoft Copilot ist frisch; Screenshots in deiner internen Doku veralten schneller, als dir lieb ist.

Fazit

Bau die Landkarte einmal und ordne jedes neue Copilot-Feature darauf ein, statt jedes Mal von vorn zu diskutieren. Entscheide mit den vier Fragen, wie hoch ein Use Case gehen soll, und nimm die Zusatzfrage ernst: Wenn ihn niemand verantwortet, wird er nicht gebaut. Für die Agents, die es schon gibt, zeigt dir die Registry genau, wo ein Owner fehlt.

Auf welcher Stufe sind die meisten deiner Nutzer heute, und wie vielen Agents in deiner Registry fehlt schon jetzt ein Owner?

Quellen

Inspiriert von einem LinkedIn-Post von Marcel Broschk über die Session „Copilot everywhere: Chat, Agents, Automatisierung: wie finde ich mich noch zurecht?“ von Patrick Kelbch auf der M365 Con D-A-CH.

Microsoft Copilot on DR.365