Copilot Managed Runtime
Copilot Managed Runtime: la pieza que puede cambiar cómo Microsoft gobierna las apps creadas con IA
Microsoft está haciendo muchísimo ruido alrededor de la creación de aplicaciones mediante IA. Podemos pedirle a Copilot que construya una app, utilizar Microsoft Copilot Studio o incluso trabajar desde un enfoque profesional basado en SDK, CLI y código.
Pero, para mí, la noticia realmente importante no está ahí.
La pieza que merece mucha más atención se llama Copilot Managed Runtime, y probablemente sea uno de los documentos que cualquier responsable de TI, seguridad, Power Platform, Microsoft 365 o desarrollo interno debería leer con calma.
Porque Microsoft no solo está intentando facilitar que cualquiera pueda crear aplicaciones con IA. Al mismo tiempo, está construyendo la infraestructura necesaria para evitar que esas aplicaciones terminen creciendo fuera del control de la organización.
Y esa diferencia es enorme.
Crear aplicaciones con IA es fácil. Gobernarlas es el problema
La IA generativa está reduciendo de forma radical la barrera de entrada al desarrollo de software. Un usuario de negocio puede describir una necesidad mediante lenguaje natural y obtener una aplicación funcional sin tener que convertirse previamente en desarrollador.
Copilot Cowork, Microsoft Copilot Studio y las herramientas de desarrollo profesional forman parte de esa misma evolución. Microsoft documenta actualmente tres caminos para crear aplicaciones que terminan ejecutándose sobre Copilot Managed Runtime: Cowork, Copilot Studio y el SDK/CLI destinado a desarrolladores profesionales.
Desde el punto de vista de productividad, esto es fantástico. Desde el punto de vista de TI y seguridad, plantea una pregunta bastante más incómoda:
¿Qué ocurre cuando cientos o miles de empleados empiezan a crear sus propias aplicaciones?
El verdadero riesgo no es que los empleados sean capaces de desarrollar software. El riesgo aparece cuando la organización deja de saber qué aplicaciones existen, quién puede utilizarlas, a qué datos acceden, qué servicios conectan, qué información comparten o dónde se están ejecutando.
Ahí es donde Copilot Managed Runtime empieza a tener sentido.
¿Qué es Copilot Managed Runtime?
Copilot Managed Runtime es el entorno administrado por Microsoft sobre el que pueden ejecutarse estas nuevas aplicaciones internas de Microsoft 365.
La idea fundamental es sencilla: una aplicación creada dentro de este modelo hereda controles de gobierno, seguridad y cumplimiento desde el momento en que nace, en lugar de añadirlos posteriormente como una capa adicional. Microsoft lo define precisamente como un entorno para aplicaciones line-of-business de Microsoft 365 que heredan automáticamente los controles organizativos desde su creación.
Esto significa que da igual que la aplicación nazca desde una conversación en Cowork, desde Copilot Studio o mediante un desarrollo tradicional utilizando el SDK y la CLI. Los diferentes mecanismos de creación terminan produciendo el mismo tipo de aplicación gobernada por Copilot Managed Runtime.
Y ahí está, para mí, el verdadero cambio de arquitectura.
Gobernanza desde el primer minuto
Microsoft indica que las aplicaciones creadas mediante Copilot Managed Runtime utilizan Microsoft Entra para autenticación, se ejecutan en un entorno alojado por Microsoft y están sujetas a las políticas de gobierno del tenant.
Además, las aplicaciones heredan políticas predeterminadas relacionadas con aspectos como los conectores permitidos, las reglas de uso compartido y las políticas de seguridad del contenido. También aparecen en el inventario del centro de administración de Microsoft 365, independientemente de cuál haya sido la herramienta utilizada para crearlas.
Desde la perspectiva administrativa, Microsoft menciona además controles como Conditional Access, Data Loss Prevention (DLP), políticas avanzadas sobre conectores, límites de uso compartido y gestión centralizada del ciclo de vida.
Es decir, Microsoft está intentando resolver uno de los problemas clásicos del desarrollo ciudadano antes de que la IA lo multiplique por cien.
No crear primero y gobernar después.
Crear ya dentro de un perímetro gobernado.
El problema no es el Citizen Development
Durante años hemos hablado de Citizen Development y de los riesgos asociados a que usuarios de negocio puedan crear aplicaciones y automatizaciones sin pasar por los equipos tradicionales de desarrollo.
La IA lleva este fenómeno a otra escala.
Ya no estamos hablando únicamente de alguien aprendiendo Power Apps o Power Automate. Estamos entrando en una etapa en la que una persona puede describir una aplicación mediante lenguaje natural y dejar que un agente o copiloto genere buena parte de su estructura, interfaz, lógica e integración con datos.
Intentar detener ese fenómeno probablemente sea poco realista.
El planteamiento de Microsoft parece ser otro: si los usuarios van a crear aplicaciones, hagamos que las creen dentro de un entorno donde TI conserve visibilidad y capacidad de gobierno.
Y esa filosofía me parece bastante más interesante que intentar prohibir el llamado vibe coding o poner barreras al Citizen Development.
De Shadow IT a Managed AI Development
El Shadow IT aparece normalmente cuando la velocidad que necesita el negocio supera la capacidad de respuesta de los procesos tradicionales de TI.
Los usuarios encuentran entonces soluciones alternativas: una hoja de cálculo, una aplicación SaaS no aprobada, un script, una automatización personal o cualquier herramienta que les permita resolver el problema.
Con la IA generativa, ese fenómeno puede evolucionar hacia algo todavía más difícil de controlar: Shadow AI Development.
Imaginemos cientos de pequeñas aplicaciones creadas por empleados utilizando agentes de programación, APIs externas y servicios cloud. Cada una puede resolver perfectamente un problema concreto, pero también puede introducir conexiones con sistemas que TI desconoce, modelos de autenticación inconsistentes, almacenamiento de datos fuera del perímetro corporativo o mecanismos de compartición difíciles de auditar.
Copilot Managed Runtime intenta ofrecer una alternativa.
El mensaje sería aproximadamente este: puedes construir rápido, puedes utilizar IA e incluso puedes trabajar desde un enfoque code-first, pero la aplicación continúa dentro de un marco corporativo gobernado.
Esto también cambia la conversación sobre Power Platform
Hay otro aspecto que me parece especialmente interesante.
Durante mucho tiempo Microsoft Power Platform ha sido el principal entorno de Microsoft para democratizar el desarrollo interno manteniendo capacidades empresariales de gobierno. Ahora estamos viendo cómo Microsoft empieza a extender algunos de esos principios hacia nuevos modelos de desarrollo impulsados directamente por IA.
Copilot Managed Runtime no convierte automáticamente cualquier desarrollo generado con IA en una aplicación perfectamente gobernada, ni elimina la necesidad de diseñar políticas, revisar conectores, configurar permisos o definir responsabilidades.
Lo que sí cambia es el punto de partida.
En lugar de comenzar con una aplicación aislada y después intentar incorporarla al gobierno corporativo, el runtime nace integrado con la identidad, las políticas y la administración del tenant.
Ese cambio puede parecer pequeño desde fuera, pero arquitectónicamente es muy importante.
TI necesita visibilidad antes que control absoluto
Hay además una idea que me parece especialmente relevante para CIO, CISO, equipos de seguridad y CSIRT.
Durante muchos años, buena parte del gobierno tecnológico se ha basado en controlar quién podía crear determinadas soluciones. La IA hace que ese modelo sea cada vez menos sostenible, porque la capacidad de creación se está distribuyendo rápidamente entre prácticamente todos los empleados.
En ese escenario, posiblemente la prioridad ya no sea impedir que alguien cree una aplicación.
La prioridad pasa a ser saber qué se está creando, quién lo ha creado, quién puede utilizarlo, qué datos consume, qué conectores utiliza y qué políticas se están aplicando.
Copilot Managed Runtime apunta precisamente hacia ese modelo. Las aplicaciones aparecen en el inventario del Microsoft 365 admin center, desde donde los administradores pueden supervisar uso, salud y ciclo de vida independientemente de la herramienta desde la que se hayan creado.
Eso convierte la observabilidad en una pieza fundamental del gobierno.
Un runtime común para makers, desarrolladores y usuarios de negocio
Otro detalle interesante es que Microsoft no está diseñando Copilot Managed Runtime exclusivamente para Citizen Developers.
El SDK permite a desarrolladores profesionales trabajar con JavaScript y TypeScript, utilizar Visual Studio Code, integrar Git y desplegar aplicaciones desde un flujo de desarrollo tradicional. Microsoft también documenta acceso a más de 1.500 conectores y fuentes de datos, incluyendo Microsoft Graph, SQL y SharePoint.
Por tanto, la frontera entre low-code, pro-code y desarrollo generado mediante IA empieza a hacerse mucho menos importante.
- Un usuario de negocio puede describir una aplicación.
- Un maker puede construirla en Copilot Studio.
- Un desarrollador puede trabajar mediante SDK y CLI.
Pero el runtime, el modelo de identidad y parte de la gobernanza pueden ser comunes.
Esa convergencia me parece mucho más relevante que discutir continuamente si una aplicación concreta debe considerarse low-code, no-code, pro-code o vibe coding.
Seguridad por diseño, pero no seguridad automática
Aquí también conviene introducir un poco de prudencia.
Que Copilot Managed Runtime incorpore gobierno desde el diseño no significa que podamos olvidarnos de la seguridad. Una política mal configurada seguirá siendo una política mal configurada, y permitir determinados conectores o compartir aplicaciones demasiado ampliamente puede seguir generando riesgos.
Lo interesante es que Microsoft está intentando que el comportamiento predeterminado sea más seguro y administrable, trasladando controles que tradicionalmente requerían trabajo posterior hacia la propia infraestructura donde se ejecutan las aplicaciones.
De hecho, la documentación administrativa resume el modelo alrededor de tres principios: aplicaciones seguras por defecto, gobierno a escala y equilibrio entre control administrativo y productividad del desarrollador.
La dirección me parece especialmente significativa.
Una pieza que conviene seguir muy de cerca
El futuro que se dibuja no parece ser uno en el que TI construye todas las aplicaciones y los empleados simplemente las utilizan. Tampoco parece uno en el que cada empleado genera software sin ningún tipo de control corporativo.
El modelo que Microsoft está intentando construir está en algún punto intermedio: permitir que muchas más personas desarrollen aplicaciones, pero hacer que esas aplicaciones nazcan directamente dentro de un runtime gobernado por la organización.
Y, desde mi punto de vista, esa puede terminar siendo una de las piezas más importantes de toda la estrategia de Copilot.
Porque quizá la gran revolución no sea que Copilot pueda crear aplicaciones.
Quizá sea conseguir que miles de personas puedan crearlas sin que TI pierda el control por el camino.
Información basada en la publicación What is Copilot Managed Runtime.
