🧩 Copilot Studio ya genera aplicaciones sobre Managed Runtime

Copilot Studio ya no se limita a construir agentes y workflows. La nueva experiencia Apps in Copilot Studio permite describir una necesidad en lenguaje natural y generar una aplicación web funcional con interfaz, modelo de datos y lógica. El maker puede probarla en un preview interactivo, iterar mediante conversación, publicarla y compartirla.

La novedad importante está debajo de la interfaz: la aplicación no es una canvas app convencional. Se ejecuta en Microsoft Copilot Managed Runtime, el mismo runtime administrado que utilizan las apps creadas desde Copilot Cowork o mediante el nuevo SDK y CLI. Hereda autenticación de Microsoft Entra, políticas corporativas, inventario central, conectores aprobados y controles de distribución.

A 27 de septiembre de 2026, toda esta superficie está en preview, en despliegue gradual y no recomendada para producción. Microsoft actualizó la documentación principal el 26 de septiembre. No debemos confundir disponibilidad de la documentación con disponibilidad en todos los tenants.

Qué cambia realmente

Hasta ahora, Copilot Studio tenía dos artefactos principales en su nueva experiencia: agentes y workflows. Ahora añade una tercera clase:

Artefacto	Resultado	Runtime principal	Interacción
Agente	Experiencia conversacional y herramientas	GitHub Copilot harness	Conversación y acciones
Workflow	Automatización ejecutable	GitHub Copilot harness	Evento o invocación
App	Aplicación web con UI, datos y lógica	Copilot Managed Runtime	Formularios, vistas, acciones y navegación

Una app generada puede incluir pantallas, formularios, campos, tablas, vistas, filtros, acciones y datos de ejemplo. La plataforma mantiene sincronizados interfaz, lógica y modelo cuando pedimos cambios al agente. También permite inspeccionar los archivos generados, aunque el código es solo lectura en la experiencia actual.

Diagrama original. La construcción se gobierna y factura desde Power Platform; la ejecución y distribución convergen en Copilot Managed Runtime y Microsoft 365.

Arquitectura: tres caminos, un mismo artefacto

Microsoft documenta tres entradas al Managed Runtime:

1. Copilot Studio, pensado para makers que quieren conversar, previsualizar, publicar y compartir desde una misma superficie.
2. Copilot Cowork, orientado a usuarios de negocio y actualmente ligado al programa Frontier.
3. SDK y CLI, para desarrolladores que trabajan con @microsoft/managed-apps, el comando ms y agentes de código.

Los tres generan el mismo tipo de aplicación administrada. En ejecución:

• el usuario abre la app desde https://managedapps.cloud.microsoft o su URL publicada;
• Microsoft Entra autentica al usuario;
• Copilot Managed Runtime carga el artefacto publicado en infraestructura alojada por Microsoft;
• las políticas de tenant y entorno filtran conexiones, distribución y acceso;
• cada conector usa la identidad del usuario, no las credenciales compartidas del maker;
• el administrador ve inventario, uso, salud y ciclo de vida en Microsoft 365 admin center.

El runtime también incorpora un repositorio Git administrado para control de código y colaboración. Desde Copilot Studio, sin embargo, el maker no edita directamente esos archivos: solicita cambios al agente y revisa el resultado generado.

Disponibilidad y requisitos

La preview se está desplegando gradualmente. Para comprobar que el tenant está habilitado:

• activa New experience en la página principal de Copilot Studio;
• verifica que aparece la tarjeta App (Preview) o la entrada Apps (Preview);
• confirma que el administrador no ha deshabilitado la creación de apps;
• asigna Copilot Credits y una política de gasto al entorno de construcción;
• comprueba el enrutamiento del maker a su entorno personal de desarrollo.

La creación desde Copilot Studio está activada por defecto para usuarios elegibles. Los roles Global Administrator y Power Platform Administrator pueden administrarla; Global Reader, AI Administrator y AI Reader solo pueden consultarla.

El tenant setting documentado es powerPlatform.powerApps.enableManagedAppsMcsPreview. No es booleano: acepta valores de texto. Por ejemplo, para aplicar el valor por defecto de public preview:

$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.powerApps.enableManagedAppsMcsPreview = "DefaultOn"
Set-TenantSettings -RequestBody $tenantSettings

No automatices este cambio sin probar primero el valor y la versión del módulo en un tenant de laboratorio. Microsoft también permite restringir la creación a un security group mediante PowerShell o API.

El efecto menos visible: environment routing automático

