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 di Copilot di GitHub.

Rispetto a GitHub Copilot Business o Pro+, Enterprise punta molto su governance, contesto organizzativo e funzionalità di misurazione. È progettato per aziende che operano in ambienti di ingegneria di grandi dimensioni, piuttosto che per singoli sviluppatori o piccoli team.

Due caratteristiche contano di più nella pratica:

1. Contesto organizzativo personalizzato tramite gli 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 interna di AI per l’ingegneria.

Le aziende che traggono il massimo valore da GitHub Copilot Enterprise lo trattano come un componente chiave dell’infrastruttura interna. Configurano attentamente il contesto organizzativo, misurano l’adozione in modo continuo e adattano le policy in base ai dati di utilizzo, non alle supposizioni.

Per una panoramica più ampia dell’ecosistema GitHub, ti consiglio di leggere la nostra guida Introduction to GitHub Products.

In cosa Enterprise differisce da Business e Pro+

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

• Metriche di utilizzo a livello di organizzazione
• Controlli di governance estesi
• Ereditarietà delle policy a livello enterprise
• Allocazioni maggiori di richieste premium (1.000 vs 300 nel livello Business)
• Accesso e gestione aggiuntivi dei modelli

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

Nota: Gli abbonati 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 si rivolge a organizzazioni che già operano ambienti GitHub maturi.

Clienti Enterprise tipici includono:

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

Nota che questo non migliora intrinsecamente le prestazioni di Copilot. Questa distinzione è importante perché molti team all’inizio acquistano più del necessario. 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 AI generalisti.

Out of the box, Copilot comprende abbastanza bene la conoscenza pubblica di programmazione. Non comprende automaticamente le tue API interne, le decisioni architetturali, le convenzioni di coding, i flussi di deployment 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 codice.

In termini pratici, gli Spaces aiutano Copilot a rispondere a domande come:

• “Come strutturiamo internamente gli handler delle API?”
• “Quale libreria di autenticazione raccomanda il nostro team di piattaforma?”
• “Quale workflow di deployment 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 di 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 comprendere i pattern di implementazione. I file Markdown forniscono spiegazioni architetturali e guide di onboarding. Le pull request mostrano discussioni di review e decisioni ingegneristiche storiche. Questa combinazione offre a Copilot una migliore consapevolezza delle pratiche di sviluppo della tua organizzazione.

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

La dismissione delle Knowledge Bases

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

Gli Spaces hanno sostituito le Knowledge Bases con:

• Supporto di contenuti più ampio
• Controlli di condivisione migliori
• Amministrazione migliorata
• Gestione più flessibile a livello di organizzazione

Troverai ancora documentazione e post datati che fanno riferimento alle Knowledge Bases. Fai attenzione quando segui tutorial più vecchi, perché molti endpoint e workflow sono cambiati durante il periodo di transizione 2025-2026.

Creazione e configurazione dei Copilot Spaces

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

La struttura che scegli all’inizio tende a restare. Ho visto organizzazioni creare involontariamente uno “sprawl documentale” dentro gli Spaces perché nessuno aveva stabilito regole di ownership fin dall’inizio.

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

Configurare uno Space

La creazione di uno Space in genere segue questo flusso:

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

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

4. L’aggiunta delle fonti può essere effettuata cliccando il pulsante “+ Add sources” sul lato destro

5. Puoi scegliere di condividere lo space o impostare i permessi di condivisione in questa fase

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

Nota per gli utenti enterprise: l’amministratore può disattivare la condivisione degli Spaces personali. Quindi, se stai usando 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 con precisione, di solito il problema è uno dei seguenti:

• 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 ingegneria, documentazione di onboarding o framework aziendali condivisi.

Un errore che vedo spesso è l’eccessiva centralizzazione. Un singolo, gigantesco Space aziendale può diventare rumoroso e difficile da usare efficacemente per Copilot.

Organizzare gli Spaces per team o dominio

Non esiste una struttura organizzativa universalmente corretta.

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

Uno Space per team

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

Esempi:

• Platform engineering
• Data engineering
• Sviluppo mobile

Uno Space per area di prodotto

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

Esempi:

• Pagamenti
• Analytics
• Infrastruttura
• Piattaforma clienti

Space condiviso per gli standard

Molte organizzazioni mantengono uno Space condiviso separato per:

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

In pratica, gli approcci ibridi funzionano di solito meglio. Ogni team può avere il proprio space, con spazi più ampi per gli 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 sistemi di telemetria più vecchi che GitHub ha ritirato durante la razionalizzazione delle API del 2026. 

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

La dashboard è passata 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.

Le metriche comuni includono:

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

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

