Microsoft 365 Copilot Orchestrator: Wie die Steuerungslogik Aktionen auswählt

Ein Mitarbeiter fragt Microsoft 365 Copilot: „Prüfe meine offenen Reisekosten und sag mir, wo Belege fehlen.“ Dafür muss das System erkennen, ob Richtlinienwissen, personenbezogene Abrechnungsdaten oder eine ausführbare Aktion benötigt werden. Ebenso wichtig ist die Frage, welche Daten der Nutzer sehen und welche Änderungen er auslösen darf.

Hier setzt der Microsoft 365 Copilot Orchestrator an: Er vermittelt zwischen Nutzeranfrage, Kontext, Wissen und Aktionen. Für Unternehmen folgt daraus eine klare Grenze: Je dynamischer Copilot den Weg zum Ergebnis plant, desto präziser müssen die erlaubten Wege technisch und organisatorisch begrenzt sein.

Was der Copilot Orchestrator konkret tut

Microsoft-Dokumentation: Nach der Dokumentation zum Copilot Orchestrator beginnt die Verarbeitung mit der natürlichsprachlichen Anfrage. Vor der Ausführung erfolgen Sicherheits- und Responsible-AI-Prüfungen. Danach erstellt die Orchestrierungsschicht einen Plan, berücksichtigt Gesprächskontext und Microsoft-Graph-Informationen und entscheidet, ob eine eingebaute Fähigkeit genügt oder zusätzliche Daten beziehungsweise Aktionen benötigt werden.

Sind externe Aktionen nötig, sucht das System in den für den Agenten aktivierten Fähigkeiten. Maßgeblich sind deren Beschreibungen und Funktionen. Das Sprachmodell ordnet der Anfrage eine geeignete Funktion zu und bestimmt die benötigten Parameter. Ein Werkzeugdienst führt den Aufruf aus; das Ergebnis fließt zurück in die weitere Verarbeitung und schließlich in die Antwort.

Diese Darstellung ist keine Zusicherung, dass jede Anfrage in genau vier sichtbaren Schritten abläuft. Sie verdichtet die von Microsoft beschriebene Logik für die Unternehmenspraxis. Wichtig ist die Trennung zwischen Planung und Ausführung: Das Modell schlägt einen Weg vor; Identität, Berechtigung, fachliche Validierung und technische Limits müssen außerhalb des frei formulierten Modellkontexts durchgesetzt werden.

Warum Namen und Beschreibungen zu Steuerungselementen werden

In einem klassischen Workflow legt ein Entwickler den Ablauf fest: Wenn Bedingung A zutrifft, wird Funktion B ausgeführt. Bei generativer Orchestrierung entscheidet das Modell dynamisch, welche verfügbare Fähigkeit zur Anfrage passt. Dadurch werden der Name einer Aktion, ihre Beschreibung sowie die Benennung von Ein- und Ausgaben zu einem Teil der Laufzeitsteuerung.

„Kundendaten bearbeiten“ ist als Werkzeugbeschreibung zu breit. Sie lässt offen, ob ein Datensatz gesucht, korrigiert, exportiert oder gelöscht werden soll. Besser sind eng geschnittene Funktionen wie „Kundenkontakt anhand der Kundennummer lesen“ und „Lieferadresse nach Bestätigung ändern“. Die zweite Aktion benötigt zusätzlich eine fachliche Berechtigungsprüfung und eine nachvollziehbare Freigabe.

Microsoft empfiehlt für die generative Orchestrierung in Copilot Studio eindeutige Werkzeugnamen, verständliche Parameter und kuratierte Fähigkeiten. Zu viele ähnlich formulierte Werkzeuge erhöhen nicht automatisch den Nutzen. Sie vergrößern den Auswahlraum und erschweren eindeutige Tests.

Deklarativer Agent, Copilot Studio oder eigene Orchestrierung?

