ARTICOLO / 30 GIUGNO 2026
Dal 1° giugno 2026 GitHub Copilot ha abbandonato il sistema a richieste premium per passare a una fatturazione basata sul consumo di token, calcolato su input, output e cache di ogni interazione con il modello. Il prezzo dei piani Business (19$ per utente al mese) e Enterprise (39$) resta nominalmente invariato, ma ora corrisponde a un credito di pari valore in "GitHub AI Credits": superato quel credito, ogni richiesta aggiuntiva viene fatturata ai prezzi pubblici delle API dei modelli utilizzati. Per accompagnare la transizione, GitHub ha previsto crediti promozionali fino ad agosto 2026: 30$ al mese per i piani Business, 70 per gli Enterprise. a si tratta di una misura temporanea, non di una soluzione strutturale.
Un cambiamento che non avrà un impatto uniforme
L'effetto reale del cambiamento dipende da come Copilot viene usato. Chi lo utilizza soprattutto per il completamento del codice non dovrebbe registrare variazioni significative, perché questa funzione resta gratuita e illimitata. Chi invece lavora con sessioni agentiche intensive: task complessi affidati al modello in autonomia, con cicli ripetuti di generazione, test e correzione, potrebbe vedere i costi crescere anche di 10 volte rispetto al regime precedente, secondo le prime stime circolate tra gli utenti enterprise dopo l'annuncio. Non è quindi un aumento generalizzato: è un aumento selettivo, che colpisce in modo sproporzionato chi ha spinto di più sull'uso autonomo dell'AI nello sviluppo.
Notizia di prodotto. Problema di governance.
Come misuriamo l'impatto dell'AI nei team di sviluppo?
Il problema, a ben guardare, esisteva già prima del cambio di pricing, solo che restava invisibile. La maggior parte delle organizzazioni che hanno attivato Copilot non dispone di indicatori per stabilire se l'adozione stia effettivamente producendo valore. Quante pull request vengono accelerate dall'AI, e di quanto? Qual è il tasso di accettazione del codice suggerito? I team che usano Copilot più intensamente sono anche quelli con cicli di rilascio più rapidi, o semplicemente quelli con i costi più alti? Senza una base di KPI di adozione, queste domande restano senza risposta. Il nuovo modello di fatturazione non crea il problema, ma lo rende urgente: ogni euro indirizzato verso l'AI senza un ritorno misurabile ora si vede chiaramente nel budget IT, mese per mese.
Due punti di partenza diversi
Le organizzazioni che dispongono già di una policy di utilizzo definita, di una formazione mirata sui casi d'uso più efficaci e di un set minimo di metriche di adozione affrontano questo cambiamento da una posizione di vantaggio: possono prevedere l'impatto sui costi e intervenire prima che diventi un problema di budget. Quelle che hanno distribuito le licenze senza un piano strutturato si trovano invece a dover rispondere, da un mese all'altro, a una domanda che prima non avevano motivo di porsi: l'AI nello sviluppo del software sta generando un ritorno proporzionato a quanto costa, o si stanno solo pagando token?
Il codi è diventato un asset critico (e quasi nessuno lo gestisce come tale)
Negli ultimi anni il codice è passato da "responsabilità del team di sviuluppo" a vera e propria spina dorsale operativa di qualsiasi organizzazione IT. Infrastrutture, applicativi, automazioni, agenti AI: tutto, oggi, viene definito, versionato e distribuito tramite codice. Eppure, in moltissime aziende — soprattutto quelle il cui core business non è lo sviluppo software — la gestione del codice resta frammentata, poco tracciata e priva di regole condivise tra team, prodotti e fornitori esterni.
Questo scenario sta diventando un rischio concreto per due motivi che si intrecciano: da un lato l'adozione esplosiva degli strumenti di intelligenza artificiale per la scrittura del codice, dall'altro l'arrivo di un quadro normativo europeo (NIS2, AI Act, Cyber Resilience Act) che rende la tracciabilità e la sicurezza del software un obbligo, non più un'opzione.
GitHub e GitHub Copilot: cosa sono davvero (e cosa non sono)
GitHub è una delle piattaforme software-as-a-service per la gestione di repository di codice più diffuse al mondo, oggi parte dell'offerta Microsoft pur mantenendo una propria identità di prodotto. Permette alle organizzazioni di organizzare i propri progetti in repository, tracciare l'evoluzione del codice attraverso branch e pull request, e abilitare dinamiche di collaborazione tipiche dei team di sviluppo moderni (code review, versionamento, automazioni di build e test).
GitHub Copilot è la componente di intelligenza artificiale che si integra con GitHub. È importante chiarire un punto spesso fonte di confusione commerciale: GitHub e Copilot sono due licenze distinte, con due logiche di costo diverse: GitHub prevede un costo a "seat" (per persona), Copilot lavora invece “a consumo”, il costo varia al variare del numreo di token utilizzati in base alle interazioni con il codice. Le due componenti possono essere attivate in momenti diversi, e questo apre la porta a percorsi di adozione graduali.
Copilot non si limita all'autocompletamento del codice. Integrato nel ciclo di sviluppo, può:
- effettuare una prima revisione automatica delle pull request, segnalando o proponendo correzioni prima dell'intervento umano;
- generare e proporre test unitari o funzionali su branch dedicati, mantenendo una supervisione umana tramite pull request separate;
- interfacciarsi anche con modelli di intelligenza artificiale di terze parti, lasciando ai team la scelta dello strumento più adatto a ciascuna fase del ciclo di sviluppo.
I numeri dell'adozione: un mercato che è già maturato
I dati di mercato confermano che GitHub Copilot non è più uno strumento da "fase pilota", ma uno standard enterprise consolidato:
- Copilot ha raggiunto circa 20 milioni di utenti cumulativi a luglio 2025, con una crescita del 400% anno su anno tra inizio 2024 e inizio 2025 (fonte).
- A gennaio 2026 gli abbonati paganti hanno toccato 4,7 milioni, in crescita del 75% su base annua (fonte).
- Oltre 50.000 organizzazioni, dalle startup alle Fortune 500, hanno integrato Copilot nei propri workflow, con il 90% delle Fortune 100 che ha già adottato lo strumento (fonte).
- L'adozione varia per settore: tecnologia e startup al 90% di utilizzo attivo tra i licenziatari, banking e finance all'80%, assicurazioni al 70% — segno che anche i settori più regolamentati stanno integrando questi strumenti (fonte).
- Sul piano della produttività, alcune ricerche hanno misurato un completamento dei task il 55% più rapido rispetto ai gruppi di controllo, con un incremento dell'84% nelle build completate con successo (fonte).
- Il mercato degli strumenti di AI per il codice ha raggiunto 7,37 miliardi di dollari nel 2025, con GitHub Copilot che detiene circa il 42% di market share (fonte).
Il rovescio della medaglia: l'adozione "selvaggia" e i suoi rischi
Numeri di adozione così alti raccontano solo metà della storia. La parte meno raccontata riguarda come questi strumenti vengono effettivamente integrati nei processi aziendali. Tre criticità emergono con particolare frequenza:
- Codice generato dall'AI senza controllo qualità strutturato.Studi citati nelle analisi di settore indicano che una quota significativa del codice Python generato da strumenti AI contiene potenziali vulnerabilità di sicurezza (fonte). Questo non significa che l'AI sia "pericolosa" — il codice scritto da umani presenta le sue vulnerabilità — ma che l'adozione di Copilot senza processi di code review strutturati lascia un vuoto di controllo.
- Repository frammentati e regole non condivise. È comune trovare organizzazioni che scrivono codice da decenni ma applicano convenzioni diverse progetto per progetto, team per team — spesso perché ogni prodotto ha seguito stack tecnologici e metodologie differenti senza alcuna contaminazione tra i gruppi. Quando l'AI entra in questo scenario senza linee guida comuni, amplifica la frammentazione invece di risolverla.
- Dipendenza dai fornitori esterni senza tracciabilità. Un numero rilevante di aziende che esternalizzano lo sviluppo richiede contrattualmente la proprietà del codice, ma lascia al fornitore piena autonomia nella sua gestione quotidiana. Il risultato: se il rapporto con il fornitore termina, l'azienda riceve l'ultima versione del codice ma perde l'intera storia delle decisioni, dei bug risolti e delle motivazioni alla base di certe scelte architetturali — un problema che diventa critico nel momento in cui occorre dimostrare conformità normativa o gestire un incidente di sicurezza.
Il contesto normativo: perchè il 2026 è l'anno della svolta
Tre quadri normativi europei stanno convergendo nello stesso periodo, rendendo la governance del codice un tema non più rinviabile:
- NIS2: la direttiva ha ampliato in modo significativo il perimetro delle organizzazioni soggette a obblighi di cybersecurity, introducendo responsabilità dirette per i vertici aziendali e tempistiche stringenti per la segnalazione degli incidenti. In Germania, ad esempio, la legge di recepimento nazionale (NIS2UmsuCG) è entrata in vigore a dicembre 2025, con la registrazione presso l'autorità competente già attiva (fonte). A maggio 2026 la Commissione Europea ha già avviato procedure di infrazione verso diversi Stati membri, segnale di un'intensificazione della vigilanza (fonte).
- Cyber Resilience Act (CRA): entrato in vigore a dicembre 2024, introduce obblighi specifici per i produttori di software e prodotti con elementi digitali. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate decorrono da settembre 2026, mentre gli obblighi generali diventeranno vincolanti da dicembre 2027 (fonte). Il principio cardine è la "security by design": i requisiti di sicurezza devono essere integrati fin dalle prime fasi di sviluppo, non aggiunti a posteriori.
- AI Act: gli ambiti di sovrapposizione con NIS2 sono già oggetto di analisi da parte degli enti regolatori, in particolare per quanto riguarda i sistemi AI ad alto rischio impiegati in settori regolamentati, che attiveranno automaticamente anche obblighi NIS2 (fonte).
Il filo comune che lega questi tre quadri normativi è la richiesta di tracciabilità end-to-end: poter dimostrare non solo cosa è stato fatto, ma come, quando e perché, lungo tutto il ciclo di vita del software — compreso il codice scritto o modificato con l'aiuto dell'intelligenza artificiale.
Dalla governance del codice al vantaggio competitivo
Adottare un sistema strutturato di repository centralizzato — con GitHub e, dove utile, Copilot — non è quindi solo un esercizio di compliance, ma porta benefici operativi concreti e misurabili:
- Onboarding più rapido: regole condivise di naming, struttura dei progetti e workflow facilitano l'inserimento di nuove persone nei team di sviluppo.
- Visione cross-progetto: con strumenti AI collegati a repository centralizzati, è possibile identificare automaticamente librerie obsolete, vulnerabilità di sicurezza o pattern di errore ricorrenti su tutta la code base aziendale, non solo progetto per progetto.
- Efficientamento del ciclo di sviluppo: l'adozione strutturata di queste pratiche viene stimata produrre un efficientamento complessivo del 20-30% del ciclo di sviluppo, secondo l'esperienza maturata sul campo in percorsi di affiancamento aziendale.
- Governance dei fornitori esterni: centralizzare il codice su un repository definito dal cliente permette di stabilire le regole con cui i fornitori esterni devono rilasciare il proprio lavoro, mantenendo continuità e tracciabilità anche in caso di cambio fornitore.
- Attrattività per i talenti: GitHub è lo strumento con cui le nuove generazioni di sviluppatori si formano e collaborano in ambito open source e personale, diventando anche una leva per attrarre nuovi profili tecnici.
Da dove iniziare
Le domande di partenza che ogni organizzazione dovrebbe porsi sono semplici, ma spesso non hanno una risposta strutturata:
- Esiste già un sistema di repository per il codice (GitHub o altri)?
- Vengono applicate metodologie definite di revisione del codice e automazione?
- I fornitori esterni operano all'interno di repository centralizzati gestiti dal cliente, o restituiscono solo il codice finale?
- Sono già stati sperimentati strumenti AI per la scrittura o l'analisi del codice, e in che modo sono stati integrati nei processi esistenti?
- Esistono regole formalizzate di governance e qualità del codice condivise tra i team?
Le risposte a queste domande permettono di individuare il punto di partenza più adatto: da un primo assessment strutturato per chi non ha mai applicato un approccio organizzato, fino a percorsi di affiancamento avanzati per chi vuole spingere su automazione, sicurezza e adozione pervasiva dell'AI nel ciclo di sviluppo.
In sintesi
GitHub Copilot non va letto solo come uno strumento di produttività individuale per chi scrive codice. Inserito in un contesto di governance strutturata, diventa una leva per affrontare insieme tre sfide che oggi si presentano in parallelo a quasi tutte le organizzazioni: la crescita esponenziale del codice da gestire (anche grazie all'AI), l'obbligo normativo crescente di tracciabilità e sicurezza, e la necessità di mantenere efficienza e qualità anche quando lo sviluppo è in parte demandato a fornitori esterni. Le organizzazioni che inizieranno ora a costruire questa struttura partiranno in vantaggio rispetto a chi affronterà il tema solo quando le scadenze normative lo renderanno indifferibile.
Fonti dei dati di mercato e normativi citati: aboutchromebooks.com, affiliatebooster.com, companieshistory.com, secondtalent.com, quantumrun.com, smartintegrityplatform.com, optro.ai, reedsmith.com, isms.online (consultate giugno 2026).