Autopilot-Lebenszyklus in Microsoft Foundry

Ein Autopilot durchläuft einen definierten Lebenszyklus. Ein Azure-Administrator stellt die Plattform bereit, ein Entwickler erstellt und veröffentlicht einen Blueprint, ein Mandantenadministrator genehmigt diesen, und ein Manager stellt für jede Instanz Mitarbeiter ein und betreibt sie. Dieser Artikel beschreibt die einzelnen Phasen, die jeweils verantwortliche Rolle und die Punkte, an denen die Verantwortung von einer Rolle auf die nächste übergeht.

Da Sie eine Blaupause statt eines Autopiloten erstellen, erstreckt sich der Lebenszyklus über drei Ebenen: die Blaupause, die Sie einmalig veröffentlichen, die Instanzen, die Teams daraus bereitstellen, und die Anzahl von Instanzen, die Ihr Mandant als Ganzes verwaltet. Das Modell dahinter finden Sie unter Was ist ein Autopilot in Microsoft Foundry?

Lebenszyklusphasen auf einen Blick

Wer macht was?

Vier Rollen verantworten die vier Entscheidungen, die den Autopiloten prägen. Andere Rollen sind optional und werden nur in bestimmten Bereitstellungsmustern angezeigt.

Zwei weitere Rollen kommen hinzu, wenn diese vier allein nicht alles abdecken können:

• Ein Leitender Geschäftssponsor tritt bei, wenn ein Manager den Autopilot in einer Organisation wünscht und finanziert.
• Ein Zugriffs-Manager kommt ins Spiel, wenn die Person, die die Instanz beauftragt, dem Autopiloten nicht die erforderlichen Berechtigungen erteilen kann oder nicht diejenige sein sollte, die das Prinzip der geringsten Rechte festlegt.

Diese Entscheidungen überschneiden sich nicht, und es gibt keine wichtigen Aspekte, die zwischen ihnen liegen: auf welcher Plattform die Plattform ausgeführt wird, welche Rolle und welche Funktionen die Blaupause übernimmt, ob und wie der Autopilot in Ihrem Mandanten funktioniert und wie die einzelnen Instanzen eingesetzt werden. Jede weitere Frage läuft auf eine davon hinaus.

Die Entscheidung des Entwicklers deckt mehr ab, als es zuerst scheint. Es ist nicht nur das, was der Autopilot tun kann . Es enthält auch die Bedingungen, für die der Autopilot entwickelt und getestet wurde, die die Betriebsgrenzen bilden, auf die sich alle anderen Beteiligten verlassen, wenn sie ihn genehmigen und einsetzen. Wenn ein Autopilot außerhalb dieses Umschlags fehlschlägt, hängt der Fehler davon ab, ob der Umschlag jemals angegeben wurde.

Rechenschaftspflicht im Vergleich zur Governance

Die Governance bestimmt, wer eine Instanz stoppen kann, und das ist absichtlich so vorgesehen, dass es fast jeder kann. Verantwortlichkeit bestimmt, wer dazu verpflichtet ist, ihn zu beenden. Dafür ist immer der Verantwortliche zuständig, unabhängig davon, wer schuld ist, denn ein fehlerhafter Autopilot sollte nicht weiterlaufen, während sein Verantwortlicher darauf wartet, dass jemand anderes eingreift.

Ein Zugriffsfehler zeigt den Unterschied am deutlichsten an. Ein Zugriffs-Manager konfiguriert eine Gewährung, die der Vorgesetzte nie vorgenommen hat, und die Instanz hat sich dadurch falsch verhalten. Der Vorgesetzte ist immer noch die Pflicht, es zu stoppen. Fehler und Verpflichtung bleiben nach Entwurf getrennt.

Andere Teilnehmer

Zwei Gruppen treffen zwar keine Entscheidungen, sind aber dennoch wichtig.

Teammitglieder nutzen den Copilot dort, wo das Team bereits arbeitet: in Teams, E-Mails und Dokumentkommentaren. Sie weisen ihm Daueraufgaben zu und geben objektive Korrekturen, die seine Verankerung aktualisieren.

Geschäftliche Leads sind weitere Leads desselben Vorgangs. Sie konfigurieren nichts und beantworten nichts, aber sie können die Instanz beobachten und blockieren. Sie können sie nicht löschen oder übertragen. Dieses Design ist beabsichtigt: Jeder, der nah genug an der Arbeit ist, um zu sehen, dass der Autopilot fehlschlagen sollte, sollte es stoppen können. Die Rolle des Managers ist die einzige, die den Autopiloten sowohl steuert als auch täglich nutzt, weshalb die Pflicht, ihn zu stoppen, bei ihr liegt.

