Cos'è una policy sui contributi di codice generato da AI?

Una policy sui contributi di codice generato da AI è la regola con cui un progetto software, o un'azienda, stabilisce se il codice prodotto da un assistente basato su modelli linguistici può entrare nel proprio repository, a quali condizioni e con quale dichiarazione da parte di chi lo propone. Non è una presa di posizione ideologica sull'intelligenza artificiale: nasce da un problema di titolarità. Chi invia un contributo firma quasi sempre un impegno formale, un accordo di licenza o il Developer Certificate of Origin, con cui certifica di avere i diritti su ciò che consegna. Su un testo prodotto da un modello addestrato sul codice di altri quella certificazione diventa difficile da sostenere, perché nessuno sa con precisione da dove venga ogni riga. La policy serve a decidere cosa fare di quell'incertezza prima che diventi un problema legale a valle, quando il software è già nelle mani dei clienti.

Leggi anche: Rischio delle licenze open source · Il rischio legale che una libreria open source, con la sua licenza, contamini un prodotto proprietario.

Tre regimi, non due

Nel 2026 i progetti che contano hanno scelto strade diverse, e conoscerle serve perché sono i tre modelli fra cui anche un'azienda finisce per scegliere. OpenJDK vieta del tutto: la sua policy provvisoria del 9 aprile 2026 stabilisce che i contributi non devono includere contenuti generati, in tutto o in parte, da modelli linguistici o sistemi simili, e la restrizione vale per codice, testo, immagini, pull request e messaggi in lista, mentre resta libero l'uso privato di quegli strumenti per capire o analizzare il codice esistente. GCC pone una soglia: rifiuta i contributi legally significant, indicativamente sopra le quindici righe, con l'eccezione dei casi di test. Il kernel Linux sceglie invece la tracciabilità: l'assistente non può firmare la riga Signed-off-by, perché solo una persona può certificare il Developer Certificate of Origin, e il suo apporto va dichiarato con una riga Assisted-by, lasciando l'intera responsabilità a chi manda la patch.

Un esempio enterprise

Una software house italiana di trenta persone adotta gli assistenti di codice senza scrivere una riga di regolamento, come è successo quasi ovunque. Un anno dopo arriva un cliente enterprise che, in fase di rinnovo del contratto, chiede una dichiarazione su quale parte del prodotto sia stata generata da AI e su quali garanzie di titolarità l'azienda possa offrire. Nessuno lo sa: la cronologia dei commit non distingue, gli sviluppatori che avevano usato lo strumento per certe parti nel frattempo se ne sono andati, e il rischio di licenza si somma all'incertezza sulla paternità del codice. La risposta costa settimane di ricostruzione a posteriori, che una riga di policy e un campo nel messaggio di commit avrebbero ridotto a una query.

Perché conta per chi decide

La domanda riguarda sia chi contribuisce a un progetto aperto sia chi lo usa a valle, cioè chiunque abbia dipendenze open source dentro il proprio prodotto. Sapere quale policy adotta un progetto da cui si dipende è un'informazione sulla catena di fornitura, al pari della SBOM e della licenza dichiarata. Il vibe coding riguarda come si scrive il software; la policy stabilisce chi risponde del codice che ne esce. Sul versante interno la scelta non è fra vietare e lasciare correre: il modello del kernel mostra che si può accettare l'assistenza e insieme sapere dove è stata usata, che è la sola posizione difendibile davanti a un cliente o a un acquirente.

Questa voce è informativa e non costituisce consulenza legale: la formulazione di una policy interna e la valutazione dei suoi effetti contrattuali vanno fatte con un legale specializzato in proprietà intellettuale.