GitHub Copilot Enterprise: um guia sobre Spaces e a Usage Metrics API

O que é o GitHub Copilot Enterprise?

O GitHub Copilot Enterprise fica no topo da hierarquia de planos do Copilot no GitHub.

Comparado ao GitHub Copilot Business ou Pro+, o Enterprise foca fortemente em governança, contexto organizacional e capacidades de medição. Ele foi projetado para empresas com ambientes de engenharia de grande porte, e não para desenvolvedores individuais ou times pequenos.

Duas características importam mais na prática:

1. Contexto organizacional personalizado por meio dos Spaces
2. Telemetria em toda a organização com a Usage Metrics API

Esses dois recursos transformam o Copilot de um “autocomplete inteligente” em algo mais próximo de uma plataforma interna de engenharia com IA.

As empresas que mais extraem valor do GitHub Copilot Enterprise tratam a solução como um componente-chave da sua infraestrutura interna. Elas configuram o contexto organizacional com cuidado, medem a adoção continuamente e ajustam políticas com base em dados de uso, não em suposições.

Para uma visão mais ampla do ecossistema do GitHub, recomendo ler nosso guia Introduction to GitHub Products.

Como o Enterprise difere do Business e do Pro+

O GitHub Copilot Enterprise expande a assinatura Business com recursos adicionais, como:

• Métricas de uso no nível da organização
• Controles de governança ampliados
• Herança de políticas em toda a empresa
• Alocações maiores de solicitações premium (1.000 vs 300 no plano Business)
• Acesso e gestão adicionais de modelos

O Enterprise exige o GitHub Enterprise Cloud além da própria assinatura do Copilot Enterprise. Isso acrescenta um custo por usuário, então verifique se sua organização realmente precisa de governança, telemetria e administração em nível corporativo.

Observação: Assinantes do Business acessam a Usage Metrics API no nível da organização (/orgs/{org}/…). Assinantes do Enterprise também acessam relatórios agregados em nível corporativo (/enterprises/{enterprise}/…) que reúnem todas as organizações em uma única visão.

Para quem é o GitHub Copilot Enterprise

O GitHub Copilot Enterprise tem como alvo organizações que já operam ambientes maduros no GitHub.

Clientes típicos do Enterprise incluem:

• Grandes organizações de engenharia
• Setores regulados
• Grupos de platform engineering com múltiplos times
• Empresas com padrões internos de desenvolvimento
• Organizações que exigem governança centralizada

Vale notar que isso não melhora, por si só, a performance do Copilot. Essa distinção é importante porque muitos times acabam comprando acima da necessidade no início. Supõem que Enterprise é igual a “Copilot melhor”, quando, na prática, o Enterprise adiciona principalmente ferramentas de governança e medição.

Copilot Spaces: contexto personalizado para sua organização

Os Copilot Spaces resolvem uma das maiores limitações dos assistentes de codificação com IA de uso geral.

Por padrão, o Copilot entende razoavelmente bem o conhecimento público de programação. Ele não entende automaticamente suas APIs internas, decisões de arquitetura, convenções de código, fluxos de deploy ou documentação de onboarding.

Os Spaces oferecem um contexto organizacional curado que o Copilot pode consultar em conversas e na assistência de código.

Na prática, os Spaces ajudam o Copilot a responder perguntas como:

• “Como estruturamos nossos handlers de API internamente?”
• “Qual biblioteca de autenticação o nosso time de plataforma recomenda?”
• “Qual fluxo de deploy este microsserviço deve usar?”
• “Quais convenções de nomenclatura nosso time de backend segue?”

O que os Spaces suportam

Os Spaces suportam um conjunto mais amplo de conteúdo organizacional do que o antigo sistema de Knowledge Bases.

Tipos de conteúdo compatíveis incluem:

• Arquivos de código
• Documentação em Markdown
• Arquivos JSON
• Arquivos enviados
• Imagens
• GitHub Issues
• Pull requests

Cada tipo de conteúdo contribui de forma diferente.

Arquivos de código ajudam o Copilot a entender padrões de implementação. Arquivos Markdown trazem explicações de arquitetura e orientações de onboarding. Pull requests expõem discussões de review e decisões históricas de engenharia. Essa combinação dá ao Copilot mais consciência das práticas de desenvolvimento da sua organização.

