Copilot Studio Agents im Unternehmen einführen: Governance, Datenzugriff und Freigaben

Ein Fachbereich möchte einen Copilot-Studio-Agenten kurzfristig in Microsoft Teams bereitstellen: Er soll Fragen zu Verträgen beantworten, Tickets anlegen und Informationen aus SharePoint nutzen. Der Prototyp funktioniert bereits. Doch bevor Kolleginnen und Kollegen sensible Inhalte eingeben oder der Agent Aktionen in anderen Systemen auslöst, müssen Zuständigkeiten, Datenzugriffe und technische Leitplanken feststehen. Genau an diesem Übergang vom Pilot zur produktiven Nutzung entscheidet sich, ob KI-Agenten helfen oder neue Risiken schaffen.

Copilot Studio ermöglicht es, dialogorientierte Agenten mit Wissensquellen, Themen, generativer Orchestrierung, Connectoren und Aktionen zu erstellen. Das ist nützlich, verschiebt aber Verantwortung: Ein Agent verarbeitet nicht nur Texteingaben. Je nach Konfiguration kann er auf Unternehmensdaten zugreifen, Prozesse über Power Automate anstoßen und Daten an angeschlossene Dienste übergeben. Deshalb behandeln wir einen produktiven Agenten nicht als kleine Chat-Anwendung, sondern als fachliche Anwendung mit klarer Governance.

Infografik zu Copilot Studio Agents im Unternehmen einführen: Governance, Datenzugriff und Freigaben (KI-generiert).

Zuerst den Einsatzzweck präzise begrenzen

Der sicherste Agent ist nicht der mit den meisten Datenquellen und Aktionen, sondern der mit einer klaren, überprüfbaren Aufgabe. „Unterstützt alle Fragen zum Vertrieb“ ist keine ausreichende Anforderung. „Beantwortet Mitarbeitenden Fragen zu freigegebenen Produktdatenblättern und erstellt auf ausdrücklichen Wunsch einen Entwurf für eine CRM-Aufgabe“ ist wesentlich besser steuerbar.

Halte vor dem Bau mindestens diese Punkte fest:

• Welche Nutzergruppe verwendet den Agenten?
• Welches konkrete Problem löst er?
• Welche Antworten darf er geben, welche ausdrücklich nicht?
• Welche Wissensquellen sind zugelassen?
• Darf er nur informieren oder auch Aktionen ausführen?
• Welche Systeme darf er ansprechen?
• Welche Daten dürfen Nutzende in den Chat eingeben?
• Wer verantwortet Inhalte, Technik, Datenschutz und Betrieb?
• Woran erkennst du, dass der Pilot erfolgreich ist?

Diese Beschreibung ist später die Grundlage für Tests, Freigaben und Änderungen. Sie verhindert auch, dass aus einem kleinen Wissensagenten schrittweise ein kaum noch überschaubarer Prozessagent wird.

Bei KI-Anwendungen solltest du zudem fachliche Risiken erfassen: Kann eine falsche Antwort zu einer Fehlentscheidung führen? Könnte der Agent vertrauliche Inhalte offenlegen? Darf eine Aktion nur vorbereitet werden, oder benötigt sie eine menschliche Bestätigung? Für die übergreifende Qualifizierung von Teams und Verantwortlichen ist unser Beitrag KI-Kompetenz nach EU AI Act aufbauen: Schulungen für Unternehmen eine sinnvolle Ergänzung.

Umgebungen trennen und Änderungen nachvollziehbar machen

Ein Agent sollte nicht direkt in einer Umgebung entstehen, die viele Mitarbeitende produktiv nutzen. Richte mindestens getrennte Umgebungen für Entwicklung, Test und Produktion ein. So können Maker neue Themen, Prompts, Wissensquellen und Aktionen ausprobieren, ohne den laufenden Betrieb zu beeinflussen.

Eine praxistaugliche Struktur sieht so aus:

Umgebung	Zweck	Zugriffsrechte
Entwicklung	Entwurf, technische Erprobung, frühe Tests	Kleines Maker-Team
Test	Fachtest, Sicherheitsprüfung, Abnahme	Fachverantwortliche, Testgruppe, IT
Produktion	Freigegebene Nutzung	Endnutzer, begrenzte Administrationsrechte

Nutze Lösungen, um Komponenten wie Agenten, Flows, Tabellen, Connector-Referenzen und Umgebungsvariablen geordnet zu transportieren. Änderungen bleiben damit nachvollziehbarer als bei manuellen Anpassungen direkt in der Produktionsumgebung. Lege außerdem fest, wer eine Lösung importieren darf und wer Produktionsänderungen freigibt.

