Planos do GitHub Copilot: guia completo de recursos e administração por níveis

Planos do GitHub Copilot em um relance

O GitHub oferece vários níveis distintos no seu ecossistema. Vale notar que a plataforma concluirá a adoção de cobrança por uso, substituindo o antigo framework "Premium Request Unit" (PRU) por GitHub AI Credits em junho de 2026.

No novo sistema, complementos de código essenciais e sugestões de “Próxima edição” permanecem ilimitados e não consomem créditos. 

Já operações avançadas, como chat entre múltiplos arquivos, fluxos agentic, sessões longas de codificação e code reviews aprofundados, consomem AI Credits com base no consumo de tokens (tokens de entrada, saída e em cache) em relação às tarifas publicadas do modelo específico. 

Os preços-base de assinatura mensal permaneceram estáveis, mas a mudança altera como administradores preveem excedentes e monitoram o uso ativo.ription prices have remained static, but the shift alters how administrators budget for overages and monitor active usage.

Planos individuais: Free, Student, Pro e Pro+

Os níveis individuais variam em acesso a modelos, limites de uso e recursos experimentais. Por exemplo, enquanto o Free atende a explorações básicas, o Pro+ dá acesso ao GitHub Spark, um ambiente voltado para construir aplicações com assistência de IA.

No momento, novas inscrições para contas individuais pagas do GitHub, como Pro, Pro+ e Student, estão pausadas. Contas existentes podem fazer upgrade de Pro para Pro+, mas novas contas não podem assinar até o GitHub concluir a transição para o novo sistema de cobrança por AI Credits.

Business e Enterprise

Nos níveis Business e Enterprise, o GitHub Copilot deixa de ser apenas uma extensão de IDE e passa a ser um ativo de infraestrutura corporativa com auditoria completa.

O GitHub Copilot Business traz recursos essenciais de gestão:

• Alocação e revogação centralizadas de assentos.
• Políticas-base em toda a organização.
• Logs estruturados de auditoria e rastreamento de eventos de compliance.
• Exclusões de conteúdo e de arquivos de repositório.
• Indenização comercial de propriedade intelectual.

O GitHub Copilot Enterprise adiciona ainda mais controle e capacidade:

• Copilot Spaces: um hub de conhecimento que permite aos desenvolvedores consultar o Copilot com base em documentação interna, wikis e padrões sistêmicos de código.
• Integração aprimorada com o Chat do GitHub.com.
• Herança hierárquica de políticas entre organizações filhas.

O GitHub Copilot Enterprise exige uma assinatura ativa do GitHub Enterprise Cloud. Como o GitHub Enterprise Cloud custa US$ 21 por usuário/mês e a licença do Copilot Enterprise é de US$ 39 por usuário/mês, o custo mínimo real é de US$ 60 por usuário/mês no Enterprise. Isso não se aplica ao nível GitHub Copilot Business, que pode ser adquirido diretamente por organizações que usam GitHub Free ou GitHub Team.

As organizações perdem benefícios de nível enterprise, como herança de políticas, mas ainda contam com indenização de PI, auditoria, exclusão de arquivos e gestão de políticas organizacionais — uma boa alternativa para times de engenharia médios.

Se você está considerando uma assinatura Enterprise, nosso guia GitHub Copilot Enterprise mostra como usar recursos como Copilot Spaces e a nova Usage Metrics API.

O que diferencia planos individuais dos corporativos

Gestão de dados, indenização de PI e cobrança são as áreas em que planos individuais e corporativos mais diferem. Embora recursos adicionais para usuários sejam ótimos, entender essas diferenças é crucial para decidir entre administrar um conjunto de licenças pessoais Pro ou uma assinatura Business.

Tratamento de dados e padrões de treinamento

Para equipes que lidam com sistemas proprietários, privacidade de dados costuma ser o fator decisivo entre planos pessoais e assinaturas Business.

Em abril de 2026, o GitHub mudou como a coleta de dados de interação funciona para planos individuais do Copilot. Para usuários Free, Pro e Pro+, dados de interação podem ser usados por padrão para treinamento de modelos, a menos que o usuário opte por desativar.

Vamos separar o que é código em repouso e o que é dado de interação, para entender o que entra no treinamento de IA:

• Código em repouso: O código bruto no seu repositório privado não é lido nem ingerido em conjuntos públicos de treinamento.
• Dados de interação: Incluem prompts, consultas de chat, contexto do cursor, blocos de código adjacentes enviados pela API da IDE durante a edição, métricas de aceitação de sugestões e logs de feedback.

Planos Business e Enterprise possuem garantia contratual rígida de que dados de interação não são usados para treinamento em nenhuma circunstância. Não é necessário o usuário ajustar nada.

Para entender mais a fundo como os dados são usados e como solucionar problemas no Copilot, recomendamos ler nosso guia GitHub Copilot Privacy and Troubleshooting.

Indenização de PI

Os planos GitHub Copilot Business e Enterprise incluem cobertura de indenização de propriedade intelectual (PI) para código gerado. Planos individuais não incluem.

Na prática, indenização significa que o GitHub concorda contratualmente em oferecer proteção legal, sob condições específicas, caso o código gerado crie disputas de PI. Isso não elimina todo o risco jurídico, mas muda a conversa sobre responsabilidade para times de software comerciais.

Freelancers que entregam código para clientes devem prestar atenção. A diferença entre “ferramenta pessoal de produtividade” e “plataforma de desenvolvimento apoiada pela organização” fica bem real quando entram contratos e entregas comerciais.

Cobrança, assentos e a migração para AI Credits

A cobrança individual é self-service e vinculada diretamente a contas pessoais. Nos planos Business, a cobrança é centralizada com assentos concedidos por administradores. Além disso, em vez de cada usuário consumir créditos de forma independente, a organização agrupa seus AI Credits mensais conforme o número de usuários.

Os planos Enterprise oferecem controle ainda mais granular, com limites de orçamento, agrupamento por centros de custo e alocações por departamento — garantindo que fluxos agentic intensivos de um único time de desenvolvimento não esgotem o pool corporativo de créditos.

SKUs e considerações de privacidade

Entender as proteções de privacidade de dados e SKUs é importante. Os limites arquiteturais que regem o fluxo de dados, proteções legais e rastreabilidade entre os vários níveis são resumidos abaixo:

Mudanças na política de treinamento em abril de 2026

A mudança de opt-in para opt-out nos planos individuais cria um vetor primário de vazamento de compliance. A carga de dados de interação capturada automaticamente durante uma sessão ativa na IDE inclui:

• Históricos detalhados de chat e contexto de prompts.
• Sugestões de código multilinha e taxas locais de aceitação.
• Contexto do cursor do editor, que frequentemente puxa contexto de arquivos adjacentes, declarações de import e variáveis de abas abertas.

Imagine que um desenvolvedor usa uma conta pessoal Copilot Pro enquanto trabalha em um repositório corporativo. Se o treinamento permanecer habilitado, dados de interação atrelados àquela sessão podem entrar no ecossistema de treinamento do GitHub. Esse cenário é uma das razões comuns para organizações adotarem o plano Business.

Como escolher o SKU certo para seus requisitos de privacidade

Dependendo do tipo de trabalho, você pode precisar de SKUs diferentes. 

• Dev solo/projetos paralelos: Free ou Pro oferecem máxima flexibilidade. Caso trabalhe com código proprietário, basta desativar o uso para treinamento nas suas configurações pessoais de privacidade.
• Freelancers/contratados: O plano Business cria uma barreira defensiva. Contratos de clientes muitas vezes proíbem o envio de dados a provedores externos de LLM; um assento dedicado na organização protege seus acordos.
• Times corporativos com exigências de compliance: O nível Business é o padrão recomendado, garantindo isolamento dos fluxos de dados e permitindo governança administrativa.
• Setores regulamentados (finanças, saúde): O nível Enterprise costuma ser obrigatório, possibilitando integrações com configurações de segurança especializadas, requisitos rígidos de residência de dados e camadas de fine-tuning localizadas.

Excluindo arquivos específicos do Copilot

Implementar regras de exclusão de arquivos no GitHub Copilot é uma das formas mais eficazes de proteger seu ambiente. A exclusão de conteúdo impede que o agente local da IDE processe determinados arquivos, tornando-os completamente invisíveis para completions inline, caixas de chat e operações agentic em segundo plano. 