Um ponto sutil, mas importante, é que os Spaces não são simplesmente bancos de vetores anexados ao GitHub. Eles incluem controles de compartilhamento e fluxos de governança organizacional pensados para ambientes corporativos.

O fim do Knowledge Bases

O GitHub encerrou o antigo recurso Copilot Knowledge Bases em 1º de novembro de 2025.

Os Spaces substituíram o Knowledge Bases com:

• Suporte a conteúdo mais amplo
• Melhores controles de compartilhamento
• Administração aprimorada
• Gestão mais flexível no nível da organização

Você ainda vai encontrar documentação desatualizada e posts de blog mencionando Knowledge Bases. Cuidado ao seguir tutoriais antigos, porque muitos endpoints e fluxos mudaram durante o período de transição de 2025 a 2026.

Criando e configurando Copilot Spaces

Do ponto de vista administrativo, criar Copilot Spaces é relativamente simples. O desafio está em gerenciá-los em dezenas ou centenas entre os times.

A estrutura que você define no início tende a permanecer. Já vi organizações criarem sem querer uma “proliferação de documentação” dentro dos Spaces porque ninguém definiu regras de responsabilidade desde o começo.

Qualquer pessoa pode criar um Copilot Space, então vamos testar criando um no seu repositório pessoal. As etapas são parecidas no nível Enterprise, com algumas páginas diferentes.

Configurando um Space

Criar um Space geralmente segue este fluxo:

1. Navegue até a página de Copilot Spaces na área de administração do Enterprise
2. Crie um novo Space

3. Selecione repositórios e fontes de conteúdo, incluindo MCPs e outras ferramentas úteis

4. Adicione fontes clicando no botão “+ Add sources” no lado direito

5. Você pode optar por compartilhar o Space ou já definir as configurações de compartilhamento nesta etapa

6. Verifique se o Copilot consegue consultar o conteúdo durante interações por chat

Um aviso para usuários enterprise: o administrador pode desativar o compartilhamento de Spaces pessoais. Se você estiver usando sua conta própria, isso pode afetar sua capacidade de compartilhar um Copilot Space que não use repositórios da empresa.

Depois da configuração, os administradores devem testar o Space com prompts práticos.

Por exemplo:

How does our authentication middleware handle token refresh logic?

Ou:

Show me an example of how our backend services structure database migrations.

Se o Copilot não conseguir responder com precisão, normalmente o problema é um destes:

• Repositórios faltando
• Qualidade ruim da documentação
• Permissões incorretas
• Tempo de indexação insuficiente

Compartilhamento e controles de acesso

Os Spaces oferecem dois modelos principais de visibilidade:

• Spaces individuais
• Spaces para toda a organização

Membros de uma enterprise podem ter seus spaces individuais gerenciados pelas configurações corporativas mais amplas. Admins do Enterprise também podem gerenciar centralmente políticas de preview e disponibilidade de recursos. 

Spaces privados funcionam bem para times experimentais ou iniciativas internas sensíveis. Spaces da organização fazem sentido para padrões de engenharia, documentação de onboarding ou frameworks usados pela empresa inteira.

Um erro comum que vejo é o excesso de centralização. Um único Space gigante para a empresa inteira pode ficar barulhento e difícil para o Copilot usar com eficácia.

Organizando Spaces por time ou domínio

Não existe uma estrutura organizacional universalmente correta.

Padrões comuns incluem um Space por time, um Space por área de produto ou Spaces compartilhados de padrões. Cada um tem um escopo diferente e basicamente usa as mesmas configurações de forma distinta.

Um Space por time

Útil quando os grupos de engenharia operam de forma relativamente independente.

Exemplos:

• Platform engineering
• Data engineering
• Desenvolvimento mobile

Um Space por área de produto

Útil para organizações estruturadas por produtos e não por departamentos.

Exemplos:

• Pagamentos
• Analytics
• Infraestrutura
• Plataforma do cliente

Space de padrões compartilhados

Muitas organizações mantêm um Space compartilhado separado para:

• Diretrizes de segurança
• Convenções de código
• Fluxos de deploy
• Padrões de arquitetura

Na prática, abordagens híbridas costumam funcionar melhor. Cada time pode ter seu próprio Space, com Spaces maiores de padrões sendo compartilhados entre os times.