Todos los tenants tienen activado el enrutamiento de Copilot Managed Runtime y no se puede desactivar. Su comportamiento depende de la configuración previa:

Estado del tenant	Resultado confirmado
No existen reglas de routing	Se crea una regla para Everyone y un default environment group
Ya existen reglas	Solo los makers incluidos en sus security groups pueden crear estas apps
Entorno personal creado para Managed Runtime	Es Managed Environment y no incluye Dataverse inicialmente
El maker también entra desde Power Apps, Power Automate o Copilot Studio por routing	Dataverse puede añadirse automáticamente y podrían aplicarse requisitos Premium

El entorno personal funciona como sandbox aislado por maker. No es un entorno de producción ni un sustituto automático de una estrategia ALM. Antes de abrir la preview a toda la organización, inventaría cuántos entornos puede generar, qué environment group heredan, quién será propietario cuando un maker salga y cómo se promocionarán las soluciones aprobadas.

Cómo se construye una app

1. Definir el contrato funcional

Una petición como “haz una app de incidencias” deja demasiadas decisiones al modelo. Especifica:

• usuarios y roles;
• entidades, campos y relaciones;
• acciones y reglas de negocio;
• origen y persistencia de datos;
• estados y transiciones;
• validaciones y mensajes de error;
• requisitos de accesibilidad;
• operaciones prohibidas.

Divide una aplicación compleja en incrementos verificables. Microsoft advierte que los roles múltiples, rutas condicionales, integraciones y reglas especializadas requieren más iteración.

2. Generar el primer borrador

1. Accede a Copilot Studio y activa New experience.
2. Selecciona App o Apps (Preview) → New app.
3. Describe el problema y adjunta documentos, hojas de cálculo, imágenes o capturas si aportan contexto.
4. Responde a las preguntas de aclaración.
5. Espera a que aparezca el preview interactivo.
6. Recorre los casos principales antes de solicitar nuevos cambios.

Los adjuntos usados como contexto no se convierten automáticamente en conexiones vivas. Una hoja Excel adjunta puede ayudar a inferir campos, pero no garantiza que los registros queden sincronizados con el archivo.

3. Refinar sin editar directamente el código

El maker puede:

• pedir cambios mediante chat;
• adjuntar un fichero o una captura;
• anotar una zona concreta del canvas;
• revisar el resultado en preview;
• alternar entre preview y vista de código.

La vista de código es solo lectura. Esto limita la corrección manual y obliga a expresar el cambio al agente. Si una personalización requiere control de código profesional, evalúa el SDK/CLI de Managed Runtime en vez de forzar el recorrido de maker.

Elegir correctamente la persistencia

Copilot Studio ofrece varias opciones que visualmente pueden parecer equivalentes, pero no lo son:

Opción	Persistencia	Uso adecuado	Riesgo principal
Sample data	Puede regenerarse o reiniciarse	Diseño y prueba visual	Confundir demo con registros reales
Browser-local	Perfil del navegador y dispositivo	Utilidades personales autocontenidas	Sin gobierno ni uso multiusuario
SharePoint	Lista organizativa compartida	Trackers y registros sencillos de equipo	Modelo relacional y permisos limitados
Dataverse	Tablas existentes del entorno	Datos estructurados, relaciones y seguridad granular	Licencia, capacidad y ALM
Excel, SQL u otra tabla	Conector permitido en el entorno	Reutilizar una fuente existente	Consentimiento, delegación y límites del conector

En preview, Copilot Studio puede conectarse a tablas Dataverse existentes, pero la creación de nuevas tablas no está soportada en todas las versiones del despliegue. La creación de un nuevo sitio SharePoint tampoco está disponible en todos los tenants.

Antes de publicar, abre Data and Connections y comprueba la fuente real. Refrescar el preview no demuestra persistencia: sample data puede formar parte del propio artefacto y browser-local puede sobrevivir a un refresh sin ser compartido.

Identidad, conexiones y seguridad

Cada usuario se autentica con Microsoft Entra y abre sus propias conexiones. Las credenciales del maker no se comparten. Por tanto:

• dos usuarios pueden ver resultados diferentes;
• compartir la app no concede acceso a la tabla, lista o fichero subyacente;
• el primer uso puede exigir consentimiento;
• una operación falla si el usuario carece de permiso;
• Conditional Access, DLP, advanced connector policies, límites de sharing y restricciones de datos se aplican automáticamente.

