Ciclo de vida de Autopilot en Microsoft Foundry

Un autopilot se mueve a través de un ciclo de vida definido. Un administrador de Azure aprovisiona la plataforma, un desarrollador compila y publica un plano técnico, un administrador de inquilinos lo aprueba y un administrador contrata y ejecuta cada instancia. En este artículo se describe cada fase, el rol que lo posee y los puntos en los que la responsabilidad pasa de un rol a otro.

Dado que se crea un blueprint en lugar de un autopilot, el ciclo de vida se desarrolla en tres niveles: el blueprint que se publica una vez, las instancias que los equipos contratan a partir de él y el conjunto de instancias que su inquilino administra en su totalidad. Para ver el modelo subyacente, consulte ¿Qué es un autopilot en Microsoft Foundry?

Fases del ciclo de vida de un vistazo

¿Quién hace lo que hace?

Cuatro roles poseen las cuatro decisiones que dan forma a un piloto automático. Otros roles son opcionales y solo aparecen en determinados patrones de implementación.

Aparecen dos funciones más cuando esas cuatro no pueden cubrir el terreno por sí solas:

• Un patrocinador ejecutivo del negocio participa cuando un directivo quiere implantar el piloto automático en toda la organización y lo financia.
• Un gestor de accesos interviene cuando la persona que contrata la instancia no puede conceder lo que necesita el piloto automático, o no debería ser quien juzgue el principio del privilegio mínimo.

Estas decisiones no se solapan, y no hay nada importante que quede entre ellas: en qué se ejecuta la plataforma, la función y las capacidades del plano, si el piloto automático funciona en tu tenant y de qué manera, y el uso de cada instancia. Una de cada dos preguntas se reduce a una de ellas.

La decisión del desarrollador abarca más de lo que parece a primera vista. No es solo lo que puede hacer autopilot. También incluye las condiciones para las que se diseñó y probó el piloto automático, que constituyen la envolvente operativa en la que confían todos los demás responsables al aprobar su uso e incorporarlo. Cuando un piloto automático falla fuera de ese rango operativo, la responsabilidad depende de si ese rango se había especificado alguna vez.

Responsabilidad en comparación con la gobernanza

La gobernanza determina quién puede detener una instancia y por diseño casi todos los usuarios pueden. La responsabilidad determina quién está obligado a detenerlo. Ese es siempre el administrador, independientemente de quién esté en culpa, porque un autopilot roto no debe seguir ejecutándose mientras su jefe espera a que otra persona actúe.

Un error de acceso muestra la diferencia más claramente. Un administrador de acceso configura una concesión que el administrador nunca realizó y la instancia se comporta mal debido a ella. El gerente sigue siendo el obligado a detenerlo. El error y la obligación permanecen separados por diseño.

Otros participantes

Dos grupos no tienen ninguna decisión, pero aún importan.

Los miembros del equipo usan el piloto automático donde el equipo ya trabaja: en Teams, en el correo electrónico y en los comentarios de documentos. Le asignan tareas fijas y le proporcionan correcciones objetivas que actualizan su base.

Los responsables de negocio son otros responsables del mismo trabajo. No configuran nada ni responden de nada, pero pueden observar la instancia y bloquearla. No pueden eliminarlo ni transferirlo. Ese diseño es intencionado: cualquier persona lo suficientemente cerca del trabajo para ver que el autopilot se comporta mal debería ser capaz de detenerlo. La persona responsable es la única función que tanto gestiona el piloto automático como lo utiliza a diario, por lo que la obligación de detenerlo recae en esa persona.

Cualquier persona del inquilino que no forme parte del público configurado es un no miembro del equipo. Las personas ajenas al equipo están bloqueadas por defecto, antes de que el piloto automático siquiera llegue a llamar a un modelo.

Cómo cambian los patrones de implementación los roles

El patrón de piloto automático que elijas determina qué roles aparecen.

• Piloto automático de grupo — abarca todos los roles. Este patrón es donde la división del administrador de acceso es importante, ya que la persona que puede conceder un proyecto de Azure DevOps rara vez es el responsable del equipo que trabaja con la instancia.
• Piloto automático para toda la empresa — tiene una instancia y un administrador responsables de toda la organización, por lo que «miembro del equipo» deja de ser una distinción útil.
• Autopilot personal : solo implica al desarrollador, que suele ser el administrador y el único usuario.