Observe que o GitHub Copilot CLI, o agente em nuvem do Copilot e o modo Agent no Copilot Chat nas IDEs não oferecem suporte à exclusão de conteúdo.

Configurando regras de exclusão

Times de administração podem aplicar configurações de exclusão tanto no painel global de Organization Settings quanto nas configurações de repositórios individuais. Basta acessar as configurações do repositório ou da organização clicando no botão Settings no canto superior direito.

Escolha “Code and automation” nas configurações do Copilot na barra lateral. Em seguida, preencha suas exclusões na caixa “Paths to exclude in this repository” assim:

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

No nível de repositório da organização é semelhante, mas a configuração fica em “Repositories and Paths to exclude” usando o formato:

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

Manter o REPOSITORY-REFERENCE é importante na configuração. Bases comuns de configuração devem priorizar credenciais sigilosas, perfis de orquestração de produção, módulos proprietários sensíveis de algoritmos ou pastas com forte regulação de compliance.

Como as exclusões se aplicam nos recursos do Copilot

Quando uma exclusão corresponde, o isolamento de dados é absoluto em todos os subsistemas do Copilot:

• Completions inline: Bloqueia a geração de contexto dentro do arquivo e o uso dele para preencher arquivos adjacentes.
• Copilot chat/agents: O sistema retorna um aviso informando que o arquivo não pode ser revisado devido a restrições de política organizacional.

Os mecanismos locais padrão da IDE funcionam normalmente. Ferramentas de conveniência, como parsing de texto, destaque de sintaxe e IntelliSense local continuam, pois a camada de exclusão se aplica explicitamente aos fluxos de telemetria externos do Copilot. 

Administradores devem testar cuidadosamente padrões de caminhos em repositórios de staging; curingas malformados podem falhar em aberto, expondo dados que você pretendia isolar.

Gestão de políticas em toda a organização

Aplicar políticas do GitHub Copilot em nível organizacional garante que a segurança corporativa seja definida pela administração — não por preferências individuais de desenvolvedores.

Configurações de política disponíveis

As organizações podem controlar várias configurações para desenvolvedores:

• Feature toggles: Ative ou suprima globalmente o Copilot Chat em ambientes de desenvolvimento, interfaces de linha de comando (via Copilot CLI) ou sistemas avançados de code review com agentes.
• Filtro de código público: Um controle legal que bloqueia o Copilot de retornar sugestões muito parecidas com repositórios open-source públicos no GitHub, reduzindo riscos de conformidade de licenças.
• Restrições de escolha de modelo: Limite quais modelos (por exemplo, variantes específicas de GPT ou Claude) os devs podem selecionar, permitindo gerenciar latência, consumo de créditos e desempenho. Para conhecer melhor os modelos disponíveis na plataforma do GitHub, veja este guia prático sobre GitHub Models.
• Instruções personalizadas da organização: Injete arquivos padrão em markdown com padrões de código, frameworks de segurança e paradigmas arquiteturais da empresa em todo prompt enviado pelos seus desenvolvedores.

Se seu time tem pouca familiaridade com a estrutura de organizações e permissões do GitHub, o curso Intermediate GitHub Concepts traz uma boa base. Para grupos que estão expandindo para ferramentas de linha de comando, veja nosso GitHub Copilot CLI Tutorial.

Herança de políticas em nível Enterprise

Em ambientes corporativos de grande escala, o mecanismo de políticas segue uma cascata rígida de herança: Política Enterprise > Política da organização > Preferências do usuário

Administradores Enterprise podem bloquear políticas globalmente em todas as unidades de negócios, permitir exceções seletivas por organização ou delegar totalmente o controle na hierarquia. Por exemplo, a empresa pode ter configurações globais que restringem o uso de certos modelos.

No nível de time, pode restringir a divisão de serviços financeiros com filtros rígidos de código público, enquanto permite à divisão interna de P&D de software mais liberdade para experimentar.

Logs de auditoria

Quando auditores de compliance pedem verificação da sua cadeia de fornecimento de software ou quando equipes de segurança rastreiam um vazamento de dados, os logs do GitHub Copilot registram as modificações na plataforma.

Eventos do Copilot no log de auditoria

