Der von Microsoft dokumentierte technische Weg ist kurz: Agent in Copilot Studio veröffentlichen, SharePoint-Kanal auswählen, Site bestimmen und bereitstellen. Microsoft verlangt dafür Schreibzugriff auf die Ziel-Site. Danach wird das Erlebnis in SharePoint getestet und kann dort als Approved sichtbar gemacht werden.

Problematisch werden improvisierte Rechte. Ein SharePoint-Administrator wird zum Agenten-Miteigentümer oder ein Maker erhält breiten Site-Zugriff, nur damit die Veröffentlichung funktioniert. Diese Rechte bleiben bestehen und verwischen Verantwortung.

Fünf Rollen trennen

Der Maker entwickelt in der Entwicklungsumgebung, pflegt Anweisungen, Wissen und Aktionen und liefert technische Release-Notizen. Er akzeptiert nicht automatisch das Geschäftsrisiko.

Der Business Owner verantwortet Zweck, Zielgruppe, akzeptables Verhalten und Nutzen. Er nimmt die getestete Version für die vorgesehene Site ab.

Die Plattform-Release-Rolle transportiert die versionierte Solution durch Test und Produktion, validiert Abhängigkeiten, Connections und Umgebungsvariablen und dokumentiert den Lauf.

Der SharePoint-Site-Owner oder begrenzte Deployer bestätigt Ziel-Site und Zielgruppe und konfiguriert den Produktionskanal. Er benötigt die dokumentierten Schreibrechte für diesen Schritt, aber nicht automatisch dauerhaftes Eigentum am Agenten.

Der Service Owner führt Monitoring, Incident Response, Kapazität, Support, regelmäßige Prüfung und Undeployment zusammen.

Eine Person kann in kleinen Organisationen mehrere Rollen tragen. Die Entscheidungen bleiben trotzdem getrennt.

Zwei Teile im Release-Nachweis

Nicht alle Copilot-Studio-Einstellungen sind Solution-aware. Microsoft nennt veröffentlichte Kanäle und Freigaben als nachgelagerte Konfiguration. Deshalb besitzt der Release-Nachweis zwei verknüpfte Teile.

Der transportierte Teil enthält Solution-Version, Komponenten, Connection References, Umgebungsvariablen, Testergebnisse, Abnahme und Produktionslauf.

Der nachgelagerte Teil enthält Produktions-Agent-ID, SharePoint-URL, Kanalstatus, Schreibberechtigung, Approval-Status in SharePoint, Zielgruppe, Smoke Test, Service Owner und Undeployment-Weg.

Ein erfolgreicher Solution-Import ist ohne diesen zweiten Teil noch kein vollständiges Release.

Der Release-Swimlane

  1. Der Maker schließt die Änderung in Development innerhalb einer Solution ab.
  2. Die Plattform-Rolle transportiert dieselbe Version nach Test und setzt umgebungsspezifische Werte.
  3. Fachtester prüfen typische und verbotene Szenarien; der Business Owner akzeptiert Verhalten und Zielgruppe.
  4. Die Plattform-Rolle bringt das freigegebene Artefakt nach Produktion und veröffentlicht den Agenten.
  5. Der SharePoint-Deployer bestätigt die exakte Site, erhält nötigenfalls zeitlich begrenzte Schreibrechte und konfiguriert den Kanal.
  6. Ein Tester öffnet den Agenten aus SharePoint und prüft Rollen, Quellen, Aktionen, Fehler und Telemetrie.
  7. Erst danach markiert der zuständige Site Owner den Agenten als Approved.
  8. Temporäre Rechte werden entfernt und der Service Owner übernimmt Release- und Rückfallnachweis.

Fehler werden nicht durch direkte Produktionsanpassung korrigiert. Die Änderung beginnt erneut in Development.

Beispiel: HR-Richtlinienagent

HR baut einen Agenten für Fragen zu kuratierten Richtlinien. Ein Plattform-Engineer kann Solutions deployen, ist aber kein Mitglied der HR-Site. Früher hätte man ihn als Agenten-Miteigentümer und dauerhaftes Site-Mitglied aufgenommen.

Im neuen Prozess verantwortet HR Verhalten und Quellen. Das Plattformteam transportiert und veröffentlicht den Produktionsagenten. Ein HR-Site-Owner mit Schreibzugriff führt die Kanalbereitstellung anhand der Checkliste aus. Eine andere Person testet mit Mitarbeiter- und Managerrolle erlaubte Quellen und Fragen zu geschützten Fallunterlagen. Sichtbarkeit wird erst nach bestandenem Test genehmigt.

Der Service-Nachweis benennt HR als Business Owner, das Plattformteam als technischen Betreiber und den Site Owner als Verantwortlichen für die Zielgruppe. Release-Befugnis erzeugt kein dauerhaftes Miteigentum.

Fehler und Entfernung planen

Undeployment wird vor der ersten relevanten Veröffentlichung getestet. Der Betrieb weiß, wann ein Agent nur verborgen, nicht mehr Approved, von einer Site entfernt oder auf Plattformebene deaktiviert wird. Ein problematisches Inhaltsupdate kann eine einzelne Site betreffen, ohne andere Kanäle abzuschalten.

Kapazität wird ausdrücklich überwacht. Microsoft weist darauf hin, dass ein in SharePoint verwendeter Agent weiterhin den Copilot-Studio-Abrechnungsregeln folgt und Kapazität verbraucht.

Auch der Wechsel von Maker, Site Owner oder Business Owner gehört in den Identitätslebenszyklus. Eigentumsübertragung darf nicht erst im Incident auffallen.

Befugnis temporär, Verantwortung dauerhaft

Minimalrechte bedeuten keinen manuellen Sonderfall bei jedem Release. Eine kleine genehmigte Deployer-Gruppe, ein Anfrageweg, regelmäßige Access Reviews und Audit schaffen einen wiederholbaren Dienst. Zeitlich begrenzte Rechte werden genutzt, wo die Plattform sie unterstützt.

Dauerhaft bleiben nur die Verantwortungen für Zweck, Site und Service. Amplified Pi gestaltet diesen Pfad über Copilot Studio, Power Platform und SharePoint, damit Releases skalieren, ohne von persönlichem Admin-Zugriff abzuhängen.