Cómo encajan las capas

El ciclo de vida transcurre a la vez en tres capas.

• Plano técnico : se ejecuta una vez, desde el aprovisionamiento hasta la aprobación. Después de la aprobación, el trabajo del desarrollador continúa como una actividad permanente que abarca la vida laboral de cada instancia y finaliza solo cuando se elimina el plano técnico. La optimización devuelve nuevas versiones a la fase de compilación.
• Instancia: se ejecuta una vez por contratación. Hay muchas instancias activas al mismo tiempo, por lo que un equipo puede dar de baja una instancia mientras otro equipo contrata una del mismo modelo.
• Flota — no es una etapa. Es la actividad permanente del administrador de inquilinos y comienza en la aprobación, ya que es cuando comienza a existir la flota.

La aprobación es el punto en el que un diseño aprobado se convierte en muchas instancias. La eliminación de la plantilla afecta en cascada a todas las instancias creadas a partir de ella.

Las actividades permanentes se describen tras las etapas de la instancia, ya que ese es el momento en el que tienen algo que abarcar.

Un único ejemplo se utiliza en todas las etapas: un gestor de flujos de trabajo, creado por un equipo de plataforma y adoptado por muchos equipos. Los párrafos de ejemplo se etiquetan como Ejemplo y son opcionales.

La capa del modelo

Las etapas del modelo se ejecutan una sola vez. Cada instancia creada a partir del plano técnico hereda sus resultados.

Aprovisionamiento de la infraestructura: administrador y desarrollador de Azure

El administrador de Azure configura el entorno y proporciona a los desarrolladores los permisos mínimos que necesitan para compilar, probar e implementar en él. Esta configuración se aplica por entorno, no por autopilot. Ocurre una vez, y cada modelo creado a partir de ahí lo hereda.

El administrador de Azure también aprovisiona lo que este autopilot específico necesita para ejecutarse, como almacenamiento para los elementos rastreados y memoria, y concede a la identidad predefinida del autopilot acceso a esos recursos. Esta infraestructura pertenece al plano técnico, no a los datos de ningún equipo. El aprovisionamiento de recursos y la asignación de permisos son las dos cosas que los desarrolladores no pueden hacer por sí mismos. El administrador de Azure es el único rol que finaliza antes de que autopilot llegue a un usuario: su trabajo se realiza cuando el desarrollo puede comenzar.

Ejemplo: en Contoso, el administrador de Azure configura una cuenta y un proyecto de Foundry e implementa los modelos. Crean un Registro de contenedores de Azure, un espacio de trabajo de Log Analytics y Application Insights, con conexiones de proyecto para el registro y Application Insights. A la identidad administrada por el proyecto se le conceden los permisos AcrPull y Log Analytics Reader. También crean una cuenta de almacenamiento con dos tablas: una para la lista de permitidos de mensajes directos y otra para los elementos de trabajo rastreados. Una vez creado el agente, a su identidad se le concede el permiso Storage Table Data Contributor. Cada desarrollador obtiene el permiso Foundry User limitado al proyecto, el permiso AcrPush limitado al registro y el permiso Monitoring Reader.

Compilación y publicación: desarrollador

El desarrollador define el rol y las funcionalidades del plano técnico: lo que hace, cómo se comporta , cuando responde, cuando permanece en silencio, cuando solicita aprobación, y lo que nunca debe hacer. La plataforma proporciona funcionalidades fundamentales, como la memoria, las rutinas y la auto-mejora, por lo que el desarrollador las habilita y configura en lugar de compilarlas. Una instancia de desarrollo permite al desarrollador iterar sin volver a introducir la aprobación del tenant para cada cambio.

La publicación también registra los ámbitos de permisos declarados y dos límites máximos: quién puede contratar el piloto automático y el acceso más amplio que cualquier gestor pueda conceder posteriormente. Junto con las condiciones para las que se diseñó y probó el piloto automático, estos valores forman la envolvente operativa en la que confía cada función posterior.