Jeder im Mandanten, der nicht zur konfigurierten Zielgruppe gehört, gilt als Nicht-Teammitglied. Nicht-Teamkollegen werden standardmäßig blockiert, bevor der Autopilot jemals ein Modell aufruft.

So ändern Bereitstellungsmuster die Rollen

Das von Ihnen ausgewählte Autopilot-Muster bestimmt, welche Rollen angezeigt werden.

• Autopilot für Gruppen — bezieht jede Rolle ein. Bei diesem Muster ist die Trennung bei der Zugriffsverwaltung besonders wichtig, da die Person, die Zugriff auf ein Azure-DevOps-Projekt gewähren kann, selten der Teamleiter ist, der mit der Instanz arbeitet.
• Unternehmensweiter Autopilot - hat eine Instanz und einen Manager, der für die gesamte Organisation antwortt, so dass "Teamkollege" nicht mehr eine nützliche Unterscheidung ist.
• Persönlicher Autopilot – umfasst nur den Entwickler, der in der Regel der Vorgesetzte und der einzige Benutzer ist.

Wie die Ebenen zusammenpassen

Der Lebenszyklus wird auf drei Ebenen gleichzeitig ausgeführt.

• Blueprint – wird einmal ausgeführt, von der Bereitstellung bis zur Genehmigung. Nach der Genehmigung wird die Arbeit des Entwicklers als ständige Aktivität fortgesetzt, die die Lebensdauer jeder Instanz umfasst und nur endet, wenn der Blueprint gelöscht wird. Die Optimierung leitet neue Versionen wieder in die Buildphase ein.
• Instanz — wird einmal pro Einstellungsvorgang ausgeführt. Viele Instanzen sind gleichzeitig aktiv, sodass ein Team ein Offboarding für eine Instanz durchführen kann, während ein anderes Team anhand derselben Blaupause eine weitere Instanz bereitstellt.
• Flotte – ist keine Phase. Es ist die fortlaufende Aufgabe des Mandantenadministrators und beginnt mit der Genehmigung, denn dann entsteht die Flotte.

Die Genehmigung ist der Punkt, an dem ein genehmigter Entwurf zu vielen Instanzen wird. Das Löschen des Blueprints wirkt sich auf jede daraus erstellte Instanz aus.

Die laufenden Aktivitäten werden nach den Instanzphasen beschrieben, da sie erst ab diesem Zeitpunkt einen Zeitraum abdecken.

Ein einzelnes Beispiel durchläuft jede Phase: ein Workstream-Manager, der von einem Plattformteam erstellt und von vielen Teams eingestellt wurde. Beispielabsätze sind " Beispiel " und sind optional.

Die Blueprint-Ebene

Die Blueprint-Phasen werden nur einmal ausgeführt. Jede instanz, die aus dem Blueprint erstellt wurde, erbt ihre Ergebnisse.

Bereitstellungsinfrastruktur – Azure Administrator und Entwickler

Der Azure-Administrator richtet die Umgebung ein und bietet Entwicklern die mindestberechtigungen, die sie zum Erstellen, Testen und Bereitstellen benötigen. Dieses Setup gilt pro Umgebung, nicht pro Autopilot. Das passiert nur einmal, und jede dort erstellte Vorlage übernimmt dies.

Der Azure-Administrator stellt außerdem fest, was dieser spezifische Autopilot ausführen muss, z. B. Speicher für nachverfolgte Elemente und Arbeitsspeicher, und gewährt dem autopilot integrierten Identitätszugriff auf diese Ressourcen. Diese Infrastruktur gehört zum Blueprint, nicht zu den Daten eines Teams. Die Bereitstellung von Ressourcen und das Zuweisen von Berechtigungen sind die beiden Aktionen, die Entwickler nicht selbst ausführen können. Der Azure-Administrator ist die einzige Rolle, die abgeschlossen wird, bevor der Autopilot einen Benutzer erreicht: Seine Arbeit erfolgt, wenn die Entwicklung beginnen kann.

