Copilot Studio: cómo usar Managed Runtime desde la CLI

Qué es Copilot Managed Runtime dentro de Copilot Studio

Copilot Managed Runtime es un entorno administrado para aplicaciones empresariales internas. El código sigue siendo editable, el control de versiones continúa en un repositorio Git real y Microsoft aporta el runtime alojado, el inicio de sesión con Microsoft Entra, las conexiones de datos gobernadas, los mecanismos de vista previa y despliegue, y un inventario para administradores.

Puede entenderse como un edificio de oficinas con servicios incluidos para el código. El equipo sigue decidiendo qué ocurre dentro de cada espacio; el edificio pone el control de acceso, los suministros, las normas de seguridad, el registro de mantenimiento y el personal de instalaciones. No es lo mismo que una superficie de programación con IA que se limita a dibujar la distribución de las oficinas.

Microsoft presenta el SDK como la capa de desarrollo para aplicaciones internas de línea de negocio. Incluye autenticación con Entra sin código de identidad personalizado y acceso a más de 1,500 conectores desde JavaScript y TypeScript, aunque la política del tenant determina qué conectores y acciones puede utilizar cada aplicación. La descripción general del SDK en versión preliminar pública y el anuncio de lanzamiento delimitan bien el alcance.

Esta guía sigue el SDK y la CLI disponibles ahora. No trata Copilot Code ni Autopilot como nombres intercambiables de esta cadena de herramientas.

Dónde vive realmente la aplicación

La respuesta cambia a medida que la aplicación avanza por su ciclo de vida:

Esta separación importa. La vista previa puede avanzar mientras producción sigue estable, y un build fallido en vista previa no sustituye a la última versión correcta.

Comprueba los requisitos antes de escribir código

La forma más rápida de perder un día es descubrir una restricción del tenant o de la licencia cuando la aplicación ya está lista. Conviene revisar primero estos cinco puntos.

Las opciones de facturación y las políticas administrativas merecen una decisión presupuestaria propia. Consulta el desglose de precios de Copilot Managed Runtime antes de dar acceso a un grupo piloto. Hay un detalle operativo que sí corresponde a esta guía: la ejecución local no es una vía gratuita para eludir la licencia. Necesita la misma cobertura de runtime que un usuario final.

Qué se verificó para esta guía

La comprobación del paquete fue real; la ejecución en un tenant, no.

Por tanto, este artículo no afirma haber medido el tiempo hasta la primera página local ni hasta la vista previa alojada. Tampoco afirma haber observado un fallo de build, inspeccionado una identidad de Entra, ejecutado una llamada a un conector, realizado un despliegue o recibido una factura de runtime. Los pasos siguientes describen la ruta documentada por Microsoft; no presentan como prueba de laboratorio algo que no lo fue.

Lleva una pequeña aplicación de operaciones por toda la CLI

Usaremos una aplicación sintética llamada Ops Intake. Su primera tarea es modesta: mostrar registros de una fuente aprobada por el tenant en una cola de solo lectura. Empezar con una operación de lectura permite que la primera revisión de políticas sea comprensible. Las escrituras deben llegar después de demostrar la identidad, los permisos de la fuente, la política de conectores y la cobertura de runtime.

Para que la secuencia sea reproducible, se fija la versión de la CLI verificada el 27 de septiembre de 2026. Registra también la versión elegida en el repositorio para que una actualización del paquete en versión preliminar no cambie el piloto sin avisar.

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

Esto es lo que significa cada transición.

1. Inicia sesión y crea la base gobernada

ms auth login abre el inicio de sesión de Microsoft Entra. En una máquina sin interfaz gráfica, la CLI también ofrece --device-code. ms app create crea el registro de la aplicación, genera la estructura inicial del proyecto y utiliza de forma predeterminada un repositorio Git administrado por la plataforma. La primera ejecución de create o init también aprovisiona el entorno de desarrollo asociado a la identidad del maker, siempre que el enrutamiento lo permita.

