Agent Governance
- Fabio Bonolo
- vor 12 Minuten
- 8 Min. Lesezeit
Seit dem 1. Mai 2026 hat Agent 365 offiziell "General Availability" erreicht. Microsoft macht damit klar: Die Zeit der Pilotprojekte und Preview-Toggles ist vorbei. Agents werden produktiv, sie greifen auf Unternehmensdaten zu, sie schreiben in Systeme, sie schicken Mails und sie agieren autonom untereinander. 🤖
Die Herausforderung? Microsoft macht solche Agentic AI Systeme mit dem Agent Builder und durch Copilot Studio für Endanwendende sehr einfach zugänglich. Und genau deshalb müssen wir uns jetzt damit auseinandersetzen, wie wir mit Agents in unseren Organisationen umgehen wollen: Nicht nur aus technischer Sicht, sondern insbesondere auch aus der "Business"-Perspektive. Denn mit dieser neuartigen KI-Technologie eröffnen sich auch neue Herausforderungen und Risiken, welche es zu adressieren gilt. ⚠️
In diesem Blogartikel teile ich mit euch ein Agent-Governance-Framework, welches ich im Rahmen meiner MVP- und Kundentätigkeiten entwickelt habe. Es ist mein Versuch, euch einen Leitfaden zu geben, wie ihr eure Agent Governance pragmatisch aufbauen könnt, ohne Innovation auszubremsen. 🚀
Die Risikolage
Bevor wir über Lösungen reden, lohnt sich ein Blick auf die oben erwähnten Herausforderungen und Risiken: 👇🏻
Unsicherheit bei der Zuständigkeit
Wer darf eigentlich Agents bauen? Welches Tool ist das richtige? Und wie verhindern wir den berüchtigten "Agent Sprawl", also das unkontrollierte Wuchern von Agents quer durch die Organisation?
Doppelte Pflege
Agents entstehen sowohl im Agent Builder (innerhalb von Microsoft 365 Copilot) als auch in Copilot Studio. Ohne klare Abgrenzung gibt es Redundanzen, Inkonsistenzen und am Ende widersprüchliche Antworten an die Nutzer.
Governance-Lücke
Es fehlen definierte Prozesse für Freigabe, Ownership und den gesamten Lifecycle eines Agents.
Offboarding-Problem
Wenn Mitarbeitende das Unternehmen verlassen, muss die IT deren Agents deaktivieren können. Das geht nur, wenn zentrale Sichtbarkeit und Ownership existieren.
Skalierungsdruck
Gartner schätzt, dass Fortune-500-Unternehmen bis 2028 über 150.000 Agents im Einsatz haben werden. Nur rund 13% der Organisationen verfügen heute über eine angemessene Agent Governance. Das ist eine ziemliche Lücke. Quelle: https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
Die Governance-Hebel im Überblick 👇🏻
1️⃣ Agent-Klassen: Klassifizierung von Copilot Agents 2️⃣ Tool-Mapping: Agent Builder vs. Copilot Studio 3️⃣ Das 3-Zonen-Rollenmodell: Wer darf was? 4️⃣ Lifecycle-Management: Vermeidung von "Agent Sprawl"
1️⃣ Agent-Klassen
Mein Credo ist immer dasselbe: Verbote schaffen Schatten-IT, klare Leitplanken schaffen Vertrauen. Ich empfehle deshalb, Agents zu klassifizieren. Diese Klassen können je nach Organisation, Kultur und "Sicherheitsnetz" variieren. Microsoft selbst hat im Work Trend Index 2025 von der "Frontier Firm" gesprochen und die Agents in folgende drei Klassen unterteilt:
Alternativ kann auf spezifischere Agent-Klassen gesetzt werden wie z.B. "Persönlich", "Team/Abteilung" und "Geschäftskritisch". Diese Klassifizierung setze ich in der Praxis eher um, da es insbesondere für KMU "greifbarer" ist. 🏷️
Basierend auf dieser Klassifikation können weitreichende Entscheide gefällt werden:
Welche Rollen im Unternehmen dürfen welche Art von Agents bauen?
(Endanwendende, Citizen Developers, IT...)
Welches Tool soll/darf für die Konfiguration eines Agents verwendet werden?
(Agent Builder vs. Copilot Studio vs. Microsoft Foundry)
Welche Arten von Agent zählt zu welcher Agent-Klasse?
(Retrieval Agents, Task Agents, Autonomous Agents)
Welche Agent-Klassen müssen einen Freigabeprozess durchlaufen?
Welche Einstellungen gelten technisch für welche Agent-Klasse?
(Agent 365, Power Platform Admin Center...)
Die nachfolgende Tabelle visualisiert beispielhaft, wie man diese Fragen basierend auf der Agent-Klasse beantworten kann: 👇🏻
Klasse | Beispiel | Risiko | Governance-Hebel |
Persönlich | Fragt eigene oder interne Dokumente ab | Niedrig | Self-Service, keine Freigabe nötig |
Team / Abteilung | Abteilungs-Knowledge-Agent oder Agent, der Tickets erstellt, Mails sendet, Flows triggert | Mittel bis hoch | Owner, Datenprüfung, Reviews |
Geschäftskritisch | Agent mit ERP-, CRM- oder API-Aktionen, schreibt in externe Systeme | Sehr hoch | IT-Projekt, ALM, Monitoring, Betrieb, Compliance-Check und DLP |
Das Schöne an dieser Logik: Sie bremst nicht Person X im Fachbereich Y aus, die sich einen kleinen Q&A-Agent bauen will um ihren Arbeitsalltag zu erleichtern. Aber sie zieht die Bremse, sobald ein Agent mit anderen in der Organisation geteilt wird oder autonome Fähigkeiten erforderlich werden. 🎯
2️⃣ Tool-Mapping
Eine der häufigsten Fragen von Kunden lautet: Agent Builder oder Copilot Studio? Meine kurze Antwort: Beides, aber nicht zufällig. 💡
Der Agent Builder ist das richtige Werkzeug für Wissensmitarbeitende und Fachabteilungen. Er lebt direkt in Microsoft 365 Copilot, ist No-Code, wird per natürlicher Sprache konfiguriert und eignet sich hervorragend für leichtgewichtige Retrieval-Agents (also Agents, die Wissen abfragen, Inhalte auf einer spezifischen Datenbasis generieren oder zusammenfassen). Wissensquellen sind typischerweise SharePoint, OneDrive oder das Web. Geteilt wird entweder gar nicht (restriktive Handhabung) oder nur mit Einzelpersonen oder kleinen Teams (offenere Handhabung). Die Governance ist hier bewusst schlank, gesteuert über das Agent 365. 🧑🏻💻
Copilot Studio ist die Spielwiese für Maker, Entwickler und die IT. Low-Code bis Pro-Code, mit der gesamten Power Platform und weiteren, modernen Workflow- und Integrations-Technologien (APIs, MCPs...) im Rücken. Hier baut ihr autonome Agents mit Workflows, Logik, Connectors zu euren Business-Applikationen innerhalb und ausserhalb von M365. Publishing geht organisationsweit, extern und über mehrere Channels hinweg. Und hier greift die volle Governance-Tiefe über das Power Platform Admin Center, Purview & Co. 🛡️
Die Unterscheidung der drei technischen Agent-Typen helfen beim Mapping zusätzlich:
Retrieval Agents
Abfragen innerhalb von M365, Beantwortung von Fragen, Inhalte generieren oder zusammenfassen.
👉🏻 Agent Builder
Task Agents
Aktionen ausführen, Workflows automatisieren, repetitive Arbeiten übernehmen
👉🏻 Copilot Studio
Autonomous Agents
Selbständiges arbeiten, Koordination anderer Agents, Human-in-the-Loop-Eskalation, eigenständiges Lernen.
👉🏻 Copilot Studio
Mein wichtigster Satz dazu, und den schreibe ich bewusst gross:
Die Tool-Wahl darf nicht nach persönlicher Präferenz erfolgen, sondern nach Risiko, Zielgruppe, Datenquellen und Automatisierungsgrad.
Die nachfolgende Visualisierung mappt das Tool (Agent Builder vs. Copilot Studio) mit den entsprechenden Agent-Typen und nach Agent-Klassen: 👇🏻
3️⃣ Das 3-Zonen-Rollenmodell
Governance funktioniert nur, wenn jeder weiss, was sein Job ist. Microsoft hat dafür einen sehr spannenden Ansatz mit dem sogenannten "3-Zonen-Modell". Dieses Modell habe ich bereits in Kundenprojekten adaptiert und ergänzt die ersten beiden Governance-Hebel ideal. Die Grundidee: Verantwortlichkeiten und Tätigkeiten werden in drei Zonen segmentiert, je nach Zweck, Automatisierungsgrad und Risikolevel des Agents. Genau diese Logik lege ich auf eure Rollen: 👥
🟢 Zone 1: Citizen Development Zone (Endanwender)
Persönliche Produktivitäts-Agents (Retrieval Agents) im Agent Builder oder als SharePoint Agent, gebaut auf Inhalten, auf die der Nutzende ohnehin Zugriff hat. Hier dürfen sich Endanwendende austoben, solange sie ihre Agents nicht mit anderen teilen! Limitierte Wissensquellen, keine Automatisierungsfunktionen und einfache Governance über Agent 365.
🟡 Zone 2: Partnered Development Zone (Citizen Developers)
Hier passiert das Wachstum. Trainierte Citizen Developers bauen in Copilot Studio Agents für Teams und Abteilungen, idealerweise begleitet von einem erfahrenen Entwickler aus der IT. Die Citizen Devs sind Business Owner ihrer Agents, definieren System-Prompts und Wissensquellen, holen notwendige Freigaben aus Compliance-Sicht und übernehmen die regelmässigen Reviews. In dieser Zone können einfache Automatisierungen innerhalb von M365 konfiguriert werden. Governance über admin-genehmigte Umgebungen (Dev/Test/Prod), relevante Authentifizierung und auch vorgegebene Veröffentlichungskanäle (intern in M365/Copilot oder auch extern auf Webseite oder im eigenen ERP).
🔴 Zone 3: Professional Development Zone (Pro Devs und IT)
Die schwere Artillerie für geschäftskritische Agents mit autonomen Fähigkeiten wie Workflows, schreibenden Aktionen in ERP oder CRM und echten Compliance-Anforderungen. Hier fahren wir die ganz grossen Governance-Geschütze auf mit ALM, stärksten Security Controls (Data Policies im Power Platform Admin Center) und volles Monitoring über Microsoft Purview.
Das Schöne daran ist die Skalierung: Zone 1 ist schnell und harmlos, Zone 2 begleitet und skalierbar, Zone 3 solide und kontrolliert. Jeder Use Case findet seine Zone und niemand bekommt Rechte, für die er keine Verantwortung tragen kann. 🎯
4️⃣ Lifecycle-Management
Ein zentrales Risiko, welches wir in diesem Blog noch nicht adressiert haben, ist der "Agent Sprawl". Jeder Agent durchläuft einen Zyklus, und genau dieser Zyklus müsst ihr im Griff haben, denn das ist eure Versicherung gegen Agent Sprawl, insbesondere in den Zonen 2 und 3. Hier ein beispielhafter Lebenszyklus eines Agents inkl. Tätigkeiten: 👇🏻
Erstellen
Antrag aus dem Business ➡️ Prüfung & Freigabe durch IT ➡️ Definition Business Owner ➡️ Konfiguration des Agents ➡️ Testing & Deployment
Betreiben
Monitoring des Agents, Feedback-Auswertung, Bugfixing etc.
Reviewen
Quartalsweiser Review durch Owner und IT. Wird der Agent überhaupt noch genutzt? Sind die Berechtigungen korrekt? Sind die Datenquellen aktuell? Muss der System-Prompt angepasst werden?
Stilllegen
Nicht mehr genutzte Agents deaktivieren. Bei Mitarbeiteraustritt Ownership transferieren. Daten archivieren oder löschen.
Die richtige Technik für eure Agent Governance
Es ist klar: Eine jede gute Governance braucht technische "Controls" und Richtlinien, welche die Spielregeln zu euren Gunsten umsetzen. Ziel ist es, euren IT-Alltag zu erleichtern, Governance-Regeln zu automatisieren und eine einfache Verwaltung eurer Agents. Stand heute gibt es drei zentrale Bereiche, auf die ihr euch für eure Agent Governance fokussieren müsst und welche sauber ineinandergreifen:
Agent 365 als Control Plane
Agent 365 ist die Kontrollinstanz, mit der ihr Agents beobachten, verwalten und sichern könnt, unabhängig davon, wo sie in Agent Builder oder Copilot Studio gebaut oder durch Lizenzen gekauft wurden. Hier landen Inventar, Identitäten, Audit Logs und Risk Signals. Wer hier nicht hinschaut, verliert mittelfristig die Übersicht, vor allem über Shadow Agents auf Endpoints und in Drittplattformen.
Power Platform Admin Center (PPAC)
Hier wohnen die harten Kontrollen:
Umgebungen und Zonen
Ich empfehle eine saubere Trennung in Dev, Test und Prod, idealerweise als Managed Environments. Dazu gilt es die App Maker-Rolle nur den Nutzenden zu vergeben, die auch wirklich Copilot Studio Agents bauen dürfen.
Data Loss Prevention
DLP-Policies steuern, welche Connectors, HTTP-Calls, Skills oder Datenquellen ein Agent nutzen darf. Das ist eure härteste Bremse gegen Datenabfluss.
Application Lifecycle Management
Automatisierte Pipelines (auch via Azure DevOps) für ein kontrolliertes Deployment.
Channel Access Control
Einschränken oder Zulassen externer Veröffentlichungskanäle aus Copilot Studio.
⚠️ Im Power Platform Admin Center gibt es noch zwei weitere, hochrelevante Einstellungen, die ihr aus Datenschutzsicht unbedingt kennen müsst: ⚠️
1️⃣ Move data across regions
Generative AI Features sind nicht in jeder Region und Sprache verfügbar. Selbst wenn in eurer Region Kapazität existiert, müssen Daten in manchen Fällen für die Verfügbarkeit aus der Region heraus bewegt werden. Genau dafür gibt es im PPAC die Einstellung "Move data across regions".
Was bedeutet das konkret für uns in Europa? Wenn euer Power Platform Environment in Europa/EU gehostet ist, läuft der Azure OpenAI Endpoint innerhalb der EU Data Boundary. Diese Einstellung hat Auswirkungen auf eure Agents: Ist der Schalter aus, kommen je nach Region bestimmte Capabilities gar nicht erst zum Laufen, etwa Generative Answers (was bedeutet, dass ihr autonome Funktionalitäten wie Agent Flows nicht verwenden könnt) oder bestimmte Datenquellen, die nicht verfügbar sind. Ist er an, wandern Prompts und Outputs unter Umständen über Regionen hinweg. Das ist keine Katastrophe (Microsoft commitet sich klar im Product Terms und nutzt Daten nicht zum Training), aber ihr müsst es aktiv entscheiden und sauber dokumentieren. 🌍
2️⃣ Bing-Suche in Agents
Der zweite Schalter, den ich liebe und fürchte zugleich, ist Bing Search. Im PPAC könnt ihr zentral steuern, ob Agents überhaupt das öffentliche Web (über Bing) als Knowledge Source verwenden dürfen.
Auswirkung: Schaltet ihr die Bing Suche generell aus, kann ein Agent zwar weiterhin auf SharePoint, Dataverse oder Connectors zugreifen, aber er liefert keine frischen Web-Antworten mehr. Das ist genau das, was ihr für sensible Use Cases wollt, etwa wenn ein Agent ausschliesslich auf kuratiertem internem Wissen arbeiten soll. Aktiviert ihr die Websuche, bekommt der Agent Zugriff auf eine sehr breite Wissensbasis, aber ihr müsst ehrlich mit dem Thema „Halluzination" und Quellenkontrolle umgehen. 🛜
Mein Tipp: Setzt eine bewusste Default-Policy auf Tenant-Ebene und lasst die Bing Suche nur in Umgebungen zu, die explizit dafür freigegeben sind. Wer feiner steuern will, nutzt Bing Custom Search und schränkt die Suche auf eine Whitelist eurer eigenen Domains und vertrauenswürdiger Quellen ein. Das ist aus meiner Sicht der Sweet Spot zwischen Aktualität und Kontrolle.
Im nachfolgenden Screenshot seht ihr, wo ihr diese beiden Einstellungen im Power Platform Admin Center vornehmen könnt:
Copilot Studio Agent Settings
Pro Agent gibt es zusätzliche Einstellungen, die ihr für eure Agent Governance bewusst setzen solltet. Diese Einstellungen gehen über die Freigabe von Funktionalitäten und dahingehend auch deren Einfluss auf Credits-Kosten für eure Agents bis hin zu erweiterten Einstellungen wie Skills, Entitäten und weitere Funktionalitäten wie Voice oder Sprachkenntnisse. ⚙️
Die wohl wichtigste Einstellung betrifft allerdings die Security, konkret die Authentifizierung. Hier definiert ihr, wie sich Endanwendende authentifizieren sollen, um den Agent nutzen zu können. Standardmässig wird via Entra ID authentifiziert, was gleichzeitig bedeutet, dass ihr euren Agent nur in M365- & Copilot-Kanälen veröffentlichen könnt. Alternativ gibt es noch eine öffentliche Verfügbarkeit des Agents ohne Credentials sowie eine individuelle Authentifizierung bspw. über O2Auth. 🔒
Bei den Settings ist wichtig zu verstehen, dass ihr diese direkt im Agent in Copilot Studio vornehmt und die Einstellungen nur für den "geöffneten" Agent gelten. Die zentrale Governance solcher Einstellungen (also was ihr überhaupt "einstellen" könnt), erfolgt hauptsächlich im Power Platform Admin Center. 🤖
Fazit
Agent 365 GA ist für mich der Startschuss, das Thema Agent Governance aus der „nice to have"-Ecke in die Produktivnutzung zu heben. Ihr braucht keine perfekte Lösung am Tag eins. Ihr braucht eine klare Klassifizierung, definierte Rollen, ein paar harte Schalter im PPAC und einen Lifecycle, der gelebt wird. Der Rest ergibt sich. 👍🏻
Innovation und Kontrolle sind kein Widerspruch. Sie sind die zwei Seiten derselben Medaille. Und wer beide jetzt zusammen denkt, ist in zwölf Monaten dort, wo andere noch über ihren Agent Sprawl klagen werden. 💡
Kommentare