Nada en esta fase concede acceso a nada. Estos valores son solo declaraciones. La publicación coloca el plano técnico delante de la gobernanza; no pone el plano técnico en funcionamiento.

Ejemplo: En Contoso, el responsable del flujo de trabajo obtiene las herramientas de Azure DevOps con transferencia de identidad, las herramientas integradas de Microsoft 365 y un rastreador de elementos de trabajo personalizado. Su lógica de respuesta decide cuándo habla en un canal y cuándo permanece en silencio. El piloto automático rechaza los chats de grupo que incluyan participantes no aprobados y devuelve una respuesta fija sin efecto a los mensajes entre distintos inquilinos. Antes de publicar, el desarrollador declara los ámbitos que necesitan consentimiento y establece ambos límites.

Aprobar, configurar y dar el consentimiento — administrador del inquilino

Esta etapa es una puerta de control con tres acciones. El administrador de inquilinos revisa el plano técnico publicado, concede consentimiento a sus ámbitos declarados, lo aprueba y selecciona quién puede contratarlo. El consentimiento y la selección del contratante son decisiones separadas con consecuencias distintas: un administrador puede aprobar una plantilla al tiempo que consiente solo una parte de lo solicitado.

En esta etapa se toma la decisión en el nivel de flota: si el piloto automático puede operar en tu inquilino y bajo qué directiva. El consentimiento determina el token, que define qué tipos de solicitudes puede realizar el autopilot. No concede datos de ningún equipo a nadie.

Cada nuevo modelo y cada ámbito ampliado vuelve a pasar por esta puerta de control, así que incluye el tiempo de revisión por parte del administrador en tus planes de implementación.

Ejemplo: En Contoso, el administrador abre la solicitud pendiente del administrador del flujo de trabajo en el centro de administración de Microsoft 365, aprueba el conjunto de ámbitos, la publica y designa a los responsables de equipo de la organización como contratadores autorizados.

Aprobación habilita la contratación

La aprobación es la condición de salida para toda la capa de modelos: al menos un gestor ya puede contratar una instancia. Es el único punto en el que se reúne la capa de plano técnico y la capa de instancia. Todo lo que ocurre hasta este punto declara y da su consentimiento a la capacidad. Aún no se ha concedido nada. Un piloto automático puede tener configurados todos los alcances que necesita y aun así no obtener ningún dato en absoluto.

La capa de instancia

Las etapas de la instancia se ejecutan una vez por cada contratación. Muchas instancias se ejecutan al mismo tiempo, cada una en su propia fase.

Contratación: administrador

La contratación es una sola acción en lugar de una fase. Crea dos objetos:

• Una identidad de agente, un principal de servicio que se autentica y tiene permisos.
• Una cuenta de usuario del agente, que contiene un buzón, presencia de Teams, un lugar en el organigrama y un administrador.

La persona que contrata al autopilot se convierte en su gerente.

Ejemplo: En Contoso, tres responsables del equipo contratan a tres administradores de flujo de trabajo del mismo plano técnico. Un diseño se convierte ahora en una flota, y todo, a partir de este punto, sucede tres veces, de forma independiente.

Incorporación — responsable

La incorporación es donde comienza realmente el empleo. El administrador configura cinco opciones.

Las concesiones de acceso ( pertenencia a grupos de seguridad, un proyecto de Azure DevOps, un sitio de SharePoint) son la primera concesión de recursos empresariales en cualquier lugar del ciclo de vida. Convierten un modelo operativo capaz en un compañero de equipo funcional.

Cada público objetivo comienza siendo únicamente el responsable y se extiende hasta el límite del desarrollador, y no más allá. Cualquier persona del inquilino que no forme parte del público objetivo configurado queda bloqueada por defecto, y el piloto automático nunca invoca un modelo en su nombre.

El consentimiento y el acceso son diferentes puertas. Los ámbitos y el consentimiento rigen el token, que determina qué tipos de llamadas se permiten. La pertenencia a grupos y los roles determinan la cuenta, que a su vez determina a qué datos acceden esas solicitudes. Microsoft Entra ID se encarga de la primera puerta de control. Cada recurso aplica la segunda puerta en sus propias listas de pertenencia y nunca comprueba el consentimiento. En el caso de una persona, el departamento de TI cierra ambas puertas mucho antes de su primer día. Para un piloto automático, ambas puertas son nuevas en el momento de la contratación, por lo que la incorporación incluye tareas que parecen que ya deberían estar realizadas.