Beispiel: Bei Contoso richtet der Azure Administrator ein Foundry-Konto und projekt ein und stellt die Modelle bereit. Sie erstellen eine Azure Container Registry, einen Log Analytics-Arbeitsbereich und Application Insights, mit Projektverbindungen für die Container Registry und Application Insights. Der vom Projekt verwalteten Identität werden AcrPull und Log Analytics Reader zugewiesen. Sie erstellen außerdem ein Speicherkonto mit zwei Tabellen, eine für die Liste zugelassener Direktnachrichten und eine für nachverfolgte Arbeitselemente. Nachdem der Agent erstellt wurde, wird seiner Identität die Rolle „Mitwirkender an Speichertabellendaten“ zugewiesen. Jeder Entwickler erhält „Foundry User“ für das Projekt, „AcrPush“ für die Registrierung sowie „Überwachungsleser“.

Erstellen und Veröffentlichen – Entwickler

Der Entwickler definiert die Rolle und Die Funktionen des Blueprints: was er tut, wie er sich verhält – wenn er antwortet, wenn er im Hintergrund bleibt, wenn er nach Genehmigung fragt – und was er niemals tun darf. Die Plattform bietet grundlegende Funktionen wie Arbeitsspeicher, Routinen und Self-Improvement, sodass der Entwickler sie ermöglicht und konfiguriert, anstatt sie zu erstellen. Mit einer Entwicklungsinstanz kann der Entwickler iterieren, ohne für jede Änderung die Genehmigung des Mandanten erneut einholen zu müssen.

Bei der Veröffentlichung werden auch die deklarierten Berechtigungsumfänge und zwei Obergrenzen festgehalten: wer den Autopiloten beauftragen darf und welchen weitestgehenden Zugriff eine Führungskraft später gewähren kann. Zusammen mit den Bedingungen, unter denen der Autopilot entwickelt und getestet wurde, bilden diese Werte die Betriebsgrenzen, auf die sich alle nachgelagerten Funktionen verlassen.

Nichts in dieser Phase gewährt Zugriff auf alles. Diese Werte sind nur Deklarationen. Durch die Veröffentlichung wird die Blaupause der Governance vorgelegt. Sie wird dadurch jedoch nicht in die Praxis umgesetzt.

Beispiel: Bei Contoso erhält der Workstream-Manager Azure-DevOps-Tools mit Identitätsdurchgriff, die integrierten Microsoft-365-Tools und einen benutzerdefinierten Tracker für Arbeitselemente. Die Antwortlogik entscheidet, wann sie in einem Kanal spricht und wann sie stumm bleibt. Der Autopilot lehnt Gruppenchats ab, die nicht autorisierte Teilnehmer enthalten, und gibt bei mandantenübergreifenden Nachrichten eine fest definierte No-Op-Antwort zurück. Vor der Veröffentlichung deklariert der Entwickler die Bereiche, die eine Zustimmung benötigen, und legt beide Obergrenzen fest.

Genehmigen, Konfigurieren und Zustimmen – Mandantenadministrator

Diese Stufe ist ein Gate mit drei Aktionen. Der Mandantenadministrator überprüft die veröffentlichte Blaupause, gibt seine Einwilligung zu den darin deklarierten Bereichen, genehmigt sie und legt fest, wer sie nutzen darf. Die Einwilligung und die Auswahl des Mandanten sind getrennte Entscheidungen mit unterschiedlichen Konsequenzen: ein Administrator kann eine Blaupause genehmigen, dabei aber nur einem Teil der darin enthaltenen Anforderungen zustimmen.

In dieser Phase wird die Entscheidung auf Flottenebene getroffen: ob der Autopilot in Ihrem Mandanten tätig sein kann und unter welcher Richtlinie. Die Zustimmung steuert das Token, das bestimmt, welche Arten von Aufrufen der Autopilot jemals tätigen darf. Es gewährt niemandem Zugriff auf die Daten eines Teams.

Jede neue Blaupause und jeder erweiterte Bereich betreten dieses Gate neu. Berücksichtigen Sie daher die Zeit für die Überprüfung durch den Administrator in Ihren Rolloutplänen.

Beispiel: Bei Contoso öffnet der Administrator die ausstehende Anfrage für den Workstream-Manager im Microsoft 365 Admin Center, erteilt seine Zustimmung für den festgelegten Berechtigungsbereich, veröffentlicht sie und legt die Teamleiter der Organisation als berechtigte Einstellungsverantwortliche fest.

Genehmigung ermöglicht Einstellung

