O GitHub Copilot está ganhando uma regra que pode mudar o que aparece para cada equipe sem que alguém precise editar modelo por modelo. A partir de 26 de agosto, o GitHub começou a liberar a política global de modelos para os planos Copilot Business e Copilot Enterprise. O rollout acontece aos poucos e deve terminar em 1º de setembro de 2026.
A mudança parece administrativa, mas mexe numa decisão prática: quais modelos ficam disponíveis para as pessoas que usam o Copilot no trabalho. Antes, um administrador podia configurar modelos individualmente. Agora, modelos de disponibilidade geral que ainda não receberam uma escolha explícita passam a seguir uma política padrão da organização ou da empresa.
O que muda para os administradores
Quando a regra chegar ao ambiente, modelos que nunca foram configurados vão aparecer no estado “Delegar à política padrão”. Esse estado é dinâmico. Se a política global estiver habilitada, os modelos aplicáveis ficam disponíveis; se o administrador mudar a política depois, eles acompanham a nova decisão.
O detalhe importante é que o GitHub diz preservar escolhas explícitas. Se alguém habilitou ou desabilitou um modelo de propósito, a nova política não substitui essa decisão. A regra global afeta principalmente o que estava sem configuração, incluindo modelos novos que forem adicionados ao catálogo.
Na prática, isso reduz o trabalho repetitivo em ambientes com muitas equipes. Também cria uma obrigação que costuma ficar escondida: revisar o padrão antes de ligá-lo para todo mundo. Uma política conveniente no painel pode liberar um modelo que não combina com as exigências internas de dados, retenção ou suporte.
Quatro estados para acompanhar
Depois do rollout, cada modelo nas configurações pode aparecer em quatro estados. “Habilitado” indica uma escolha direta para permitir o uso. “Desabilitado” bloqueia o modelo. “Delegar às equipes, aplicativos ou organizações da empresa” mostra que a decisão veio de uma camada superior. Já “Delegar à política padrão” significa que o modelo acompanha a regra global configurada pelo administrador.
Essa diferença entre uma permissão direta e uma permissão herdada merece atenção. Um modelo pode estar disponível hoje não porque alguém o aprovou individualmente, mas porque a política padrão o deixou passar. Se o catálogo mudar ou a regra for alterada, o resultado também muda. O painel passa a ser menos uma lista fixa e mais uma árvore de decisões.
Open-weight e retenção de dados ficam fora do padrão
O GitHub informa que modelos open-weight, como DeepSeek e Kimi K2, ficam desabilitados por padrão. O mesmo vale para modelos que não estão cobertos pelo acordo de retenção de dados do GitHub, como o exemplo citado pela empresa, Fable 5.
Isso não significa que todo modelo fora dessas condições seja automaticamente adequado para qualquer equipe. Significa que esses grupos não entram no mecanismo de habilitação padrão descrito no anúncio. A organização ainda precisa olhar para contrato, região, dados enviados ao serviço, requisitos de segurança e o tipo de código que o Copilot pode receber.
Para quem administra uma instalação corporativa, a lista de verificação é menos glamourosa do que testar o modelo mais novo, mas é onde o problema costuma aparecer: conferir as escolhas explícitas, identificar permissões herdadas, revisar modelos liberados pela política padrão e confirmar quais opções ficam bloqueadas por retenção ou por serem open-weight.
O que vale conferir antes de 1º de setembro
Primeiro, descubra quais modelos estão sem configuração individual. Eles são os mais afetados pela mudança. Depois, compare a política global atual com o catálogo que a equipe realmente usa. Se o padrão estiver habilitado, um modelo novo pode ser disponibilizado sem uma aprovação manual específica.
Também vale separar disponibilidade de recomendação. Um modelo aparecer para o usuário não quer dizer que ele seja a melhor opção para revisão de código, dados sensíveis ou projetos regulados. A empresa pode deixar a opção disponível e ainda orientar as equipes a usar modelos diferentes em determinados repositórios ou fluxos.
Por fim, registre quem toma a decisão e como uma alteração será revisada. A política global existe para evitar configurações espalhadas, mas não elimina a necessidade de governança. Ela só concentra o botão. A pergunta continua sendo quem confere o efeito depois que alguém clica.
Uma política global ajuda, mas pode esconder dependências
Minha leitura é que a novidade resolve um problema real de manutenção. Administrar muitos modelos individualmente vira uma coleção de exceções, e exceções esquecidas são difíceis de auditar. Um padrão central dá um ponto claro para começar.
O risco está no estado delegado. Ele é útil justamente porque acompanha a política, mas pode fazer uma permissão parecer permanente quando, na verdade, depende de uma regra distante. Para o desenvolvedor, a experiência tende a ser simples: o modelo aparece ou não aparece. Para quem responde pelo ambiente, a explicação precisa ser mais detalhada.
O GitHub diz que está avaliando remover o estado “Delegar à política padrão” e exigir uma escolha explícita para cada política. Se isso acontecer, o painel ficará mais trabalhoso, mas também deixará menos decisões implícitas. Até lá, a mudança de agosto pede uma revisão concreta das configurações, não apenas um aviso no changelog.