Microsoft-Dokumentation: Microsoft unterscheidet grundsätzlich zwischen deklarativen Agenten und Custom Engine Agents. Deklarative Agenten verwenden den Orchestrator, die Basismodelle und die vertrauenswürdigen KI-Dienste von Microsoft 365 Copilot. Unternehmen konfigurieren Anweisungen, Wissen und Aktionen, kontrollieren aber nicht die zugrunde liegende Orchestrierungslogik. Custom Engine Agents erlauben eine eigene Modell- und Ablaufsteuerung, benötigen dafür zusätzliche Infrastruktur und eigene Sicherheits- sowie Betriebsprozesse.

Die Tabelle ist eine redaktionelle Entscheidungshilfe, keine vollständige Lizenzübersicht. Die Microsoft-Übersicht zu Agententypen empfiehlt deklarative Agenten als Ausgangspunkt für Microsoft-365-Szenarien. Eine eigene Engine ist nicht automatisch „professioneller“. Sie lohnt sich erst, wenn der zusätzliche Kontrollbedarf die Betriebs- und Sicherheitslast rechtfertigt.

Durchgehendes Praxisbeispiel: Reisekosten klären

Hypothetisches, aber realistisches Szenario: Ein Unternehmen möchte einen Agenten bereitstellen, der Beschäftigten fehlende Belege in ihren Reisekostenabrechnungen nennt. Später soll er auch Erinnerungen versenden und fehlerhafte Zuordnungen zur Korrektur vorschlagen.

Stufe 1: Nur lesen

Der Agent erhält eine Aktion, die offene Abrechnungen für die angemeldete Person liest, sowie eine Wissensquelle mit der gültigen Reiserichtlinie. Die API erzwingt, dass ein Nutzer nur die eigenen Vorgänge abrufen kann. Eine vom Modell übergebene fremde Personalnummer erweitert diese Berechtigung nicht.

Fragt der Nutzer „Was fehlt noch?“, muss der Orchestrator zwischen Wissensfrage und persönlicher Statusabfrage unterscheiden. Für die Antwort können beide Fähigkeiten nötig sein: Der Status liefert den fehlenden Beleg, die Richtlinie erklärt, welche Nachweise akzeptiert werden. Der Pilot misst deshalb nicht nur die sprachliche Qualität, sondern auch korrekte Werkzeugwahl, Parameter, Quellenbezug und Zugriffsgrenzen.

Stufe 2: Einen Entwurf erzeugen

Der Agent darf eine Erinnerung formulieren, aber nicht selbst versenden. Der Mitarbeiter sieht Empfänger, Betreff und Inhalt und kann den Entwurf ändern oder verwerfen. Diese Stufe erhöht den Nutzen, ohne bereits einen extern wirksamen Schreibzugriff zu erlauben.

Stufe 3: Kontrolliert handeln

Erst nach stabilen Tests wird eine eng begrenzte Versandaktion ergänzt. Die Anwendung prüft Empfänger, Mandant, erlaubten Vorlagentyp und Versandhäufigkeit deterministisch. Vor dem Aufruf zeigt die Oberfläche die konkrete Aktion und ihre Folgen. Die Bestätigung wird außerhalb des vom Modell veränderbaren Textkontexts verarbeitet und protokolliert.

Der Orchestrator darf in diesem Szenario den passenden Weg auswählen. Er darf aber weder Identitäten erfinden noch den zulässigen Empfängerkreis erweitern. Diese Grenze ist die zentrale Architekturentscheidung.

Die fünf wichtigsten Risiken

Microsoft-Dokumentation und AI-Fabrik-Einordnung: Die Copilot-Plattform bringt Sicherheits- und Compliance-Funktionen mit. Das entbindet ein Unternehmen nicht von der Aufgabe, den konkreten Prozess zu prüfen. Microsoft weist selbst darauf hin, dass generative Abläufe durch deterministische, hybride und KI-gesteuerte Kontrollschichten begrenzt werden sollten. Für irreversible Vorgänge empfiehlt die Dokumentation regelbasierte Abläufe oder ausdrückliche Bestätigungen.

