💳 Copilot Studio: el GitHub Copilot harness cobra desde el desarrollo

En un agente estándar de Copilot Studio solemos asociar el consumo facturable con el agente publicado. Ese supuesto deja de ser válido para los agentes, workflows y apps construidos sobre el GitHub Copilot harness.

Microsoft documenta un modelo nuevo basado en consumo: crear soluciones con lenguaje natural, usar Preview, probar, generar evaluaciones y ejecutar el agente puede consumir Copilot Credits. La licencia de Microsoft 365 Copilot del maker o del usuario no cubre este consumo. Además, los entornos developer y trial pasan a facturación basada en uso el 1 de septiembre de 2026. Documentación oficial actualizada el 29 de agosto de 2026.

No es solo un cambio de precio. Modifica cómo debemos diseñar entornos, accesos, presupuestos, pruebas automatizadas y continuidad del servicio.

Qué cambia frente al harness estándar

ActividadStandard harnessGitHub Copilot harness
Autoría y diseñoNo empieza a facturar hasta publicarPuede consumir desde que empezamos a construir
Preview y pruebasDepende del escenario estándarConsume cuando utiliza modelo, herramientas, knowledge o harness
Generación de evaluacionesModelo estándar aplicablePuede consumir Copilot Credits
RuntimeFacturable según canal y licenciaTodo el uso es facturable
Microsoft 365 CopilotPuede cubrir uso elegible en canales Microsoft 365No cubre el consumo del nuevo harness

Los Credits cubren la experiencia completa: tokens del LLM, herramientas —incluidos knowledge y MCP— y el propio harness. Microsoft no publica en estas páginas una tarifa fija por conversación: el consumo depende del diseño, la complejidad y los componentes utilizados. Resumen del modelo de facturación.

Flujo de Copilot Credits desde la actividad del maker y el runtime hasta los controles de entorno y agente.

Diagrama original. Un presupuesto de Azure alerta, pero no detiene el agente; el hard stop debe configurarse a nivel de agente.

A quién afecta y cuándo

El alcance confirmado es:

  • agentes, workflows y apps construidos con el GitHub Copilot harness;
  • actividades de creación, preview, prueba, evaluación y ejecución;
  • cualquier usuario, incluso si dispone de Microsoft 365 Copilot;
  • entornos developer y trial desde el 1 de septiembre de 2026.

El Standard harness continúa soportado y conserva su modelo. Tampoco debemos aplicar automáticamente estas reglas a Copilot Chat: Copilot Studio es ahora una plataforma multi-harness y cada agente debe clasificarse correctamente.

En Power Platform admin center → Manage → Copilot Studio, la columna Harness identifica GitHub Copilot, Standard o Copilot Chat. Es el inventario mínimo antes de calcular capacidad.

Arquitectura de consumo y control

El flujo operativo tiene cuatro capas:

  1. El maker o usuario inicia una actividad que requiere el modelo, una herramienta, knowledge o el harness.
  2. Copilot Studio registra Copilot Credits contra el agente y el entorno.
  3. El entorno consume capacidad prepago asignada, capacidad disponible del tenant o un plan pay-as-you-go vinculado.
  4. Los límites de agente, las notificaciones y la política de enforcement deciden si el uso continúa.

Una asignación de entorno no siempre es un límite. Si está permitido consumir del pool del tenant, el entorno seguirá usando capacidad no asignada. Si existe pay-as-you-go, también puede seguir facturando a Azure después de agotar el prepago.

Actividad de maker o runtime
        ↓
Copilot Credits por agente y entorno
        ↓
Asignación prepago agotada
        ├─ Pool del tenant permitido → continúa
        ├─ Pay-as-you-go vinculado → continúa y factura Azure
        └─ Sin capacidad disponible → autoría y runtime se detienen

Qué ocurre cuando se agotan los Credits

Si el entorno no tiene Credits disponibles, las experiencias que los necesitan dejan de funcionar:

  • el agente deja de responder a usuarios;
  • el maker no puede crear mediante lenguaje natural;
  • Preview y las pruebas dejan de funcionar;
  • no se pueden generar ni crear evaluaciones.

Microsoft admite cierto overage parecido a un periodo de gracia para evitar un corte inmediato de procesos, pero no documenta en la política una cantidad o duración garantizada. No debe utilizarse como capacidad de reserva. Política de enforcement.

Configuración paso a paso

1. Inventariar agentes y responsables

  1. Abre Power Platform admin center.
  2. Ve a Manage → Copilot Studio.
  3. Filtra Harness = GitHub Copilot.
  4. Registra agente, entorno, owner funcional, owner técnico y criticidad.
  5. Separa prototipos, desarrollo y workloads productivos.

La columna Harness es actualmente una propiedad de la interfaz de inventario. No construyas una integración asumiendo que ese campo concreto existe en una API sin verificar el esquema soportado.

2. Elegir la fuente de capacidad

ModeloUso recomendadoRiesgo principal
Packs prepagoDemanda estable y capacidad mensual previsibleLa capacidad no usada no se traslada al mes siguiente
Pay-as-you-goPilotos o demanda variableCoste abierto si no hay límites de agente
Pre-purchase planConsumo anual elevado y previsibleCompra anual final; no admite cancelación, split ni exchange

