Los equipos que usan GitHub Copilot deben separar tres fechas en vez de tratar “los cambios de septiembre” como un único evento. El 1 de septiembre de 2026, GitHub comienza a reabrir las altas self-service de Copilot Business y Copilot Enterprise para clientes que pagan con tarjeta de crédito o PayPal, con un comportamiento de facturación actualizado para nuevas asignaciones de puestos. El 28 de septiembre pueden comenzar dos cambios — pero el anuncio dice no antes del 28 de septiembre, por lo que el despliegue puede ocurrir ese día o después: la unificación de Copilot Chat en github.com, GitHub Mobile y Copilot cloud agent bajo una sola política, y el cambio por el que el esfuerzo “Default” de code review pasa de Lite a Balanced. Para clientes Business y Enterprise existentes que pagan con tarjeta o PayPal, las actualizaciones de billing entran en vigor a partir del 1 de octubre de 2026.
La tarea práctica es revisar configuración, gobernanza y presupuesto antes del 28/9 sin asumir que los cambios ya están activos. El anuncio oficial del 28 de agosto está en el GitHub Changelog.
Qué ya rige el 1 de septiembre — y qué todavía no
El 1 de septiembre, el hito inmediato es la reapertura gradual de las altas self-service para nuevos clientes Business y Enterprise que pagan con tarjeta de crédito o PayPal. GitHub indica que las nuevas asignaciones de puestos Business o Enterprise requerirán pago antes de que el usuario obtenga acceso a Copilot. La empresa también refuerza la verificación de cuentas y actualiza la experiencia de facturación para esos medios de pago.
Esto no significa que el valor Balanced por defecto del code review o la nueva retención del chat ya entren en vigor el 1 de septiembre. Esos dos elementos están vinculados al relanzamiento previsto para no antes del 28 de septiembre de 2026. Del mismo modo, los clientes Business y Enterprise existentes que pagan con tarjeta o PayPal deben mirar al 1 de octubre como inicio de las actualizaciones de facturación para sus suscripciones actuales.
Matriz de decisión: cambio, afectados, dónde revisar y decisión necesaria
| Cambio | Quién se ve afectado | Dónde revisar | Decisión necesaria |
|---|---|---|---|
| Pago de puestos y billing actualizado | Nuevos clientes Business/Enterprise self-service y, desde el 1/10, clientes existentes elegibles con tarjeta o PayPal | Billing, puestos, budgets y uso | Confirmar puestos necesarios, presupuesto para uso adicional y ciclo de facturación |
| Política unificada para Copilot en github.com, Mobile y cloud agent | Organizaciones Business/Enterprise que administran el acceso mediante políticas | Configuración de Copilot; opción de Copilot cloud agent cuando esté disponible | Decidir si la experiencia unificada debe permanecer habilitada para los equipos |
| La retención de chat en github.com pasa de 28 días a la vida de la cuenta | Usuarios y organizaciones que usan Copilot en github.com después de la migración | Políticas internas de uso de IA, clasificación de datos y gobernanza | Reevaluar qué puede enviarse al chat y si la retención más larga encaja con las reglas internas |
| “Default” de code review pasa de Lite a Balanced | Organizaciones y repositorios que usan el valor Default | Organization/Repository Settings > Copilot > Code review | Mantener Default y aceptar Balanced, o fijar Lite explícitamente antes del cambio |
Billing: qué cambia y qué debe entrar en el checklist
El anuncio de septiembre no es un aumento de precio de Copilot Business o Enterprise. GitHub afirma que los precios de esos planes no cambian. Lo que cambia es el comportamiento de facturación y de habilitación del acceso.
- Nuevos puestos: las nuevas asignaciones Business o Enterprise requieren pago antes de que el usuario obtenga acceso.
- Cobro anticipado por ciclo: al comienzo del siguiente ciclo de facturación, todos los puestos asignados generarán un cobro anticipado. Para clientes existentes con tarjeta o PayPal, esta actualización comienza el 1 de octubre de 2026.
- Uso por encima de lo incluido: puede ser necesario un pago adicional para que los usuarios sigan usando Copilot después de superar el uso incluido.
- Prorrateo: el uso incluido puede prorratearse durante el mes para alinearse con el prorrateo del coste del puesto.
- Retirada de puesto: revocar un puesto no genera un reembolso proporcional; la retirada se refleja en el siguiente ciclo mensual.
- Controles existentes: spend controls, seguimiento de uso y compra de AI Credits adicionales siguen disponibles.
Para los equipos financieros o de plataforma, la acción más útil es comparar puestos asignados, usuarios realmente activos, budgets y consumo adicional antes del siguiente ciclo. GitHub ya utiliza facturación basada en consumo para Copilot desde junio de 2026; ese contexto está en el changelog de billing y planes. La actualización de septiembre cambia principalmente cómo y cuándo los puestos y el uso deben estar cubiertos por el pago.
Retención: por qué la política unificada merece una revisión de gobernanza
En el relanzamiento previsto para no antes del 28 de septiembre, Copilot Chat en github.com, Copilot Chat en GitHub Mobile y Copilot cloud agent compartirán una única experiencia y política. Esa experiencia unificada quedará habilitada por defecto después del lanzamiento.
El cambio más sensible para la gobernanza está en github.com: al migrar a la experiencia de agent sessions, los datos de chat pasarán a conservarse durante la vida de la cuenta en vez de 28 días, alineándose con el comportamiento ya utilizado por Copilot cloud agent.
El anuncio indica que no se requiere ninguna acción para mantener Copilot disponible en github.com y GitHub Mobile. Sin embargo, si la organización opta por salir de la experiencia unificada, perderá el acceso a Copilot en esos dos canales después del lanzamiento del nuevo modelo. Por eso, GitHub aconseja a los administradores Business y Enterprise revisar la política antes del 28 de septiembre.
Implicación operativa: una retención más larga cambia la premisa de borrado automático que algunos equipos pueden haber usado para decidir qué era aceptable enviar al chat. Conviene revisar reglas internas sobre secretos, datos personales, código confidencial e información de clientes. Esa es una decisión de gobernanza propia de cada organización; GitHub anuncia el cambio de retención, pero no sustituye la política interna de cada empresa.
Code review: “Default” dejará de significar Lite
GitHub Copilot code review admite actualmente niveles de esfuerzo. Lite prioriza una revisión más rápida y dirigida, mientras que Balanced utiliza un análisis más profundo para lógica compleja, código sensible a seguridad y cambios entre servicios. La documentación de GitHub indica que Balanced usa más AI Credits y puede consumir marginalmente más minutos de GitHub Actions que Lite.
El punto de migración es preciso: a partir del 28 de septiembre, para organizaciones y repositorios configurados como Default, ese valor pasará a usar Balanced. Si un equipo quiere conservar Lite, no basta con “dejarlo como está”: debe cambiar Default por Lite explícitamente a nivel de organización o repositorio antes de la fecha.
La jerarquía también importa. El valor por defecto de la organización se aplica a repositorios que no hayan elegido un nivel propio; el valor del repositorio se aplica a revisiones solicitadas automáticamente en ese repositorio. En revisiones solicitadas manualmente, el nivel de esfuerzo puede elegirse desde el menú de revisores del pull request. Consulta la documentación de configuración de code review.
Existe un impacto potencial en costes. La documentación de code review estima actualmente alrededor de US$0,05 a US$1 en AI Credits para una revisión Lite y US$0,25 a US$5 para una revisión Balanced, sin incluir minutos de Actions. GitHub advierte que el consumo varía con el tamaño del pull request, las instrucciones del repositorio y la evolución de los modelos. Para equipos con revisión automática en muchos PR, pasar silenciosamente de Default/Lite a Balanced puede elevar el consumo aunque no cambie el volumen de pull requests.
Checklist para completar antes del 28 de septiembre
- Mapea responsables por capa: identifica quién gestiona billing, políticas de Copilot, configuración de organización y overrides de repositorio.
- Haz inventario de puestos: identifica puestos asignados con poco o ningún uso real y considera que la revocación no genera reembolso proporcional.
- Revisa budgets y consumo: comprueba AI Credits, uso adicional y GitHub Actions en equipos que usan code review.
- Decide la política unificada: confirma si Copilot en github.com y Mobile debe seguir habilitado después del relanzamiento.
- Actualiza la evaluación de retención: trata “vida de la cuenta” como nueva referencia para chats de github.com después de la migración, no 28 días.
- Lista repositorios en Default: identifica dónde code review hereda el valor de la organización y dónde existen overrides locales.
- Elige Lite o Balanced de forma intencional: si quieres Lite, configúralo explícitamente antes del 28 de septiembre; si aceptas Balanced, ajusta expectativas de coste y profundidad.
- Registra la decisión: documenta responsable, configuración elegida y fecha de revisión para evitar cambios invisibles entre organización y repositorio.
Qué no debe tratarse como una emergencia del 1 de septiembre
No es necesario adelantar al 1 de septiembre la nueva retención ni el cambio a Balanced por defecto: GitHub marcó esos elementos para no antes del 28 de septiembre. Tampoco hay un anuncio de aumento del precio nominal de Copilot Business o Enterprise. El trabajo de septiembre consiste principalmente en tomar decisiones antes de que cambien defaults y políticas, no en reconfigurar todo el primer día del mes.
En resumen: el 1 de septiembre, atención a altas y nuevas asignaciones de puestos; antes del 28 de septiembre, cierra la decisión sobre política unificada, retención y esfuerzo del code review; y, si tu organización es un cliente Business o Enterprise existente que paga con tarjeta o PayPal, prepara el billing para los cambios que comienzan el 1 de octubre.