Für produktive Umgebungen sind zusätzliche Governance-Funktionen der Power Platform sinnvoll. Entscheidend ist nicht nur die Technik, sondern auch die Rollenverteilung: Maker erstellen Inhalte, Plattformverantwortliche verwalten Umgebungen und Richtlinien, Fachverantwortliche prüfen Nutzen und Qualität, Security und Datenschutz bewerten Risiken. Eine Person sollte nicht unkontrolliert alle diese Rollen gleichzeitig ausüben.

Datenzugriff nach dem Prinzip der minimalen Rechte planen

Ein Agent benötigt Daten nicht automatisch deshalb, weil sie nützlich sein könnten. Jede Wissensquelle und jeder Connector braucht eine nachvollziehbare fachliche Begründung. Beginne mit wenigen, klar abgegrenzten Quellen und erweitere erst nach belastbaren Tests.

Bei SharePoint bedeutet das beispielsweise: Stelle nicht eine gesamte Site-Sammlung bereit, wenn nur eine Bibliothek mit freigegebenen Handbüchern erforderlich ist. Prüfe Eigentümerschaft, Berechtigungen, Aktualität und Klassifizierung der Dokumente. Veraltete oder widersprüchliche Dateien führen zu schlechten Antworten, selbst wenn die technische Anbindung funktioniert.

Besondere Aufmerksamkeit verdient die Identität, mit der ein Zugriff erfolgt. Kläre für jede Verbindung:

• Greift der Agent im Kontext der angemeldeten Person zu?
• Wird eine fest hinterlegte Verbindung oder ein technisches Konto verwendet?
• Welche Rechte besitzt diese Identität tatsächlich?
• Können Nutzende über den Agenten Inhalte sehen oder Aktionen auslösen, die ihnen sonst nicht erlaubt wären?
• Wie werden Kennwörter, Secrets und Zugriffsrechte verwaltet und regelmäßig überprüft?

Ein technisches Konto mit weitreichenden Berechtigungen ist für schnelle Prototypen verlockend, aber im Produktivbetrieb oft ein Sicherheitsproblem. Nutze es nicht als Abkürzung, um fehlende Berechtigungskonzepte zu überdecken. Gerade bei Dienstidentitäten, App-Registrierungen und automatisierten Zugriffswegen hilft dir unser Ratgeber Microsoft Entra Workload Identities absichern: Service Principals, Managed Identities und KI-Agenten kontrollieren.

Bei Wissensquellen solltest du zudem testen, ob das konkrete Konfigurationsmodell die vorgesehenen Berechtigungsgrenzen zuverlässig abbildet. Verlasse dich nicht auf Annahmen wie „Der Agent wird schon nur das sehen, was der Nutzer sieht“. Dokumentiere die gewählte Authentifizierung und prüfe sie mit Testkonten unterschiedlicher Rollen.

Connectoren und Aktionen konsequent begrenzen

Der größte Unterschied zwischen einem reinen Informationsagenten und einem handlungsfähigen Agenten liegt in den Aktionen. Ein Agent, der ein Dokument zusammenfasst, hat ein anderes Risikoprofil als ein Agent, der Datensätze anlegt, E-Mails versendet, Berechtigungen ändert oder Bestellungen auslöst.

Erstelle daher ein Verzeichnis aller verwendeten Connectoren, benutzerdefinierten Connectoren, Power-Automate-Flows und externen Endpunkte. Für jeden Eintrag dokumentierst du Zweck, verantwortliche Person, Authentifizierung, Datenarten, Zielsystem und mögliche Auswirkungen.

Prüfe insbesondere diese Fragen:

• Kann der Agent Daten nur lesen oder auch schreiben, ändern oder löschen?
• Werden Aktionen direkt ausgeführt oder zunächst als Entwurf angezeigt?
• Ist vor einer kritischen Aktion eine Bestätigung durch den Nutzer erforderlich?
• Welche Eingaben gelangen an externe Systeme?
• Was passiert bei einer fehlerhaften, unvollständigen oder missverständlichen Eingabe?
• Gibt es einen sicheren Abbruchweg und eine nachvollziehbare Protokollierung?

Für Prozesse mit relevanten Folgen empfehlen wir eine menschliche Freigabe im Ablauf. Der Agent kann etwa eine Ticketbeschreibung vorbereiten, aber die anfragende Person bestätigt Zielsystem, Priorität und Inhalt vor dem Absenden. Bei besonders sensiblen Abläufen sollte eine fachlich zuständige Stelle zusätzlich prüfen.

Wenn du KI-Agenten an Werkzeuge und Daten anbinden möchtest, gelten ähnliche Grundsätze auch für moderne Schnittstellenmuster. Lies dazu MCP-Server sicher entwickeln: KI-Agenten kontrolliert an Tools und Daten anbinden.

DLP-Richtlinien als technische Leitplanke einsetzen

