Cosa dice la GR 2026-002 con cui Debian ha votato sull'IA generativa

Fra il 15 e il 28 agosto 2026 il progetto Debian ha fatto una cosa che fa di rado: ha convocato una General Resolution, il suo strumento costituzionale più pesante, per decidere come comportarsi con l'IA generativa. Hanno votato 1.045 sviluppatori registrati, su otto opzioni che coprivano l'intero spettro delle posizioni possibili: dal divieto totale iscritto nel Social Contract alla messa al bando per ragioni di consumo energetico, passando per l'accettazione condizionata. Ha vinto l'opzione 5, "Responsible Use of Generative AI", proposta da Marc Haber. Se gestisci server, questo voto ti riguarda più di quanto sembri: Debian è il sistema operativo, diretto o via derivate, di una quota enorme dei VPS in produzione, e la GR 2026-002 definisce con quali regole verranno scritti e mantenuti i pacchetti che il tuo apt upgrade installa ogni settimana. In questo articolo scendo in profondità su un concetto solo, perché è il cuore della risoluzione e il motivo per cui la considero la decisione più lucida presa quest'anno da una grande comunità open source: la responsabilità non si delega allo strumento. Vediamo cosa dice il testo, cosa dicevano le alternative sconfitte, come si posiziona Debian rispetto ai divieti di Gentoo e QEMU, e cosa puoi copiare da questa policy per la tua azienda.

Cosa ha deciso davvero Debian il 28 agosto?

La risposta secca: Debian non vieta e non incoraggia l'uso di strumenti di IA generativa nello sviluppo, nella manutenzione e nella documentazione; ogni contributo deve rispettare gli standard di qualità e legali già esistenti; chi contribuisce resta pienamente responsabile del proprio lavoro, il che include aver compreso e riesaminato l'output assistito dall'IA prima di sottometterlo; e le informazioni confidenziali del progetto non vanno mai passate a servizi terzi non fidati. Il testo integrale, con le otto opzioni e l'esito, è pubblicato sulla pagina ufficiale della votazione.

Per pesare l'evento serve sapere quanto è raro. La General Resolution è lo strumento costituzionale con cui l'intero corpo dei Debian Developer decide al posto delle strutture ordinarie, e il progetto lo estrae dal cassetto una manciata di volte per decennio, sempre su questioni che spaccano: la convivenza fra init system nel 2019, il firmware non libero nell'installer nel 2022. Che l'IA generativa sia finita in quella compagnia dice molto della temperatura del dibattito interno; che il voto, con il metodo Condorcet che il progetto usa da vent'anni, abbia premiato l'opzione meno ideologica delle otto dice molto della maturità con cui il dibattito si è chiuso.

Nota cosa manca, perché è la parte migliore: non c'è nessuna regola nuova. La risoluzione non introduce un registro dei contributi assistiti, non impone etichette, non crea una burocrazia di dichiarazioni. Dice che le regole esistenti bastano, a patto di prenderle sul serio: un pacchetto rotto è un pacchetto rotto, una violazione di licenza è una violazione di licenza, chiunque o qualunque cosa abbia scritto il diff. La qualità si giudica sull'artefatto e la responsabilità sta in capo a un essere umano con nome e cognome, iscritto al progetto attraverso un processo di ammissione che non è cambiato di una virgola.

La GR 2026-002 non è una policy sull'IA: è una riaffermazione del modello di responsabilità di Debian, scritta in un momento in cui serviva ripeterlo. Lo strumento non entra nella catena di fiducia; la persona sì.

C'è un solo obbligo genuinamente nuovo nel perimetro, ed è quello sulla confidenzialità: vietato dare in pasto informazioni riservate del progetto a servizi esterni non fidati. È la regola che qualunque azienda dovrebbe avere scritta da tre anni, e che nella mia esperienza di consulenza è ancora la più violata: non dal management, ma dal singolo che incolla un log di produzione in una chat pubblica per farsi aiutare a leggerlo.

Le otto opzioni: uno spettro completo delle posizioni possibili

