Zuletzt aktualisiert: 17. September 2026 · Version: 2.0
Copilot Studio und Agents kontrolliert einführen
Vom geeigneten Anwendungsfall über Umgebungen, Identitäten und Datenrichtlinien bis zur technischen Abnahme und zum Regelbetrieb.
Ein Agent ist nicht einfach ein Chatbot mit besserem Prompt. Sobald er interne Datenquellen nutzt, Werkzeuge aufruft oder Aktionen ausführt, wird er zu einer kleinen Unternehmensanwendung – mit Identität, Berechtigungen, Abhängigkeiten, Kosten und Betriebsverantwortung.
Low-Code senkt die Hürde zum Erstellen. Es beseitigt aber weder Architekturentscheidungen noch Sicherheits- und Testaufwand. Die wichtigste Builder-Regel lautet deshalb: Je größer die Wirkung einer Aktion, desto weniger darf ihre Kontrolle vom Sprachmodell abhängen.
In 30 Sekunden
- Copilot Studio eignet sich für wissensbasierte und aktionsfähige Agents, benötigt aber eine Power-Platform-Umgebungs- und Governance-Strategie.
- Wissensquellen, Tools, Connectoren, HTTP-Aufrufe, Trigger und Veröffentlichung müssen getrennt kontrolliert werden.
- Persönliche Maker-Anmeldedaten können unbeabsichtigt Rechte des Erstellers an Nutzer weiterreichen. Authentifizierung ist deshalb eine Architekturentscheidung.
- Entwicklung, Test und Produktion gehören getrennt; Änderungen benötigen Versionierung, Abnahme und Rückfallplan.
- Copilot Cowork ist ein Microsoft-365-Copilot-Arbeitsmodus und nicht dasselbe wie ein eigener Copilot-Studio-Agent.
Zuerst entscheiden: Standardfunktion, Cowork oder eigener Agent?
Nicht jedes Problem braucht einen neuen Agent. Der geringste zusätzliche Betriebsaufwand entsteht, wenn eine vorhandene Microsoft-365-Copilot-Funktion die Aufgabe bereits ausreichend löst.
| Option | Geeignet, wenn … | Zusätzliche Verantwortung |
|---|---|---|
| Microsoft 365 Copilot | Nutzer mit E-Mails, Meetings, Dokumenten und vorhandenem Arbeitskontext arbeiten. | Tenant-, Daten- und Nutzungsgovernance |
| Copilot Cowork | ein berechtigter Nutzer mehrstufige Arbeit im eigenen Microsoft-365-Kontext delegiert. | Aufgabenfreigabe, Verbrauch, Ergebnisse und Automationen |
| Copilot-Studio-Agent | ein klarer Prozess, eigene Wissensquellen, Kanäle, Werkzeuge oder definierte Aktionen benötigt werden. | kompletter Lebenszyklus von Identität bis Stilllegung |
Copilot Cowork ist seit Juni 2026 allgemein verfügbar und kann mehrstufige Aufgaben übernehmen. Microsoft dokumentiert dafür eigene Modelle, Automationen und Verbrauchsabrechnung. Es ist dennoch kein Ersatz für einen kontrolliert entwickelten Fachagenten mit eigener Veröffentlichung, Datenpolitik und Betriebsverantwortung. [Microsoft: Neuerungen in Cowork]
Schritt 1: Einen tragfähigen Anwendungsfall auswählen
Ein guter erster Agent bearbeitet eine klar begrenzte Aufgabe, nutzt wenige verlässliche Quellen und erzeugt Ergebnisse, die fachlich überprüfbar sind. Riskant sind dagegen Projekte, die gleichzeitig unbekannte Datenbestände, mehrere Geschäftssysteme und irreversible Aktionen kombinieren.
Vier Prüfbereiche
- Wert: Welcher konkrete Aufwand, Fehler oder Medienbruch soll reduziert werden?
- Daten: Welche Quellen werden benötigt, wem gehören sie und wie aktuell sind sie?
- Aktion: Liest der Agent nur, erstellt er Entwürfe oder verändert er Geschäftsdaten?
- Reversibilität: Kann eine falsche Aktion erkannt, gestoppt und zurückgenommen werden?
Ein interner Richtlinienassistent mit kuratierten Dokumenten eignet sich eher als Einstieg als ein Agent, der selbständig Bestellungen, Zahlungen oder Personalentscheidungen auslöst.
Schritt 2: Umgebungen und Verantwortlichkeiten festlegen
Copilot-Studio-Agents werden innerhalb von Power-Platform-Umgebungen erstellt. Diese Umgebungen definieren Daten- und Verwaltungsgrenzen, Rollen, Richtlinien und die Trennung zwischen Entwicklung und Produktion. Microsoft empfiehlt eine risikobasierte, zonierte Governance statt eines einzigen offenen Maker-Bereichs. [Microsoft: Zoned Governance]
- Persönliche Produktivität: begrenzte Reichweite, keine kritischen Aktionen, einfache Freigabe.
- Team- und Abteilungsnutzung: benannter Owner, definierte Nutzergruppe, Test- und Supportprozess.
- Unternehmensanwendung: getrennte Entwicklungs-, Test- und Produktionsumgebungen, ALM, technische Kontrollen und formale Abnahme.
Mindestens erforderlich sind fachlicher Owner, technischer Owner, Datenverantwortliche und eine Stelle, die Veröffentlichung sowie Änderungen freigibt. Der ursprüngliche Maker allein ist kein belastbares Betriebsmodell.
Schritt 3: Identität und Berechtigungen außerhalb des Modells begrenzen
Die riskanteste Abkürzung ist ein Agent, der für alle Nutzer mit den persönlichen Zugangsdaten seines Erstellers auf ein System zugreift. Microsoft weist darauf hin, dass Maker-Anmeldedaten dazu führen können, dass Nutzer indirekt Funktionen oder Daten erreichen, die nur der Maker verwenden dürfte. [Microsoft: Maker Credentials kontrollieren]
Für jedes Werkzeug muss deshalb dokumentiert werden:
- Welche Identität führt den Aufruf aus?
- Wer darf den Agent und die Aktion verwenden?
- Welche Daten, Datensätze und Felder sind erreichbar?
- Welche Operationen sind erlaubt: lesen, erstellen, ändern oder löschen?
- Welche Betrags-, Mengen-, Ziel- oder Frequenzlimits gelten?
- Welche Aktionen benötigen eine externe menschliche Freigabe?
Der Freigabemechanismus muss außerhalb des manipulierbaren Agentenkontexts liegen. Eine Textanweisung wie „Frage vorher den Menschen“ ist keine ausreichende Zugriffskontrolle.
Schritt 4: Wissen, Tools und Datenbewegung kontrollieren
Power-Platform-Datenrichtlinien können unter anderem Wissensquellen, Connectoren, HTTP-Anfragen, Skills, Veröffentlichungskanäle und Trigger erlauben oder blockieren. Seit 2025 gilt die Durchsetzung laut Microsoft für alle Tenants. [Microsoft: Datenrichtlinien für Agents]
Die Kontrolle muss dabei zwei unterschiedliche Risiken behandeln:
- Datenzugriff: Der Agent erhält mehr Informationen, als für seinen Zweck nötig sind.
- Datenbewegung: Ein Connector oder Werkzeug überträgt Informationen in einen anderen Dienst oder eine andere Region.
Eine Freigabeliste vertrauenswürdiger Connectoren, blockierte anonyme Authentifizierung und dokumentierte Datenflüsse sind belastbarer als eine allgemeine Richtlinie „keine sensiblen Daten verwenden“.
Schritt 5: Entwicklungs- und Abnahmetests operationalisieren
Ein freundlicher Testdialog beweist nicht, dass ein Agent sicher funktioniert. Der Testplan muss Wissen, Identität, Werkzeuge, Aktionen und Fehlerbehandlung gemeinsam untersuchen.
| Testfeld | Beispiel | Abnahmekriterium |
|---|---|---|
| Grounding | widersprüchliche oder veraltete Quellen | Quellen werden erkennbar priorisiert; Unsicherheit wird angezeigt. |
| Berechtigungen | Nutzer ohne Zugriff fragt nach geschützten Daten | kein Inhalt und keine indirekte Bestätigung werden ausgegeben. |
| Prompt Injection | bösartige Anweisung in Dokument oder Webseite | Agent ignoriert die Anweisung und führt keine unzulässige Aktion aus. |
| Werkzeugfehler | Timeout, unvollständige Antwort oder doppelter Aufruf | keine unbemerkte Doppelbuchung; verständliche Eskalation. |
| Serienaktion | viele Datensätze oder Empfänger | Mengenlimit, Vorschau und Freigabe greifen technisch. |
Erneute Tests sind mindestens nach Änderungen an Modell, Anweisungen, Quellen, Tools, Berechtigungen oder Veröffentlichung erforderlich. Bei hoher Wirkung gehören unabhängige Prüfung und Red Teaming hinzu.
Schritt 6: Veröffentlichen, beobachten und stilllegen
Vor der Veröffentlichung müssen Nutzergruppe, Kanal, Owner, Supportweg und Rückfalloption feststehen. Microsoft stellt im Microsoft-365-Admin-Center und im Power-Platform-Admin-Center unterschiedliche Steuerungen für Zugriff, Veröffentlichung, Inventar und Richtlinien bereit. Copilot Studio ergänzt Laufzeit- und Sicherheitsinformationen; Agent 365 kann als zusätzliche Kontroll- und Beobachtungsebene dienen. [Microsoft: Security and Governance]
Das Agentenregister sollte mindestens Zweck, Owner, Umgebung, Nutzer, Datenquellen, Werkzeuge, Identitäten, Kostenmodell, letzten Test, nächste Prüfung und Stilllegungsweg enthalten. Ein Agent ohne aktiven Owner oder ohne genutzten Geschäftszweck gehört deaktiviert.
Vier gefährliche Abkürzungen
- Produktionsagent direkt in der persönlichen Maker-Umgebung bauen.
- Persönliche Maker-Anmeldedaten als bequeme Standardidentität verwenden.
- Schreibende Aktionen nur durch Promptregeln begrenzen.
- Nach der Veröffentlichung weder Kosten, Fehler noch Eigentümerschaft prüfen.
Go/No-Go für den ersten produktiven Agent
- Zweck, Nutzergruppe und fachlicher Owner sind dokumentiert.
- Entwicklungs-, Test- und Produktionsweg sind der Risikostufe angemessen.
- Datenquellen, Connectoren, Identitäten und Datenflüsse sind geprüft.
- Least Privilege, technische Limits und externe Freigaben greifen.
- Funktion, Berechtigung, Prompt Injection, Werkzeugfehler und Serienaktionen sind getestet.
- Monitoring, Kostenverantwortung, Incident-Prozess und Stilllegung sind geklärt.
Fazit: Low-Code beschleunigt Entwicklung, nicht Verantwortung
Copilot Studio kann Fachwissen und Prozesse schneller zugänglich machen. Der produktive Wert entsteht aber erst, wenn der Agent wie eine Unternehmensanwendung behandelt wird: mit klarer Aufgabe, kontrollierter Identität, begrenzten Werkzeugen, wiederholbaren Tests und verantwortetem Betrieb.
Der nächste Schritt ist kein freier Maker-Workshop, sondern ein abgegrenzter Agenten-Steckbrief. Beschreiben Sie Zweck, Nutzer, Quellen, Aktionen, Identität, größtmöglichen Schaden und Rückfallweg auf einer Seite. Wenn diese Fragen nicht beantwortet werden können, ist der Anwendungsfall noch nicht bereit für die Entwicklung.