Die Genehmigung ist die Beendigungsbedingung für die gesamte Blaupausenebene: mindestens ein Manager kann jetzt eine Instanz einstellen. Es ist der einzige Punkt, an dem die Blueprint-Ebene und die Instanzebene aufeinandertreffen. Alles bis zu diesem Punkt deklariert die Fähigkeit und stimmt ihr zu. Noch wurde nichts gewährt. Ein Autopilot kann alle benötigten Berechtigungsumfänge besitzen und trotzdem auf keinerlei Daten zugreifen.

Die Instanzebene

Die Instanzphasen werden einmal pro Einstellung ausgeführt. Viele Instanzen werden gleichzeitig ausgeführt, jeweils in einer eigenen Phase.

Einstellung — Manager

Einstellung ist eine einzelne Aktion anstelle einer Phase. Es werden zwei Objekte erstellt:

• Eine Agent-Identität, ein Dienstprinzipal, der sich authentifiziert und über Berechtigungen verfügt.
• Ein Agentbenutzerkonto, das ein Postfach, die Teams-Anwesenheit, einen Ort im Organigramm und einen Vorgesetzten enthält.

Die Person, die den Autopiloten einstellt, wird sein Manager.

Beispiel: Bei Contoso beauftragen drei Teamleiter drei Workstream-Manager aus demselben Blueprint. Aus einem Entwurf ist nun eine ganze Flotte geworden, und alles, was von diesem Zeitpunkt an geschieht, findet dreimal unabhängig voneinander statt.

An Bord — Manager

Onboarding ist der Ort, an dem die Beschäftigung wirklich beginnt. Der Manager konfiguriert fünf Einstellungen.

Die Zugriffserteilungen – Sicherheitsgruppenmitgliedschaft, ein Azure DevOps Projekt, eine SharePoint Website – sind die erste Gewährung von Geschäftsressourcen überall im Lebenszyklus. Sie verwandeln einen leistungsfähigen Entwurf in einen einsatzbereiten Teamkollegen.

Jede Zielgruppe beginnt nur mit dem Manager und erstreckt sich höchstens bis zur Entwicklerebene, und nicht darüber hinaus. Jede Person im Mandanten, die nicht zur konfigurierten Zielgruppe gehört, wird standardmäßig blockiert, und der Autopilot ruft niemals ein Modell in deren Namen auf.

Einwilligung und Zugriff sind zwei unterschiedliche Hürden. Bereiche und Einwilligung steuern das Token, das bestimmt, welche Arten von Aufrufen zulässig sind. Gruppenmitgliedschaften und Rollen steuern das Konto, das bestimmt, welche Daten diese Anrufe erreichen. Microsoft Entra ID erzwingt das erste Gate. Jede Ressource prüft die zweite Schranke anhand ihrer eigenen Mitgliederlisten und prüft niemals eine Einwilligung. Für eine Person schließt die IT beide Tore lange vor ihrem ersten Tag. Bei einem Autopiloten sind beide Gates bei der Einstellung neu, sodass die Einarbeitung Aufgaben umfasst, die eigentlich schon erledigt sein sollten.

Die Autorisierung beginnt hier, endet aber nie. Teams ändern sich, Ressourcen ändern sich und Fördermittel werden entzogen. Der Autopilot benötigt schließlich eine SharePoint Website, die niemand bei der Einstellung erwartet hat.

Wenn die Person, die die Einstellung durchführt, diese Erteilungen nicht vornehmen kann, wird die Phase geteilt. Manager sind Wissensarbeiter, die häufig nicht die Rechte zum Hinzufügen eines Kontos zu einer Sicherheitsgruppe oder einer Azure DevOps Organisation besitzen, und die geringste Berechtigung ist ein Sicherheitsurteil, das die meisten Teamleiter nie treffen mussten. Stattdessen übernimmt ein Zugriffs-Manager diese Phase: sie beauftragen, integrieren und autorisieren die Instanz und übertragen dann die Managerrolle an den Lead, der damit arbeitet. Die Beschäftigungsentscheidung selbst bewegt sich nicht.

