Piani GitHub Copilot: guida completa a funzionalità e amministrazione tra i vari livelli

Piani GitHub Copilot in sintesi

GitHub offre diversi livelli distinti per il suo ecosistema. In particolare, la piattaforma completerà il rollout della fatturazione basata sull’uso, sostituendo il vecchio framework "Premium Request Unit" (PRU) con i GitHub AI Credits a giugno 2026.

Nel nuovo sistema, i completamenti di codice di base e i suggerimenti “Next Edit” restano illimitati e non consumano crediti. 

Tuttavia, operazioni avanzate come chat multi-file, workflow agentici, sessioni di coding di lunga durata e revisioni del codice approfondite consumeranno AI Credits in base al consumo di token (input, output e token in cache) rispetto alle tariffe API pubblicate per lo specifico modello. 

I prezzi base dell’abbonamento mensile sono rimasti invariati, ma il cambiamento altera il modo in cui gli amministratori pianificano gli extra e monitorano l’utilizzo attivo.

Piani individuali: Free, Student, Pro e Pro+

I livelli individuali differiscono per soglie di accesso ai modelli, limiti d’uso e funzionalità sperimentali. Ad esempio, mentre il livello Free consente un’esplorazione di base, Pro+ offre accesso a GitHub Spark, un ambiente pensato per creare applicazioni con assistenza AI.

Attualmente, le nuove registrazioni per gli account a pagamento individuali di GitHub, come Pro, Pro+ e Student, sono sospese. Gli account esistenti possono passare da Pro a Pro+, ma i nuovi account non possono iscriversi finché GitHub non completa la transizione al nuovo sistema di fatturazione a AI Credits basata sull’uso.

Business ed Enterprise

Con Business ed Enterprise, i piani GitHub Copilot passano da un’estensione IDE a una risorsa infrastrutturale enterprise completamente verificabile.

GitHub Copilot Business introduce funzionalità di gestione essenziali:

• Assegnazione e revoca centralizzate dei posti.
• Baseline di policy a livello di organizzazione.
• Log di audit strutturali e tracciamento degli eventi di conformità.
• Esclusioni di contenuti e file del repository.
• Indennizzo commerciale della proprietà intellettuale.

GitHub Copilot Enterprise aggiunge ancora più controllo e funzionalità:

• Copilot Spaces: un hub della conoscenza che consente agli sviluppatori di interrogare Copilot sulla documentazione interna, wiki e standard di codice sistemici.
• Integrazione potenziata con la Chat su GitHub.com.
• Ereditarietà gerarchica delle policy tra organizzazioni figlie.

GitHub Copilot Enterprise richiede un abbonamento attivo a GitHub Enterprise Cloud. Poiché GitHub Enterprise Cloud costa 21 $ per utente al mese e la licenza Copilot Enterprise costa 39 $ per utente al mese, il costo minimo effettivo è di 60 $ per utente al mese per Enterprise. Questo non si applica al livello GitHub Copilot Business, che può essere acquistato nativamente dalle organizzazioni che usano i piani GitHub Free o GitHub Team.

Le organizzazioni rinunciano ai benefici a livello enterprise come l’ereditarietà delle policy, ma ottengono comunque indennizzo IP, auditing, esclusione dei file e gestione delle policy organizzative: è quindi una buona alternativa per team di ingegneria di medie dimensioni.

Se stai valutando un abbonamento Enterprise, la nostra guida GitHub Copilot Enterprise ti mostrerà come usare funzionalità come Copilot Spaces e la nuova Usage Metrics API.

Cosa distingue i piani individuali da quelli Business

Gestione dei dati, indennizzo IP e fatturazione sono le aree principali in cui i piani individuali e business differiscono molto. Sebbene le funzionalità aggiuntive per gli utenti siano utili, comprendere queste differenze è fondamentale per chi deve scegliere tra gestire un pacchetto di licenze Pro personali e un abbonamento Business.

Gestione dei dati e impostazioni di default per l’addestramento

Per i team che gestiscono sistemi proprietari, la privacy dei dati è di solito il fattore decisivo tra piani personali e abbonamenti Business.

Ad aprile 2026, GitHub ha cambiato il funzionamento della raccolta dei dati di interazione per i piani individuali di Copilot. Per gli utenti Free, Pro e Pro+, i dati di interazione possono ora essere usati per l’addestramento dei modelli per impostazione predefinita, a meno che l’utente non effettui esplicitamente l’opt-out.

Assicuriamoci di comprendere la distinzione tra codice a riposo e dati di interazione, così da sapere cosa viene usato per l’addestramento AI:

• Codice a riposo: Il codice grezzo presente nel tuo repository privato non viene letto o inserito in set di addestramento pubblici.
• Dati di interazione: Includono prompt, query in chat, contesto del cursore, blocchi di codice circostanti inviati tramite l’API dell’IDE durante le sessioni di modifica attive, metriche di accettazione dei suggerimenti e log di feedback.

I contratti Business ed Enterprise garantiscono in modo rigoroso che i dati di interazione non vengano mai usati per l’addestramento in nessuna circostanza. Non è richiesta alcuna azione manuale da parte dell’utente.

Per uno sguardo più approfondito su come vengono usati i dati e su come risolvere i problemi in Copilot, ti consiglio di leggere la nostra guida GitHub Copilot: privacy e troubleshooting.

Indennizzo IP

GitHub Copilot Business ed Enterprise includono copertura di indennizzo per la proprietà intellettuale (IP) sul codice generato. I piani individuali no.

In pratica, l’indennizzo significa che GitHub accetta contrattualmente di fornire tutela legale in circostanze specificate se il codice generato crea controversie di proprietà intellettuale. Questo non elimina ogni rischio legale, ma cambia la conversazione sulla responsabilità per i team che sviluppano software commerciale.

Un freelance che consegna codice ai clienti dovrebbe farci attenzione. La differenza tra “strumento di produttività personale” e “piattaforma di sviluppo supportata dall’organizzazione” diventa molto concreta quando entrano in gioco contratti e consegne commerciali.

Fatturazione, posti e passaggio agli AI Credits

La fatturazione individuale usa metodi self-service collegati direttamente agli account personali. I piani Business centralizzano la fatturazione con posti assegnati dagli amministratori. Inoltre, invece che gli utenti interagiscano con bucket di crediti indipendenti, l’organizzazione mette in comune i propri AI Credits mensili in base al numero di utenti.

I piani Enterprise offrono un controllo ancora più preciso con limiti granulari di enforcement del budget, raggruppamento per centri di costo e allocazioni a livello di dipartimento, per garantire che i workflow agentici intensivi di un singolo team di sviluppo non esauriscano l’intera dotazione di crediti aziendali.

SKU e considerazioni sulla privacy

Comprendere le varie protezioni per la privacy dei dati e le SKU è importante. I confini architetturali che regolano il flusso dei dati, le tutele legali e il tracciamento nei vari livelli sono riassunti di seguito:

Modifiche alle policy di addestramento di aprile 2026

Il passaggio da un modello opt-in a uno opt-out per i piani individuali enfatizza un vettore primario di possibili fughe di conformità. Il payload di dati di interazione catturato automaticamente durante una sessione IDE attiva include:

• Storici dettagliati della chat e contesto dei prompt.
• Suggerimenti di codice multi-linea e tassi locali di accettazione.
• Contesto del cursore nell’editor, che spesso include contesto dei file adiacenti, istruzioni di import e dichiarazioni di variabili dalle schede aperte.

Immagina che uno sviluppatore usi un account personale Copilot Pro mentre lavora in un repository aziendale. Se l’addestramento rimane abilitato, i dati di interazione legati a quella sessione di lavoro potrebbero entrare nell’ecosistema di addestramento di GitHub. Questo scenario è un motivo comune per cui le organizzazioni adottano i piani Business.

Scegliere la SKU giusta per i tuoi requisiti di privacy

A seconda del livello di lavoro, potresti aver bisogno di SKU diverse. 

• Sviluppatore singolo/progetti personali: i livelli Free o Pro offrono massima flessibilità. Effettua semplicemente l’opt-out nelle impostazioni di privacy personali se lavori su codice proprietario.
• Freelance/contractor: il piano Business offre una barriera difensiva. Gli accordi con i clienti spesso vietano esplicitamente la trasmissione di dati a fornitori LLM esterni; un posto dedicato nell’organizzazione tutela i tuoi contratti.
• Team aziendali con mandati di conformità: il livello Business rappresenta la base standard, garantendo isolamento delle pipeline di dati e abilitando la governance amministrativa.
• Settori regolamentati (finanza, sanità): in genere è obbligatorio il livello Enterprise, che consente integrazione con configurazioni di sicurezza specializzate, rigorosi requisiti di residenza dei dati e livelli di fine-tuning localizzati.

Escludere file specifici da Copilot

Implementare set di regole di esclusione dei file in GitHub Copilot è uno dei modi più efficaci per proteggere difensivamente un ambiente. L’esclusione dei contenuti impedisce all’agente IDE locale di elaborare i contenuti di file specifici, rendendoli completamente invisibili a completamenti inline, finestre di chat e operazioni agentiche in background. 

