Autonome Agenten in Microsoft 365

Ein Chatbot, der nur höflich Antworten gibt, ist schnell eingerichtet. Doch sobald ein Agent Berechtigungen, Gedächtnis und Handlungsspielraum bekommt, bucht er Meetings, schreibt Kunden an oder löst Zahlungen aus. Der Unterschied zwischen einem Copilot, der Vorschläge macht, und einem Agenten, der handelt, ist deshalb vor allem eine Frage der Konfiguration und der Governance.

Dieser Artikel zeigt, wo diese Grenze verläuft, wo das Gedächtnis eines Agenten liegt, welche Werkzeuge in Microsoft 365 und Azure dahinterstehen und welche drei Leitplanken Ihren Tenant absichern.

Copilot oder autonomer Agent: Der Unterschied liegt in der Handlung

Ein Copilot gleicht einem Praktikanten. Er entwirft Inhalte oder macht Vorschläge, und Sie genehmigen mit einem Klick. Die Kontrolle bleibt bei Ihnen. Ein autonomer Agent verhält sich dagegen wie ein Mitarbeiter mit Eigeninitiative: Er führt Arbeitsabläufe aus, ergreift Maßnahmen mit oder ohne Nachfrage und berichtet im Nachhinein.

Administratoren können dieses Verhalten konfigurieren. Sie legen fest, ob ein Agent vor dem Senden einer E-Mail, dem Buchen einer Reise oder dem Aktualisieren von Daten zustimmen lassen muss oder völlig eigenständig handelt. Dieser eine Schalter trennt den unterstützenden Assistenten vom unabhängigen Akteur.

Microsoft Copilot in Teams macht das deutlich. Schlägt er beim Tippen eine bessere Formulierung vor, sind Sie weiterhin diejenige oder derjenige, der auf „Senden“ klickt. In einer autonomen Konfiguration mit entsprechenden Berechtigungen bucht er Meetings, plant Nachfassaktionen und mailt direkt an Kunden. App und Oberfläche sind dieselben, das Verhalten ist ein völlig anderes, je nachdem, ob Aktionen oder nur Vorschläge zugelassen sind.

KI denkt nicht wie ein Mensch

Wichtig ist die richtige Erwartung. Ein Agent wägt den Kontext nicht ab wie ein Mensch. Er führt Abläufe aus und plant Aktionen auf Basis von Daten, Speicher und verfügbaren Berechtigungen. Hat er Zugriff auf Kreditkartendaten, kann er Zahlungen auslösen. Hat er Kalenderrechte, kann er Meetings buchen. Die Frage lautet daher nicht, ob die KI klug ist, sondern ob die richtigen Leitplanken stehen, bevor man ihr die Schlüssel gibt.

Gedächtnis von KI-Agenten: Warum Cosmos DB eine Schlüsselrolle spielt

Was einen Praktikanten zum Mitarbeiter befördert, ist das Gedächtnis. Bei Copilots hält der Kontext meist nur für einige Prompts und verschwindet mit dem Ende der Sitzung. Agenten speichern dagegen Gesprächsverläufe, halten IDs fest und beziehen sich auf frühere Aktionen, um neue zu steuern. In Microsofts eigenen Beispielimplementierungen werden dafür Sitzungs-IDs und Gesprächsverläufe abgelegt, damit sich Interaktionen über mehrere Aufgaben hinweg abrufen lassen.

Praktisch heißt das: Der Bot, der gestern einen Serviceanruf bearbeitet hat, erinnert sich heute daran, protokolliert das Nachfassen und plant morgen den nächsten Kontaktpunkt, ohne dass Sie Details erneut eingeben. Sie prüfen dann keine Entwürfe mehr, sondern verwalten ein System, das sich Dinge merkt.

In diesen Beispielen fungiert Cosmos DB als einheitlicher Speicher. Dort liegen nicht nur Gesprächsverläufe, sondern auch Embeddings und Workflow-Kontext. Mit Latenzen im einstelligen Millisekundenbereich und globaler Skalierbarkeit bleiben Agenten über Sitzungen hinweg schnell und konsistent. Ohne dieses Gedächtnis verhält sich eine KI wie ein Goldfisch. Mit ihm lässt sich Tage später anknüpfen. Diese Beständigkeit ist leistungsstark, aber auch potenziell problematisch, denn ein Agent mit Speicher und Berechtigungen arbeitet ohne Pause und wartet nicht zwingend auf eine Freigabe.

