GitHub Copilot Enterprise: guida a Spaces e Usage Metrics API

Che cos’è GitHub Copilot Enterprise?

GitHub Copilot Enterprise si colloca al vertice della gerarchia dei piani Copilot di GitHub.

Rispetto a GitHub Copilot Business o Pro+, Enterprise punta molto su governance, contesto organizzativo e funzionalità di misurazione. È progettato per aziende con ambienti di engineering su larga scala, più che per singoli sviluppatori o piccoli team.

Due capacità contano soprattutto nella pratica:

1. Contesto organizzativo personalizzato tramite Spaces
2. Telemetria a livello di organizzazione tramite la Usage Metrics API

Queste due funzionalità trasformano Copilot da “autocomplete intelligente” a qualcosa di più simile a una piattaforma di AI engineering interna.

Le aziende che traggono più valore da GitHub Copilot Enterprise lo trattano come un componente chiave dell’infrastruttura interna. Configurano con cura il contesto organizzativo, misurano l’adozione in modo continuo e adattano le policy in base ai dati d’uso invece che alle supposizioni.

Per una panoramica più ampia dell’ecosistema GitHub, ti consiglio di leggere la nostra guida Introduzione ai prodotti GitHub.

In cosa Enterprise differisce da Business e Pro+

GitHub Copilot Enterprise amplia l’abbonamento Business con funzionalità aggiuntive come:

• Metriche d’uso a livello di organizzazione
• Controlli di governance ampliati
• Eredità delle policy a livello enterprise
• Allocazioni maggiori di richieste premium (1.000 vs 300 nel livello Business)
• Accesso e gestione di modelli aggiuntivi

Enterprise richiede GitHub Enterprise Cloud oltre all’abbonamento a Copilot Enterprise. Questo aggiunge un costo per utente, quindi assicurati che la tua organizzazione abbia effettivamente bisogno di governance, telemetria e amministrazione a livello enterprise.

Nota: Gli abbonati a Business accedono alla Usage Metrics API a livello di organizzazione (/orgs/{org}/…). Gli abbonati Enterprise accedono inoltre a report aggregati a livello enterprise (/enterprises/{enterprise}/…) che coprono tutte le organizzazioni in un’unica vista.

A chi è destinato GitHub Copilot Enterprise

GitHub Copilot Enterprise è rivolto a organizzazioni che già operano ambienti GitHub maturi.

Clienti tipo Enterprise includono:

• Grandi organizzazioni di engineering
• Settori regolamentati
• Gruppi di platform engineering multi-team
• Aziende con standard interni di sviluppo
• Organizzazioni che richiedono governance centralizzata

Nota che questo non migliora intrinsecamente le prestazioni di Copilot. Penso che la distinzione sia importante perché molti team inizialmente acquistano in eccesso. Presumono che Enterprise significhi “Copilot migliore”, quando in realtà Enterprise aggiunge soprattutto strumenti di governance e misurazione.

Copilot Spaces: contesto personalizzato per la tua organizzazione

I Copilot Spaces risolvono una delle maggiori debolezze degli assistenti di coding IA generici.

Out-of-the-box, Copilot comprende abbastanza bene la conoscenza pubblica sulla programmazione. Non comprende automaticamente le tue API interne, le decisioni architetturali, le convenzioni di coding, i workflow di deploy o la documentazione di onboarding.

Gli Spaces forniscono un contesto organizzativo curato a cui Copilot può fare riferimento durante le conversazioni e l’assistenza al coding.

In pratica, gli Spaces aiutano Copilot a rispondere a domande come:

• “Come strutturiamo internamente i gestori delle API?”
• “Quale libreria di autenticazione raccomanda il nostro team piattaforma?”
• “Quale workflow di deploy dovrebbe usare questo microservizio?”
• “Quali convenzioni di naming segue il nostro team backend?”

Cosa supportano gli Spaces

Gli Spaces supportano una gamma più ampia di contenuti organizzativi rispetto al vecchio sistema Knowledge Bases.

I tipi di contenuto supportati includono:

• File di codice
• Documentazione Markdown
• File JSON
• File caricati
• Immagini
• GitHub Issues
• Pull request

Ogni tipo di contenuto contribuisce in modo diverso.

I file di codice aiutano Copilot a capire i pattern di implementazione. I file Markdown forniscono spiegazioni architetturali e guide di onboarding. Le pull request espongono discussioni di review e decisioni ingegneristiche storiche. Questa combinazione offre a Copilot una migliore consapevolezza delle pratiche di sviluppo della tua organizzazione.