Nota che la GitHub Copilot CLI, l’agente cloud di Copilot e la modalità Agent in Copilot Chat negli IDE non supportano l’esclusione dei contenuti.

Configurare le regole di esclusione

I team amministrativi possono applicare configurazioni di esclusione sia nel pannello globale delle Impostazioni dell’organizzazione sia nelle impostazioni dei singoli repository mirati. Basta entrare nelle impostazioni del repository o dell’organizzazione cliccando sul pulsante Settings in alto a destra.

Scegli “Code and automation” nelle impostazioni di Copilot nella sidebar. Quindi compila le esclusioni nel riquadro “Paths to exclude in this repository” in questo modo:

# 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/**"

Il livello a repository nell’organizzazione è simile, tranne che l’impostazione sarà sotto “Repositories and Paths to exclude” usando il seguente formato:

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

Mantenere il REPOSITORY-REFERENCE è importante come parte delle impostazioni. Le baseline di configurazione comuni dovrebbero dare priorità a credenziali hard-coded, profili di orchestrazione di produzione, moduli algoritmici proprietari sensibili o cartelle con normative stringenti.

Come si applicano le esclusioni nelle funzionalità di Copilot

Quando si verifica una corrispondenza di esclusione, l’isolamento dei dati è assoluto in tutti i sottosistemi di Copilot:

• Completamenti inline: impossibile generare contesto all’interno del file o trarre contesto da esso per popolare file adiacenti.
• Chat/agent di Copilot: il sistema restituisce un avviso che indica che il file non può essere revisionato a causa di restrizioni di policy organizzative.

I motori IDE locali standard funzionano allo stesso modo. Strumenti di qualità della vita come parsing del testo, evidenziazione della sintassi interna e IntelliSense localizzato compilano normalmente perché il livello di esclusione dei file si applica esplicitamente ai flussi di telemetria esterni di Copilot. 

Gli amministratori devono testare accuratamente i pattern dei percorsi usando repository di staging; wildcard mal formate possono fallire in modalità aperta, esponendo dati che intendevi isolare.

Gestione delle policy a livello di organizzazione

Applicare la gestione delle policy di GitHub Copilot a livello di organizzazione garantisce che la sicurezza aziendale sia determinata dal team di amministrazione e non dalle preferenze dei singoli sviluppatori.

Impostazioni di policy disponibili

Le organizzazioni possono controllare diverse impostazioni per gli sviluppatori:

• Feature toggle: attiva o disattiva globalmente Copilot Chat negli ambienti di sviluppo, nelle interfacce a riga di comando (tramite Copilot CLI) o nei sistemi avanzati di code review agentici.
• Filtro del codice pubblico: un meccanismo legale che impedisce a Copilot di restituire suggerimenti di codice che corrispondono strettamente a repository open-source pubblici su GitHub, riducendo i rischi di conformità alle licenze open-source.
• Restrizioni sulla scelta del modello: limita quali modelli (ad es. specifiche varianti GPT o Claude) gli sviluppatori possono selezionare, consentendoti di gestire latenza, consumo di crediti e performance. Per uno sguardo da vicino ai modelli disponibili tramite la piattaforma di GitHub, vedi questa guida pratica a GitHub Models.
• Istruzioni personalizzate dell’organizzazione: inserisci file di policy in markdown standard che aggiungono pattern di coding aziendali, framework di sicurezza e paradigmi architetturali a ogni prompt inviato dai tuoi sviluppatori.

Se il tuo team ha meno familiarità con il modello di organizzazione e permessi di GitHub, il corso Intermediate GitHub Concepts fornisce un utile background. Per i gruppi di ingegneria che si espandono sugli strumenti da riga di comando, vedi il nostro Tutorial su GitHub Copilot CLI.

Ereditarietà delle policy a livello Enterprise

Nei contesti aziendali su larga scala, il motore delle policy segue una rigorosa cascata gerarchica di ereditarietà: Policy Enterprise > Policy di organizzazione > Preferenze utente

Gli amministratori Enterprise possono scegliere di bloccare globalmente le policy in tutte le unità di business più piccole, come i team, consentire override selettivi a livello di organizzazione o delegare completamente il controllo lungo la gerarchia. Ad esempio, l’azienda può impostare configurazioni globali per limitare l’uso di specifici modelli.

A livello di team, potrebbe limitare la divisione dei servizi finanziari a filtri rigorosi sul codice pubblico, consentendo invece a un reparto R&D software interno una sperimentazione più flessibile.

Log di audit