Ein Human-in-the-loop ist dabei nur wirksam, wenn die Person erkennen kann, was tatsächlich passieren soll. Ein Dialogfeld mit „Möchten Sie fortfahren?“ genügt nicht. Sichtbar sein müssen Aktion, Zielsystem, betroffene Daten, Reichweite und mögliche Folgen. Zusätzlich braucht es technische Limits, Least Privilege, Protokollierung, Fehlerbehandlung und – wo möglich – Rollback.

Governance für DACH-Unternehmen

AI-Fabrik-Praxisempfehlung: Für deutsche, österreichische und schweizerische Organisationen beginnt Governance mit einem Inventar: Welcher Agent darf welche Wissensquellen und Aktionen in welchem Mandanten nutzen? Wer hat ihn genehmigt? Welche Datenklassen verarbeitet er? Welche Logs entstehen, wo werden sie gespeichert und wer wertet sie aus?

Bei personenbezogenen Daten sind Zweck, Rechtsgrundlage, Datenminimierung, Aufbewahrung, Empfänger und Betroffenenrechte zu klären. Je nach Einsatz können Datenschutz-Folgenabschätzung, Auftragsverarbeitung und Drittlandtransfers relevant sein. Der EU AI Act verlangt zusätzlich eine risikobasierte Einordnung; nicht jeder Copilot-Agent ist automatisch ein Hochrisiko-KI-System. Maßgeblich sind Zweck und tatsächlicher Einsatz, nicht der Produktname.

Der Betriebsrat sollte früh eingebunden werden, sobald Leistungs- oder Verhaltensdaten verarbeitet, Arbeitsabläufe verändert oder Beschäftigte bewertet werden könnten. Ein Agent, der Belege nennt, ist organisatorisch anders zu behandeln als ein System, das Freigabeentscheidungen vorbereitet oder Beschäftigte priorisiert.

Ein schlanker Abnahmetest für den Pilot

AI-Fabrik-Praxisempfehlung: Ein Test mit zehn freundlichen Standardprompts reicht nicht. Vor der Produktivsetzung sollte das Team mindestens vier Klassen abdecken:

1. Normale Fälle: Eindeutige Anfragen in verschiedenen Formulierungen wählen die richtige Aktion und liefern korrekte Parameter.
2. Mehrdeutige Fälle: Der Agent fragt nach, statt eine folgenreiche Annahme zu treffen.
3. Grenz- und Rechtefälle: Fremde Datensätze, ungültige Werte und nicht erlaubte Aktionen werden technisch abgewiesen.
4. Adversariale Fälle: Direkte und indirekte Prompt-Injection, manipulierte Dokumente, Werkzeugmissbrauch und wiederholte Ausführung führen nicht zu unzulässigen Aktionen.

Für einen risikoarmen Leseagenten kann ein dokumentierter, wiederholbarer Testplan mit etwa 30 bis 50 gezielt ausgewählten Fällen genügen; diese Bandbreite ist eine redaktionelle Empfehlung, keine Microsoft-Vorgabe. Bei finanziellen, personenbezogenen oder produktionsnahen Schreibzugriffen sind umfangreichere Tests, unabhängige Prüfung und feste Abbruchkriterien erforderlich.

Abgenommen wird nicht mit dem Satz „Die Antworten wirkten gut“. Messbar sind mindestens korrekte Aktionsauswahl, korrekte Parameter, verweigerte unzulässige Zugriffe, Anteil notwendiger Rückfragen, belegte Ergebnisse, doppelte Ausführungen und vollständige Protokollierung. Nach Änderungen an Modell, Anweisungen, Werkzeugen, Berechtigungen oder Datenquellen wird der relevante Testsatz erneut ausgeführt.

Was der Orchestrator nicht löst

