Copilot Managed Runtime (III) - todo por un clic

ℹ️ En colaboración con Ana Estigarribia

En la segunda parte sobre managed apps y Copilot Managed Runtime (CMR) vimos qué opciones tenemos para tomar el control: bloquear temporalmente, limitar quién puede crear, configurar el routing y las políticas, y controlar el consumo.

Pero dejamos dos preguntas pendientes. Porque decidir quién puede crear y bajo qué reglas es solo una parte del gobierno. También necesitamos saber cuánto consume esa aplicación y qué ocurre con ella después de publicarla.

Así que cerremos el recorrido de aquel clic con las dos piezas que nos faltaban: consumo y monitorización.

Empecemos por la primera.

¿Cómo se paga todo esto?

Para responder, tenemos que separar dos momentos que pueden parecer parte de la misma experiencia, pero que se administran y facturan de forma diferente: la construcción de la aplicación y su ejecución. Una cosa es lo que consume el maker mientras construye y otra lo que consumen las personas cuando ejecutan la aplicación.

Build: mientras construimos

Aquí hablamos de las acciones que realiza el maker para crear, generar, probar y publicar la aplicación. El consumo depende del punto de entrada utilizado:

• Desde Copilot Cowork, el maker necesita una licencia de Microsoft Copilot y Copilot Credits asociados a su spending policy de Cowork.

• Desde Copilot Studio, la construcción consume Copilot Credits mediante la facturación existente de Copilot Studio para el entorno. La actividad facturable comienza durante la creación e incluye la autoría en lenguaje natural, las pruebas y la evaluación.

• Desde la CLI de Copilot Managed Runtime, crear, compilar y desplegar no consume Copilot Credits de construcción. La CLI puede utilizarse directamente o mediante herramientas como GitHub Copilot; en este último caso, la asistencia para generar el código depende de la licencia de GitHub Copilot. La ejecución local queda fuera de esta cobertura de desarrollo y se considera runtime.

Aunque todas las aplicaciones terminen ejecutándose sobre el mismo runtime, su construcción no se financia necesariamente desde el mismo lugar.

Runtime: cuando la aplicación se ejecuta

El runtime comienza cuando una persona abre y utiliza la aplicación, incluida su ejecución local desde la CLI. Para utilizarla, Microsoft establece dos vías de cobertura:

• Power Apps Premium, que cubre la ejecución sin consumir Copilot Credits. Las llamadas API cuentan para los límites diarios de solicitudes de Power Platform asociados a la licencia.

• Copilot Credits, gestionados mediante spending policies y asignaciones por usuario en el M365 Admin Center.

Si la aplicación usa servicios con facturación propia, como las APIs de Work IQ, esos servicios mantienen su propio consumo. Del mismo modo, las llamadas que superen los límites diarios de solicitudes de Power Platform asociados a Power Apps Premium se facturan mediante Copilot Credits.

Pero… ¿qué significa realmente “consumir”?

Copilot Managed Runtime mide el uso de la aplicación en llamadas API. Entre los ejemplos que Microsoft documenta están lanzar la aplicación, publicar una versión y realizar operaciones de lectura o escritura mediante conectores. Según la documentación (a fecha de publicación de este artículo), cada llamada API consume 0,1 Copilot Credits.

Por tanto, para estimar el consumo no basta con mirar cuántas personas utilizarán la aplicación. También importa qué hace y cuántas operaciones necesita para hacerlo.

Compartir no significa poder ejecutar

Hemos creado la aplicación, todo está correctamente gobernado y decidimos compartirla con alguien. ¿Puede utilizarla? Aquí hay que tener claro que:

Compartir ≠ licenciar ≠ autorizar los datos

Compartir una aplicación, poder ejecutarla y acceder a sus datos son decisiones distintas. Una persona puede recibir el vínculo y, aun así, no tener cobertura para ejecutar o permisos sobre las fuentes utilizadas.

• Acceso a la aplicación. Compartir concede acceso al recurso. No proporciona automáticamente la cobertura necesaria para ejecutarlo.

• Derecho de ejecución. La persona necesita estar cubierta para ejecutar la aplicación mediante Power Apps Premium o Copilot Credits.

• Acceso a los datos. Cada destinatario necesita permisos adecuados para las fuentes que usa la aplicación.

Podemos entregar el enlace correctamente y encontrarnos con que la persona no tiene cobertura para ejecutar la aplicación o no puede acceder a alguna de las fuentes utilizadas.

Y hay otro detalle importante para el ciclo de vida: retirar el acceso a la aplicación y retirar los permisos sobre sus fuentes de datos tampoco son la misma operación.

Así que gobernar el sharing exige mirar más allá del botón Compartir.

Y... ¿dónde encuentro todas esas managed apps?

Volvamos por un momento a la escena con la que empezó esta serie.

Alguien pulsa un botón → Aparece un PDE → Se crea una aplicación → Se comparte → Se usa → Genera consumo

Para el equipo encargado del gobierno queda entonces una pregunta bastante razonable:

¿Dónde puedo consultar las managed apps creadas y supervisar su actividad y consumo?

Y aquí entramos en la segunda pieza que nos faltaba: la monitorización. Para empezar, podemos localizarlas desde dos centros de administración:

En el Power Platform Admin Center (PPAC)

Puedes verlas en Manage → Inventory y filtrar por “Item Type = Managed App”.

Si seleccionas una podrás consultar información como propietario, identificador, datos del entorno, conectores, usuarios activos y sesiones.

Nos permite localizar las aplicaciones y entender dónde están y qué gobierno están heredando.

En el M365 Admin Center (MAC)

Las encontrarás en Apps → All apps.

Podrás consultar información similar a la del PPAC, pero también disponemos de una pestaña Monitor con métricas adicionales como tasa de éxito de apertura, tiempo hasta la inactividad, tasa de éxito de solicitudes de datos y su latencia. Además, podemos configurar reglas de alertas personalizadas, y bloquear o borrar aplicaciones.

Inventariar nos dice qué existe. Monitorizar nos ayuda a decidir qué hacer con ello.

Y aquí termina la historia de aquel inocente clic de nuestro maker en el botón Aplicación de Copilot Studio. Tres capítulos después, sabemos que detrás había bastante más que una app: entornos, routing, políticas, permisos, créditos y monitorización.

Y recuerda, gobernar no consiste en evitar el clic, sino en estar preparados para todo lo que viene después.