La aplicación puede usar un subconjunto del catálogo de conectores. Una conexión puede no aparecer porque la política la bloquea, no existe en el entorno, el usuario no tiene permiso o falta una licencia.

Recomendaciones mínimas:

1. prueba con una cuenta equivalente al usuario final, no solo con el maker;
2. aplica mínimo privilegio en cada origen;
3. revisa DLP y la clasificación de todos los conectores;
4. separa claramente datos de ejemplo y datos reales;
5. valida entradas, cálculos y operaciones destructivas;
6. comprueba accesibilidad, navegación por teclado y mensajes de error;
7. registra propietario, finalidad, usuarios autorizados y fecha de revisión.

Publicar no es compartir

Copilot Studio separa ambas operaciones:

• Publish crea una versión estable disponible para los destinatarios. Los cambios posteriores no llegan a usuarios hasta volver a publicar.
• Share concede a personas o grupos permiso para abrirla, sujeto a las políticas del entorno. No permite editar el diseño ni concede permisos sobre los datos.

El flujo seguro es:

1. validar build, conexiones, políticas y ajustes requeridos;
2. probar la URL publicada;
3. compartir con un security group piloto;
4. comprobar consentimiento y acceso a datos con usuarios representativos;
5. ampliar el grupo solo después de revisar telemetría, errores y coste.

Facturación: build por entorno, runtime por usuario

Apps usa el GitHub Copilot harness, por lo que la construcción, el chat, la generación, el preview y las pruebas pueden consumir Copilot Credits antes de publicar.

La separación administrativa es importante:

Fase	Cómo se factura	Dónde se controla
Construcción en Copilot Studio	Copilot Credits por entorno	Power Platform admin center
Ejecución de la app	Copilot Credits y política por usuario	Microsoft 365 admin center

La facturación por entorno que se aplica al runtime de los agentes de Copilot Studio no se aplica al runtime de estas apps.

Microsoft documenta una excepción: con Power Apps Premium, ejecutar la app no consume Copilot Credits salvo que use servicios facturados aparte, como Work IQ APIs, o supere los límites aplicables de Power Apps Premium API requests. Esta excepción no cubre la construcción.

Durante la preview, un usuario sin cobertura suficiente recibe primero un aviso. El acceso se bloquea tras 20 operaciones de app o cinco minutos de uso, lo que ocurra antes. Configura la política de runtime antes del piloto; el aviso no es un modelo sostenible de licencia.

Limitaciones y preguntas aún abiertas

Hechos confirmados de la preview:

• el despliegue es gradual;
• el código generado es de solo lectura en Copilot Studio;
• layouts, cálculos, campos, acciones o sample data pueden ser incompletos o incorrectos;
• los conectores y operaciones varían según tenant, entorno, política y licencia;
• crear tablas Dataverse o sitios SharePoint nuevos no está disponible en todos los despliegues;
• resultados pueden variar por idioma y contexto cultural;
• preview, conexiones, límites y opciones de despliegue pueden cambiar antes de GA.

Microsoft no documenta todavía en estas páginas un proceso completo de promoción entre entornos, versionado, backup o recuperación desde la superficie de Copilot Studio. Managed Runtime incorpora Git y administración de ciclo de vida, pero no debemos inferir que equivale al ALM de solutions de Power Platform. Para un caso regulado o crítico, mantén la preview fuera de producción hasta disponer de un recorrido soportado y probado.

Checklist de piloto

• Crear un security group reducido para makers.
• Revisar las reglas de environment routing y el environment group resultante.
• Asignar presupuesto y Copilot Credits de build al entorno.
• Definir política y límite de runtime por usuario.
• Empezar con sample data sin información sensible.
• Sustituirlo después por una fuente gobernada y explícita.
• Probar con usuarios de alto y bajo privilegio.
• Verificar DLP, Conditional Access, consentimiento y permisos del origen.
• Validar cálculos, errores, accesibilidad y acciones destructivas.
• Publicar y compartir únicamente con el grupo piloto.
• Comprobar inventario, propietario, salud y consumo en Microsoft 365 admin center.
• Documentar una salida manual si la preview cambia o se retira.

Fuentes oficiales

• Apps overview in Microsoft Copilot Studio
• Create an app in Copilot Studio
• Manage data in your app
• Publish and share an app
• FAQ for apps in Copilot Studio
• What is Copilot Managed Runtime
• Copilot Managed Runtime overview for admins
• Environment routing for Copilot Managed Runtime
• Usage-based billing for the GitHub Copilot harness