Crear aplicaciones empresariales ya es fácil. Copilot Managed Runtime apunta a lo difícil.

La frase más honesta de los anuncios de Microsoft en septiembre ni siquiera trataba de IA. Estaba en la entrada que presenta Copilot Managed Runtime: “Un código que funciona es solo el primer paso.”

A continuación, Microsoft enumera lo que viene después: aprovisionar y proteger recursos en la nube, configurar identidad y seguridad, cumplir las políticas de la organización, establecer procesos de despliegue y operar la aplicación durante todo su ciclo de vida. Quien haya intentado llevar un prototipo interno de IA a producción reconocerá esa lista. Ahí es donde la mayoría se detiene.

Qué anunció Microsoft

Copilot Managed Runtime entró en vista previa pública el 25 de septiembre. Microsoft lo describe como una plataforma empresarial para ejecutar código dentro de los límites del tenant de Microsoft 365, gobernada por TI. Según la compañía, ya sostiene las aplicaciones creadas en Copilot Cowork, Copilot Code y Copilot Studio, y se abre a herramientas de terceros y a desarrolladores profesionales mediante un SDK y una CLI.

Las aplicaciones desplegadas en el runtime pueden usar, en palabras de Microsoft:

• Identidad y uso compartido con Microsoft Entra.
• Entornos de ejecución alojados por Microsoft.
• Políticas de la organización para conectores, acceso a datos, endpoints aprobados y auditoría.
• Controles de despliegue, versiones y ciclo de vida, con control de código mediante Git.
• Inventario central, supervisión, visibilidad de uso y control de TI en el centro de administración de Microsoft 365.

Disponibilidad frente a implicaciones de arquitectura

Conviene separar dos cosas. La primera es el producto: está en vista previa, y el anuncio no detalla precios, licencias ni disponibilidad por región. Para organizaciones en España o Latinoamérica, eso debe confirmarse con Microsoft antes de planificar.

La segunda es el patrón de arquitectura, que ya es válido hoy, se use o no este producto: separar dónde se construyen las aplicaciones de dónde y cómo se ejecutan.

El problema real: el volumen de aplicaciones, no su calidad

Las empresas ya han vivido esto. Bases de datos en Access, hojas de cálculo llenas de macros y, más recientemente, aplicaciones low-code siguieron el mismo patrón: fáciles de crear, difíciles de encontrar y aún más difíciles de retirar. La IA abarata todavía más la creación: Microsoft describe ahora las pequeñas aplicaciones a medida como una nueva unidad del trabajo, junto a documentos y hojas de cálculo.

Cuando crear es casi gratis, el cuello de botella pasa a ser operar. Cada aplicación necesita alojamiento, modelo de identidad, política de acceso a datos, registro de auditoría y un responsable. Si cada área tiene que montar esa base por su cuenta, pasan dos cosas: la mayoría de las aplicaciones útiles nunca llega a publicarse, y las que llegan siguen cada una un modelo de gobernanza distinto.

Ese es el argumento a favor de un runtime gestionado. Microsoft lo llama “la separación entre construir libremente y operar de forma gestionada”: cada persona construye con la herramienta que le sirve, pero todo se ejecuta sobre una única capa gobernada.

1. Creada en Copilot Cowork, Code, Studio o en herramientas de terceros
2. Identidad de Entra, políticas y versiones
3. Centro de administración: inventario, uso y estado
4. Responsable de la aplicación: lógica, uso de datos y retiro

• Construcción libre: Creada en Copilot Cowork, Code, Studio o en herramientas de terceros
• Operación gestionada (vista previa): Identidad de Entra, políticas y versiones · Centro de administración: inventario, uso y estado
• Sigue siendo del negocio: Responsable de la aplicación: lógica, uso de datos y retiro

Lo estandariza el runtime gestionadoDecisiones que siguen en manos del negocio

Lo que un runtime no decide

Una plataforma gobernada elimina una gran clase de riesgos: aplicaciones sin autenticación, credenciales en el código, conectores que nadie aprobó, aplicaciones que nadie sabe que existen. No elimina las preguntas que son del negocio:

¿La lógica es correcta? Una aplicación puede estar perfectamente alojada y aun así calcular mal. El código generado por IA necesita una revisión proporcional a lo que la aplicación decide.

¿El uso de los datos es adecuado? Acceso gobernado significa que la aplicación solo alcanza lo que permite la política. No significa que todo uso permitido sea buena idea. Un conector aprobado para informes puede no ser adecuado para una aplicación que envía correos a clientes, y cuando hay datos personales la finalidad tiene que estar definida.

¿Quién es el responsable? Un inventario central muestra lo que existe. No hace responsable a nadie cuando quien creó la aplicación cambia de área.

¿La IA que contiene es lo bastante buena? Si la aplicación llama a un modelo, su comportamiento sigue necesitando evaluación y una forma de verificarlo tras cada cambio.

¿Cuándo se retira? Las versiones hacen que cambiar sea seguro. Retirar es una decisión que alguien tiene que tomar.

Un modelo operativo distinto

Para organizaciones estandarizadas en Microsoft 365 y Entra, el runtime permite un modelo en el que TI gobierna cómo se ejecutan las aplicaciones, no quién puede construirlas. Eso solo funciona con reglas claras:

1. Criterios de promoción. ¿Cuándo pasa una aplicación personal a ser compartida y qué revisión activa?
2. Responsable obligatorio. Ninguna aplicación compartida sin un área de negocio responsable y una fecha de revisión.
3. Políticas por defecto acordes al riesgo. Revise las políticas por defecto de conectores y endpoints antes de habilitar el runtime a gran escala, no después.
4. Un camino hacia ingeniería. Microsoft señala que los desarrolladores pueden descargar el código y seguir evolucionándolo. Defina cuándo una aplicación es lo bastante importante para pasar a un equipo que la mantenga.

En resumen

Copilot Managed Runtime apunta a la capa donde más mueren las aplicaciones internas de IA: alojamiento, identidad, políticas y ciclo de vida. Estandarizar esa capa es la dirección correcta, y todavía está en vista previa. Las decisiones sobre responsabilidad, corrección y uso adecuado no vienen incluidas. Son la diferencia entre una plataforma gobernada y un portafolio gobernado.

Para ver cómo encaja en el stack completo, consulte nuestra guía de 2026.