Quando gli auditor di conformità richiedono una verifica della tua supply chain software o i team di sicurezza rintracciano una fuga di dati, GitHub Copilot registra le modifiche alla piattaforma.

Eventi di Copilot nel log di audit

Il sistema registra un resoconto completo delle operazioni di gestione, tracciando:

• Assegnazioni esplicite di posti, revoche e modifiche ai gruppi di fatturazione.
• Modifiche al filtro di duplicazione del codice pubblico.
• Alterazioni dei pattern di esclusione di file e directory.
• Stati di abilitazione delle funzionalità (ad es. attivazione delle modalità di code review agentiche)

La granularità dipende interamente dal tuo abbonamento. Mentre i livelli Business si concentrano sui flussi di eventi ad ambito organizzativo, gli account Enterprise sbloccano telemetria forense cross-organization sistemica.

Ricerca, filtro ed export

I flussi dei log di audit sono accessibili nativamente tramite il pannello Impostazioni dell’organizzazione. Gli amministratori possono interrogarne l’interfaccia usando qualificatori di azione specifici:

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Gli account Enterprise supportano lo streaming di questi eventi di audit direttamente in sistemi SIEM (come Splunk o Datadog) per alerting automatico e conservazione centralizzata e immutabile.

Gestire i posti di Copilot con la REST API

Il provisioning manuale dei posti utente tramite una dashboard UI va bene per i team piccoli, ma non regge con flussi di onboarding aziendali ad alto volume. Usare gli endpoint dei posti della REST API di Github Copilot ti consente di trattare identità e accessi interamente come codice.

Questa è una delle mie parti preferite dell’amministrazione di Copilot perché trasforma le licenze in qualcosa che i team di ingegneria possono davvero automatizzare in modo pulito.

Endpoint API chiave

I workflow API comuni includono:

• Elenco delle assegnazioni dei posti
• Assegnazione dei posti
• Rimozione dei posti
• Recupero delle metriche di utilizzo
• Lettura delle impostazioni di Copilot dell’organizzazione

L’autenticazione generalmente richiede:

• Personal access token con permessi granulari
• Permessi per GitHub App
• Privilegi di amministratore dell’organizzazione

Per accedere a questi percorsi di gestione, i tuoi script di integrazione devono autenticarsi usando un Personal Access Token (PAT) con scope admin:org elevati oppure eseguire tramite una GitHub App autorizzata con privilegi espliciti di gestione di Copilot a livello di organizzazione. 

Per approfondire le integrazioni programmatiche con la piattaforma, ti consiglio di seguire il nostro percorso di competenze GitHub Foundations. 

Pattern di automazione comuni

Alcuni pattern pratici includono:

• Onboarding identità automatizzato: collegare un sistema informativo HR (come Workday o Okta) direttamente a GitHub tramite webhook. Quando un ingegnere si unisce a un team specificato, uno script invia una richiesta POST per effettuare automaticamente il provisioning del suo workspace Copilot.

• Recupero dei posti inattivi: uno script Cron pianificato interroga tramite API l’utilizzo attivo dei posti. Se un utente non interagisce con Copilot da oltre 30 giorni, lo script esegue un comando DELETE per recuperare la licenza, preservando il pool di crediti aziendali.

• Dashboard finanziari: acquisire quotidianamente telemetria di allocazione e consumo per alimentare piattaforme BI interne (come Tableau) e abilitare chargeback chiari a livello di dipartimento/centro di costo.

Esempio: assegnare un posto Copilot con Python

Il seguente script mostra come assegnare programmaticamente un posto dell’organizzazione a un determinato sviluppatore 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())

Considerazioni finali

La struttura dei piani di GitHub Copilot sembra semplice dalla pagina dei prezzi. Quando inizi a gestire i team, le differenze diventano molto più sostanziali.

Confini di privacy, policy di addestramento, verificabilità e controlli di governance spesso contano più dell’accesso grezzo ai modelli. Per questo le discussioni su GitHub Copilot Business vs Enterprise diventano di solito conversazioni su sicurezza e operazioni, più che puramente ingegneristiche.

Se dovessi consigliare un team oggi, partirei prima dai requisiti di governance:

• Ti servono garanzie contrattuali sulla privacy?
• Ti servono i log di audit?
• Ti serve una gestione centralizzata delle policy?

Dopodiché, ottimizzerei per volume d’uso e accesso alle funzionalità.

Per approfondire le competenze tecniche del tuo team e prepararti alle certificazioni ufficiali, esplora questi percorsi di apprendimento avanzati:

• Corso: Sviluppo software con GitHub Copilot
• Percorso competenze: AI per l’ingegneria del software
• Guida alle certificazioni GitHub per professionisti dei dati