El pre-purchase plan se compra como Copilot Credit Commit Units en Azure Reservations. Tiene un año de duración, renovación automática por defecto y puede aplicar hasta un 20 % de ahorro según volumen. Confirma siempre el precio y términos de vuestro acuerdo antes de comprar. Gestión oficial del pre-purchase plan.

3. Contener el consumo prepago por entorno

Se necesita el rol Power Platform Administrator, Global Administrator o permisos equivalentes.

  1. Ve a Licensing → Copilot Studio → Manage Copilot Credits.
  2. Selecciona el entorno.
  3. Asigna la cantidad de Credits aprobada.
  4. En Capacity overages, desactiva Draw from the available capacity in my tenant si quieres impedir que el entorno use el pool no asignado.
  5. Guarda.

Esto contiene el prepago, pero no detiene pay-as-you-go. Si el entorno tiene un billing plan vinculado, el consumo puede continuar contra Azure.

4. Crear un límite por agente

  1. Ve a Licensing → Copilot Studio → Manage Agents.
  2. Selecciona el agente y pulsa Set limit.
  3. Define el límite mensual.
  4. Configura el umbral de notificación.
  5. Activa Stop usage si el agente debe apagarse al alcanzar el límite.

Este es el control para contener un workload individual. Un presupuesto de Azure envía alertas, pero Microsoft confirma que no detiene el consumo de Copilot Studio.

5. Configurar pay-as-you-go con doble protección

  1. Crea un billing plan asociado a una suscripción Azure.
  2. Vincula únicamente los entornos aprobados.
  3. Configura Azure Cost Management budgets y alertas sobre el recurso de cuenta Power Platform.
  4. Añade también límites de agente con hard stop.
  5. Asigna un responsable que revise consumo y excepciones.

La combinación es deliberada: Azure controla visibilidad financiera; Copilot Studio controla la detención del agente.

Monitorización y pruebas

En Licensing → Copilot Studio, Microsoft ofrece vistas a cuatro niveles:

  • tenant: capacidad comprada, asignada y consumida;
  • entorno: prepago, pay-as-you-go y estado de overage;
  • agente: consumo del mes, límite y estado;
  • informe descargable: detalle para análisis adicional.

La atribución no llega al maker o usuario individual: la facturación se registra por entorno y agente. Para imputar costes internos hay que combinar ese consumo con ownership, centro de coste y proceso de aprobación.

Propongo medir una línea base por escenario:

EscenarioMedición mínima
Crear agente con lenguaje naturalCredits antes y después
Cinco conversaciones de PreviewDiferencia total y media orientativa
Generar un test setDiferencia por generación
Ejecutar evaluación completaCredits por número de casos
Invocar knowledge, connector o MCPComparar con respuesta sin herramienta

Estas pruebas producen una estimación, no una tarifa contractual estable. Modelos, instrucciones, rutas de herramientas y complejidad cambian el consumo.

Seguridad y gobierno

  • Mínimo privilegio: limita quién puede crear agentes GitHub Copilot harness en cada entorno.
  • Separación de entornos: no mezcles prototipos sin límite con agentes productivos.
  • Datos en evaluaciones: generar test cases puede usar credenciales conectadas y producir datos sensibles visibles para otros makers autorizados.
  • MCP y herramientas: cada llamada puede influir en consumo y mantiene sus propios controles de autenticación y DLP.
  • Continuidad: decide qué agentes admiten hard stop y cuáles requieren pay-as-you-go como respaldo.
  • Segregación financiera: quien crea agentes no debería aprobar sin control su propia ampliación de capacidad.

Checklist antes del 1 de septiembre

  • Inventariar agentes con Harness = GitHub Copilot.
  • Revisar el consumo no facturado disponible en los informes actuales.
  • Clasificar DEV, trial y producción.
  • Asignar Credits a los entornos autorizados.
  • Decidir si pueden consumir del pool del tenant.
  • Vincular pay-as-you-go solo donde sea necesario.
  • Definir límite, aviso y hard stop por agente.
  • Configurar presupuestos y alertas Azure.
  • Nombrar owner de consumo y proceso de ampliación.
  • Medir creación, Preview, evaluaciones y herramientas por separado.

Limitaciones

  • Microsoft no publica una cifra fija de Credits por conversación para el nuevo harness.
  • El consumo no se atribuye directamente a cada maker o usuario.
  • El overage de gracia no tiene cantidad ni duración garantizadas.
  • Los presupuestos Azure no actúan como interruptor.
  • Una asignación de entorno no es un cap si siguen habilitados el pool del tenant o pay-as-you-go.
  • El consumo observado durante preview no garantiza el coste futuro de producción.

Conclusión

El GitHub Copilot harness convierte la autoría en parte del runtime económico. Crear, probar y evaluar ya son actividades que debemos presupuestar y gobernar.

La respuesta no consiste en evitar las pruebas, sino en darles un entorno, una capacidad y un owner: inventario por harness, asignaciones explícitas, límites por agente y pay-as-you-go solo cuando la continuidad lo justifique.

Referencias oficiales