O sistema registra um histórico abrangente de operações de gestão, incluindo:

• Alocações e revogações explícitas de assentos e mudanças em grupos de cobrança.
• Modificações no filtro de duplicação de código público.
• Alterações nos padrões de exclusão de arquivos e diretórios.
• Estados de habilitação de recursos (por exemplo, ativar modos de code review com agentes).

A granularidade depende totalmente da sua assinatura. Enquanto o Business foca em eventos de ação com escopo de organização, contas Enterprise liberam telemetria forense sistêmica entre organizações.

Busca, filtragem e exportação

Os fluxos de logs são acessíveis nativamente pelo painel de Organization Settings. Administradores podem consultar a interface usando qualificadores de ação específicos:

# Filtrar logs para identificar quem ajustou privilégios de acesso ao Copilot
action:copilot.cfb_seat_assignment_created

# Identificar mudanças feitas em exclusões sistêmicas dentro de uma janela de datas
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Contas Enterprise suportam o envio direto desses eventos para sistemas externos de SIEM (como Splunk ou Datadog) para alertas automáticos e preservação centralizada e imutável.

Gerenciando assentos do Copilot com a REST API

Provisionar assentos manualmente pelo dashboard funciona para times pequenos, mas não escala em fluxos corporativos de onboarding em alto volume. Usar os endpoints de assentos da REST API do GitHub Copilot permite tratar identidade e acesso totalmente como código.

Esta é uma das minhas partes favoritas da administração do Copilot porque transforma licenciamento em algo que equipes de engenharia podem automatizar de forma limpa.

Principais endpoints da API

Workflows comuns de API incluem:

• Listar assentos atribuídos
• Atribuir assentos
• Remover assentos
• Recuperar métricas de uso
• Ler configurações do Copilot na organização

A autenticação geralmente requer:

• Tokens de acesso pessoal granulares
• Permissões de GitHub App
• Privilégios de admin da organização

Para acessar esses caminhos de gestão, seus scripts de integração devem se autenticar usando um Personal Access Token (PAT) com escopos elevados admin:org ou executar via um GitHub App autorizado com privilégios explícitos de gestão do Copilot em nível organizacional. 

Para se aprofundar em integrações programáticas com a plataforma, recomendo fazer nossa trilha de habilidades GitHub Foundations. 

Padrões comuns de automação

Alguns padrões práticos incluem:

• Onboarding automatizado de identidade: Conectar um sistema de RH (como Workday ou Okta) diretamente ao GitHub via webhooks. Quando um engenheiro entra em um time específico, um script dispara um POST para provisionar automaticamente seu workspace do Copilot.

• Recuperação de assentos inativos: Um script em Cron consulta o uso ativo de assentos via API. Se um usuário não interagiu com o Copilot por mais de 30 dias, o script executa um DELETE para recuperar a licença, preservando o pool de créditos corporativo.

• Dashboards financeiros: Coletar telemetria diária de alocação e consumo para alimentar plataformas internas de BI (como Tableau) e viabilizar rateio claro por centro de custo.

Exemplo: atribuindo um assento do Copilot com Python

O script abaixo demonstra como atribuir programaticamente um assento da organização a um desenvolvedor específico usando Python:

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

Considerações finais

A estrutura de planos do GitHub Copilot parece simples na página de preços. Mas, ao gerenciar times, as diferenças ficam bem mais significativas.

Limites de privacidade, políticas de treinamento, auditabilidade e controles de governança muitas vezes pesam mais do que o acesso bruto a modelos. Por isso, discussões entre GitHub Copilot Business e Enterprise quase sempre viram conversas de segurança e operações — e não só de engenharia.

Se eu fosse aconselhar um time hoje, começaria pelos requisitos de governança:

• Você precisa de garantias contratuais de privacidade?
• Você precisa de logs de auditoria?
• Você precisa de gestão centralizada de políticas?

Depois disso, eu otimizaria por volume de uso e acesso a recursos.

Para aprofundar as capacidades técnicas do seu time e se preparar para certificações oficiais, explore estes caminhos avançados de aprendizado:

• Software Development with GitHub Copilot Course
• AI for Software Engineering Skills Track
• The GitHub Certification Guide for Data Professionals