Generative Orchestrierung reduziert den Aufwand für starre Dialogbäume und kann mehrere Absichten flexibler verarbeiten. Sie beseitigt aber keine schlechte Prozessdefinition. Wenn zwei Abteilungen unterschiedliche Bedeutungen von „freigegeben“ verwenden, kann eine bessere Toolbeschreibung den Konflikt nicht auflösen. Wenn ein Quellsystem falsche Berechtigungen liefert, macht der Orchestrator sie nicht korrekt. Und wenn niemand für die fachliche Qualität zuständig ist, bleibt das auch bei einem technisch erfolgreichen Pilot so.

Auch die häufige Annahme „Mehr Werkzeuge bedeuten einen leistungsfähigeren Agenten“ greift zu kurz. Ein kleiner, sauber abgegrenzter Werkzeugkatalog ist oft zuverlässiger und leichter zu prüfen. Erst wenn echte Nutzerfälle nicht abgedeckt werden, sollte das Team weitere Fähigkeiten ergänzen.

FAQ

Ist Copilot Orchestrator ein eigenes Microsoft-Produkt?

Nein. Der Begriff bezeichnet die Laufzeit-Steuerung in Microsoft 365 Copilot, die Anfragen mit verfügbaren Fähigkeiten und Aktionen verbindet.

Ist der Copilot Orchestrator dasselbe wie Copilot Studio?

Nein. Der Orchestrator ist eine Laufzeitfunktion. Copilot Studio ist die Entwicklungs- und Verwaltungsplattform, in der Unternehmen Agenten, Aktionen, Wissensquellen und Kontrollpunkte konfigurieren.

Warum wählt ein Agent manchmal die falsche Aktion?

Typische Ursachen sind überlappende Werkzeugzwecke, unklare Beschreibungen, zu breite Funktionen oder fehlende Abgrenzungsfälle. Die Korrektur beginnt meist beim Werkzeugdesign und beim Testsatz – nicht bei einem längeren allgemeinen Prompt.

Fazit: Orchestrierung ist eine Betriebsentscheidung

Der Microsoft 365 Copilot Orchestrator senkt die Einstiegshürde für Agenten, weil nicht jeder Gesprächspfad vorab programmiert werden muss. Genau daraus entsteht aber eine neue Aufgabe: Unternehmen müssen Fähigkeiten so zuschneiden, beschreiben und absichern, dass ein dynamischer Plan innerhalb belastbarer Grenzen bleibt.

Für den Einstieg genügt ein lesender Agent mit wenigen klar getrennten Aktionen, benanntem Owner und einem wiederholbaren Abnahmetest. Erst wenn dieser kleine Werkzeugraum zuverlässig funktioniert, folgen schreibende Aktionen oder untergeordnete Agenten. Die nächste Managemententscheidung lautet daher nicht „Wie viele Tools können wir anbinden?“, sondern: Welche eine Aktion können wir heute so begrenzen, dass ihr Nutzen messbar und ihr Fehler beherrschbar ist?

Weiterführende Artikel auf AI-Fabrik

• Generative AI, Agentic AI und AI Agents: Der Unterschied einfach erklärt
• Microsoft Copilot knackt 20-Millionen-Marke: Was Unternehmen jetzt wissen müssen
• 743.000 Lizenzen: Was DACH-Unternehmen vom größten Copilot-Deal lernen können

Quellen

• Microsoft Learn: Overview of the Microsoft 365 Copilot orchestrator, zuletzt aktualisiert am 22. Januar 2026.
• Microsoft Learn: Apply generative orchestration capabilities, zuletzt aktualisiert am 27. August 2026.
• Microsoft Learn: Introduction to agents, zuletzt aktualisiert am 21. Mai 2026.
• Microsoft Learn: Declarative agents for Microsoft 365 Copilot, zuletzt aktualisiert am 18. Juni 2026.
• Microsoft Learn: Custom engine agent architecture, zuletzt aktualisiert am 8. Januar 2026.
• Europäische Union: Verordnung (EU) 2024/1689 über künstliche Intelligenz.