Copilot Studio braucht eine klare Governance für Lizenzen und Daten

In vielen Tenants, die ich mir anschaue, ist Copilot Studio spätestens mit der Umbenennung von Power Virtual Agents Ende 2023 praktisch über Nacht sichtbar geworden – ob gewollt oder nicht. Manche Admins haben die vielen neuen Copilot-Objekte im Power Platform Admin Center schon bemerkt. Andere erleben die erste Überraschung erst, wenn plötzlich ein Copilot mit sensiblen Firmendaten in Microsoft Teams auftaucht. Ich sehe immer wieder, dass Unternehmen ohne klare Copilot-Studio-Governance schnell die Kontrolle verlieren und Datenrisiken eingehen. Die Stolpersteine stecken dabei weniger in der Technik selbst als in scheinbar kleinen Details bei Lizenzen und Konfiguration.

Ein Klick auf die Testlizenz genügt, um Copilots zu bauen

Standardmäßig kann jeder Benutzer mit einer Microsoft-365-Lizenz Copilot Studio ausprobieren. Häufig reicht ein Klick auf „Copilot erstellen“, und schon läuft eine Testlizenz. Am deutlichsten merkt man das im globalen Default Environment, denn dort greifen die wenigsten Einschränkungen. Copilot Studio benötigt zwar eigene Lizenzen (bzw. Power-Virtual-Agents-Lizenzen), dank der Trial-Angebote bleibt die Hürde aber niedrig. Wer den Wildwuchs unterbinden will, muss selbst tätig werden. Im Power Platform Admin Center lässt sich die Self-Service-Lizenzierung für Trials abschalten, außerdem kann man das Erstellen in Copilot Studio auf bestimmte Gruppen oder Benutzer beschränken. Eine feingranulare Steuerung nach Funktionsumfang gibt es im Juni 2024 leider noch nicht. In Managed Environments (siehe unten) bekommt man die Grundfunktion trotzdem recht gut in den Griff.

Praxistipp: Wer Copilot Studio im Tenant nicht haben möchte, sollte neben der App auch die Umgebungskontrollen der Power Platform nutzen und die Lizenzzuweisungen regelmäßig prüfen. Sonst genügt ein einziger Klick, und die Schatten-IT wächst weiter.

Das Default Environment taugt nicht als Umgebung für produktive Copilots

In vielen Tenants ist das Default Environment der Power Platform zu einem Sammelbecken für Experimente, Schatten-IT und unübersichtliche Apps geworden. Bei Copilot Studio ist das besonders heikel, weil hier im Zweifel alle Benutzer sofort loslegen können und eigene Umgebungen oft gar nicht existieren. Für produktive Copilots empfehle ich deshalb immer dedizierte Environments, die konsequent als „Managed Environment“ konfiguriert sind. So gewinnt man deutlich mehr Kontrolle, etwa beim Schutz sensibler Daten und bei der Steuerung von Connectors. Eine gute Übersicht zu Managed Environments finden Sie bei Microsoft.

Das folgende Diagramm skizziert einen Governance-Prozess für Copilot Studio, der auf dedizierte, als Managed Environments konfigurierte Umgebungen setzt:

flowchart TD
    Benutzer["Benutzer"] --> Umgebungsauswahl["Umgebung wählen"]
    Umgebungsauswahl --> DefaultEnv["Default Environment"]
    Umgebungsauswahl --> DedizierteEnv["Dedizierte Umgebung"]
    DedizierteEnv --> ManagedEnv["Managed Environment"]
    ManagedEnv --> Kontrolle["Governance & DLP-Kontrollen"]
    Kontrolle --> CopilotBauen["Copilot bauen"]
    DefaultEnv --> Risiko["Weniger Kontrolle, hohes Risiko"]
    CopilotBauen --> Veröffentlichung["Veröffentlichen"]

Abbildung: Governance-Prozess für Copilot Studio im Default Environment und in dedizierten Managed Environments.

Meine Erfahrung aus Projekten ist eindeutig. Wo Copilot Studio in eigenen Managed Environments läuft, gibt es bei Berechtigungen und Schnittstellen deutlich seltener Überraschungen. Zugleich lassen sich die Copilots viel leichter inventarisieren und über ihren gesamten Lebenszyklus verwalten.

