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 do GitHub.

Em comparação com o GitHub Copilot Business ou Pro+, o Enterprise foca fortemente em governança, contexto organizacional e recursos de mensuração. Ele foi criado para empresas que operam grandes ambientes de engenharia, e não para desenvolvedores individuais ou times pequenos.

Duas capacidades são as mais importantes na prática:

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

Esses dois recursos fazem o Copilot deixar de ser apenas um “autocomplete inteligente” para se aproximar de uma plataforma interna de engenharia com IA.

As empresas que extraem mais valor do GitHub Copilot Enterprise tratam a solução como um componente chave da infraestrutura interna. Elas configuram o contexto organizacional com cuidado, medem a adoção continuamente e ajustam as políticas com base nos 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 amplia a assinatura Business com recursos adicionais, como:

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

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

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 toda a empresa (/enterprises/{enterprise}/…) cobrindo todas as organizações em uma única visualização.

Para quem é o GitHub Copilot Enterprise

O GitHub Copilot Enterprise é voltado para organizações que já operam ambientes GitHub maduros.

Clientes típicos do Enterprise incluem:

• Grandes organizações de engenharia
• Setores regulados
• Grupos de plataforma com vários times
• Empresas com padrões internos de desenvolvimento
• Organizações que exigem governança centralizada

Observe que isso não melhora, por si só, o desempenho do Copilot. Essa distinção é importante porque muitos times compram além do necessário no início. Supõem que Enterprise significa “Copilot melhor”, quando na prática o Enterprise adiciona principalmente ferramentas de governança e mensuração.

Copilot Spaces: contexto personalizado para sua organização

Os Copilot Spaces resolvem uma das maiores limitações dos assistentes de código com IA genéricos.

Pronto para uso, 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 implantação ou documentação de onboarding.

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

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

• “Como estruturamos os handlers de API internamente?”
• “Qual biblioteca de autenticaçã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 uma variedade maior de conteúdo organizacional do que o sistema anterior 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 sobre as 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 enterprise.

O fim do Knowledge Bases

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

Os Spaces substituíram o Knowledge Bases com:

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

Você ainda encontrará documentação e posts desatualizados mencionando Knowledge Bases. Tenha 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 de administração, Copilot Spaces são relativamente simples de criar. O desafio está em gerenciar dezenas ou centenas deles entre os times.

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

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

Configurando um Space

Criar um Space geralmente segue este fluxo:

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

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

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

5. Você pode optar por compartilhar o Space ou definir as configurações de compartilhamento neste estágio

6. Verificar se o Copilot consegue consultar o conteúdo durante as interações no chat

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

Depois da configuração, 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, o problema normalmente é um destes:

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

Compartilhamento e controles de acesso

Os Spaces suportam dois principais modelos de visibilidade:

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

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

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

Um erro comum é o excesso de centralização. Um único Space gigante para toda a empresa pode ficar barulhento e difícil para o Copilot usar de forma eficaz.

Organizando Spaces por time ou domínio

Não existe uma estrutura organizacional “certa” universalmente.

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, na prática, usa as mesmas configurações de forma distinta.

Um Space por time

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

Exemplos:

• Plataforma
• Engenharia de dados
• Desenvolvimento mobile

Um Space por área de produto

Útil para organizações estruturadas por produtos em vez de 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 e padronizados 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 mensuração. Ela substituiu vários sistemas de telemetria mais antigos que o GitHub aposentou durante a consolidação de APIs em 2026. 

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

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 no 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 no IDE
• Uso de modelos
• Interações com agentes
• Distribuição por linguagens

Isso dá às organizações uma visão muito mais detalhada do que simples contagem de assentos.

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

A transição de APIs 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 a transição de 2025 a 2026, concluída em abril de 2026.

Isso incluiu:

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

Os endpoints mais novos 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 antigos e exemplos do GitHub ainda fazem referência a endpoints obsoletos. Sempre verifique a documentação mais recente do GitHub antes de construir automações em torno da Usage Metrics API.

Consultando a Usage Metrics API

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

Autenticação e permissões

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

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

• Para tokens com acesso granular, garanta que você está usando o token de acesso de usuário do app do GitHub ou o token de instalação com a permissão Enterprise Copilot metrics enterprise permissions (read).

Normalmente, usar tokens granulares é preferível, pois reduz a exposição desnecessária de permissões.

Endpoints no nível da 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 é ótimo para monitoramento operacional e análise de tendências de curto prazo. Há histórico disponível desde 10 de outubro de 2025 e pode ser acessado por até um ano a partir da data atual.

O comando curl abaixo chama a API do relatório de um dia e retorna uma resposta JSON com links de download para os relatórios de uso. Você precisa incluir YOUR_TOKEN para a 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 com tempo limitado, ou seja, expiram pouco depois de geradas. Seu fluxo precisa buscar a URL de download e puxar o arquivo imediatamente na mesma execução; não é possível armazenar essas URLs para uso posterior.

A resposta pode conter apenas download_links e report_day, mas este é o schema 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 bem parecidos, 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 semelhante, exceto pela presença de response_start_day e response_end_day.

Estrutura do relatório no nível da organização

Os relatórios JSON para um dia e 28 dias da organização 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, de seus times e de suas tags de time. 

Endpoints no nível do usuário

Relatórios no nível do usuário fornecem visibilidade mais granular da adoção. Isso significa entender, em linhas gerais, como cada pessoa usa o Copilot.

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 por departamento

Essas requisições são muito semelhantes aos relatórios de um dia e 28 dias no nível da organização; 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 user-teams

Também existe um 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; seu propósito é servir como chave de junção quando você quiser agregar dados por usuário no nível de time.

Estrutura do relatório no nível do usuário

O nível de detalhamento nesses relatórios é bem maior, já que apontam 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 no nível do 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 que você pode encontrar, visite the GitHub usage metrics data documentation com as medições mais atualizadas.

Os relatórios no nível do usuário incluem dados de interação via CLI. Se seus times usam o Copilot pela linha de comando, nosso GitHub Copilot CLI Tutorial cobre setup e fluxos comuns.

Construindo um fluxo de relatórios do Copilot

Chamar a API manualmente é útil para experimentação e para entender o schema. Para ser acionável, o ideal é criar um fluxo automatizado.

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

Métricas-chave para provar o ROI

Nem toda métrica do Copilot tem a mesma importância. As mais úteis costumam incluir:

• Crescimento de usuários ativos
• Tendências na taxa de aceitação
• Código sugerido versus retido
• Melhorias no tempo de ciclo de PRs
• 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 de trabalho — e é exatamente por isso que a Usage Metrics API existe. Um time de infraestrutura backend pode interagir com o Copilot de forma diferente de um time de prototipação frontend.

Do dado bruto ao dashboard do time

Um fluxo leve de relatórios costuma ser assim:

1. Chamada de API agendada
2. Armazenar respostas em um banco de dados 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 usando scripts em Python agendados e exports em CSV já pode oferecer visibilidade operacional útil.

Exemplo de arquitetura:

GitHub API

  ↓

Script em Python agendado

 ↓

PostgreSQL / CSV / Planilha

 ↓

Power BI / Tableau / Looker

Considerações finais

O GitHub Copilot Enterprise tem a ver com criar a 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á funcionando.

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

• Curam o contexto interno com cuidado
• Monitoram a adoção continuamente
• Tratam a governança do Copilot com seriedade
• Medem resultados em vez de presumir ganhos de produtividade

Essa mentalidade importa muito mais do que apenas atribuir assentos.

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