La autorización comienza aquí, pero nunca finaliza. Los equipos cambian, los recursos cambian y se revocan las subvenciones. Con el tiempo, el piloto automático necesita un sitio de SharePoint que nadie había previsto cuando lo contrataron.

Cuando la persona encargada de la contratación no puede conceder estas autorizaciones, la etapa se divide. Los gerentes son trabajadores del conocimiento que a menudo no tienen permisos para añadir una cuenta a un grupo de seguridad o a una organización de Azure DevOps, y el principio de mínimo privilegio es un criterio de seguridad que la mayoría de los líderes de equipo nunca han tenido que aplicar. Un administrador de acceso toma esta fase en su lugar: contratan, incorporan y autorizan la instancia y, a continuación, transfieren el rol de administrador al responsable que trabaja con él. La propia decisión de contratación no cambia.

Ejemplo: En Contoso, un responsable configura su línea de trabajo como la de sus compañeros de equipo y a los responsables de ingeniería y de producto como responsables de negocio. Agregan la cuenta del agente al grupo de seguridad y a la lista de distribución del equipo, lo que le otorga acceso al proyecto de Azure DevOps y al sitio de SharePoint, y le conceden acceso de escritura en la organización de GitHub. En otro equipo, el responsable no puede conceder acceso al proyecto de Azure DevOps, por lo que un administrador de acceso da de alta la instancia y transfiere el rol de administrador.

Operar: el responsable, los compañeros de equipo y los responsables de negocio.

Cuatro actividades se ejecutan al mismo tiempo durante el tiempo que reside la instancia y cada actividad implica un conjunto diferente de roles.

Utilizar: los compañeros de equipo y el responsable. Autopilot desempeña su función en sus entornos configurados, incluidos los mensajes directos de Teams, los chats grupales y los canales, el correo electrónico y los comentarios en documentos. Su contexto abarca todas las interacciones, independientemente de la superficie o del usuario. Los compañeros de equipo asignan rutinas, que son instrucciones permanentes dadas en un solo mensaje.

Observar: el responsable y los responsables de negocio. Revisan lo que hizo la instancia, para quién, a qué costo, y si algo necesita investigar. La rendición de cuentas del día a día tiene lugar aquí.

Gobernar: el responsable y los responsables de negocio. Estos controles son reversibles: apriete el acceso, revoque el acceso o bloquee la instancia. Gobernar se deriva de observar, porque bloqueas como respuesta a algo que viste. El bloqueo es intencionadamente asimétrico. Cualquier persona lo suficientemente cerca del trabajo para ver un problema puede detener la instancia, pero solo un administrador de inquilinos puede iniciarlo de nuevo.

Asesorar y personalizar: el responsable. La mejora llega a través de dos canales desiguales. Las correcciones objetivas, como una fecha que se ha pasado por alto o un responsable erróneo, pueden provenir de cualquier persona que trabaje con la instancia, y actualizan su base. La supervisión y la personalización —estilo, ediciones de memoria y rutinas de ajuste— corresponden exclusivamente al administrador, lo que resuelve los conflictos automáticamente: prevalece lo que establezca el administrador. El coaching cambia el piloto automático de un equipo. Cuando el desarrollador optimiza la plantilla, cambia lo que cada instancia es.

Ejemplo: En Contoso, los miembros del equipo configuran su trabajo recurrente en un único mensaje: un resumen interno de los viernes, un borrador semanal externo que permanece sin enviarse hasta que lo aprueba un responsable y un resumen de fin de día que menciona a todos los responsables de tareas pendientes. El administrador revisa la actividad reciente de la instancia. Cuando la instancia sigue ocultando el punto principal en sus resúmenes, el responsable le ofrece orientación una vez y el nuevo estilo se mantiene.

Retirar la instancia: el responsable