Il valore documentale di questa votazione sta anche nelle opzioni sconfitte, perché fotografano il dibattito interno di ogni organizzazione tecnica del 2026, la tua compresa. Sul tavolo c'erano, tra le altre: il divieto dei contributi LLM sancito nel Social Contract (Matthias Geiger), il rifiuto "per quanto praticabile" (Ian Jackson), la posizione identitaria "Debian is created by humans" (Gard Spreemann), l'accettazione condizionata con requisiti espliciti (Lucas Nussbaum), fino all'opzione che chiedeva di evitare gli LLM per ragioni climatiche (Holger Levsen). Otto proposte, otto firmatari con nome pubblico, un periodo di discussione esteso dal 23 luglio al 13 agosto: comunque la si pensi sull'esito, il processo è stato esemplare, ed è la differenza fra una policy e un editto.

Dietro le opzioni più restrittive c'era un argomento serio che va riconosciuto anche se ha perso: quello delle licenze. Un modello addestrato su miliardi di righe di codice con licenze eterogenee produce output il cui stato giuridico non ha ancora una giurisprudenza consolidata, e per un progetto che della pulizia delle licenze ha fatto una ragione sociale l'ansia è legittima: è la stessa che ha spinto QEMU al divieto. La risposta implicita della risoluzione vincente è che il problema è già normato: gli "standard legali esistenti" che ogni contributo deve rispettare includono la conformità di licenza, e chi sottomette codice di provenienza incerta li sta violando oggi esattamente come li violava incollando codice da un forum nel 2010. È cambiata la scala del rischio, non la regola che lo governa.

La scelta della via di mezzo, in questo contesto, non è tiepidezza: è una presa di posizione precisa contro entrambe le derive. Contro il divieto, perché un divieto non verificabile è teatro normativo: nessun revisore può dimostrare che un patch pulito e ben scritto sia nato da un prompt, e una regola inapplicabile insegna solo a mentire. E contro l'entusiasmo, perché la responsabilità piena del contributore significa che "l'ha scritto il modello" non sarà mai un'attenuante dentro Debian: se non capisci il codice che sottometti, il problema sei tu, non il modello. Nel mio lavoro quotidiano, dove gestisco decine di codebase con automazione LLM spinta, applico da tempo la stessa regola nella forma più brutale: ogni riga che esce con il mio nome è mia, con tutto quello che ne consegue quando è sbagliata.

Se vuoi capire come imposto questo equilibrio fra automazione e responsabilità nei progetti reali, dal refactoring assistito alla revisione sistematica dell'output, nel mio profilo professionale trovi il perimetro delle attività che seguo e il modo in cui lavoro.

Gentoo, QEMU, Debian: tre governance, tre risposte

Per pesare la scelta di Debian serve il contesto delle scelte altrui. Gentoo è stata la prima grande distribuzione a muoversi: il consiglio ha votato nell'aprile 2024, sei a zero, il divieto esplicito di contribuire contenuti creati con l'assistenza di strumenti di NLP, motivandolo con tre argomenti dichiarati, copyright, qualità ed etica; la policy ufficiale è sulla wiki del progetto, insieme alla clausola che la rende rivedibile se emergesse uno strumento senza quei problemi. QEMU ha seguito nel 2025 con un ragionamento più giuridico che ideologico: il progetto richiede il Developer's Certificate of Origin, con cui il contributore certifica di avere il diritto di contribuire il codice sotto la licenza del progetto, e finché lo stato legale dell'output dei generatori resta incerto, quella certificazione non è credibile; il commit che definisce la policy è di una chiarezza notarile. La parte interessante è cosa è successo dopo: nel maggio 2026 dentro QEMU è partita la discussione per allentare il divieto assoluto, con la proposta di un trailer AI-used-for: nei commit per dichiarare dove lo strumento è stato usato, perché nel frattempo contributi sospettabilmente assistiti erano già entrati e il divieto secco stava diventando una finzione difficile da difendere.

La traiettoria è leggibile: i divieti assoluti del 2024-2025 stanno convergendo verso modelli di responsabilità dichiarata, e Debian, arrivando dopo, ha potuto saltare direttamente alla destinazione senza passare per il divieto intermedio. Non è un giudizio di merito su Gentoo o QEMU, che hanno vincoli propri, il DCO di QEMU è un vincolo reale che Debian non ha nella stessa forma; è l'osservazione che il tempo sta dando ragione a chi ha normato la responsabilità invece dello strumento.

Perché ti riguarda, se il tuo mestiere è tenere su dei server

