Copilot Managed Runtime (II): todo por un clic
ℹ️ En colaboración con Ana Estigarribia
En la primera parte seguimos el clic del maker para crear una managed app hasta su entorno de desarrollo personal (PDE) y vimos cómo Copilot Managed Runtime aplica un gobierno predeterminado. Pero que exista una configuración de serie no significa que sea la adecuada para nuestra organización. Así llegamos a la siguiente pregunta.
¿Qué opciones tenemos para tomar el control?
La respuesta corta es: depende de lo que necesitemos controlar.
No existe un único interruptor que resuelva acceso, routing, seguridad y consumo a la vez. Tenemos varias palancas y cada una actúa sobre una parte diferente del problema.
Opción 1: bloquear temporalmente el punto de entrada
Si necesitamos tiempo para entender el impacto, podemos deshabilitar la creación de aplicaciones desde Copilot Studio. Esta vía está habilitada de forma predeterminada y puede administrarse desde el centro de administración de Microsoft 365.
Apps → Overview → Set up app creation spaces
Esto detiene la creación desde Copilot Studio, pero no bloquea otras vías de entrada, como Cowork o la CLI, que se gestionan por separado. La CLI está deshabilitada de forma predeterminada y se habilita por entorno o Environment Group; en Cowork, la creación depende de que el maker tenga acceso a la herramienta.
Por tanto, esta opción puede ser una buena medida de contención mientras revisamos la configuración. Pero debería servir para ganar tiempo, no para posponer indefinidamente la decisión.
Bloquear Copilot Studio no equivale a deshabilitar Copilot Managed Runtime.
Opción 2: limitar la creación a determinados grupos
Si no queremos abrir la experiencia a toda la organización, podemos restringir la creación desde Copilot Studio a grupos de seguridad de Microsoft Entra a través de CLI con:
powerPlatform.powerapps.enabledGroupsManagedAppsMcsPreview
Cuando la vía de Copilot Studio está habilitada, solo las personas incluidas en esos grupos pueden crear aplicaciones desde ella. Esto nos permite empezar con un grupo reducido: un piloto, un equipo de innovación o makers que ya hayan pasado por un proceso de acompañamiento. Pero cuidado: estar autorizado para entrar no garantiza tener una regla de routing aplicable.
El grupo que permite acceder a la experiencia y el que utiliza Environment Routing cumplen funciones distintas:
El primero decide quién puede utilizar el punto de entrada.
El segundo decide quién puede obtener un PDE y dónde se aprovisionará.
Si no coordinamos ambos controles, podemos permitir que una persona vea la experiencia y, aun así, impedir que complete la creación.
Opción 3: controlar capacidad y consumo
También podemos actuar sobre los Copilot Credits: definir qué usuarios o grupos están cubiertos, establecer límites y supervisar el consumo. Porque… ¡SORPRESA! ¡Las managed apps consumen créditos! (Os lo contaremos en el último capítulo)
Pero controlar el presupuesto no sustituye el gobierno técnico. Los límites de consumo no deciden a qué Environment Group llega el PDE del maker, qué conectores utiliza, hasta dónde comparte la aplicación o qué políticas de seguridad se aplican.
Controlar el consumo limita la exposición económica. No define por sí solo el comportamiento de la plataforma.
Opción 4: configurar routing y políticas para tomar el control
Esta es la opción que nos permite pasar de la contención a un modelo sostenible. Las aplicaciones heredan las reglas de su entorno y de su Environment Group. Antes de ampliar el acceso, deberíamos revisar:
Quién queda cubierto por cada regla de routing y en qué orden se evalúa
Qué conectores, acciones concretas y servidores MCP están permitidos
Cómo se configura el sharing interno y con invitados
Qué Content Security Policy se aplica y si se introduce primero en report-only
Cómo conviven las Advanced Connector Policies con las políticas DLP existentes
Y, por supuesto, cómo convive todo ello con las demás políticas del marco de gobierno.
Vale, pero… ¿qué opción escoger?
No son opciones excluyentes. Podemos combinar las cuatro palancas:
Bloquear temporalmente mientras analizamos el impacto
Abrir a un grupo reducido para validar el escenario
Establecer límites de consumo para controlar la exposición económica
Diseñar routing y políticas antes de ampliar la adopción
La clave está en no confundirlas:
Bloquear una experiencia no diseña el routing
Limitar el acceso no controla el consumo
Controlar créditos no sustituye las políticas de seguridad
Configurar routing no decide por sí solo quién puede utilizar cada punto de entrada
Bloquear nos permite parar. Limitar nos permite probar. Controlar el consumo nos permite acotar el coste. Gobernar nos permite escalar.
Entonces, ¿bloquear o gobernar?
Bloquear temporalmente puede ser una decisión razonable cuando todavía no conocemos el alcance, no hemos revisado el consumo o necesitamos tiempo para configurar el gobierno. Pero no debería ser nuestra única estrategia.
Porque bloquear responde a una sola pregunta: ¿Queremos detener ahora mismo la creación desde este punto de entrada?
Pero gobernar exige responder a unas cuantas más:
¿Quién puede crear y desde qué puntos de entrada?
¿Dónde se aprovisionará su PDE?
¿Qué conectores, acciones y servidores MCP podrá utilizar?
¿Hasta dónde podrá compartir la aplicación?
¿Cómo se controlarán el consumo y el ciclo de vida?
No se trata de permitirlo todo ni de bloquearlo todo. Se trata de entender qué ocurre después de aquel simple clic y tomar el control de cada decisión: empezar con un grupo reducido, configurar el routing, revisar el gobierno predeterminado, establecer límites de consumo y ampliar el acceso cuando el modelo esté preparado.
Cuando hablamos de gobierno, hablamos de facilitar, no de prohibir: de permitir que el maker resuelva una necesidad sin que cada nueva aplicación o funcionalidad desborde al equipo de gobierno.
Bloquear frena la creación. Gobernar permite escalar con control.
Y hasta aquí la parte II. En el tercer y último capítulo abordaremos las dos piezas que nos faltan: consumo y monitorización.
Comentarios