DLP-Policies begrenzen, welche Connectors ein Copilot kombinieren darf

Zu den wichtigsten Stellschrauben der Copilot-Studio-Governance gehört die DLP-Policy (Data Loss Prevention) der Power Platform. Sobald ein Copilot auf interne Datenquellen zugreift, HTTP-Requests absetzt oder in externen Kanälen wie Teams oder auf Websites veröffentlicht wird, können sensible Daten nach außen gelangen. Über DLP-Policies legt man auf Environment-Ebene fest, welche Connectors (z. B. Authentifizierung, Knowledge Sources, HTTP) gemeinsam genutzt werden dürfen. Wie DLP in Copilot Studio funktioniert, beschreibt Microsoft hier.

In Workshops und Tenant-Analysen begegnen mir immer wieder dieselben Problemfälle:

• Copilots greifen auf Knowledge Sources (SharePoint, Websites) mit sensiblen Inhalten zu und verwenden diese für Antworten in öffentlich zugänglichen Kanälen
• HTTP-Connectors schicken Daten an Drittanbieter, und niemand bemerkt es
• Die DLP-Policy ist zu grob eingestellt und lässt zu viele riskante Kombinationen zu

Für produktive Copilots sollten die DLP-Policies riskante Connector-Kombinationen ausschließen und vor allem HTTP-Requests sowie Zugriffe auf Knowledge Sources streng behandeln. Ein klarer Vorteil von Managed Environments ist, dass DLP-Policies dort verpflichtend sind.

So kann eine einfache DLP-Konfiguration aussehen:

{
  "Environment": "Copilot-Prod",
  "BlockedConnectors": ["HTTP", "Custom"],
  "AllowedConnectors": ["SharePoint", "Teams", "Outlook"]
}

Audit-Logs in Purview decken Lücken beim Datenabfluss auf

Auch mit DLP bleibt ein Restrisiko. Offen ist nämlich, wer einen Copilot so konfigurieren darf, dass sensible Informationen über Knowledge Sources abfließen. Quellen und Kanäle muss man deshalb im Blick behalten und regelmäßig überprüfen. Ich rate dazu, die Inventarisierung der Copilot-Objekte über das Power Platform Admin Center zu automatisieren und die Audit-Logs in Microsoft Purview regelmäßig auszuwerten. Copilot Studio schreibt inzwischen eigene Audit-Einträge. Damit lassen sich Änderungen an Knowledge Sources, Veröffentlichungen und Publishing-Channels nachvollziehen, vorausgesetzt, die Purview-Audit-Logs sind aktiviert.

Wer Copilot Studio produktiv einsetzen will, sollte die Auditing-Funktionen von Purview ausprobieren, bevor die ersten kritischen Bots live gehen. Häufig fehlen noch passende Suchabfragen, und die Datenmenge ist oft größer als erwartet.

Noch ein Hinweis am Rande. Die Audit-Suche in Purview arbeitet mit Filterfeldern und nicht mit KQL. Am schnellsten verschafft man sich einen Überblick im Microsoft-Purview-Portal unter Überwachung (Audit) → Suchen. Dort setzt man den Datumsbereich, wählt im Feld „Aktivitäten – Anzeigenamen“ die Copilot-Studio-Aktivitäten aus und exportiert das Ergebnis bei Bedarf als CSV. Welche Aktivitäten Copilot Studio protokolliert, steht in der Dokumentation zur Überwachung von Copilot Studio.

Erweiterungen verlangen eine mitwachsende Governance-Strategie

Seit sich eigene Plugins und Copilot Extensions bauen lassen, wächst die Verantwortung weiter. Managed Environments helfen, diese Erweiterungen zu steuern, die Governance-Strategie muss aber Schritt halten. Wer sich für die technische Seite der Copilot-Erweiterungen interessiert, findet in meinem Beitrag Copilot Extensions und Governance – Erkenntnisse von der Build 2024 weitere Details und Empfehlungen aus der Praxis.

Governance für Copilot Studio erledigt man nicht einmal und hakt sie dann ab. Sie bleibt eine Daueraufgabe zwischen technischen Anforderungen, Compliance und den Wünschen der Anwender. Wer jetzt konsequent aufräumt, erspart sich später viel Ärger und kann die neuen Möglichkeiten mit gutem Gefühl nutzen.