Veniamo alla parte operativa, quella che interessa chi legge questo blog. Il tuo VPS Debian è fatto di decine di migliaia di pacchetti mantenuti da una comunità nell'ordine del migliaio di sviluppatori attivi: è una supply chain, e la GR definisce le regole di ingaggio di chi la alimenta. Cosa cambia per te, in concreto? Meccanicamente niente, ed è importante dirlo senza giri: non esiste e non esisterà un'etichetta "AI-free" sui pacchetti, non puoi filtrare con apt i contributi assistiti, e chiunque ti venda un audit che pretende di distinguerli sta vendendo fumo. Quello che cambia, o meglio, quello che viene riaffermato, è dove sta la garanzia: non nella genesi del codice ma nel processo che lo porta fino a te. Il maintainer identificato e responsabile, la revisione, la QA del progetto, gli advisory di sicurezza con il loro processo, le build riproducibili che permettono di verificare che il binario corrisponda al sorgente: è questa catena a proteggerti, oggi come prima di ChatGPT. È lo stesso ragionamento che faccio per le dipendenze applicative nella guida alla supply chain security con Composer: la fiducia non si dà al codice, si dà al processo che lo seleziona e lo firma.

C'è anche un rischio simmetrico che vale la pena nominare: il panico da provenienza. Ho già sentito, in un paio di riunioni, l'argomento "allora Debian ora contiene codice AI, dobbiamo valutare alternative". È un ragionamento rotto in entrambe le premesse: primo, perché nessuna distribuzione può garantire il contrario, e chi lo promette non ha modo di verificarlo; secondo, perché sposta l'attenzione dal parametro che puoi misurare, la qualità del processo di manutenzione, a uno che non puoi misurare, la biografia di ogni diff. Se la provenienza del software ti preoccupa davvero, le energie vanno su ciò che funziona: aggiornamenti di sicurezza tempestivi, monitoraggio degli advisory, e la disciplina di gestione del parco che ho descritto parlando di point release e aggiornamenti su un parco VPS in produzione.

Vale la pena esplicitare anche l'effetto a valle, perché la portata della decisione supera i confini del progetto. Ubuntu e la costellazione delle derivate ereditano da Debian la maggioranza dei pacchetti, e con essi il lavoro dei maintainer che questa policy disciplina: la GR 2026-002 diventa di fatto la regola d'ingaggio implicita di una fetta larghissima dell'infrastruttura Linux mondiale, senza che le derivate abbiano votato nulla. È il modo in cui funziona la gravità nell'open source: le decisioni di governance prese a monte scendono lungo la catena delle dipendenze insieme al codice, e chi sta a valle le eredita, quasi mai le discute.

Il testo che vale la pena copiare

Chiudo con l'uso più concreto che puoi fare di questa storia: la GR 2026-002 è una policy aziendale sull'IA generativa già scritta, testata da un dibattito pubblico di un mese e votata da mille tecnici, e si adatta a un'azienda con quattro sostituzioni di parole. Provo a riscriverla in forma di policy interna: l'azienda non vieta e non impone gli strumenti di IA generativa; ogni artefatto prodotto con il loro aiuto deve rispettare gli stessi standard di qualità, sicurezza e conformità di qualunque altro artefatto; chi firma il lavoro ne risponde per intero, il che presuppone averlo compreso e riesaminato; i dati riservati non entrano in servizi esterni non approvati. Quattro frasi, nessun comitato, nessun modulo in tre copie. L'unico lavoro vero che resta da fare è definire cosa significhi "servizi non approvati" nel tuo contesto: una whitelist esplicita di strumenti e piani contrattuali, rivista ogni sei mesi, e per i dati davvero sensibili la valutazione onesta dell'inferenza self-hosted, che il problema lo elimina alla radice invece di regolarlo. La maggior parte delle policy AI aziendali che ho letto negli ultimi due anni dice le stesse cose in ventisei pagine, o dice cose peggiori in due.

Il punto profondo, quello che il voto di agosto ha messo nero su bianco, è che gli strumenti passano e la responsabilità resta. Debian ha attraversato in trent'anni i flame sul C++, l'arrivo dei build system esoterici, systemd, e ne è uscita ogni volta con lo stesso principio: si giudica il lavoro, risponde la persona. L'IA generativa è il test più recente di quel principio, non la sua eccezione. Se stai definendo adesso le regole d'uso degli LLM nel tuo team, o se ti serve una mano a capire quanto del panico e dell'entusiasmo che circolano meriti spazio nelle tue decisioni infrastrutturali, contattami per una consulenza: distinguere le policy che proteggono davvero da quelle che producono solo attrito è diventato una parte non piccola del mio lavoro.