A Copilot Usage Metrics API

Os Spaces resolvem o problema de contexto. A Usage Metrics API resolve o problema de medição. Ela substituiu vários sistemas antigos de telemetria que o GitHub aposentou durante a consolidação de APIs em 2026. 

Sem medições claras, as organizações rapidamente perdem visibilidade sobre se a adoção do Copilot está de fato dando certo. A liderança quer evidências de que o investimento melhora o fluxo de trabalho dos desenvolvedores, e não apenas adiciona mais uma assinatura na planilha.

O dashboard chegou a disponibilidade geral em fevereiro de 2026 e pode ser acessado pela sua conta enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics na aba Insights.

Exemplo do Copilot Usage Metrics Dashboard do github.blog

O que a API mede

A Usage Metrics API expõe várias categorias de telemetria operacional.

Métricas comuns incluem:

• Usuários ativos
• Linhas de código sugeridas vs linhas aceitas
• Padrões de uso por IDE
• Uso de modelos
• Interações com agentes
• Distribuição por linguagens

Isso dá às organizações uma visão bem mais rica do que simples contagens de licenças.

Um time com 100 licenças atribuídas, mas apenas 15 usuários ativos, tem um perfil de adoção muito diferente de outro com uso diário consistente e altas taxas de aceitação.

A transição de API em 2026

O GitHub aposentou várias APIs anteriores de telemetria (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) durante o período de transição de 2025 a 2026, com encerramento completo em abril de 2026.

Isso incluiu:

• A antiga Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

Os novos endpoints de Usage Metrics, disponíveis desde fevereiro de 2026, consolidaram esses sistemas de relatórios em um modelo mais unificado, incluindo versionamento dessas APIs em caso de mudanças incompatíveis.

Isso é importante porque muitos posts e exemplos antigos do GitHub ainda fazem referência a endpoints descontinuados. Sempre que for trabalhar com a Usage Metrics API, confira a documentação nas referências mais recentes do GitHub antes de criar automações.

Consultando a Usage Metrics API

Agora que entendemos o propósito da Usage Metrics API, vamos falar de como usá-la na prática.

Autenticação e permissões

Os endpoints da GitHub Copilot Usage Metrics geralmente exigem configurar algumas permissões no seu Personal Access Token (PAT). Isso pode ser feito via PAT clássico ou PAT com escopo granular.

• Para PATs clássicos, você vai precisar que o admin da enterprise conceda as permissões: manage_billing:copilot e read:org. 

• Para tokens de acesso granulares, garanta que está usando o user access token do app do GitHub ou o installation access token com a permissão Enterprise Copilot metrics enterprise permissions (read).

Normalmente, tokens granulares são preferíveis porque reduzem a exposição desnecessária de permissões.

Endpoints em nível de organização

Os dois relatórios mais comuns no nível da organização são:

• organization-1-day

• organization-28-day

Relatório de um dia no nível da organização

O relatório de um dia é ideal para monitoramento operacional e análise de tendências de curto prazo. Há histórico desde 10 de outubro de 2025, acessível por até um ano a partir da data atual.

O comando curl abaixo chama a API de relatório de um dia e retorna uma resposta JSON com links para download dos relatórios de uso. Você deve incluir YOUR_TOKEN na autenticação Bearer e escolher um DAY para o dia específico do relatório no formato YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

As URLs em download_links são assinadas e têm validade limitada, ou seja, expiram pouco depois de geradas. Seu fluxo deve buscar a URL de download e baixar o arquivo imediatamente na mesma execução; não é possível guardar essas URLs para uso posterior.

A resposta pode conter apenas download_links e report_day, mas este é o esquema completo possível:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

Relatório de 28 dias no nível da organização

O relatório de 28 dias ajuda a identificar padrões de adoção mais amplos e mudanças de uso no longo prazo. Os comandos são muito similares, com uma pequena alteração para usar a API de 28 dias.

Exemplo de requisição:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Você receberá uma resposta similar, exceto pela presença de response_start_day e response_end_day.

Estrutura do relatório em nível de organização

Os relatórios JSON, tanto de um dia quanto de 28 dias em nível organizacional, podem se parecer com isto:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Como você pode ver, isso oferece uma visão de alto nível dos usuários dentro de uma organização específica, seus times e as tags desses times. 

