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

Panoramica dei piani di GitHub Copilot

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 core e i suggerimenti “Next Edit” restano illimitati e non consumano crediti. 

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

I prezzi base dell’abbonamento mensile sono rimasti invariati, ma il cambiamento modifica il modo in cui gli amministratori pianificano gli extra budgetari e monitorano l’uso 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 l’accesso a GitHub Spark, un ambiente pensato per creare applicazioni assistite dall’AI.

Al momento, 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 registrarsi finché GitHub non completa la transizione al nuovo sistema di fatturazione basato su AI Credits.

Business ed Enterprise

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

GitHub Copilot Business introduce funzionalità di gestione essenziali:

• Assegnazione e revoca centralizzate delle postazioni.
• Criteri di base a livello di organizzazione.
• Audit log strutturati e tracciamento degli eventi di conformità.
• Esclusioni di contenuti e file dei repository.
• Indennizzo commerciale della proprietà intellettuale.

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

• Copilot Spaces: un hub della conoscenza che consente agli sviluppatori di interrogare Copilot su documentazione interna, wiki e standard di codice sistemici.
• Integrazione potenziata con GitHub.com Chat.
• Ereditarietà gerarchica dei criteri 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 reale per Enterprise è di 60 $ per utente al mese. Questo non si applica al livello GitHub Copilot Business, che può essere acquistato nativamente da organizzazioni che usano i piani GitHub Free o GitHub Team.

Le organizzazioni rinunciano ai vantaggi a livello enterprise come l’ereditarietà dei criteri, ma mantengono indennizzo IP, auditing, esclusione dei file e gestione dei criteri a livello organizzativo, quindi è una buona alternativa per team di engineering di medie dimensioni.

Se stai pensando a un abbonamento Enterprise, la nostra guida GitHub Copilot Enterprise ti mostra 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 principali aree in cui i piani individuali e quelli business differiscono notevolmente. Sebbene le funzionalità aggiuntive per gli utenti siano ottime, comprendere queste differenze è fondamentale per chi deve decidere tra gestire un insieme di licenze Pro personali e un abbonamento Business.

Gestione dei dati e predefiniti di training

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 modificato la gestione della raccolta dei dati di interazione per i piani Copilot individuali. Per gli utenti Free, Pro e Pro+, i dati di interazione possono ora essere usati per l’addestramento del modello per impostazione predefinita, a meno che l’utente non esegua esplicitamente l’opt-out.

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

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

Gli accordi Business ed Enterprise prevedono una rigorosa garanzia contrattuale che i dati di interazione non vengano mai usati per l’addestramento in nessuna circostanza. Non è richiesto alcun intervento manuale dell’utente.

Per approfondire come vengono usati i dati e 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 della proprietà intellettuale (IP) per il 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 sulla proprietà intellettuale. Questo non elimina tutti i rischi legali, ma cambia il discorso 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 delivery commerciali.

Fatturazione, postazioni e passaggio agli AI Credits

La fatturazione individuale usa metodi self-service associati direttamente agli account personali. I piani Business centralizzano la fatturazione con postazioni assegnate dagli admin. Inoltre, invece che ogni utente interagisca con bucket di crediti indipendenti, l’organizzazione mette in pool i propri AI Credits mensili assegnati in base al numero di utenti.

I piani Enterprise offrono un controllo ancora più fine con limiti di enforcement del budget granulari, 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’intero monte crediti aziendale.

SKU e considerazioni sulla privacy

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

Modifiche alle policy di training di aprile 2026

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

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

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

Scegliere la SKU giusta per i requisiti di privacy

In base al livello di lavoro, potresti aver bisogno di SKU diverse. 

• Sviluppatore solista/progetti personali: i livelli Free o Pro offrono la massima flessibilità. Esegui semplicemente l’opt-out nelle impostazioni di privacy personali se lavori su codice proprietario.
• Freelance/contrattisti: il piano Business fornisce una barriera difensiva. Spesso i contratti con i clienti vietano esplicitamente la trasmissione di dati a provider LLM esterni; una postazione dedicata dell’organizzazione tutela i tuoi contratti.
• Team aziendali con mandati di conformità: il livello Business rappresenta la base standard, garantendo isolamento dei flussi di dati e abilitando la governance amministrativa.
• Settori regolamentati (finanza, sanità): il livello Enterprise è in genere obbligatorio, consentendo 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 file di GitHub Copilot è uno dei modi più efficaci per mettere in sicurezza l’ambiente in modo difensivo. L’esclusione dei contenuti impedisce all’agente IDE locale di elaborare contenuti di file specifici, rendendoli completamente invisibili a completamenti inline, riquadri di chat e operazioni agentiche in background. 

Nota che 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 Global Organization Settings sia nelle impostazioni del singolo repository. Basta entrare nelle impostazioni del repository o dell’organizzazione cliccando il pulsante Settings in alto a destra.

Nel menu laterale, sotto le impostazioni di Copilot, scegli “Code and automation”. Poi inserisci le esclusioni nel riquadro “Paths to exclude in this repository” così:

# 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 repo dell’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 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 altamente regolamentate ai fini della conformità.

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: bloccati dal generare contesto all’interno del file o dall’attingere contesto da esso per popolare file adiacenti.
• Copilot chat/agent: il sistema restituisce un avviso che indica che il file non può essere revisionato a causa di restrizioni dei criteri organizzativi.

