Tra il 26 agosto e il 2 settembre 2026, GitHub ha fatto evolvere diversi meccanismi di governance di Copilot: politica globale di disponibilità dei modelli, ritiro di modelli selezionati, applicazione delle esclusioni dei contenuti nell’applicazione e nella CLI, e definizione di un modello predefinito a livello aziendale o di team. Considerati separatamente, questi cambiamenti sembrano semplici impostazioni amministrative. Nel loro insieme, mostrano che la scelta di un modello sta diventando una questione di portafoglio, dati e continuità operativa.
Da ricordare: autorizzare «Copilot» non è più sufficiente. Un’organizzazione deve decidere quali modelli sono disponibili, per quali team, su quali dati, con quali garanzie e fino a quale data. I valori predefiniti ereditati devono essere distinti dalle decisioni esplicite, e ogni ritiro di un modello deve attivare test di non regressione.
1. Perché il multi-modello cambia la governance
Inizialmente, un assistente di programmazione era percepito come un prodotto relativamente omogeneo: un’interfaccia, un fornitore e una politica centrale. Oggi le piattaforme propongono diversi modelli, talvolta di editori differenti, con caratteristiche distinte in termini di costi, prestazioni, licenze e trattamento dei dati.
Il modello interviene in contesti diversi: completamento locale, conversazione, modifica di più file, agente autonomo, revisione del codice o CLI. Un’autorizzazione adeguata alla scrittura di un test non lo è necessariamente per un agente che esplora un repository, esegue comandi e propone una pull request.
Questa varietà offre flessibilità. Un team può usare un modello rapido per le interazioni quotidiane e un modello più avanzato per una migrazione complessa. Ma crea anche decisioni implicite. Un nuovo modello può diventare accessibile perché eredita una politica globale; un modello preferito può scomparire; un’impostazione di riservatezza può essere applicata nell’IDE ma non ancora in un’altra interfaccia.
La governance deve quindi riguardare la combinazione modello + funzionalità + dati + team + versione, e non il solo nome del prodotto.
2. Comprendere i quattro stati della politica GitHub
Il 26 agosto GitHub ha annunciato la disponibilità generale della propria politica globale per i modelli Copilot, con un’implementazione progressiva fino al 1° settembre. I modelli generalmente disponibili che non erano stati configurati esplicitamente potevano seguire lo stato di questa politica.
L’amministrazione distingue quattro situazioni: attivato esplicitamente, disattivato esplicitamente, delegato a un team o a un’organizzazione, e delegato alla politica predefinita. Quest’ultimo valore è dinamico: se la politica globale cambia, cambiano con essa tutti i modelli che la seguono.
La distinzione è essenziale per l’audit. Due modelli visualizzati come disponibili possono derivare da decisioni molto diverse. Il primo è stato valutato e attivato; il secondo è apparso per eredità. Occorre quindi registrare l’origine della decisione e non considerare lo stato effettivo come prova di approvazione.
GitHub precisa che le scelte esplicite vengono preservate. Indica inoltre che i modelli open-weight e quelli non coperti dal suo accordo di conservazione dei dati sono disattivati per impostazione predefinita in questo meccanismo. Questa protezione è un punto di partenza, non una politica completa: l’organizzazione deve comunque verificare le condizioni applicabili, le regioni, le funzionalità e i propri impegni verso i clienti.
Una buona pratica consiste nel disattivare l’attivazione automatica negli ambiti sensibili e richiedere una decisione esplicita per ogni nuovo modello. Negli ambienti meno critici, l’ereditarietà può rimanere consentita, con una revisione automatica e una notifica ai responsabili.
3. Gestire la riservatezza a livello di contenuto
Il 2 settembre GitHub ha annunciato che l’applicazione Copilot e Copilot CLI rispettano ormai le politiche di esclusione dei contenuti configurate a livello aziendale, organizzativo e di repository per i piani Business ed Enterprise. I file esclusi non devono essere usati come contesto in questi flussi di lavoro.
Questa funzione consente di proteggere segreti, codice soggetto a vincoli contrattuali, dati proprietari o directory il cui utilizzo da parte di un assistente non è autorizzato. Tuttavia, non sostituisce i controlli di accesso. Un programmatore o un agente che può leggere un file può comunque copiarlo in un’altra interfaccia, riassumerlo manualmente o esporlo a uno strumento esterno.
L’esclusione deve quindi inserirsi in una strategia più ampia: classificazione dei repository, separazione dei segreti, regole DLP, autorizzazioni minime e registrazione degli eventi. Deve inoltre essere testata su ogni interfaccia. Una politica annunciata per l’applicazione e la CLI non deve essere considerata identica in tutte le estensioni, integrazioni o API.
Documentate che cosa significa «escluso». La domanda non è soltanto se il contenuto entra nel prompt. Verificate suggerimenti, indici, cache, registri, tracce di valutazione ed eventuali funzioni di memoria. I contratti e la documentazione del fornitore restano la fonte di verità.
Il nostro articolo su Zero Data Retention e Private Safety Processing approfondisce la distinzione tra conservazione, addestramento, registrazione e controlli di sicurezza.
4. Preparare le dismissioni come migrazioni
Il 31 agosto GitHub ha annunciato la dismissione di diversi modelli a partire dal 1° settembre nella maggior parte delle esperienze Copilot. L’elenco comprendeva in particolare versioni di Gemini, Claude e Raptor Mini, con alternative suggerite.
Il termine molto breve dimostra che un nome di modello non deve essere codificato senza una strategia di sostituzione. Un team che utilizza un modello in istruzioni, automazioni, valutazioni o impostazioni aziendali può subire un’interruzione o un cambiamento silenzioso del comportamento.
Trattate ogni ritiro come una migrazione applicativa. Inventariate gli utilizzi, scegliete un candidato, ripetete le valutazioni, misurate la qualità e verificate i costi. I prompt possono dipendere da uno stile di ragionamento, da una finestra di contesto o da un formato di output. Sostituire un modello con «quello più simile» non garantisce l’equivalenza.
Aggiungete un livello logico tra il caso d’uso e il nome commerciale. Per esempio, il profilo code-review-standard punta a un modello approvato con una determinata configurazione. Il cambiamento di fornitore o versione viene realizzato nel registro, senza modificare tutti i flussi di lavoro.
Monitorate i calendari, ma preparatevi anche a una sostituzione non pianificata. Un modello può essere ritirato per motivi di sicurezza, licenza o disponibilità. Ogni utilizzo critico deve avere una soluzione di ripiego testata e una modalità degradata esplicita.
5. Definire modelli per team senza frammentare l’organizzazione
Il 2 settembre GitHub ha annunciato la possibilità di definire un modello predefinito nelle impostazioni gestite dall’azienda, con valori diversi per team, per l’applicazione Copilot, la CLI e Visual Studio Code sui piani Business ed Enterprise.
Questa granularità è utile. Un team PHP può privilegiare un modello efficiente sui propri repository e sulle proprie attività; un team di supporto può cercare velocità e contenimento dei costi; un team di sicurezza può richiedere un modello e una politica più restrittivi.
Il rischio è la frammentazione. Se ogni team sceglie senza un quadro comune, l’azienda non sa più quali modelli trattano i suoi dati, le valutazioni si moltiplicano e gli incidenti diventano difficili da riprodurre.
Definite un catalogo ristretto. Due o tre profili coprono generalmente la maggior parte delle esigenze: interazione rapida, ragionamento complesso e contesto sensibile. I team richiedono un’eccezione quando dimostrano una necessità misurabile. L’eccezione deve avere un responsabile, una data di scadenza e un set di valutazione.
Il modello predefinito non è necessariamente l’unico autorizzato. Rappresenta la scelta consigliata. La possibilità per l’utente di sostituirlo dipende dal livello di rischio. In un repository pubblico la libertà può essere ampia; in un prodotto regolamentato il modello e l’interfaccia possono essere imposti.
6. Costruire un registro di modelli e casi d’uso
Il registro costituisce la fonte di verità. Per ogni modello, conservate il fornitore, la versione, lo stato su GitHub, le interfacce disponibili, la politica dei dati, le regioni, il costo, la data di introduzione, la data di revisione e il responsabile interno.
Collegate poi i casi d’uso: completamento, chat, agente, CLI, revisione, generazione di test o migrazione. Aggiungete la classificazione dei dati, il livello di autonomia, gli strumenti accessibili, il modello predefinito e il modello di ripiego.
Una riga del registro potrebbe indicare: «revisione automatica di repository interni non regolamentati; modello A; solo suggerimenti; contenuto segreto escluso; approvazione umana obbligatoria; valutazione mensile; ripiego sul modello B».
Questo registro deve essere versionato. Un file leggibile dalle macchine consente di generare le impostazioni gestite, le tabelle di audit e gli avvisi di dismissione. Quando necessario, le modifiche passano attraverso una pull request approvata dai responsabili della piattaforma, della sicurezza e del business.
Evitate tuttavia di trasformare il registro in un catalogo teorico. Ogni voce attiva deve corrispondere a un utilizzo osservato. I modelli non utilizzati aumentano la superficie di governance senza creare valore.
7. Testare qualità, costi e rischi prima dell’attivazione
Un benchmark generale non basta per scegliere un modello di sviluppo. Costruite un set di valutazione a partire da attività reali e anonimizzate: correzione mirata, comprensione di un modulo, generazione di test, migrazione, revisione di sicurezza e rispetto delle convenzioni.
Misurate il tasso di riuscita, i difetti introdotti, la qualità della spiegazione, le chiamate agli strumenti, il costo e la latenza. Verificate il comportamento di fronte a un’istruzione presente nel repository, a un file escluso, a un segreto fittizio e a una richiesta fuori ambito.
Per gli agenti aggiungete criteri d’azione: rispetta il branch, i file autorizzati, i comandi e i limiti? Il modello migliore nella generazione del codice non è necessariamente quello più controllabile in un flusso di lavoro autonomo.
Ripetete il set a ogni nuova versione o modifica dell’interfaccia. Un aggiornamento di GitHub può modificare l’orchestrazione attorno al modello, anche quando il modello rimane identico. Conservate risultati e configurazioni per poter spiegare un’evoluzione della qualità.
L’attivazione segue una distribuzione progressiva: team pilota, repository selezionati, osservazione e poi estensione generale. Gli incidenti e i feedback degli utenti alimentano il registro e possono portare a tornare al modello precedente.
8. Istituire un ciclo trimestrale di governance
Ogni trimestre esaminate l’elenco dei modelli disponibili, le decisioni ereditate, le esclusioni, gli utilizzi reali, i costi e le date di ritiro annunciate. Disattivate i modelli non utilizzati e rinnovate solo le eccezioni giustificate.
Ogni mese monitorate i changelog dei fornitori e di GitHub. Un cambiamento sostanziale attiva un’analisi senza attendere la revisione trimestrale. L’automazione può aprire un ticket quando un nome del registro compare in un annuncio di dismissione.
Prima di ogni attivazione, richiedete una scheda breve: esigenza, dati, interfacce, valutazione, costo, ripiego e responsabile. Dopo l’attivazione, verificate che le impostazioni effettive corrispondano al registro. La differenza tra politica dichiarata e configurazione reale è un indicatore prioritario.
Infine, comunicate con gli sviluppatori. Spiegate perché alcuni modelli sono disponibili, come segnalare un problema e quali informazioni non devono mai essere fornite all’assistente. Una governance comprensibile ottiene più adesione di un elenco di restrizioni privo di contesto.
Conclusione
La moltiplicazione dei modelli in GitHub Copilot offre una capacità di adattamento utile, ma trasforma un’impostazione di produttività in un sistema da governare. Politiche globali, esclusioni dei contenuti, valori per team e dismissioni devono essere trattati insieme.
Un’organizzazione solida mantiene un registro versionato, rende esplicita l’origine delle decisioni, valuta i modelli sulle proprie attività, prepara le sostituzioni e verifica le protezioni dei dati su ogni interfaccia. Partitech accompagna la progettazione di questa governance, l’automazione dei controlli e l’integrazione di Copilot in un approccio DevSecOps misurabile.
Riferimenti verificati il 3 settembre 2026
- GitHub — «Global model policy generally available», 26 agosto 2026: https://github.blog/changelog/2026-08-26-global-model-policy-generally-available/
- GitHub — «Selected GitHub Copilot models deprecated», 31 agosto 2026: https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated/
- GitHub — «Content exclusions generally available in Copilot app and CLI», 2 settembre 2026: https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/
- GitHub — «Enterprise-managed settings support any default model», 2 settembre 2026: https://github.blog/changelog/2026-09-02-enterprise-managed-settings-support-any-default-model/