Un team con 100 licenze assegnate ma solo 15 utenti attivi ha un profilo di adozione molto diverso rispetto a un team con utilizzo 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) durante il periodo di transizione 2025-2026, con dismissione completa entro 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 reporting in un modello più unificato, includendo il versionamento delle API in caso di breaking changes.

Questo è importante perché molti post e esempi su 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 compreso lo scopo della usage metrics API, vediamo come usarla in pratica.

Autenticazione e permessi

Gli endpoint di GitHub Copilot Usage Metrics in genere richiedono di impostare alcuni permessi per il tuo Personal Access Token (PAT). Questo può essere fatto tramite PAT classico o PAT con granularità fine.

• Per i PAT classici, devi farti fornire dall’amministratore enterprise i seguenti permessi: manage_billing:copilot e read:org. 

• Per i token a granularità fine, 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).

In genere si preferiscono i token con granularità fine perché riducono l’esposizione a 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 di organizzazione

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

Il comando curl seguente chiama l’API dei report giornalieri e restituisce una risposta JSON con i link per scaricare i report di utilizzo. Assicurati di includere YOUR_TOKEN per l’autenticazione Bearer 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, il che significa che scadono poco dopo il recupero. Il tuo workflow deve recuperare l’URL di download e scaricare subito il file nella stessa esecuzione; non puoi conservare questi URL per un uso successivo.

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 di organizzazione

Il report di 28 giorni aiuta a individuare pattern di adozione più ampi e cambiamenti d’uso a lungo termine. 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

Otterrai una risposta simile, tranne che con response_start_day e response_end_day.

Struttura dei report a livello di organizzazione

I report JSON sia per il report di un giorno che per quello di 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 vedi, questo ti fornisce una panoramica di alto livello degli utenti all’interno di una determinata organizzazione, del loro team e dei tag del team. 

Endpoint a livello utente

I report a livello utente offrono una visibilità più granulare sull’adozione. Ciò 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 con bassa adozione
• Opportunità di formazione
• Trend di utilizzo a livello di reparto

Queste richieste sono molto simili ai report di un giorno e 28 giorni a livello organizzativo; 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 ogni utente alle sue membership di team. Non contiene metriche d’uso in 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 si riferiscono ai dati d’uso di un particolare 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. I tassi di accettazione e i conteggi di utilizzo sono segnali operativi, non misure della qualità degli sviluppatori.

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

I report a livello utente includono dati di interazione via CLI. Se i tuoi team usano Copilot tramite riga di comando, il nostro GitHub Copilot CLI Tutorial copre l’installazione e i workflow comuni.

Costruire un workflow di reporting 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 ricavano il massimo valore da Copilot Enterprise in genere costruiscono pipeline di reporting leggere che combinano la telemetria d’uso con metriche ingegneristiche interne.

Metriche chiave per dimostrare l’ROI

Non tutte le metriche di Copilot hanno la stessa importanza. Le più utili tendono a includere:

• Crescita degli utenti attivi
• Trend dei tassi di accettazione
• Codice suggerito rispetto a quello mantenuto
• Miglioramenti del cycle time delle PR
• Frequenza di utilizzo dell’IDE

GitHub ha pubblicato benchmark come:

• 55% di completamento dei task più veloce
• 88% di tasso di mantenimento del codice

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

Dai dati grezzi a una dashboard di team

Un workflow di reporting leggero spesso assomiglia a questo:

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

Lo stack in sé conta meno della costanza.

Anche un workflow semplice con script Python pianificati ed esportazioni CSV può offrire una visibilità operativa utile.

Architettura di esempio:

GitHub API

  ↓

Script Python pianificato

  ↓

PostgreSQL / CSV / Foglio di calcolo

 ↓

Power BI / Tableau / Looker

Considerazioni finali

GitHub Copilot Enterprise riguarda davvero la costruzione della tua infrastruttura per un codice pronto all’AI. Gli Spaces forniscono il contesto organizzativo che rende Copilot più utile negli ambienti di ingegneria reali. La Usage Metrics API fornisce la telemetria necessaria per capire se l’adozione sta avendo successo.

Le organizzazioni che ottengono i risultati migliori con Copilot Enterprise tendono a condividere uno schema comune:

• Curano con attenzione il contesto interno
• Monitorano l’adozione in modo continuo
• Prendono sul serio la governance di Copilot
• Misurano i risultati invece di presumere guadagni di produttività

Questo mindset conta molto più del semplice assegnare licenze.

Se vuoi approfondire le tue competenze su Copilot e l’AI, ti consiglio il nostro corso Software Development with GitHub Copilot o l’intero percorso AI for Software Engineering.