I motori IDE locali standard funzionano allo stesso modo. Strumenti di qualità della vita come parsing del testo, evidenziazione sintattica 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 path usando repository di staging; wildcard malformate possono fallire in apertura, esponendo dati che intendevi isolare.

Gestione dei criteri a livello di organizzazione

Applicare la gestione dei criteri dell’organizzazione per GitHub Copilot garantisce che la sicurezza aziendale sia determinata dal team di amministrazione invece che dalle preferenze dei singoli sviluppatori.

Impostazioni dei criteri disponibili

Le organizzazioni possono controllare diverse impostazioni per gli sviluppatori:

• Feature toggle: attivare o disattivare 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 di controllo legale che impedisce a Copilot di restituire suggerimenti di codice che corrispondono da vicino a repository open-source pubblici su GitHub, riducendo i rischi di conformità alle licenze open-source.
• Restrizioni sulla scelta del modello: limitare i modelli (ad esempio varianti specifiche di GPT o Claude) selezionabili dagli sviluppatori, così da gestire latenza, consumo di crediti e prestazioni. Per un approfondimento sui modelli disponibili tramite la piattaforma di GitHub, vedi questa guida pratica a GitHub Models.
• Istruzioni personalizzate dell’organizzazione: inserire file di policy in markdown standard che aggiungano 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 organizzazioni e permessi di GitHub, il corso Intermediate GitHub Concepts offre un utile background. Per i gruppi di engineering che si espandono verso strumenti da riga di comando, vedi il nostro Tutorial su GitHub Copilot CLI.

Ereditarietà dei criteri a livello Enterprise

Nei contesti aziendali su larga scala, il motore dei criteri segue una rigida cascata gerarchica di eredità: Criteri Enterprise > Criteri di organizzazione > Preferenze utente

Gli amministratori Enterprise possono scegliere di bloccare i criteri a livello globale 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’enterprise potrebbe avere impostazioni globali per bloccare l’uso di modelli specifici.

A livello di team, potrebbe limitare la divisione servizi finanziari a filtri rigorosi sul codice pubblico, mentre consentire a una divisione R&S software interna una sperimentazione più flessibile.

Audit log

Quando i revisori della conformità hanno bisogno di verificare la tua supply chain software o i team di sicurezza tracciano una perdita di dati, GitHub Copilot registra la cronologia delle modifiche alla piattaforma.

Eventi di Copilot nel registro di controllo

Il sistema registra un libro mastro completo delle operazioni di gestione, includendo:

• Assegnazioni esplicite di postazioni, revoche e modifiche ai gruppi di fatturazione.
• Modifiche al filtro di duplicazione del codice pubblico.
• Alterazioni ai 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 su flussi di eventi di azioni con ambito organizzativo, gli account Enterprise sbloccano telemetria forense sistemica cross-organizzazione.

Ricerca, filtri ed esportazione

I flussi del registro di controllo sono accessibili nativamente tramite il pannello Organization Settings. Gli amministratori possono interrogare 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 diretto di questi eventi di audit in sistemi esterni di Security Information and Event Management (SIEM) come Splunk o Datadog, per alerting automatizzato e conservazione immutabile centralizzata.

Gestire le postazioni di Copilot con la REST API

Il provisioning manuale delle postazioni utente tramite dashboard UI funziona per i team piccoli, ma si rompe rapidamente con workflow di onboarding aziendale ad alto volume. Usare gli endpoint dei posti della REST API di GitHub Copilot ti consente di trattare l’identity e l’access management interamente come codice.

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

Endpoint API chiave

Workflow API comuni includono:

• Elencare le assegnazioni di postazioni
• Assegnare postazioni
• Rimuovere postazioni
• Recuperare metriche di utilizzo
• Leggere le impostazioni di Copilot dell’organizzazione

L’autenticazione di norma richiede:

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

Per accedere a questi percorsi di gestione, gli script di integrazione devono autenticarsi usando un Personal Access Token (PAT) con scope admin:org elevati o 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 skill track GitHub Foundations. 

Pattern di automazione comuni

Alcuni pattern pratici includono:

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

• Recupero postazioni inattive: uno script Cron pianificato interroga l’utilizzo attivo delle postazioni via API. Se un utente non ha interagito con Copilot per oltre 30 giorni, lo script esegue un comando DELETE per recuperare la licenza, preservando il pool di crediti aziendale.

• Dashboard finanziari: estrarre telemetria giornaliera di allocazione e consumo per alimentare piattaforme BI interne (come Tableau) per un chiaro riaddebito a livello di dipartimento/centro di costo.

Esempio: assegnare una postazione Copilot con Python

Il seguente script mostra come assegnare in modo programmatico una postazione dell’organizzazione a uno sviluppatore specifico 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 team, le differenze diventano molto più sostanziali.

Confini di privacy, policy di training, verificabilità e controlli di governance spesso contano più del semplice accesso ai modelli. Ecco perché 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 audit log?
• Ti serve una gestione centralizzata dei criteri?

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

Per approfondire le capacità tecniche del tuo team e prepararti a certificazioni ufficiali, esplora questi percorsi avanzati di apprendimento:

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