Azure AI Foundry und Copilot Studio: Der Werkzeugkasten für Agenten

Autonome Agenten „in Minuten“ zu starten, klingt nach Magie. In der Praxis erfordert es Integrationsarbeit mit Modellen, Berechtigungen und Connectors.

Azure AI Foundry: die Werkstatt

Azure AI Foundry ist eine Integrationsebene, an die Sie Sprachmodelle, APIs und vorhandene Unternehmenssysteme anschließen: Kundendaten, SharePoint-Bibliotheken, CRM-Daten oder eigene APIs. Die KI erhält so eine strukturierte Methode, Ihre Daten zu verstehen und zu nutzen, statt mit unstrukturierten Prompts auf Kohärenz zu hoffen. Verwechseln Sie Foundry nicht mit Fabric: Foundry dient dem Erstellen und Integrieren von Agenten, Fabric ist eher eine Analyse-Suite. Da Microsoft Produkte häufig umbenennt, sollten Sie bei Lizenz- und Architekturentscheidungen zuerst die Dokumentation des Anbieters prüfen.

Copilot Studio: das Low-Code-Frontend

Microsoft Copilot Studio sitzt innerhalb der Power Platform und arbeitet mit Power Automate, Power Apps und AI Builder zusammen. Geschäftsanwender und Administratoren erstellen, konfigurieren und veröffentlichen hier Copilots mit Vorlagen, Datenkonnektoren und Workflows, die sich in Teams, SharePoint und Dynamics 365 einfügen.

Ein Beispiel ist ein Reisebuchungs-Bot in Teams. Tippt ein Mitarbeiter „Buche einen Flug nach Chicago nächste Woche“, liefert der Copilot keinen statischen Entwurf, sondern leitet die Anfrage an die Dynamics-Reisedaten weiter und bucht die Reservierung. Für die Nutzer ist es eine Unterhaltung, im Hintergrund laufen Workflow-Schritte, die sonst manuell eingegeben würden.

Der Vorteil ist Tempo: Ein Proof-of-Concept-Agent entsteht in Tagen statt Monaten, und schnellere Prototypen bedeuten schnelleres Feedback. Der Aufwand verlagert sich allerdings von Programmierung auf Integration und Governance.

Vorgefertigte Copilot-Agenten: Was taugt, was ist noch zu riskant?

Microsoft bietet bereits fertige Agenten an, die sich im Tenant aktivieren lassen. Dazu zählen der Facilitator in Teams, der Interpreter, Employee-Self-Service-Agenten, Projektmanagement-Copilots und eine wachsende Auswahl an Dynamics-365-Copilots für Vertrieb, Lieferkette und Kundenservice. Ob sie Zeit sparen oder nur Lärm erzeugen, hängt vom Einsatzfeld ab.

Erste Zahlen sind ermutigend: Eine Vertriebsorganisation, die einen vorgefertigten Vertriebsagenten testete, meldete einen Umsatzanstieg von 9,4 % pro Verkauf. Solche Werte stammen jedoch aus kontrollierten Pilotprojekten, nicht aus dem Alltag eines chaotischen Produktiv-Tenants, und sind eher als interessante Testergebnisse zu verstehen.

• Facilitator: Fasst Besprechungsnotizen aus verstreuten Quellen zusammen. Risiko: halluzinierte Aufgaben, die niemand vereinbart hat und die zu Streit führen können.
• Interpreter: Übersetzt Live-Gespräche in Teams. Im lockeren Chat sind Fehler ärgerlich, bei Verträgen, Richtlinienklauseln oder regulatorischer Sprache können sie zur Haftungsfrage werden.
• Employee-Self-Service: Beantwortet Standardfragen zu Personal und IT. Die Abläufe sind vorhersehbar und klar abgegrenzt, daher eignen sich diese Agenten am besten für erste Pilotprojekte, etwa bei Personalthemen oder Passwortresets.
• Projektmanagement-Copilots: Sparen bei überschaubaren Projekten zuverlässig Zeit. Ohne Begrenzung verschieben sie jedoch Fristen oder weisen Aufgaben falsch zu.
• Dynamics-365-Agenten: Einfache Service-Tickets zu schließen funktioniert gut. Eskalierte Fälle sind dagegen ein Terrain, auf dem Urteilsvermögen fehlt.

