Resumen

  • Si la organización activa las políticas necesarias, sus miembros sin licencia Copilot pueden utilizar la revisión de código. Sus créditos de IA se facturan directamente a la organización o empresa como uso adicional de pago, sin atribuirlos a un presupuesto individual.
  • Las reglas pueden exigir revisar nuevos envíos y borradores aunque el usuario desactive sus preferencias personales. Elegir esa frecuencia es también ordenar compras futuras.

El departamento de compras puede celebrar que no ha contratado otra licencia de Copilot mientras la empresa empieza a pagar las revisiones de esa misma persona. GitHub ofrece justamente esa posibilidad: abrir la revisión de código a miembros de una organización que carecen de licencia y cargar su consumo directamente a la organización o empresa.

Para quien contribuye de vez en cuando, el arreglo tiene sentido. Recibe una revisión sin que alguien tenga que justificar primero una suscripción individual. Para la empresa, el recuento de licencias deja de describir todo lo que está comprando. El servicio ha ganado una puerta de entrada y la contabilidad necesita seguirla.

El presupuesto personal no ve toda la mesa

La documentación del producto establece dos condiciones: permitir el uso de pago de créditos de IA y habilitar la revisión para miembros sin licencia. Esta segunda política está desactivada de inicio. Al abrirla, las revisiones manuales y automáticas de esos miembros generan uso adicional que se factura a la organización o empresa. No cuentan con una asignación mensual individual para esa función ni consumen un presupuesto atribuido a la persona.

En los miembros con licencia de pago, GitHub utiliza por defecto sus derechos de consumo. El propietario de la organización o empresa puede optar por facturar a la organización. Hace falta autorizar el uso de pago, pero fijar un presupuesto es opcional. El cambio de facturación, por sí solo, no concede acceso al servicio.

Son tres decisiones distintas: quién entra, quién paga y dónde se impone un límite. Una organización que solo revisa las gráficas personales puede encontrarse con usuarios frugales y una cuenta colectiva bastante animada. No hay contradicción: está mirando una parte del gasto. Cerrar todos los monederos individuales deja intacta la posibilidad de comprar a nombre de la oficina.

La petición tiene su propia dirección de cobro

La atribución por defecto también depende de quién solicite la revisión. Si es automática, el consumo de IA se asigna al autor de la solicitud de incorporación de código. Si otro usuario la pide manualmente, se asigna a ese solicitante. Cuando Copilot cloud agent ha escrito el cambio, GitHub busca primero al coautor humano y, si no puede facturarle, carga a la organización. Los cambios escritos por otros bots, o las revisiones pedidas por un bot, van directamente a la organización.

Por tanto, preguntar quién escribió más código no basta para explicar quién generó la compra. Una revisión adicional pedida por un compañero y una regla automática pueden examinar el mismo cambio, pero seguir caminos de atribución diferentes. La organización que centraliza el pago debe reconocer la demanda que centraliza con él.

También se mueve el punto de interrupción. Las revisiones dependen de los presupuestos aplicables a la fuente de facturación elegida. Con cargo al usuario, agotar su presupuesto bloquea el servicio; con cargo organizativo, entran en juego los límites pertinentes de organización, centro de costes o empresa. Cambiar el pagador afecta al lugar donde una restricción económica se convierte en una restricción de trabajo.

El pago común puede ser una buena solución. Evita que la revisión exigida por la empresa dependa del saldo del colaborador que más cambios aporta. Pero requiere una política para el servicio común: qué revisión merece recursos, quién puede pedir más y quién responde cuando el consumo aumenta.

La palabra «siempre» tiene consecuencias comerciales

Las instrucciones de configuración permiten revisar cada nuevo envío y revisar borradores. Las preferencias de usuario y las reglas del repositorio o la organización se evalúan de manera independiente. Si varias coinciden en un mismo evento, Copilot publica una sola revisión. El usuario, sin embargo, no puede apagar con su preferencia una revisión de envíos o borradores que una regla exige.

La repetición surge cuando el trabajo avanza: corregir, volver a enviar, ajustar otra vez. Una regla que reclama intervención en cada paso convierte esa secuencia en sucesivas ocasiones de consumo. Contar únicamente solicitudes de incorporación oculta cuántas veces se ha comprado una revisión dentro de cada una.

Examinar antes puede encontrar un error antes de que otro ingeniero pierda tiempo con él. Examinar cada pequeño ajuste puede producir más confirmación que información nueva. Elegir entre ambas situaciones forma parte del diseño de la compra. La diligencia queda muy bien en una presentación; la frecuencia se liquida en otro departamento.

La profundidad tiene sus propios controles. La organización puede fijar un nivel predeterminado que los repositorios modifiquen, y un nivel máximo que no pueden superar. El primero expresa una costumbre; el segundo acota las opciones. Confundir una recomendación con un techo deja a la disciplina presupuestaria trabajando con una regla imaginaria.

El modelo trae un taller detrás

El anuncio de GitHub del 27 de abril de 2026 fijó para el 1 de junio el consumo conjunto de créditos de IA y minutos de GitHub Actions. El modelo consume por la interacción; las capacidades agentivas utilizan ejecución para reunir contexto y emplear herramientas. En repositorios privados con ejecución alojada estándar hay que separar el cómputo incluido de la utilización adicional.

La guía de ejecutores explica que desactivar los ejecutores alojados de GitHub elimina esas capacidades agentivas y lleva a una revisión más limitada. La organización puede alojar sus propios ejecutores; la solución admitida oficialmente es ARC sobre Ubuntu x64, con controles de red a su cargo.

Alojar la ejecución evita consumir minutos Actions y entrega a la empresa la tarea de operar los recursos. Una línea que desaparece de la factura del proveedor puede reaparecer como trabajo interno. Y si siguen apareciendo comentarios, pero con menos capacidad para reunir contexto, también ha cambiado el producto recibido. Comparar compras exige atender a ambos movimientos.

Los documentos públicos no aportan las ejecuciones, facturas conciliadas y hallazgos útiles de un cliente concreto; reunirlos permitiría calcular el rendimiento de sus revisiones adicionales. Antes de ese cálculo, la empresa ya puede asignar una responsabilidad: quien establece que la máquina revise siempre debe poder ver y explicar lo que ese «siempre» compra.