Data Loss Prevention, kurz DLP, gehört in Copilot-Studio-Projekte von Beginn an. DLP-Richtlinien der Power Platform steuern, welche Connectoren innerhalb einer Umgebung gemeinsam verwendet werden dürfen. Damit kannst du beispielsweise geschäftlich benötigte Dienste gruppieren, nicht geschäftliche Dienste ausschließen und riskante Connectoren blockieren.

Eine DLP-Richtlinie ersetzt keine Berechtigungen und keine Inhaltsprüfung. Sie ist aber eine wichtige Schranke gegen unkontrollierte Datenwege. Wenn ein Agent auf SharePoint zugreift, sollte ein Maker diese Daten nicht über einen ungeeigneten Connector an einen externen Dienst weitergeben können.

Plane DLP in drei Schritten:

1. Ermittle, welche Connectoren für den konkreten Agenten zwingend nötig sind.
2. Ordne zugelassene Connectoren kontrolliert den passenden Gruppen zu und blockiere nicht benötigte Dienste.
3. Teste reale Datenflüsse in der Testumgebung, einschließlich Fehlerfällen und Eingaben mit vertraulichen Informationen.

Ergänzend solltest du für Microsoft 365 prüfen, wie sensible Informationen klassifiziert und geschützt werden. Unser Beitrag Microsoft Purview DLP einrichten: sensible Daten in Teams, SharePoint und Exchange schützen zeigt, warum Schutzregeln für Inhalte und Connector-Governance zusammengehören.

Einen verbindlichen Freigabeprozess etablieren

Ein produktiver Agent braucht einen klaren Freigabeprozess, der zur Risikostufe passt. Für einen kleinen Agenten mit öffentlich freigegebenem Wissen genügt eine schlankere Prüfung als für einen Agenten mit Personal-, Kunden- oder Vertragsdaten und schreibenden Aktionen.

Ein sinnvoller Prozess umfasst diese Stationen:

• Fachbereich beschreibt Zweck, Nutzerkreis, Datenquellen und erwartete Aktionen.
• IT prüft Umgebung, Rollen, Connectoren, Identitäten und Betriebsverantwortung.
• Datenschutz und Informationssicherheit bewerten Datenarten, Risiken und Schutzmaßnahmen.
• Eine Testgruppe prüft Antworten, Berechtigungsgrenzen, Fehlverhalten und Ausgaben bei ungewöhnlichen Eingaben.
• Die fachliche Eigentümerschaft bestätigt Inhalt, Aktualität und Einsatzgrenzen.
• Die verantwortliche Stelle gibt Veröffentlichungskanal und Produktivsetzung frei.

Dokumentiere auch, wie Nutzende den Agenten erreichen, etwa in Teams oder auf einer internen Website. Ein Agent sollte nicht über einen breiten Kanal veröffentlicht werden, bevor Zugriffsgruppen, Kommunikationshinweise und Supportweg festgelegt sind. Nutzende müssen wissen, wofür der Agent gedacht ist, welche Angaben sie nicht eingeben sollen und wie sie problematische Antworten melden.

Betrieb überwachen und regelmäßig nachschärfen

Mit der Veröffentlichung beginnt die eigentliche Arbeit. Überwache Nutzung, Fehlermeldungen, nicht beantwortete Fragen, Abbrüche und ausgelöste Aktionen. Prüfe Gesprächsverläufe nur im Rahmen der festgelegten Datenschutz- und Zugriffsregeln. Das Ziel ist, Qualitätsprobleme und Risiken früh zu erkennen, nicht Mitarbeitende unnötig zu kontrollieren.

Lege feste Termine fest, an denen du diese Punkte überprüfst:

• Sind Wissensquellen noch aktuell und erforderlich?
• Haben sich Berechtigungen oder Eigentümer geändert?
• Werden nicht mehr benötigte Connectoren oder Verbindungen entfernt?
• Gibt es neue Aktionen, die eine erneute Prüfung benötigen?
• Sind DLP-Richtlinien weiterhin wirksam?
• Häufen sich falsche Antworten oder riskante Eingaben?
• Ist der Agent weiterhin für den ursprünglich freigegebenen Zweck im Einsatz?

Ein kurzer Änderungsprozess hilft: Jede neue Datenquelle, jeder Connector und jede schreibende Aktion wird zunächst in Entwicklung umgesetzt, getestet und erneut freigegeben. So bleibt der Agent auch nach Monaten steuerbar.

Passende Seminare und Termine zu Microsoft, Cloud, Security und Power Platform findest du bei uns auf cmt.de. Für die Einführung im Team lohnt sich außerdem unser Leitfaden Weiterbildung fürs IT-Team planen: so geht’s.

Ein gut eingeführter Copilot-Studio-Agent ist kein unkontrollierter Zugang zu Unternehmenswissen. Er ist ein klar abgegrenztes Werkzeug: mit passenden Identitäten, minimalen Berechtigungen, begrenzten Datenwegen, überprüften Aktionen und einer Verantwortung, die auch nach dem Go-live nicht endet.