Die Faustregel: Testen Sie zuerst berechenbare Fälle wie Personalwesen, IT-Self-Service oder routinemäßige Projekterinnerungen. Dokumentieren Sie Fehlalarme und Übersetzungsfehler, um Konnektoren und Umfang vor der Skalierung anzupassen. Kundenorientierte Copilots heben Sie sich für später auf.

Verantwortungsvolle KI: Die drei Leitplanken für Ihren Tenant

Verantwortungsvolle KI hat weniger mit Ethik-Postern zu tun als mit Leitplanken. Wenn Sie nicht erklären können, was ein Agent getan hat, wann er es getan hat und welche Daten er berührt hat, landen die Beschwerden bei Ihnen. Es geht um Vertrauen, Auditierbarkeit und Überlebensfähigkeit. Derselbe Agent, der Stunden bei Planung oder Ticket-Triage spart, kann ohne Kontrolle Gehaltsdaten an eine vertrauliche Verteilergruppe schicken.

1. Rollenbasierter Zugriff und begrenzte Berechtigungen, gebunden an die Identität des Agenten. Agenten sollten keine globalen Administratorrechte erben. Behandeln Sie sie wie gezielte Dienstkonten mit genau definiertem Zugriff.
2. Datenklassifizierung und deren Durchsetzung, typischerweise mit Azure Purview. Vertraulichkeitsbezeichnungen verhindern, dass Agenten etwa Gehaltsabrechnungen in öffentliche Teamseiten hochladen. Sie machen den Unterschied zwischen einem Schluckauf und einem Compliance-Verstoß.
3. Verpflichtende Audit-Protokollierung und sitzungsbasierter Speicher. So entsteht ein nachvollziehbares Protokoll darüber, was der Agent gesehen hat und warum er gehandelt hat.

Genehmigung nach Risiko festlegen

Ob ein Agent mit oder ohne menschliche Zustimmung arbeitet, ist konfigurierbar. Bei Finanzen, Personalwesen und allem, was in Kerndatensätze schreibt, sollte standardmäßig eine Genehmigung verlangt werden. Bei risikoarmen Aufgaben wie dem Bereitstellen von Dokumenten oder dem Zusammenfassen von Meetings kann Autonomie vertretbar sein. Entscheiden Sie vorab, in welche Kategorie eine Aufgabe fällt.

Speicherhygiene

Ohne strukturierte Sitzungs-IDs und Speicher pro Agent ist ein Bot entweder ein vergesslicher Goldfisch oder eine Blackbox. Fordern Sie eine Bereichsbegrenzung pro Agent und Sitzung, damit kein Kontext an Stellen weitergegeben wird, die ihn nicht haben sollen. Verlangen Sie außerdem die Möglichkeit, den Speicher bei Compliance-Fragen gezielt zu löschen.

Häufige Fehler und Stolpersteine bei autonomen Agenten

• Zu breiter Handlungsspielraum: Wird die Ausführungsplanung zu weit gefasst und mit „Team versorgen“ verknüpft, stehen plötzlich 20 Pizzen auf der Firmenkreditkarte. Schuld ist eine schwache Abgrenzung kombiniert mit selbstsicherer Automatisierung, nicht die Intelligenz des Bots.
• Unsauber eingegrenzte Connectors: Low-Code senkt die Einstiegshürde, doch ein Agent kann mit dem falschen Connector Datensätze falsch ablegen oder Besprechungsserien ohne Berechtigungsprüfung buchen. Die Komplexität verschwindet nicht, sie ändert nur ihre Form.
• Fehlende Genehmigungsschranken: Ohne sie vervielfachen sich Fehler, die niemand abgesegnet hat.
• Zu frühe Kundennähe: Kundenorientierte Szenarien und compliance-kritische Übersetzungen gehören nicht an den Anfang.
• Auf Marketingnamen verlassen: Bezeichnungen ändern sich schnell, die Dokumentation ist die verlässlichere Quelle.
• Fehlalarme nicht erfassen: Wer halluzinierte Aufgaben und Übersetzungsfehler nicht protokolliert, kann Prompts und Umfang nicht gezielt nachschärfen.

Ausblick: Magma-Agenten und Autonomie auf UI-Ebene

