Abstract
L’articolo spiega a chi appartengono i diritti su un software sviluppato con strumenti di intelligenza artificiale e quali prove servono per dimostrare il contributo creativo umano. Il focus è su titolarità, ruolo dell’AI, rischi legati al codice generato e documentazione utile per proteggere il software.
Chi può rivendicare diritti sul software sviluppato con l’AI?
Quando un software viene sviluppato anche con strumenti di intelligenza artificiale, la titolarità dei diritti deve essere ricostruita distinguendo tre posizioni: i) il sistema AI utilizzato nel processo di sviluppo; ii) il provider che mette a disposizione lo strumento e iii) l’utente umano che progetta, guida e integra il risultato.
Il sistema AI resta uno strumento tecnico. Nel diritto italiano ed europeo, l’autore è il soggetto umano che realizza un’opera dell’ingegno dotata di carattere creativo. L’intelligenza artificiale può generare testo, codice, funzioni o soluzioni tecniche, ma non può assumere la paternità giuridica dell’opera.
Questo principio, già affrontato in “Chi è l’autore di un’opera creata con l’intelligenza artificiale?”, vale anche quando l’opera è un software. L’art. 1 della Legge n. 633/1941 (LDA) tutela le opere dell’ingegno umano di carattere creativo “anche laddove create con l’ausilio di strumenti di intelligenza artificiale, purché costituenti risultato del lavoro intellettuale dell’autore”. Il riferimento all’“ausilio” chiarisce il ruolo dell’AI: uno strumento che può partecipare al processo tecnico di generazione, senza sostituire il presupposto umano della tutela autorale.
Il provider dello strumento AI va valutato alla luce dei Terms & Conditions applicabili.
Accanto al sistema AI, occorre considerare la posizione della società che fornisce il servizio: OpenAI, Google, Anthropic, GitHub o altri provider. In linea generale, i principali servizi non si presentano come proprietari degli output generati dall’utente. I Terms of Use di OpenAI prevedono, nei limiti consentiti dalla legge, che l’utente mantenga i diritti sugli input e possieda gli output. Anche i termini della Gemini API precisano che Google non rivendica la proprietà dei contenuti generati tramite alcuni servizi.
Queste previsioni contrattuali sono importanti, ma vanno verificate rispetto al servizio effettivamente utilizzato, perché piani gratuiti, API, account business, strumenti enterprise e integrazioni di sviluppo possono prevedere condizioni differenti. Per questo, come già evidenziato in “Contratti AI: come tutelarsi su dati, modelli, output e responsabilità”, la verifica dei termini contrattuali resta un passaggio essenziale.
L’utente umano può essere autore del software quando il risultato incorpora il suo contributo creativo. Nel software, il principio generale sull’autorialità umana si coordina con la disciplina speciale dei programmi per elaboratore. L’art. 2, n. 8, LDA tutela i programmi per elaboratore, in qualsiasi forma espressi, purché originali quale risultato di creazione intellettuale dell’autore. La Direttiva 2009/24/CE adotta la stessa impostazione: il software è protetto se costituisce una creazione intellettuale propria dell’autore.
L’utilizzo di strumenti come ChatGPT, Gemini, Claude, Copilot o Cursor è compatibile con la tutela del software quando l’essere umano mantiene un ruolo creativo effettivo nel processo. Tale contributo può emergere dalla progettazione dell’architettura, dalla selezione e modifica degli output, dall’integrazione dei moduli, dall’organizzazione del codice, dal testing e dalla revisione.
Questa conclusione è coerente con quanto da noi osservato in “Intelligenza artificiale e diritto d’autore: la creatività resta ancora umana” e in “Software e creatività: la Suprema Corte sulla tutelabilità della digital art”. Proprio con riferimento all’uso di strumenti tecnologici nel processo creativo, la Corte di Cassazione, Sezione I civile, con ordinanza 16 gennaio 2023, n. 1107, ha escluso che l’impiego di un software determini automaticamente il venir meno della tutela autorale, richiedendo invece una verifica concreta del contributo creativo umano e del peso assunto dallo strumento nella realizzazione dell’opera.
La regola operativa può essere formulata così: l’AI resta uno strumento, il provider va valutato secondo i termini contrattuali applicabili e l’utente può rivendicare diritti sul software quando il codice finale riflette un suo contributo creativo umano.
Quale contributo umano è necessario perché il software sia tutelabile?
L’utilizzo dell’intelligenza artificiale nello sviluppo software è compatibile con la tutela autorale quando il risultato finale incorpora un contributo umano creativo. Il punto decisivo è verificare se il programmatore abbia inciso sulla forma espressiva del programma attraverso scelte di architettura, selezione, organizzazione, integrazione e revisione del codice.
Nel diritto europeo, il programma per elaboratore è protetto quando è originale, ossia quando costituisce una creazione intellettuale propria dell’autore. Questo principio, sancito dalla Direttiva 2009/24/CE, è recepito anche nell’art. 2, n. 8, della Legge n. 633/1941, che tutela i programmi per elaboratore “in qualsiasi forma espressi” purché originali quale risultato di creazione intellettuale dell’autore.
Nel software, la creatività si manifesta nella forma con cui una funzione viene strutturata, organizzata e tradotta in codice. Come chiarito dalla Corte di Giustizia dell’Unione Europea nella causa SAS Institute v. World Programming, il diritto d’autore riconduce la tutela all’espressione del programma, distinguendola da idee, funzionalità, linguaggio di programmazione e formato dei dati. Questo principio è essenziale anche nel software AI-assisted: la tutela riguarda il modo in cui una soluzione viene costruita, articolata e resa operativa, quando tale forma espressiva riflette scelte creative umane.
Il contributo umano rilevante può manifestarsi in diverse fasi del processo di sviluppo: nella progettazione dell’architettura, nella scelta delle tecnologie, nella definizione dei moduli, nell’organizzazione del repository, nella selezione tra soluzioni alternative, nella riscrittura del codice generato, nell’integrazione degli output AI, nel refactoring, nel testing e nella revisione finale. In questi casi, la forma finale del software resta riconducibile a un percorso decisionale umano.
L’apporto creativo emerge con maggiore chiarezza quando il comando iniziale è seguito da selezione, revisione, adattamento e integrazione dell’output nel progetto complessivo. Il prompt assume valore probatorio soprattutto quando è accompagnato da tracce di correzione, riscrittura, test, confronto tra alternative e integrazione nel software finale. In questa prospettiva, il programmatore non si limita a formulare una richiesta funzionale, ma orienta il processo creativo e assume la responsabilità della forma finale del programma.
La distinzione è particolarmente importante perché il software è un’opera a forte componente funzionale. Molte scelte possono essere imposte da vincoli tecnici, standard di settore, interoperabilità, performance, sicurezza o compatibilità. In questi casi, la tutela autorale si concentra sugli elementi nei quali permane un margine di libertà creativa: la struttura del codice, la combinazione dei moduli, l’organizzazione delle istruzioni, il materiale preparatorio e le scelte espressive non obbligate dalla funzione.
È questa la linea che consente di collegare il tema dell’AI alla disciplina tradizionale del software, già approfondita in “Gli strumenti di tutela legale del software” e in “Come proteggere un algoritmo senza brevetto”: il diritto d’autore tutela la forma originale con cui il programma viene espresso, mentre la funzione tecnica, l’algoritmo in sé e il risultato pratico perseguito restano affidati ad altri strumenti di protezione o di regolazione contrattuale.
Quali rischi sorgono quando il codice è generato, suggerito o integrato dall’AI?
L’impiego di strumenti di intelligenza artificiale nello sviluppo software apre tre profili di attenzione:
- la proteggibilità del codice,
- la sua provenienza e
- la sicurezza giuridica del suo utilizzo.
Il primo profilo attiene alla proteggibilità del codice generato. Come già osservato prima, la tutela autorale è più solida quando il codice proposto dall’AI viene selezionato, modificato e integrato dal programmatore in una forma espressiva complessiva riconducibile a scelte umane. Al contrario, codice standard, banale o funzionalmente obbligato può risultare più debole sul piano della protezione.
Il secondo profilo concerne la somiglianza con codice preesistente. Gli strumenti di AI generativa sono addestrati su grandi quantità di dati e possono produrre output simili a porzioni di codice già esistenti, , incluse librerie, snippet o repository pubblici. In questi casi, la verifica deve concentrarsi sulla provenienza dell’output e sulla possibile incorporazione di materiale di terzi (Si. v. “Contratti AI: come tutelarsi su dati, modelli, output e responsabilità”).
Il terzo profilo si collega alle licenze open source. Un codice suggerito dall’AI può presentare analogie con componenti distribuiti con licenze permissive o copyleft. Alcune licenze impongono obblighi di attribuzione, conservazione delle notice, distribuzione del codice sorgente o rilascio delle modifiche secondo la medesima licenza. Il tema ha già trovato riscontro nella giurisprudenza nazionale, come approfondito in “Licenze open source e diritto d’autore: il Tribunale di Milano sulla violazione della licenza”: il Tribunale di Milano, Sezione specializzata in materia di impresa, con sentenza n. 7112/2023, ha affrontato il caso della violazione di una licenza open source applicata a un software, confermando il rilievo giuridico degli obblighi collegati alla conservazione delle indicazioni di copyright, delle notice e delle condizioni di licenza. L’inserimento inconsapevole di codice incompatibile con il modello di business del progetto può generare contestazioni contrattuali, richieste di rimozione, obblighi di disclosure o perdita di esclusività sul software.
Anche sul piano dei contratti e delle garanzie verso clienti, investitori o acquirenti, l’uso dell’AI assume rilievo. In operazioni di sviluppo, licenza, cessione, investimento o acquisizione, diventano centrali la titolarità del codice, la libertà da vincoli di terzi, la verifica delle licenze e la documentazione del contributo umano. Da qui l’importanza di regolare espressamente l’uso dell’AI nei contratti, come evidenziato in “Contratti AI: come tutelarsi su dati, modelli, output e responsabilità” e, con specifico riferimento alla proprietà del software, in “Proprietà del software: il riparto dei diritti tra committenti e sviluppatori”.
La regola operativa è prudenziale: il codice generato dall’AI deve essere verificato, documentato, sottoposto a controlli di similarità e compatibilità open source, integrato attraverso review umana e accompagnato da una chiara catena di provenienza. In questo modo l’uso dell’AI resta uno strumento di efficienza, senza diventare un punto debole nella tutela e nello sfruttamento del software.
Quali prove documentali servono per dimostrare titolarità e apporto umano?
La prova della titolarità di un software sviluppato anche con strumenti di intelligenza artificiale riguarda il percorso che ha condotto al codice finale: progettazione, selezione, modifica, integrazione e controllo umano.
Nel software AI-assisted, infatti, la prova non riguarda soltanto l’esistenza del codice, ma il modo in cui quel codice è stato pensato, guidato, selezionato, modificato e integrato. La giurisprudenza qualifica la valutazione dell’apporto creativo come giudizio di fatto: diventa quindi essenziale costruire una documentazione capace di raccontare il processo, non solo il risultato (cfr. Cass. civ., Sez. I, Sent., 13/06/2014, n. 13524; Cass. civ., Sez. I, Sent., 29/05/2020, n. 10300; Cass. civ., Sez. I, Ord., 08/11/2022, n. 32871 “La consistenza in concreto di tale autonomo apporto forma oggetto di una valutazione destinata a risolversi in un giudizio di fatto”).
Questa impostazione trova un interessante riscontro nella giurisprudenza della Corte di Giustizia dell’Unione Europea. Nella sentenza Painer (CGUE, 1° dicembre 2011, C-145/10), la Corte ha osservato che l’originalità di una fotografia può emergere dalle scelte libere e creative compiute dall’autore nelle diverse fasi della realizzazione dell’opera, dalla preparazione dello scatto alla selezione finale dell’immagine. Sebbene riferita alla fotografia, la pronuncia evidenzia un principio di portata generale: la creatività può manifestarsi attraverso una pluralità di decisioni che caratterizzano il processo di realizzazione dell’opera. Nel software sviluppato con strumenti di intelligenza artificiale, tale principio induce a valorizzare le scelte di progettazione, selezione, integrazione, revisione e organizzazione del codice, che possono costituire la principale manifestazione dell’apporto creativo umano.
Il primo presidio è la storia tecnica del progetto. In termini semplici, occorre conservare le tracce che mostrano come il software è nato e come è cambiato nel tempo: versioni del codice, modifiche apportate, correzioni, test, commit, note tecniche e passaggi di revisione.
Il secondo presidio è la prova del governo umano dell’AI. Questa categoria ha una funzione diversa dalla semplice cronologia dello sviluppo: serve a dimostrare come l’essere umano ha diretto lo strumento generativo. Sono utili i prompt utilizzati, gli output prodotti dal sistema, le alternative generate, le note sulle ragioni per cui una soluzione è stata accettata, scartata o riformulata, nonché le correzioni con cui il codice proposto dall’AI è stato adattato al progetto.
Il terzo presidio è la documentazione progettuale. Specifiche funzionali, documenti di architettura, diagrammi, roadmap tecniche, manuali, documentazione API, decision log e materiale preparatorio aiutano a dimostrare che il software nasce da una direzione progettuale umana.
Il rilievo della documentazione progettuale trova conferma nella giurisprudenza comunitaria in materia di software. Nella sentenza Bezpečnostní softwarová asociace (CGUE, 22 dicembre 2010, C-393/09), la Corte di Giustizia ha ricordato che l’espressione “programma per elaboratore” comprende anche “i lavori preparatori di progettazione per realizzare un programma”, purché siano tali da consentire la successiva realizzazione del programma stesso.
Questo principio è stato applicato in modo particolarmente utile, sul piano probatorio, dalla Corte d’Appello di Venezia, Sezione specializzata in materia di impresa, nella sentenza 7 giugno 2021, n. 1665. In quel caso, la Corte ha precisato che il materiale preparatorio rilevante “già presuppone l’utilizzo di un linguaggio tecnico che permetta al programmatore di procedere immediatamente alla realizzazione successiva dei codici sorgente”. La stessa Corte ha escluso la rilevanza di documenti che costituivano “nient’altro che una spiegazione del risultato che si voleva attenere [sic] con il programma” e “una indicazione specifica ai programmatori su ciò che il programma doveva fornire all’utente”.
Il principio è prezioso anche nel software AI-assisted: la documentazione progettuale dimostra le scelte che hanno dato forma al risultato finale, andando oltre la semplice descrizione dell’obiettivo del programma. Per questo documenti di architettura, diagrammi, specifiche tecniche e decision log possono diventare decisivi quando mostrano flussi logici, organizzazione dei moduli, criteri di selezione degli output, revisioni, test e integrazione del codice.
Questo profilo si collega alla tutela generale del software già approfondita in Gli strumenti di tutela legale del software e al tema della registrazione del copyright del software per vendere nell’Unione Europea. La documentazione progettuale serve a mostrare che il programma non nasce da un comando isolato, ma da scelte organizzative, tecniche ed espressive riconducibili a un autore umano.
Il quarto presidio è la provenienza del codice. Quando nel progetto entrano output AI, librerie, snippet, framework o componenti di terzi, diventa importante conservare dependency list, licenze, notice, report di similarity scan, audit open source, Software Composition Analysis e, nei progetti più strutturati, una SBOM. Questi documenti aiutano a chiarire quali parti derivano dall’apporto umano, quali provengono da componenti esterni e quali devono essere gestite secondo specifiche condizioni di licenza.
Il tema è centrale alla luce dei rischi connessi alle licenze open source, già affrontati in Licenze open source e diritto d’autore: il Tribunale di Milano sulla violazione della licenza. Inoltre, la Corte di Giustizia dell’Unione Europea, con sentenza 18 dicembre 2019, causa C-666/18, IT Development SAS contro Free Mobile SAS, ha chiarito che la violazione di una clausola di licenza di un programma per elaboratore, quando attiene a diritti di proprietà intellettuale, può integrare una violazione di diritti di proprietà intellettuale.
Il quinto presidio è la prova dell’anteriorità. Marcatura temporale, deposito del codice sorgente, deposito SIAE, registrazione del software, notarizzazione digitale e conservazione a norma servono a collocare nel tempo una determinata versione del programma. La loro funzione è probatoria: rafforzano la posizione di chi deve dimostrare che quel software, o quella specifica versione, esisteva già a una certa data.
Questi strumenti non sostituiscono la prova dell’apporto creativo umano, ma la completano. Sul punto sono utili gli approfondimenti su “La registrazione del software in SIAE tra tutela legale e pianificazione fiscale”.
Le categorie di prova sono simili in tutti i casi; cambia il grado di formalizzazione. Il singolo sviluppatore potrà fare affidamento su cronologia del codice, prompt conservati, note tecniche, test e marcature temporali. Il freelance o la software house dovranno aggiungere contratti, clausole sull’uso dell’AI, garanzie sulla provenienza del codice e regole sulla consegna del sorgente. L’azienda o il team strutturato dovranno integrare questi elementi con policy interne, ruoli, flussi di approvazione, audit periodici e conservazione documentale.
Fermo quanto già detto sui Terms & Conditions dei provider e sui materiali di terzi, il profilo contrattuale assume particolare rilievo quando il software coinvolge clienti, freelance, software house, dipendenti, collaboratori o fornitori. In questi casi, oltre a provare l’apporto creativo umano, occorre dimostrare anche la catena dei diritti economici. Sono profili già approfonditi in Proprietà del software: il riparto dei diritti tra committenti e sviluppatori, in Chi è il vero proprietario del software? e in Codice sorgente: la software house è tenuta a consegnarlo al committente?.
La prova migliore è una catena documentale coerente: storia tecnica del codice, prove del governo umano dell’AI, documentazione progettuale, controlli sulla provenienza del codice, strumenti di anteriorità e, quando necessario, contratti che chiariscano la catena dei diritti.
La regola operativa è chiara: la titolarità del software AI-assisted si difende dimostrando che l’AI ha operato come strumento e che il risultato finale riflette un percorso umano riconoscibile, verificabile e giuridicamente rilevante.
Revisionato da: Arlo Canella
Data di pubblicazione: 19 Giugno 2026
© Canella Camaiora S.t.A. S.r.l. - Tutti i diritti riservati.
È consentita la riproduzione testuale dell’articolo, anche a fini commerciali, nei limiti del 15% della sua totalità a condizione che venga indicata chiaramente la fonte. In caso di riproduzione online, deve essere inserito un link all’articolo originale. La riproduzione o la parafrasi non autorizzata e senza indicazione della fonte sarà perseguita legalmente.
Celeste Martinez Di Leo
Praticante avvocato, laureata in Giurisprudenza presso l’Università degli Studi di Pavia e in “Abogacía” presso l’Universidad de Belgrano (Argentina) a pieni voti.