Beispiel: Bei Contoso legt ein Lead seinen Arbeitsstream als Teamkollegen fest und die Leads der Bereiche Technik und Produktentwicklung als Geschäftsleads. Sie fügen das Agent-Konto zur Sicherheitsgruppe und zur Verteilerliste des Teams hinzu, wodurch Zugriff auf das Azure-DevOps-Projekt und die SharePoint-Website gewährt wird, und sie gewähren dem Konto Schreibzugriff auf die GitHub-Organisation. In einem anderen Team kann der Lead das Azure DevOps Projekt nicht gewähren, sodass ein Zugriffsmanager die Instanz integriert und die Managerrolle übergibt.

Arbeiten – Manager, Teamkollegen und Geschäftsleads

Vier Aktivitäten werden gleichzeitig ausgeführt, solange die Instanz lebt, und jede Aktivität umfasst eine andere Gruppe von Rollen.

Verwenden – Teamkollegen und Manager Der Autopilot übernimmt seine Rolle auf seinen konfigurierten Oberflächen, einschließlich Teams-Direktnachrichten, Gruppenchats und Kanälen, E-Mail- und Dokumentkommentaren. Der Kontext erstreckt sich über jede Interaktion, unabhängig von der Oberfläche oder dem Benutzer. Teammitglieder weisen Routinen zu, also dauerhafte Anweisungen, die in einer einzigen Nachricht erteilt werden.

Beobachten – Manager und Geschäftsleads Sie überprüfen, was die Instanz getan hat, für wen, zu welchen Kosten und ob etwas untersucht werden muss. Die tägliche Rechenschaftspflicht geschieht hier.

Verwalten – Manager und Geschäftsleiter. Diese Steuerelemente sind alle umkehrbar: Engerer Zugriff, Widerrufen des Zugriffs oder Blockieren der Instanz. Die Steuerung folgt der Beobachtung, weil Sie als Reaktion auf etwas, was Sie gesehen haben, blockieren. Das Blockieren ist absichtlich asymmetrisch. Jeder, der der Arbeit nahe genug ist, um ein Problem zu sehen, kann die Instanz beenden, aber nur ein Mandantenadministrator kann es erneut starten.

Anleiten und anpassen – Manager. Die Verbesserung erfolgt durch zwei ungleiche Kanäle. Objektive Korrekturen, wie beispielsweise ein falsches Datum oder ein falscher Besitzer, können von jedem vorgenommen werden, der mit der Instanz arbeitet, und sie aktualisieren deren Basis. Coaching und Anpassung – Stil, Speicherbearbeitungen und Gestaltungsroutinen – liegen ausschließlich beim Manager, wodurch Konflikte automatisch entschieden werden: Was der Manager festlegt, gilt. Coaching ändert den Autopilot eines Teams. Wenn der Entwickler den Blueprint optimiert, ändert er, was jede Instanz ist.

Beispiel: Bei Contoso fassen die Teammitglieder ihre laufenden Aufgaben jeweils in einer einzigen Nachricht zusammen: eine interne Zusammenfassung am Freitag, einen externen Wochenentwurf, der so lange unversendet bleibt, bis ein Lead ihn genehmigt hat, und eine Tageszusammenfassung am Ende des Tages, in der alle Verantwortlichen mit offenen Punkten aufgeführt werden. Der Vorgesetzte überprüft die aktuelle Aktivität der Instanz. Wenn die Instanz in ihren Zusammenfassungen immer wieder den Kernpunkt ausblendet, weist der Lead einmal darauf hin, und schon setzt sich der neue Stil durch.

Offboarding der Instanz – Manager

Das Offboarding ist die einzige unwiderrufliche Instanzaktion. Das Agent-Benutzerkonto wird entfernt, seine Mitgliedschaften werden widerrufen, und der Zugriff endet sofort. Nur ein Team ist betroffen, und es wird keine andere Instanz berührt. Nichts kann wiederhergestellt werden.

Die Entscheidung gehört zum Vorgesetzten, und es ist das ein Urteil, das niemand sonst treffen kann: Ob die Instanz immer noch genügend Wert liefert, um die Ausführung zu rechtfertigen. Administratoren können auf flottenweite Signale reagieren, aber sie können nicht sehen, ob eine einzelne Instanz weiterhin ihre Kosten verdient. Das Offboarding ist keine verstärkte Form der Kontrollmaßnahmen in der Betriebsphase. Jede dort vorgenommene Änderung kann rückgängig gemacht werden. Da dies beim Offboarding nicht möglich, handelt es sich um eine separate Phase.

Beispiel: Bei Contoso wird ein Arbeitsstream abgeschlossen, und der Lead führt ein Offboarding ihrer Instanz durch. Ihre Mitgliedschaften werden widerrufen. Die anderen beiden Workstream-Manager sind nicht betroffen.