Die nächste Generation geht über Text hinaus. Magma ist ein multimodales Vision-Language-Action-Modell (VLA), das Bilder, Videos, Bildschirmlayouts und Bewegungen verarbeitet und auf einem Sprachmodell aufbaut. Mit Set of Mark (SOM) erhalten interaktive Elemente wie Schaltflächen numerische Labels, Trace of Mark (ToM) verfolgt Objekte über die Zeit. So lernt das Modell, Gesehenes mit Handlungen zu verknüpfen. Trainiert wurde es mit rund 39 Millionen multimodalen Beispielen aus UI-Screenshots, Roboter-Trajektorien und Videodaten.

Der Unterschied zu heutigen Copilots: Sie arbeiten in der Entwurfsphase, Magma-Agenten arbeiten auf der Ausführungsebene. Statt einen Outlook-Entwurf vorzuschlagen, erkennt ein solcher Agent die Senden-Schaltfläche und betätigt sie. Statt in Power BI einen Datenpunkt hervorzuheben, scrollt er durch das Dashboard und überführt Diagramme in einen Aktionsplan.

Damit müssen Sicherheitsrichtlinien auch Schnittstellenaktionen abdecken, nicht nur den Datenzugriff. Ein Agent, der Dashboards und Kundenprozesse beobachtet hat, braucht keine API zum Verfassen von E-Mails, sondern baut die Klickkette selbst. Das spart Zeit, verlangt aber zusätzliche Prüfung, ob die Schritte den Richtlinien entsprechen. Fehlkonfigurationen führen dann nicht mehr nur zur Offenlegung von Daten, sondern zur direkten Ausführung von Workflows. Dazu gehören falsch zugewiesene Aufgaben, nicht autorisierte Ausgaben oder fehlgeleitete Kundenkommunikation. Je schneller der Agent handelt, desto schneller verbreiten sich Fehler.

Orchestrierungsframeworks wie Autogen, Langchain oder die Assistants-API gewinnen ebenfalls an Bedeutung. Entwickler verknüpfen damit mehrere Agenten: einen, der plant, einen, der ausführt, und einen, der validiert. Administratoren müssen diese Toolkits nicht beherrschen, sollten aber wissen, welche Agenten im Tenant das Sagen haben und welche Sicherheitsvorgaben für jeden gelten.

Praktische Takeaways für Administratoren

• Beginnen Sie mit vorhersehbaren, risikoarmen Agenten wie Personal- oder IT-Self-Service, bevor Sie kundenorientierte Szenarien angehen.
• Vergeben Sie rollenbasierte, eng begrenzte Berechtigungen an die Identität des Agenten und vermeiden Sie geerbte Administratorrechte.
• Verlangen Sie für Finanzen, Personalwesen und alle Schreibvorgänge in Kerndatensätze standardmäßig eine menschliche Genehmigung.
• Wenden Sie Vertraulichkeitskennzeichnungen auf alle Datenquellen an und setzen Sie Datenklassifizierung durch, etwa mit Azure Purview.
• Aktivieren Sie vollständige Audit-Protokolle und nutzen Sie strukturierte Sitzungs-IDs mit Speicher pro Agent.
• Stellen Sie sicher, dass sich der Speicher bei Bedarf gezielt löschen lässt.
• Grenzen Sie Connectors sorgfältig ein und legen Sie fest, wo welche Daten liegen.
• Dokumentieren Sie Fehlalarme und Übersetzungsfehler im Pilotprojekt, bevor Sie skalieren.
• Planen Sie Governance schon jetzt so, dass sie künftig auch UI-Aktionen abdeckt.

Fazit

Autonome Agenten in Microsoft 365 sind weder Produktivitäts-Hack noch Admin-Albtraum. Entscheidend ist, wie sie eingeführt werden. Mit Gedächtnis, Berechtigungen und Handlungsspielraum werden aus Vorschlagsmaschinen digitale Mitarbeiter, die schnell und ausdauernd arbeiten, aber nicht von selbst nachfragen. Wer Berechtigungen eingrenzt, Genehmigungen für schreibende Aktionen verlangt und Speicher sowie Audit-Logs sauber aufsetzt, macht sie zu verlässlichen Helfern. Wer darauf verzichtet, riskiert Compliance-Probleme und Chaos, das sich mit der Geschwindigkeit der Agenten verbreitet. Die Schlüssel zum Firmenwagen sollte die IT deshalb behalten.