Il voto è aperto. Dopo una fase di raccolta delle proposte, gli sviluppatori Debian hanno avviato la procedura di risoluzione generale per decidere come considerare i contributi generati da LLM all'interno del progetto. Non è una questione di preferenza tecnicica: è una scelta su chi garantisce il codice che finisce in una delle distribuzioni più usate al mondo, anche nei server e nei deployment on-premise.

Chi segue AI-RADAR sa che il modello è solo una parte del problema. Il nodo spesso trascurato riguarda il codice e i processi che alimentano le pipeline di inference e di fine-tuning. Un LLM può produrre patch formalmente corrette ma opache nella provenienza: non esiste un autore con responsabilità legale, i dati di addestramento possono includere codice con licenze incompatibili e la revisione umana diventa più onerosa, non meno.

La tesi che emerge da questa votazione è che Debian stia trasformando una domanda tecnica in un segnale strutturale: il costo della fiducia nel software cresce quando l'automazione entra nella catena di produzione del codice. Se il progetto adotta una posizione restrittiva, i manutentori proteggono la tracciabilità a scapito della velocità; se adotta una posizione permissiva, sposta il rischio sugli auditor e sui responsabili del rilascio. Nessuna delle due strade elimina il problema di fondo: un LLM non è un contributore con identità, è una superficie statistica.

La posta in gioco oltre la singola patch

Il secondo ordine di conseguenza riguarda i manutentori. Un contributo generato da LLM può sembrare ragionevole in una diff, ma nascondere vulnerabilità sottili o comportamenti non documentati. Nelle distribuzioni usate come base per server self-hosted, questo si traduce in un onere aggiuntivo per chi deve mantenere build riproducibili e firmate. Il terzo ordine tocca le aziende: se Debian restringe l'uso dei LLM, i fornitori che integrano i suoi pacchetti possono rivendicare una catena di fornitura più controllata, ma perdono un possibile canale di automazione; se la apre, guadagnano rapidità ma devono potenziare i controlli di conformità.

Per chi valuta deployment on-premise e self-hosted, il trade-off non è nuovo. AI-RADAR propone framework analitici su /llm-onpremise per confrontare i costi di controllo e automazione, ma la decisione di Debian aggiunge un precedente di governance che pochi altri progetti possono permettersi di ignorare. Non si tratta di bloccare o accettare un tool: si tratta di stabilire chi risponde quando una patch generata da LLM diventa un problema in produzione.

Il voto, qualunque sia l'esito, non chiuderà il dibattito. Indicherà soltanto il punto in cui una comunità tecnica decide di tracciare il confine tra accelerazione e controllo. Per questo la risoluzione Debian va letta come un proxy: misura la tolleranza di un'infrastruttura open source verso un tipo di automazione che non firma, non spiega e non risponde.