Fino a pochi anni fa la risposta alla domanda "chi ha scritto questo codice?" era relativamente semplice. Si poteva indicare il programmatore, il team o la software house responsabile di un modulo specifico.
Oggi la situazione è completamente diversa.
Una parte del codice può essere scritta manualmente. Un’altra può essere generata da Copilot. Un ulteriore frammento può essere creato da un agente di programmazione. Altri pezzi possono essere presi da una libreria open source. Altri ancora possono essere dipendenze di un pacchetto esterno. A questo si aggiungono API, servizi cloud, componenti pronti all’uso, framework e strumenti forniti da altre aziende.
Il sistema funziona. Ma sai davvero da cosa è stato costruito?
Il codice generato dall’AI non nasce nel vuoto
Lo sviluppo di strumenti AI per la programmazione non cambia solo il modo di scrivere software. Cambia anche la struttura della responsabilità sul codice.
Oggi un programmatore può descrivere un compito a un agente e poi ricevere una funzione pronta, un modulo, dei test, una configurazione o persino una proposta di modifiche architetturali. È una fortissima accelerazione del lavoro.
Il problema inizia quando trattiamo il codice generato come "codice dal nulla".
L’AI, infatti, non crea codice separatamente dall’intero ecosistema di sviluppo. I modelli vengono addestrati su enormi quantità di dati e il frammento generato può somigliare a soluzioni esistenti, pattern o codice disponibile pubblicamente. Proprio per questo la questione dell’origine del codice, delle licenze e della responsabilità sta diventando sempre più importante.
Questo non significa automaticamente che ogni frammento di codice generato dall’AI violi una licenza altrui. Significa però che un’organizzazione che utilizza l’AI nel processo di sviluppo del software dovrebbe trattare l’origine e la verifica del codice come parte del processo ingegneristico, e non come una curiosità legale.
Non è più solo teoria
Il 16 settembre 2026 la Corte d’Appello del 9° Circuito ha deciso una parte della causa Doe v. GitHub, in cui alcuni programmatori accusavano GitHub, Microsoft e soggetti OpenAI, tra le altre cose, di aver utilizzato codice pubblicamente disponibile su GitHub nella creazione e nell’addestramento di strumenti come Copilot e Codex.
Una delle richieste riguardava il DMCA e le informazioni sul copyright. Il tribunale ha confermato il rigetto di questa specifica accusa. Allo stesso tempo, il caso comprende anche altre questioni relative al copyright e alle licenze open source.
È importante non perché una singola sentenza dia una risposta semplice alla domanda "si può usare codice generato dall’AI".
Non la dà.
Più importante è il fatto che la disputa mostra un problema più ampio: nel mondo dell’AI, il confine tra codice scritto da un essere umano, codice generato da un modello e codice proveniente da un ecosistema software esistente diventa sempre più difficile da tracciare.
E per le aziende che sviluppano software questo significa dover gestire meglio questo processo.
Software supply chain, cioè il tuo sistema ha molti più "autori"
Nella sicurezza del software esiste da anni il concetto di software supply chain - la catena di fornitura del software.
Si tratta di tutti i componenti, gli strumenti, le librerie, le dipendenze e i processi che partecipano alla creazione del prodotto finale.
Il NIST indica in questo contesto, tra le altre cose, la necessità di gestire l’origine dei componenti, controllare le dipendenze open source, monitorare le vulnerabilità e utilizzare SBOM, cioè Software Bill of Materials.
In modo molto semplificato, un SBOM si può paragonare a una lista degli ingredienti di un prodotto.
Non dice solo "abbiamo un’applicazione". Mostra quali componenti si trovano all’interno.
Ad esempio:
- framework dell’applicazione,
- librerie esterne,
- versioni dei singoli pacchetti,
- componenti open source,
- dipendenze indirette,
- elementi forniti da fornitori terzi.
In questo modo, quando emerge una vulnerabilità in una libreria specifica, si può verificare più rapidamente quali sistemi la utilizzano.
Il NIST richiama inoltre l’attenzione sulla provenance, cioè la possibilità di ricostruire l’origine degli elementi software.
Ed è proprio qui che l’AI aggiunge un nuovo livello di complessità.
Perché alla catena esistente si aggiunge un altro modo di creare codice.
Immagina un tipico sistema aziendale
Il 40% del codice è stato scritto dal team.
Il 20% è stato creato con il supporto dell’AI.
Ulteriori frammenti sono stati generati da un agente.
Alcune librerie provengono dall’open source.
Una parte delle dipendenze è stata aggiunta dal framework.
Il sistema utilizza API di un fornitore esterno.
Un componente proviene da un pacchetto che nessuno aggiorna da due anni.
E la documentazione delle dipendenze?
È da qualche parte nel repository.
Oppure non c’è.
Il sistema funziona...
Ed è proprio per questo che il problema è invisibile. Finché non succede nulla.
E poi compare una vulnerabilità
Supponiamo che in una delle librerie venga scoperta una grave falla di sicurezza.
La domanda è: sai se il tuo sistema la utilizza?
Se hai un registro ordinato delle dipendenze, la risposta può richiedere pochi minuti.
Se non ce l’hai, inizia una ricerca manuale nei repository, il contatto con i programmatori, il controllo degli ambienti, delle versioni dei pacchetti e delle dipendenze indirette.
Ora aggiungiamo a questo il codice generato dall’AI.
Si sa quale frammento è stato creato con quale strumento?
È stata fatta una code review?
Il codice è stato coperto da test?
Sono state controllate le dipendenze?
Qualcuno ha verificato la licenza del componente?
Si può ricostruire il processo che ha portato alla creazione di un determinato frammento?
Non sono più domande solo per il programmatore.
Sono domande che riguardano la gestione del rischio tecnologico dell’azienda.
Il problema più grande non è l’AI. È l’assenza di un processo
Sarebbe facile trasformare questo articolo in un avvertimento contro l’intelligenza artificiale.
Sarebbe però una conclusione troppo semplice.
L’AI può migliorare moltissimo la produttività del team di sviluppo.
Il problema nasce quando l’azienda aumenta la velocità di produzione del codice, ma non aumenta allo stesso tempo il controllo su quel codice.
È un po’ come se una fabbrica iniziasse a produrre dieci volte più componenti, ma non aumentasse il controllo qualità, la registrazione dei materiali o il controllo dei fornitori.
In una software house gli equivalenti di questo sistema di controllo sono tra gli altri:
- code review
- test automatici
- scansione delle dipendenze
- SBOM
- monitoraggio delle vulnerabilità
- controllo delle licenze open source
- CI/CD con controlli di sicurezza
- gestione dei repository
- documentazione dell’architettura
- tracciamento dell’origine dei componenti
- chiare regole per l'uso dell'IA nello sviluppo
NIST indica anche la possibilità di integrare i meccanismi di sicurezza della supply chain direttamente nei pipeline CI/CD.
È un importante cambiamento di prospettiva.
La sicurezza non dovrebbe essere un controllo eseguito solo prima del rilascio.
Dovrebbe essere parte del processo di creazione del software.
"Chi ha scritto questo codice?" smette di essere la domanda giusta
Nel mondo dello sviluppo tradizionale si poteva chiedere chi fosse l'autore.
Nel mondo dell'AI-assisted development diventano molto più importanti le domande:
- Da dove proviene questo componente?
- Quale licenza ha?
- Chi lo ha verificato?
- Quale versione utilizziamo?
- Quali dipendenze ha?
- È ancora mantenuto?
- Conosciamo le sue vulnerabilità?
- Possiamo ricostruire la cronologia delle modifiche?
- Sappiamo dove l'IA ha partecipato alla sua creazione?
E soprattutto:
- L'azienda è in grado di dimostrare di avere tutto sotto controllo?
Perché il cliente non acquista certo "codice dall'IA". Acquista un sistema funzionante. E la responsabilità di quel sistema ricade ancora sull'organizzazione che lo fornisce e lo mantiene.
Il codice può essere automatico. La responsabilità no
Questa è probabilmente una delle trasformazioni più importanti che l'IA porta nelle software house.
Il programmatore non scompare. Il suo ruolo cambia.
Sempre più spesso non si tratta solo di scrivere un certo numero di righe di codice. Si tratta di progettare la soluzione, controllare gli elementi generati, valutare i rischi, testare, integrare, garantire la sicurezza e mantenere l'intero sistema.
Allo stesso modo l'azienda non può limitarsi a chiedersi se i suoi programmatori usano l'IA.
Dovrebbe sapere come la usano, in quale processo, con quali controlli e come questo influisce sull'intero ciclo di vita del software.
Perché tra qualche anno la domanda potrebbe non essere: "Chi ha scritto questo sistema?"
ma: "Sai ricostruire da cosa e in che modo è stato costruito?"
Se la risposta è "non proprio", il problema non è la mancanza di un altro strumento di IA.
Il problema è la mancanza di controllo sulla software supply chain.