No elijas el modo de repositorio a la ligera. Git administrado por la plataforma ofrece el arranque más directo. Un repositorio externo puede estar en GitHub.com o GitHub Enterprise Cloud. GitHub Enterprise Server, Azure DevOps y otros proveedores no son compatibles con esta ruta. El modo de repositorio queda fijado durante toda la vida de la aplicación; cambiarlo más adelante exige crear otra aplicación.

2. Ejecuta en local y registra el primer tiempo útil

Instala una vez las dependencias de la estructura generada y ejecuta ms app dev. El comando lee ms.config.json, inicia el proceso de desarrollo del proyecto y muestra una Local Play URL. Ábrela en el mismo perfil del navegador utilizado para el tenant.

Inicia un cronómetro justo antes de ms app dev y detenlo cuando aparezca la primera página utilizable. Anota por separado las interrupciones por permisos del navegador. Chrome y Microsoft Edge pueden impedir que un origen público acceda a localhost hasta que se conceda acceso a la red local; esa es una restricción del navegador, no un fallo del build de la aplicación.

3. Demuestra una lectura gobernada

ms connector list muestra los identificadores de los conectores, el tipo de autenticación, la compatibilidad con datos tabulares y el estado tanto de Data Loss Prevention como de Advanced Connector Policy. Toma esa salida como fuente de verdad para el entorno. Que un conector exista en el catálogo de Microsoft no significa que esté permitido automáticamente en el tenant.

Para Ops Intake, selecciona una conexión, un conjunto de datos y una lista de SharePoint que estén permitidos; después elige una operación de lectura o listado. El flujo interactivo de ms app add data-source genera modelos y servicios TypeScript tipados dentro de generated/. Invoca desde la aplicación el método de lectura generado en lugar de crear un flujo propio con un token de Graph sin procesar.

Valida tres puntos en el navegador:

1. El usuario que inició sesión corresponde a la identidad de Entra esperada.
2. El usuario solo ve los registros que el sistema de origen ya le permite consultar.
3. La aplicación falla de manera segura si ese usuario pierde el acceso al origen.

Compartir la aplicación más adelante no concede acceso a los datos subyacentes. Cada destinatario sigue necesitando los permisos y la conexión correctos en el origen. Es una característica, no una molestia del despliegue.

4. Confirma y envía código fuente real

Utiliza comandos Git habituales. La CLI del runtime no sustituye al control de versiones. El commit debe incluir el cambio funcional de la aplicación y los enlaces de conectores generados que formen parte del proyecto.

La trampa importante es sencilla: git push no compila la aplicación. Solo actualiza la fuente de verdad remota.

5. Abre la vista previa alojada e inspecciona el build

ms app play --mode preview abre el endpoint estable de vista previa. Si el último commit enviado aún no tiene un build, abrir la vista previa pone uno en cola. Registra el tiempo desde que la abres hasta que la nueva versión está lista.

Si el build falla, ejecuta ms app build-status, opcionalmente con --commit <sha>, y guarda el motivo completo junto al commit. La vista previa sigue sirviendo el build correcto anterior mientras el nuevo todavía se compila o si ha fallado. La URL de vista previa está destinada a desarrolladores con acceso de escritura al repositorio, no a revisores arbitrarios.

Puedes ejecutar ms app build si quieres iniciar un build antes de abrir la vista previa. Para la mayoría de los equipos conviene aprender primero el comportamiento predeterminado: enviar el código y después abrir la vista previa.

6. Despliega solo la versión que inspeccionaste

ms app deploy promueve un build correcto a la aplicación en producción. La versión publicada es una instantánea fija: no sigue cada push ni cada build de vista previa.

Para una publicación controlada, registra el SHA del commit, comprueba el estado del build, abre su vista previa y luego despliega ese SHA con ms app deploy --commit <sha>. La misma opción permite volver limpiamente a un build correcto anterior sin reescribir el historial de Git.

La lógica económica cambia en la capa de plataforma

El runtime no convierte el trabajo de una aplicación en algo gratuito. Lo que cambia es qué componentes debe comprar o construir el equipo por separado.

