Piani e ambito amministrativo

Il modello di governance di GitHub Copilot dipende dal piano. Copilot Business e Copilot Enterprise sono i piani gestiti a livello organizzativo: introducono l’assegnazione centralizzata dei seat, le policy amministrative, gli audit log e le content exclusions. Copilot Enterprise richiede GitHub Enterprise Cloud e aggiunge funzionalità come le knowledge bases e i riepiloghi delle pull request generati da Copilot. I piani individuali (Copilot Pro / Pro+) restano legati all’account personale e non offrono controlli amministrativi: in uno scenario aziendale la scelta ricade sempre su Business o Enterprise.

Gerarchia enterprise → organizzazione ed ereditarietà

L’amministrazione segue due livelli: l’enterprise e le organization che ne fanno parte. Le policy delle funzionalità (Copilot Chat nell’IDE, Copilot su GitHub.com, Copilot nella CLI, suggerimenti che corrispondono a codice pubblico, disponibilità di modelli) possono essere impostate dall’enterprise owner su tre stati:

  • Enabled o Disabled: la decisione viene imposta a tutte le organizzazioni, che non possono sovrascriverla.
  • No policy (o “configurabile a livello di organizzazione”): l’enterprise delega la scelta agli organization owner.

Il principio chiave è l’ereditarietà discendente: quando l’enterprise fissa un valore esplicito, questo prevale e l’organizzazione lo eredita senza possibilità di renderlo meno restrittivo. Solo lo stato “no policy” lascia autonomia al livello inferiore. Questo spiega perché, se una funzione risulta indisponibile in un’organizzazione nonostante l’admin locale l’abbia “abilitata”, la causa va cercata in una policy enforced a livello enterprise.

Gestione dei seat e controllo accessi

I seat di Copilot si assegnano a livello di organizzazione a singoli utenti, a team o all’intera organizzazione. Assegnare un seat a un team è la scelta più scalabile: i nuovi membri ereditano automaticamente l’accesso. La rimozione di un seat interrompe l’accesso alla fine del ciclo di fatturazione corrente. L’accesso richiede comunque l’appartenenza all’organizzazione: rimuovere un utente dall’org revoca implicitamente Copilot. Per l’automazione esistono le REST API dedicate alla gestione dei seat (assegnazione, rimozione, elenco degli utenti abilitati), utili per l’onboarding/offboarding integrato con l’IdP.

Content exclusions: configurazione di sicurezza, non feature policy

Le content exclusions definiscono file e percorsi dove Copilot non deve fornire suggerimenti né usare quel contenuto come contesto. È una configurazione di dati/sicurezza, distinta dalle feature policy, e si imposta a livello di repository o di organization, non a livello di enterprise. La sintassi è basata su path/glob nel file di configurazione:

"*":
  - "**/secrets/**"
  - "/config/production.env"

Punto d’esame frequente: le esclusioni non sono immediate su tutti gli entry point e non garantiscono che il codice non sia mai stato letto in sessioni precedenti; servono a limitare l’esposizione, non a sostituire la gestione dei segreti.

Audit log e governance

Le azioni amministrative di Copilot vengono registrate nell’audit log dell’enterprise e dell’organizzazione: creazione/rimozione seat, modifiche alle policy, aggiornamenti alle content exclusions. Gli eventi sono identificabili dal prefisso della categoria copilot. (per esempio l’assegnazione di un seat). Il log è consultabile dall’interfaccia, esportabile e disponibile via audit log API, oltre a poter essere inviato in streaming verso un SIEM. Per l’analisi dell’adozione si usano invece i Copilot metrics/usage report e le relative API, che aggregano accettazione dei suggerimenti e utenti attivi (dato distinto dagli eventi di audit, che tracciano le azioni amministrative, non la produttività).

Trappole tipiche d’esame

  • Una funzione è disabilitata nell’org ma l’admin locale l’aveva attivata → una policy enforced a livello enterprise ha priorità e viene ereditata: verifica il livello enterprise, non solo l’organizzazione.
  • Impedire che Copilot suggerisca codice da file con segreti → configura le content exclusions (repo o org), non una feature policy; ricorda che non esistono a livello enterprise.
  • Bloccare i suggerimenti che coincidono con codice pubblico → è una feature policy (“suggestions matching public code”), impostabile a livello enterprise/org, diversa dalle content exclusions.
  • Sapere chi ha assegnato o rimosso un seat, o modificato una policy → consulta l’audit log (eventi copilot.), non i report di utilizzo.
  • Dare accesso a un intero reparto minimizzando la manutenzione → assegna i seat a un team, così i nuovi membri lo ereditano automaticamente, invece di aggiungere utenti uno a uno.