Die letzten Monate haben deutlich gemacht, dass für produktive Copilot- und autonome Agenten in Microsoft 365 Begeisterung für KI allein nicht reicht. In vielen Tenants, die ich begleite, wird Agenten-Governance spätestens nach den ersten Erfahrungen aus dem Betrieb zur Chef*innensache, und das zu Recht. Mit jedem neuen Agenten gewinnt man Effizienz, holt sich aber auch Risiken und organisatorische Fragen ins Haus. Wer von Anfang an sauber arbeitet, erspart sich später viel Ärger mit Datenschutz, Oversharing und Schatten-IT.

Ein vollständiges Agenteninventar braucht mehr als ein Portal

Meist hakt es schon beim vollständigen Inventar. Unter Microsoft 365 Admin Center → „Agenten verwalten“ gibt es inzwischen eine recht komfortable Übersicht aller zentral registrierten Copilot-Agenten samt Status. Vollständig ist das Bild damit aber selten. Agenten auf Basis der Power Platform, also mit Copilot Studio gebaut und womöglich über mehrere Umgebungen verteilt, erscheinen in der Umgebungsliste des Power Platform Admin Center – manche entstehen sogar ganz ohne zentrale Sicht. Ich gehe deshalb einmal im Monat durch beide Portale und lasse zusätzlich ein PowerShell-Skript für die Power Platform laufen, das alle Umgebungen mit ihren Agenten als Tabelle ausgibt. Am besten funktioniert das, wenn ich das Inventar regelmäßig mit den Teams und Fachbereichen abgleiche und Verantwortliche benenne.

Tipp aus der Praxis: Verlasst euch nicht blind auf die Übersicht im Microsoft 365 Admin Center. Gerade in Organisationen mit vielen Power-Platform-Makern zeigt sie oft nur die halbe Wahrheit, deshalb gehört der Abgleich mit den Copilot-Studio-Umgebungen unbedingt dazu.

Jeder Agent braucht einen Owner und im besten Fall eine Entra Agent ID

Für jeden Agenten muss es einen klaren Owner geben, idealerweise ergänzt um einen fachlichen Sponsor aus dem Business. Im Alltag sehe ich oft, wie Agenten „mal eben“ gebaut werden. Wechselt der Ersteller dann das Team oder verlässt er die Firma, ist plötzlich niemand mehr zuständig. So entstehen verwaiste Bots, und obendrein drohen Probleme beim Datenschutz und bei der Abrechnung. Technisch interessant finde ich, dass sich neuere Copilot-Studio-Agenten auf Wunsch mit einer Entra Agent ID betreiben lassen (Voraussetzung: Entra ID Premium P1). Das vereinfacht Identitätsverwaltung und Berechtigungen. Bestehende Agenten muss man allerdings bewusst umstellen; die Übersicht unter https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/manage hilft dabei weiter.

Datenzugriff, Aktionen und Konnektoren müssen klar geregelt sein

Im Kern dreht sich jede Agenten-Governance um zwei Fragen: Was darf der Agent tun, und auf welche Daten und Systeme greift er zu? Bei Copilot-Studio-Agenten lässt sich der Zugriff auf Wissensquellen und Daten fein steuern. Die Einstellungen der jeweiligen Umgebung kontrolliere ich regelmäßig (mehr dazu in meinem Leitfaden zu Berechtigungen für Wissensquellen). Für erlaubte Aktionen und Konnektoren gelten ebenfalls Richtlinien, die man unter Power Platform Admin Center → Datenrichtlinien konfiguriert. Spätestens hier zahlt es sich aus, DLP-Richtlinien für die Power Platform konsequent umzusetzen, vor allem bei Agenten, die mit externen Tools oder APIs arbeiten. Die neuen, granularen Connector-Policies aus dem Jahr 2025 sollte man als Pflicht betrachten.

Bevor ein Agent bei mir produktiv geht, prüfe ich:

  • Wissensquellen und Datenzugriffsrechte
  • erlaubte Aktionen und Konnektoren (inkl. DLP)
  • Freigabe- und Sichtbarkeitseinstellungen (siehe Teilen von Agenten und Umgebungen)

Das folgende Diagramm zeigt, welche Governance-Faktoren rund um einen Agenten zusammenspielen:

flowchart TD
  Inventar["Inventar"] --> Owner["Owner/Sponsor"]
  Owner --> Identitaet["Agentenidentität (Entra Agent ID)"]
  Inventar --> Daten["Datenzugriff/Wissensquellen"]
  Daten --> Aktionen["Aktionen/Konnektoren"]
  Aktionen --> Sharing["Teilen/Grenzen"]
  Inventar --> Monitoring["Überwachung/Audit"]
  Monitoring --> Lifecycle["Lifecycle (Review/Abschalten)"]
  Lifecycle --> Abrechnung["Abrechnung"]
  Owner --> Training["User Training"]

Abbildung: Die wichtigsten Governance-Aspekte eines Agenten auf einen Blick.

Audit, DSPM und ein geordneter Lifecycle bewahren vor bösen Überraschungen

Laufend überwachen lässt sich das am besten mit Purview Audit (im Compliance-Portal → Audit-Suche). Dort erscheinen mittlerweile auch viele Copilot-interne Aktionen und Agentenausführungen als Events. Wer mehr Transparenz braucht, etwa bei Datenabflüssen aus sensiblen Quellen, sollte unbedingt DSPM for AI einsetzen. Damit werden die KI-spezifischen Datenflüsse und Rechte endlich nachvollziehbar, und Policy-Verstöße, ungewöhnliche Nutzung oder fehlende Reviews fallen sofort auf.

Unterschätzen sollte man auch Pay-as-you-go-Agenten nicht, denn sie können am Monatsende für Überraschungen sorgen. Die Abrechnung pro Agent lässt sich inzwischen in den jeweiligen Portalen nachvollziehen. Im Zweifel lohnt sich ein monatliches Review, besonders bei Agenten mit externen API-Aufrufen. Spätestens beim Offboarding oder bei Umstrukturierungen gehören Agenten deaktiviert oder archiviert. Andernfalls bleiben ein Sicherheitsrisiko und eine mögliche Kostenfalle zurück.

Governance gelingt nur im Team und mit Rückendeckung der Leitung

Agenten-Governance ist längst kein reines IT-Thema mehr. Immer wieder beobachte ich, dass Organisationen, die früh ein konsolidiertes Inventar mit Ownership und Policies aufbauen, später deutlich weniger Stress mit Datenschutz, Compliance und Kosten haben. Transparenz, klare Verantwortlichkeiten und regelmäßige Reviews bringen mehr als noch so viele technische Features. Die Fachbereiche gehören dabei von Anfang an mit ins Boot. Konkrete Schritte für die Praxis findet ihr in meinen Beiträgen zur Agentenverwaltung, zu Teilen und Umgebungen und zu Berechtigungen für Wissensquellen sowie in meiner Einschätzung der Ignite-Neuerungen für Copilot-Agenten. Und wie immer gilt: Bleibt pragmatisch, aber wachsam. KI-Governance ist und bleibt Chefsache.