El presupuesto de software comparable no es menor. La página oficial de precios de Retool sitúa el plan Team en $10 por desarrollador y $5 por usuario interno al mes, y el plan Business en $50 por desarrollador y $15 por usuario interno al mes. Copilot Managed Runtime no mejora esas cifras de forma automática. Puede eliminar trabajo de plataforma independiente en una organización que ya utiliza Microsoft 365, pero las licencias o créditos de runtime, el trabajo con conectores y el tiempo de administración siguen generando costos reales.

Antes de concluir que el piloto es más barato, utiliza esta ecuación:

Costo del piloto = tiempo de desarrollo + configuración administrativa + cobertura del runtime + trabajo de conectores y datos.

La partida con más probabilidades de reducirse es el montaje de la plataforma. La que más puede sorprender es la cobertura del runtime para cada persona que abra la aplicación.

Siete aplicaciones internas adecuadas para este runtime

Los mejores candidatos son flujos internos en los que la identidad, los datos gobernados de Microsoft 365 y una publicación controlada pesan más que disponer de una tienda pública.

Cada caso de uso debe comenzar en modo de solo lectura. Una acción de escritura, un endpoint externo, un conector de terceros o una aplicación compartida de forma amplia cambia la revisión. La política predeterminada incluye 18 conectores propios de Microsoft, no todo el catálogo, y bloquea algunas acciones abiertas de HTTP, código arbitrario, consultas arbitrarias y plataformas arbitrarias incluso dentro de conectores aprobados.

Tres productos que vale la pena construir sobre el runtime

El producto con más potencial es un centro de mando para la incorporación en Microsoft 365. Combina la mayor demanda medida con un flujo que, por naturaleza, abarca identidad, documentos, tareas, correo y traspasos entre equipos.

1. Un centro de mando para la incorporación en Microsoft 365

Construye una única aplicación interna donde RR. HH. y TI puedan consultar el registro aprobado de una nueva contratación, las tareas pendientes, los enlaces a documentos y sus responsables. Los equipos de operaciones de RR. HH. y de servicios de TI pagarían por reducir los traspasos olvidados y simplificar la pista de auditoría.

La demanda es visible: “employee onboarding software” recibe unas 590 búsquedas mensuales en Estados Unidos, con intención comercial y un costo por clic de $156.35. La búsqueda más específica “best employee onboarding software” recibe 90 búsquedas al mes y mostró un crecimiento interanual de tendencia del 180% en los datos de sugerencias.

La versión mínima vendible atiende a un departamento, lee una lista aprobada de empleados, muestra una lista de tareas y vincula cada tarea con su responsable. Añade acciones de conectores solo después de que la ruta de lectura supere las pruebas de políticas y permisos.

La dificultad es seria. Los datos de RR. HH. son sensibles, es fácil interpretar mal los permisos del origen y los proveedores consolidados de onboarding ya cubren flujos más amplios de recursos humanos. El producto solo gana cuando el gobierno de Microsoft 365 y la operación nativa del tenant importan más que una larga lista de funciones genéricas.

2. Un panel gobernado de aprobaciones

Construye una superficie reutilizable de aprobaciones para equipos de finanzas, compras u operaciones que tengan un estado de decisión claro pero un contexto de respaldo disperso. El cliente paga por acelerar la revisión y controlar el proceso de publicación, no por otro creador de formularios.

“Approval workflow software” recibe unas 320 búsquedas mensuales en Estados Unidos, con intención comercial, un costo por clic de $114.86 y un crecimiento interanual de tendencia del 53% en los datos de sugerencias. Esa combinación revela un problema de compra activo y espacio para una implementación enfocada en Microsoft 365.

El MVP incluye un tipo de solicitud, una fuente aprobada, una pantalla de revisión de solo lectura, el historial de decisiones y una única acción permitida por las políticas. Mantén determinista el modelo de decisión. No ocultes las reglas de aprobación dentro de texto generado.

La dificultad está en la política de conectores. Un conector puede estar permitido mientras una acción concreta sigue bloqueada; además, las políticas clásicas de datos pueden combinarse con Advanced Connector Policies, de modo que prevalece el resultado más restrictivo.

3. Una evaluación para migrar aplicaciones administradas