Un punto sottile ma importante è che gli Spaces non sono semplici database vettoriali collegati a GitHub. Includono controlli di condivisione e workflow di governance organizzativa progettati per ambienti enterprise.

Il tramonto delle Knowledge Bases

GitHub ha dismesso la vecchia funzionalità Copilot Knowledge Bases il 1° novembre 2025.

Gli Spaces hanno sostituito le Knowledge Bases con:

• Supporto a contenuti più ampio
• Migliori controlli di condivisione
• Amministrazione migliorata
• Gestione più flessibile a livello di organizzazione

Troverai ancora documentazione e post obsoleti che fanno riferimento alle Knowledge Bases. Fai attenzione quando segui tutorial datati perché molti endpoint e workflow sono cambiati nel periodo di transizione 2025–2026.

Creare e configurare i Copilot Spaces

Dal punto di vista amministrativo, i Copilot Spaces sono piuttosto semplici da creare. La sfida sta nel gestirne dozzine o centinaia tra i vari team.

La struttura scelta all’inizio tende a rimanere. Ho visto organizzazioni creare involontariamente una “giungla di documentazione” negli Spaces perché nessuno ha definito regole di ownership in partenza.

Chiunque può creare un Copilot Space, quindi proviamo a crearne uno in un nostro repo personale. Questi passaggi sono simili anche a livello Enterprise, con alcune pagine diverse.

Configurare uno Space

La creazione di uno Space in genere segue questo workflow:

1. Vai alla pagina Copilot Spaces nell’area di amministrazione dell’Enterprise
2. Crea un nuovo Space

3. Seleziona repository e fonti di contenuto, inclusi MCP e altri strumenti utili

4. L’aggiunta delle fonti si fa cliccando il pulsante “+ Add sources” sul lato destro

5. Puoi scegliere di condividere lo space o impostare le impostazioni di condivisione in questa fase

6. Verifica che Copilot possa fare riferimento ai contenuti durante le chat

Una nota per gli utenti enterprise: l’amministratore può disattivare la condivisione degli Spaces personali. Quindi se usi il tuo account, questo può influire sulla possibilità di condividere uno Space Copilot che non utilizza i repository dell’enterprise.

Dopo la configurazione, gli amministratori dovrebbero testare lo Space con prompt pratici.

Per esempio:

How does our authentication middleware handle token refresh logic?

Oppure:

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

Se Copilot non riesce a rispondere correttamente, di solito il problema è uno tra:

• Repository mancanti
• Documentazione di scarsa qualità
• Permessi non corretti
• Tempo di indicizzazione insufficiente

Condivisione e controlli di accesso

Gli Spaces supportano due principali modelli di visibilità:

• Spaces individuali
• Spaces a livello di organizzazione

I membri di un’enterprise possono avere i propri spazi individuali gestiti dalle impostazioni enterprise più ampie. Gli admin enterprise possono anche gestire centralmente le policy di anteprima e disponibilità delle funzionalità. 

Gli Spaces privati funzionano bene per team sperimentali o iniziative interne sensibili. Gli Spaces a livello di organizzazione hanno senso per standard di engineering, documentazione di onboarding o framework aziendali.

Un errore che vedo spesso è l’eccessiva centralizzazione. Un unico Space aziendale enorme può diventare rumoroso e difficile da usare in modo efficace per Copilot.

Organizzare gli Spaces per team o dominio

Non esiste una struttura organizzativa universalmente corretta.

Pattern comuni includono uno space per team, uno per area di prodotto o spazi di standard condivisi. Ciascuno ha uno scope diverso e usa sostanzialmente le stesse impostazioni in modo differente.

Uno Space per team

Utile quando i gruppi di engineering operano in modo relativamente indipendente.

Esempi:

• Platform engineering
• Data engineering
• Sviluppo mobile

Uno Space per area di prodotto

Utile per organizzazioni strutturate attorno ai prodotti piuttosto che ai reparti.

Esempi:

• Pagamenti
• Analytics
• Infrastruttura
• Piattaforma clienti

Space di standard condivisi

Molte organizzazioni mantengono uno Space condiviso separato per:

• Linee guida di sicurezza
• Convenzioni di coding
• Workflow di deploy
• Standard architetturali

In pratica, gli approcci ibridi funzionano di solito meglio. Ogni team può avere il proprio space, con spazi più ampi di standard condivisi tra i team.

La Copilot Usage Metrics API

