O GitHub anunciou que, não antes de 28 de setembro de 2026, pretende relançar o Copilot Chat no GitHub.com, o Copilot Chat no GitHub Mobile e o GitHub Copilot cloud agent como uma experiência única. O ponto mais importante para administradores é que a data de 28/9 funciona como marco mínimo de lançamento, e não como promessa de que a mudança ocorrerá exatamente nesse dia.
Quando o relançamento entrar em vigor, as políticas separadas dessas três experiências serão substituídas por uma política unificada. O novo conjunto ficará habilitado por padrão após o lançamento. Para organizações que usam Copilot Business ou Copilot Enterprise, isso muda a revisão operacional: uma decisão sobre a experiência unificada passa a afetar, em conjunto, o acesso ao Copilot no GitHub.com e no GitHub Mobile, além do cloud agent.
O que muda na unificação do Copilot
O anúncio do GitHub concentra três mudanças que têm impacto direto em governança e uso diário:
- uma política em vez de políticas separadas: cloud agent, Copilot Chat no GitHub.com e Copilot Chat no GitHub Mobile passam a ser governados por uma política unificada;
- habilitação padrão: a experiência unificada será habilitada por padrão depois do lançamento;
- nova base de sessão no GitHub.com: o Copilot no site migra integralmente para a experiência de agent sessions, já usada pelo cloud agent, e o cloud agent passa a usar Sandbox para a execução em nuvem.
O comunicado oficial está no GitHub Changelog de 28 de agosto de 2026. Como a formulação usada pelo GitHub é “no earlier than September 28th”, vale acompanhar o changelog e a página de políticas no momento da implantação, especialmente em ambientes com mudança controlada.
Antes e depois: o que o administrador precisa entender
| Aspecto | Antes do relançamento | Após a unificação |
|---|---|---|
| Política de acesso | Experiências com políticas separadas. | Uma política passa a governar cloud agent, Chat no GitHub.com e Chat no GitHub Mobile. |
| Estado padrão | O comportamento depende das políticas atuais de cada experiência e da hierarquia enterprise/organização. | A experiência unificada será habilitada por padrão após o lançamento, segundo o anúncio. |
| Chat no GitHub.com | Na documentação vigente em 12/9/2026, mensagens de conversas são mantidas por 28 dias. | Com a migração para agent sessions, o GitHub anunciou retenção dos dados de chat por toda a vida da conta. |
| Opt-out | As experiências podiam ser governadas separadamente. | Ao optar por sair da experiência unificada, o usuário ou a equipe perde acesso ao Copilot no GitHub.com e no GitHub Mobile depois do lançamento. |
| Ação administrativa | Revisar controles separados conforme a superfície usada. | Revisar a política unificada antes da implantação e confirmar se o resultado atende às regras internas da organização. |
Retenção de chat: de 28 dias para a vida da conta
A alteração de retenção é a mudança mais sensível para equipes com requisitos de privacidade, segurança ou minimização de dados. A documentação atual do Copilot Chat no GitHub informa que o histórico mostra até 100 conversas recentes e que as mensagens de cada conversa são mantidas por 28 dias antes de serem excluídas. O anúncio de 28 de agosto afirma que, quando o GitHub.com migrar totalmente para agent sessions, os dados de chat serão retidos durante a vida da conta, alinhando o comportamento à experiência existente do cloud agent.
Há uma ressalva importante: o texto do changelog vincula explicitamente essa mudança ao Copilot no GitHub.com. Ele não afirma que todo chat do Copilot em todos os clientes e IDEs passará automaticamente a ter a mesma retenção. Portanto, políticas internas não devem generalizar a nova regra para superfícies que o anúncio não menciona.
Para administradores, o efeito prático é revisar documentos de governança que ainda assumem uma janela de 28 dias para o chat do GitHub.com. A mudança também merece atenção em procedimentos de classificação de informações e orientação a usuários sobre o que pode ou não ser colocado em prompts e conversas. Isso é uma recomendação operacional; requisitos legais ou contratuais específicos devem ser avaliados conforme o contexto de cada organização.
Como a política enterprise e a política da organização se combinam
A unificação não elimina a hierarquia de administração do Copilot. A documentação de políticas do GitHub Copilot explica que as políticas são definidas primeiro no nível enterprise. Em geral, administradores de enterprise podem habilitar, desabilitar ou permitir que as organizações decidam. Para o cloud agent existe uma particularidade: o enterprise pode selecionar quais organizações recebem acesso.
Na prática, uma organização não consegue sobrescrever uma decisão explícita tomada no nível enterprise. A documentação de administração do cloud agent para organizações reforça esse ponto. Assim, a revisão antes do relançamento deve começar pelo nível mais alto de governança: primeiro enterprise, depois organização e, por fim, controles aplicáveis a repositórios.
O que ainda pode ser controlado além da política unificada
“Política unificada” não significa que todos os controles administrativos do Copilot foram condensados em um único botão. A documentação atual do cloud agent prevê controles adicionais, e o anúncio de unificação não informa que eles serão removidos.
- Disponibilidade por organização: o enterprise pode restringir o cloud agent a organizações selecionadas.
- Disponibilidade por repositório: organizações podem bloquear o cloud agent em alguns ou todos os seus repositórios.
- Automações: a permissão para automações em repositórios é administrada separadamente da política principal do cloud agent.
- Firewall do agente: administradores de organização podem configurar o firewall do cloud agent e quais hosts externos ele pode acessar.
Esses controles ajudam a separar a pergunta “quem pode usar a experiência?” de perguntas mais específicas, como “em quais repositórios?”, “com automações?” e “com quais destinos de rede?”. Para equipes reguladas, essa separação evita interpretar a unificação como liberação irrestrita do agente.
O que acontece se a organização optar por sair
O GitHub diz que nenhuma ação será necessária para continuar usando o Copilot no GitHub.com e no GitHub Mobile quando a experiência unificada for lançada. A consequência relevante está no opt-out: se a experiência unificada for desabilitada, o usuário ou a equipe perderá acesso ao Copilot no GitHub.com e no GitHub Mobile após o novo modelo entrar em vigor.
Por isso, administradores de Copilot Business e Enterprise foram orientados pelo GitHub a revisar a política antes de 28 de setembro. No anúncio, o caminho informado é acessar as configurações do Copilot no GitHub.com, selecionar a política de Copilot cloud agent — marcada como “coming soon” no comunicado — e definir a opção desejada. Como a interface pode mudar no lançamento, o mais seguro é confirmar o nome e a localização finais do controle no dia da implantação.
Há outra mudança em 28/9: Code Review passa a usar Balanced como padrão
O mesmo changelog traz uma alteração paralela, mas separada da política unificada. A partir de 28 de setembro de 2026, o valor Default do GitHub Copilot code review passa a usar o nível de esforço Balanced em vez de Lite. A configuração pode existir nos níveis de organização e repositório: o padrão da organização se aplica a repositórios que não definiram seu próprio nível, e o padrão do repositório vale para revisões solicitadas automaticamente.
Quem quiser manter Lite deve selecionar explicitamente Lite antes de 28/9, em vez de deixar a opção em Default. Essa mudança é útil no checklist de admins porque ocorre na mesma janela, mas não deve ser confundida com a unificação de Chat e cloud agent.
Não confunda a mudança de 28/9 com as alterações de cobrança de 1º/10
O anúncio de 28 de agosto também trata de faturamento de Copilot Business e Enterprise. Para clientes existentes que pagam com cartão ou PayPal, as mudanças de cobrança anunciadas começam em 1º de outubro de 2026. Elas são uma frente separada: não definem a política unificada nem a retenção de chat.
Separar as datas evita um erro comum de rollout: 28/9 é a janela mais cedo para a nova experiência e para a mudança do padrão de Code Review; 1º/10 é a data indicada para determinadas mudanças de billing de clientes existentes.
Checklist de revisão para administradores
- Antes da implantação: confirmar no nível enterprise qual política do Copilot prevalece e quais organizações recebem acesso.
- Revisar a política unificada: decidir se GitHub.com, GitHub Mobile e cloud agent devem permanecer disponíveis para as equipes afetadas.
- Atualizar a matriz de retenção: substituir a premissa de 28 dias para o chat no GitHub.com pela retenção anunciada para a vida da conta, quando a migração entrar em vigor.
- Checar controles complementares: repositórios permitidos, automações e firewall do cloud agent.
- Revisar Code Review: se a organização não quiser Balanced como novo padrão, selecionar Lite explicitamente antes de 28/9.
- Comunicar usuários: explicar o efeito do opt-out e a mudança de retenção antes da ativação.
- Confirmar a data real de lançamento: como o GitHub disse “não antes de 28/9”, validar o changelog e as configurações no momento do rollout.
O ganho de governança está em tratar a mudança como um pacote de decisões, não apenas como uma troca de interface. A política unificada simplifica o controle das três superfícies, mas aumenta o impacto de uma única escolha; ao mesmo tempo, a retenção mais longa do chat no GitHub.com exige uma revisão explícita das expectativas de dados. Para acompanhar a implantação, use o changelog oficial e a documentação de políticas do Copilot.