Dauerhafte Blaupause und Flottenaktivitäten

Zwei Aktivitäten finden während der gesamten Betriebsdauer jeder Instanz statt: die Arbeit des Entwicklers mit dem Blueprint und die Verwaltung der Flotte durch den Administrator des Mandanten.

Betreiben des Blueprints – Entwickler

Der Entwickler steuert, beobachtet, bewertet und optimiert den Blueprint. Sie beobachten Produktivbereitstellungen, ohne standardmäßig Inhalte privater Gespräche einzusehen. Sie filtern Telemetriedaten nach Version und nach Instanz, um Rollouts zu überwachen, und sie führen Bewertungen anhand des Betriebsbereichs durch, für den der Autopilot entwickelt und getestet wurde. Korrekturen werden in Form neuer Versionen ausgeliefert, die an alle Instanzen gesendet werden.

Eine neue Version, die ihren Geltungsbereich erweitert, umgeht Governance nicht. Für hinzugefügte Berechtigungen muss das Einwilligungsgate erneut aufgerufen werden. Das Gate bezieht sich auf die Obergrenze und nicht auf die Änderung selbst. Deshalb gilt die Entscheidung des Mandantenadministrators dauerhaft und nicht nur einmalig.

Der Entwickler verfügt auch über Governance auf Blueprint-Ebene. Sie können den von ihnen ausgelieferten Blueprint blockieren, und wie alle anderen können sie die Blockierung nicht wieder aufheben. Verwechseln Sie diese Aktivität nicht mit dem Coaching eines Vorgesetzten. Der Entwickler ändert, was jede Instanz ist. Ein Manager ändert das Verhalten einer Instanz.

Flotte verwalten — Mandantenadministrator

Der Mandantenadministrator überwacht, verwaltet und sichert die Flotte, sobald eine Blaupause in den Genehmigungsprozess eintritt. In einer einzigen Registrierung sind alle Einstellungen mit dem jeweiligen Team, der Blaupause und der Version sowie alle dieser Identität zugeordneten Aktionen aufgeführt. Der Administrator hat die umfassendste Kontrolle im System: Durch das Sperren der Blaupause werden alle Instanzen sofort angehalten, da jedes Instanz-Token auf die Anmeldedaten der Blaupause zurückverfolgt werden kann.

Dieses Steuerelement spiegelt wider, wie Blueprints fehlschlagen. Ein Konstruktionsfehler ist immer systembedingt. Wenn ein Workstream-Manager E-Mails an Empfänger außerhalb des Mandanten sendet, dann ist das kein Fehlverhalten einer einzelnen Teams-Instanz. Jede Instanz weist denselben Fehler auf und wartet auf die gleichen Bedingungen. Der Block gilt für die Blaupause, nicht für die Instanz, auf die jemand zufällig aufmerksam geworden ist.

Die Blaupause einstellen und löschen – Mandantenadministrator und Entwickler

Ein Bauplan hat zwei Ausgänge.

• Einstellen — ein Mandantenadministrator stoppt Neueinstellungen, und die Blaupause wird beendet, wenn keine aktiven Instanzen mehr vorhanden sind. Durch die Einstellung wird verhindert zukünftige Einstellungen, ohne dass sich dies auf aktuelle Instanzen auswirkt.
• Löschen – jede instanz, die aus dem Blueprint erstellt wurde, wird damit entfernt. Delete ist das Äquivalent auf Blueprint-Ebene dazu, dass ein Manager eine einzelne Instanz aus dem System entfernt.

Dieser Unterschied ist die Zeile, die den gesamten Lebenszyklus organisiert. Alle Steuerelemente in den Betriebsphasen sowie die laufenden Aktivitäten können rückgängig gemacht werden. Das Löschen einer Blaupause hingegen nicht.

Verwandte Inhalte

• Was ist ein Autopilot in Microsoft Foundry? erklärt das Identitätsmodell und warum autopilots Blueprints verwenden.
• Schnellstart: Ihren ersten Autopiloten erstellen behandelt die Themen Bereitstellung, Erstellung, Veröffentlichung, Genehmigung und die Einstellung Ihrer ersten Instanz.
• Microsoft Agent 365-Integration in Foundry umfasst registrierungssynchronisierung, Datensammlung und Datenaufbewahrung.