Gli Spaces risolvono il problema del contesto. La Usage Metrics API risolve il problema della misurazione. Ha sostituito diversi vecchi sistemi di telemetria che GitHub ha ritirato durante la razionalizzazione delle API nel 2026. 

Senza misurazioni chiare, le organizzazioni perdono rapidamente visibilità sul fatto che l’adozione di Copilot stia avendo successo. La leadership vuole prove che l’investimento migliori i workflow degli sviluppatori, invece di aggiungere semplicemente un’altra voce di abbonamento.

La dashboard è giunta alla disponibilità generale a febbraio 2026 ed è accessibile tramite il tuo account enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics nella scheda Insights.

Esempio di Copilot Usage Metrics Dashboard da github.blog

Cosa misura l’API

La Usage Metrics API espone diverse categorie di telemetria operativa.

Metriche comuni includono:

• Utenti attivi
• Righe di codice suggerite vs righe accettate
• Pattern di utilizzo degli IDE
• Uso dei modelli
• Interazioni con gli agent
• Ripartizione per linguaggi

Questo offre alle organizzazioni un quadro molto più sfumato rispetto ai semplici conteggi delle licenze.

Un team con 100 licenze assegnate ma solo 15 utenti attivi ha un profilo di adozione molto diverso da uno con uso quotidiano costante e alti tassi di accettazione.

La transizione delle API nel 2026

GitHub ha ritirato diverse API di telemetria precedenti (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) nel periodo di transizione 2025–2026, con sunset completo ad aprile 2026.

Queste includevano:

• La vecchia Metrics API
• Le Feature Engagement API
• Le Direct Data Access API

I nuovi endpoint Usage Metrics, disponibili da febbraio 2026, hanno consolidato quei sistemi di reportistica in un modello più unificato, includendo il versionamento delle API in caso di breaking changes.

Questo è importante perché molti post e esempi GitHub più vecchi fanno ancora riferimento a endpoint deprecati. Quando lavori con la Usage Metrics API, verifica sempre la documentazione con i riferimenti API più recenti di GitHub prima di costruire automazioni.

Interrogare la Usage Metrics API

Ora che abbiamo capito lo scopo della usage metrics API, vediamo come usarla in pratica.

Autenticazione e permessi

Gli endpoint della GitHub Copilot Usage Metrics richiedono in genere di configurare alcuni permessi per il tuo Personal Access Token (PAT). Questo può essere fatto sia tramite PAT classico che PAT con accesso granulare.

• Per i PAT classici, avrai bisogno che il tuo admin enterprise ti fornisca i seguenti permessi: manage_billing:copilot e read:org. 

• Per i token con accesso granulare, devi assicurarti di usare il token di accesso utente dell’app GitHub o il token di installazione con il set di permessi Enterprise Copilot metrics enterprise permissions (read).

Di norma, è preferibile usare token granulari perché riducono l’esposizione di permessi non necessari.

Endpoint a livello di organizzazione

I due report più comuni a livello di organizzazione sono:

• organization-1-day

• organization-28-day

Report di un giorno a livello organizzazione

Il report di un giorno è utile per il monitoraggio operativo e l’analisi di trend a breve termine. I dati storici sono disponibili a partire dal 10 ottobre 2025 e accessibili fino a un anno dalla data corrente.

Il comando curl seguente chiama l’API del report di un giorno e restituisce una risposta JSON con link per scaricare i report d’uso. Assicurati di includere YOUR_TOKEN per la bearer auth e di scegliere un DAY per il giorno specifico del report in 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"

Gli URL in download_links sono firmati e a tempo, quindi scadono poco dopo il recupero. Il tuo workflow deve ottenere l’URL di download e scaricare subito il file nella stessa esecuzione; non puoi conservare questi URL per usi successivi.

La risposta che ricevi potrebbe contenere solo download_links e report_day, ma questo è lo schema potenziale completo:

{
  "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"
  ]
}

Report di 28 giorni a livello organizzazione

Il report di 28 giorni aiuta a identificare pattern di adozione più ampi e cambiamenti d’uso di lungo periodo. I comandi sono molto simili, con una piccola modifica per usare l’API dei 28 giorni.

Richiesta di esempio:

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

Riceverai una risposta simile, tranne che con un response_start_day e un response_end_day.

Struttura dei report a livello organizzazione

I report JSON sia per il singolo giorno che per i 28 giorni a livello organizzativo potrebbero apparire così:

[
  {
    "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"
  }
]