Vende una evaluación empaquetada que tome una aplicación web interna, personalizada o generada con IA, y determine si puede trasladarse a Copilot Managed Runtime. El cliente es una organización con Microsoft 365 que ya tiene un prototipo útil y no quiere mantener otra infraestructura independiente de hosting y gobierno.

“Custom business app development” recibe unas 90 búsquedas mensuales en Estados Unidos, con intención comercial y un costo por clic de $84.03. El volumen es menor, pero la consulta está cerca de una compra de servicios.

El MVP levanta un inventario del repositorio de la aplicación, sus supuestos de runtime, los endpoints externos, el código de identidad, las fuentes de datos y las acciones necesarias. Después entrega una decisión de continuar, modificar o detener, y porta a un entorno de prueba una sección de solo lectura.

La dificultad es la concentración en una sola plataforma. El resultado solo sirve para tenants elegibles de Microsoft 365, el comportamiento de la versión preliminar pública puede cambiar y los proveedores de código fuente no compatibles o los recursos externos bloqueados pueden convertir una migración aparentemente sencilla en una reconstrucción.

Qué problemas no resuelve Copilot Managed Runtime

Es una ruta prometedora para aplicaciones internas gobernadas, no una plataforma universal de aplicaciones.

• Es una función en versión preliminar pública con documentación previa al lanzamiento. Hay que tratar como variables tanto el comportamiento de los comandos como las superficies de políticas.
• No habilita automáticamente la creación desde la CLI. Esta vía está desactivada de forma predeterminada, aunque el tenant sea elegible para el runtime.
• No convierte los más de 1,500 conectores en fuentes de datos permitidas. La política del tenant, la política de acciones de conectores, las políticas clásicas de datos y los permisos del origen siguen decidiendo el acceso.
• No transforma una aplicación interna de línea de negocio en un producto público para clientes. La vista previa está limitada a desarrolladores con acceso de escritura al repositorio, mientras que el acceso a producción se comparte de forma deliberada dentro del modelo gobernado.
• No admite todos los proveedores de repositorios. El código fuente externo se limita a GitHub.com y GitHub Enterprise Cloud, y el modo de repositorio no puede modificarse sobre la misma aplicación.
• No elimina las licencias de runtime. La ejecución local y la de los usuarios requieren Power Apps Premium o Managed Application Copilot Credits con fondos.
• No ofrece a los administradores un registro forense perfecto. La vista administrativa cubre inventario, uso, estado, conectores, fuentes de datos y dependencias, pero Microsoft aclara que no presenta una visión completa de los destinos exactos, los endpoints dinámicos, las acciones ejecutadas ni los permisos efectivos de cada usuario en el origen.
• No demuestra que esta redacción haya realizado un despliegue. La falta de Git Credential Manager, la ausencia de una biblioteca de almacenamiento secreto en Linux y no disponer de un tenant elegible detuvieron la prueba antes del inicio de sesión.

La decisión honesta es acotada: conviene usarlo cuando la aplicación es interna, la organización ya trabaja en Microsoft 365 y evitar el trabajo de identidad y gobierno compensa aceptar una plataforma en versión preliminar y sus controles de tenant. Es preferible otro host si se necesita un producto SaaS público, otro proveedor de código fuente, control de infraestructura o un modelo de publicación que los administradores no puedan autorizar.

Preguntas frecuentes

La acción para el lunes

Pide a un administrador de Power Platform que habilite la creación desde la CLI para un grupo de prueba, confirme la regla de enrutamiento del entorno de ese grupo y cubra el runtime de dos usuarios de prueba. Elige una lista de SharePoint sin datos sensibles y una operación de solo lectura. Después, pide a un desarrollador que anote cuatro datos en el registro del piloto: la versión de la CLI, el tiempo hasta la primera página local, el tiempo hasta la vista previa alojada y el SHA del commit desplegado. Detén el piloto si la identidad de Entra, los permisos del origen o la política de conectores se comportan de forma distinta a lo previsto por escrito.

Si quieres diseñar y construir para tu empresa esta ruta gobernada de aplicaciones, empieza con una evaluación de sistemas de producción de IA.