Endpoints em nível de usuário

Relatórios no nível do usuário oferecem uma visibilidade mais granular da adoção. Ou seja, dá para entender como cada pessoa usa o Copilot em um nível bem alto.

Endpoints comuns incluem:

• users-1-day

• users-28-day

• user-teams-1-day

Esses relatórios ajudam administradores a identificar:

• Usuários altamente ativos
• Times com baixa adoção
• Oportunidades de treinamento
• Tendências de uso em nível de departamento

Essas requisições são muito parecidas com os relatórios de um dia e 28 dias em nível organizacional; elas apenas apontam para uma API diferente.

Relatório de um dia no nível do usuário

Exemplo de chamada da API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

Relatório de 28 dias no nível do usuário

Exemplo de chamada da API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Relatório de um dia no nível usuário-times

Também existe o endpoint user-teams-1-day, que mapeia cada usuário para suas associações de time. Ele não contém métricas de uso em si; seu objetivo é servir como chave de junção quando você quiser agregar os dados por usuário em nível de time.

Estrutura do relatório em nível de usuário

O nível de detalhe nesses relatórios é muito maior, já que aponta para os dados de uso de um usuário específico:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Essas métricas são mais valiosas como sinais de adoção em nível de time. Taxas de aceitação e contagens de uso são sinais operacionais, não medições de qualidade do desenvolvedor.

Para ver o conjunto completo de métricas possíveis, consulte a documentação de dados de usage metrics do GitHub com as medições mais atualizadas.

Os relatórios em nível de usuário incluem dados de interação via CLI. Se seus times usam o Copilot pela linha de comando, nosso GitHub Copilot CLI Tutorial aborda a configuração e fluxos de trabalho comuns.

Construindo um fluxo de relatórios do Copilot

Chamar a API manualmente é útil para experimentação e para entender o esquema. Para virar ação, é melhor criar um fluxo automatizado.

Os times que mais extraem valor do Copilot Enterprise costumam construir pipelines leves de relatórios que combinam a telemetria de uso com métricas internas de engenharia.

Métricas-chave para provar ROI

Nem toda métrica do Copilot tem o mesmo peso. As mais úteis tendem a incluir:

• Crescimento de usuários ativos
• Tendências na taxa de aceitação
• Código sugerido versus retido
• Melhorias no tempo de ciclo de PR
• Frequência de engajamento no IDE

O GitHub publicou benchmarks como:

• 55% mais rapidez na conclusão de tarefas
• 88% de retenção de código

Esses números mostram ganhos significativos de produtividade. Seus resultados vão variar por time e fluxo, e é exatamente por isso que a Usage Metrics API existe. Um time de backend de infraestrutura pode interagir com o Copilot de forma diferente de um time de frontend focado em prototipação.

Do dado bruto ao dashboard do time

Um fluxo leve de relatórios geralmente segue este desenho:

1. Chamada agendada à API
2. Armazenar respostas em um banco ou planilha
3. Transformar dados em tabelas de relatório
4. Visualizar métricas em uma plataforma de BI existente

A pilha em si importa menos do que a consistência.

Mesmo um fluxo simples com scripts Python agendados e exportações em CSV já oferece uma visibilidade operacional útil.

Arquitetura de exemplo:

GitHub API

  ↓

Script Python agendado

  ↓

PostgreSQL / CSV / Planilha

  ↓

Power BI / Tableau / Looker

Considerações finais

O GitHub Copilot Enterprise é, no fim das contas, sobre preparar sua infraestrutura para um código pronto para IA. Os Spaces fornecem o contexto organizacional que torna o Copilot mais útil em ambientes reais de engenharia. A Usage Metrics API oferece a telemetria necessária para entender se a adoção está avançando.

As organizações que alcançam os melhores resultados com o Copilot Enterprise costumam seguir um padrão:

• Curam o contexto interno com cuidado
• Monitoram a adoção de forma contínua
• Levam a governança do Copilot a sério
• Medem resultados em vez de presumir ganhos de produtividade

Essa mentalidade pesa muito mais do que simplesmente atribuir licenças.

Se você quer aprofundar suas habilidades com Copilot e IA, recomendo o curso Software Development with GitHub Copilot ou a trilha completa AI for Software Engineering.