Come puoi vedere, questo offre una panoramica ad alto livello degli utenti all’interno di una determinata organizzazione, del loro team e dei relativi tag di team. 

Endpoint a livello utente

I report a livello utente forniscono una visibilità più granulare dell’adozione. Significa che puoi capire come i singoli utilizzano Copilot a un livello molto alto.

Endpoint comuni includono:

• users-1-day

• users-28-day

• user-teams-1-day

Questi report aiutano gli amministratori a identificare:

• Utenti molto attivi
• Team a bassa adozione
• Opportunità di formazione
• Trend d’uso a livello di reparto

Queste richieste sono molto simili ai report di 1 e 28 giorni a livello di organizzazione; puntano semplicemente a un’API diversa.

Report di un giorno a livello utente

Esempio di chiamata 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"

Report di 28 giorni a livello utente

Esempio di chiamata 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

Report di un giorno a livello user-teams

Esiste anche un endpoint user-teams-1-day, che mappa ciascun utente alle sue appartenenze ai team. Non contiene metriche d’uso di per sé; il suo scopo è fungere da chiave di join quando vuoi aggregare i dati per utente per team.

Struttura dei report a livello utente

Il livello di dettaglio in questi report è molto più alto, dato che puntano ai dati d’uso di un singolo utente:

[{
  "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
}]

Queste metriche sono più preziose come segnali di adozione a livello di team. Tassi di accettazione e conteggi d’uso sono segnali operativi, non misure della qualità degli sviluppatori.

Per l’elenco completo delle potenziali metriche che potresti vedere, visita the documentazione dei dati sulle usage metrics di GitHub per le metriche misurate più aggiornate.

I report a livello utente includono dati sulle interazioni da CLI. Se i tuoi team usano Copilot da riga di comando, il nostro Tutorial su GitHub Copilot CLI copre l’impostazione e i workflow più comuni.

Creare un workflow di reportistica per Copilot

Chiamare l’API manualmente è utile per sperimentare e comprendere lo schema. Per essere davvero utile, è meglio creare un workflow automatizzato.

I team che traggono più valore da Copilot Enterprise in genere costruiscono pipeline di report leggere che combinano la telemetria d’uso con metriche interne di engineering.

Metriche chiave per dimostrare l’ROI

Non tutte le metriche di Copilot contano allo stesso modo. Le più utili tendono a includere:

• Crescita degli utenti attivi
• Trend dei tassi di accettazione
• Codice suggerito vs codice mantenuto
• Miglioramenti del ciclo di vita delle PR
• Frequenza di utilizzo dell’IDE

GitHub ha pubblicato benchmark come:

• 55% di completamento attività più veloce
• 88% di tasso di mantenimento del codice

Questi numeri mostrano miglioramenti significativi di produttività. I tuoi risultati varieranno in base al team e al workflow, ed è proprio per questo che esiste la Usage Metrics API. Un team di backend infrastrutturale può interagire con Copilot in modo diverso da un team frontend di prototipazione.

Dai dati grezzi a una dashboard di team

Un workflow di reportistica leggero spesso ha questo aspetto:

1. Chiamata API schedulata
2. Archiviazione delle risposte in un database o foglio di calcolo
3. Trasformazione dei dati in tabelle di report
4. Visualizzazione delle metriche in una piattaforma BI esistente

Lo stack in sé conta meno della costanza.

Anche un workflow semplice con script Python schedulati ed export CSV può fornire una visibilità operativa utile.

Architettura di esempio:

GitHub API

  ↓

Script Python schedulato

 ↓

PostgreSQL / CSV / Foglio di calcolo

 ↓

Power BI / Tableau / Looker

Considerazioni finali

GitHub Copilot Enterprise serve davvero a costruire un’infrastruttura pronta per il codice con IA. Gli Spaces forniscono il contesto organizzativo che rende Copilot più utile negli ambienti di engineering reali. La Usage Metrics API fornisce la telemetria necessaria per capire se l’adozione sta avendo successo.

Le organizzazioni che ottengono i risultati più forti con Copilot Enterprise tendono a condividere un pattern comune:

• Curano attentamente il contesto interno
• Monitorano l’adozione in modo continuo
• Prendono sul serio la governance di Copilot
• Misurano i risultati invece di dare per scontati i guadagni di produttività

Questo mindset conta molto più del semplice assegnare le licenze.

Se vuoi approfondire le tue competenze su Copilot e l’IA, ti consiglio il nostro corso Sviluppo software con GitHub Copilot o l’intero percorso di competenze AI per il software engineering.