La retirada es la única acción irreversible de la instancia. Se elimina la cuenta de usuario del agente, se revocan sus afiliaciones y su acceso finaliza inmediatamente. Solo se ve afectado un equipo y no se toca ninguna otra instancia. No se puede restaurar nada.

La decisión pertenece al administrador y es la única sentencia que nadie puede tomar: si la instancia sigue entregando suficiente valor para justificar su ejecución. Los administradores pueden actuar en función de las señales de toda la flota, pero no pueden ver si una sola instancia sigue justificando su coste. La retirada no es una versión más estricta de los controles de la etapa de operación. Todos los controles de esa etapa se pueden deshacer, pero la retirada no, por lo que constituye una etapa independiente.

Ejemplo: En Contoso, finaliza una línea de trabajo y su responsable da de baja su instancia. Se revocan sus afiliaciones. Los otros dos administradores de secuencias de trabajo no se ven afectados.

Plan de trabajo permanente y actividades de la flota

Dos actividades se llevan a cabo durante toda la vida útil de cada instancia: la operación del plano por parte del desarrollador y la gestión de la flota por parte del administrador del arrendatario.

Operar el plan de trabajo — desarrollador

El desarrollador rige, observa, evalúa y optimiza el plano técnico. Observan implementaciones de producción sin recibir contenido de conversación privada de forma predeterminada. Filtran la telemetría por versión y por instancia para supervisar los despliegues, y realizan evaluaciones con respecto al rango operativo para el que se diseñó y probó el piloto automático. Las correcciones se distribuyen como nuevas versiones que llegan a todas las instancias.

Una nueva versión que amplía sus ámbitos no omite la gobernanza. Los permisos añadidos vuelven a pasar por la puerta de consentimiento. La puerta se aplica al límite máximo y no al cambio en sí, por lo que la decisión del administrador del inquilino es permanente y no puntual.

El desarrollador también ejerce la gobernanza a nivel de plano. Pueden bloquear el plano técnico que enviaron y, al igual que todos los demás, no pueden desbloquearlo. No confunda esta actividad con la labor de acompañamiento que realiza un gerente. El desarrollador cambia lo que es cada instancia. Un administrador cambia el comportamiento de una instancia.

Administración de la flota: administrador de inquilinos

El administrador de inquilinos observa, rige y protege la flota desde el momento en que un plano técnico entra en aprobación. Un registro único recoge cada incorporación con su equipo, plantilla y versión, junto con cada acción atribuida a su identidad. El administrador tiene el mayor control del sistema: bloquear el modelo detiene todas las instancias a la vez, ya que cada token de instancia está vinculado a las credenciales del modelo.

Ese control refleja cómo se producen errores en los planos técnicos. Un defecto de plano técnico siempre es sistémico. Si un responsable de un flujo de trabajo envía un correo electrónico fuera del entorno del inquilino, eso no significa que una instancia de un equipo esté funcionando mal. Todas las instancias presentan el mismo fallo y esperan las mismas condiciones. El bloqueo se aplica al modelo, no a la instancia que alguien haya detectado por casualidad.

Retirar y eliminar el blueprint: administrador de inquilinos y desarrollador

Un plano tiene dos salidas.

• Retirar : un administrador de inquilinos detiene las nuevas contrataciones y el plano técnico finaliza cuando no quedan instancias activas. La retirada evita contrataciones futuras sin afectar a las instancias actuales.
• Eliminar — cada instancia creada a partir de la plantilla se elimina junto con ella. Delete equivale, en la capa de blueprint, a que un administrador retire una sola instancia.

Esa diferencia es la línea que organiza todo el ciclo de vida. Todas las acciones de las etapas de operación y las actividades en curso se pueden deshacer. No se puede eliminar un plano.

Contenido relacionado

• ¿Qué es un autopilot en Microsoft Foundry? explica el modelo de identidad y por qué los autopilots usan planos técnicos.
• Guía de inicio rápido: Crea tu primer Autopilot abarca el aprovisionamiento, la creación, la publicación, la aprobación y la contratación de tu primera instancia.
• La integración de Microsoft Agent 365 con Foundry cubre la sincronización del registro, la recopilación de datos y la residencia de los datos.