Il codice scritto dall'AI è davvero tuo? Il caso Claude Code fa emergere un rischio reale

Una parte crescente del codice che arriva nei repository aziendali nasce con l’aiuto di strumenti come Claude Code, GitHub Copilot, ChatGPT/Codex, Cursor e altri modelli AI accessibili via API. Il problema non riguarda solo qualità, bug o sicurezza: ha a che fare anche con gli aspetti legati al copyright, alle licenze open source e alla proprietà del lavoro prodotto. Il caso del leak di Claude Code del 31 marzo 2026 ha riportato in auge una domanda fondamentale: chi possiede davvero il codice generato o riscritto da un’AI?

Anthropic ha pubblicato per errore, nel pacchetto npm @anthropic-ai/claude-code 2.1.88, una source map da circa 60 MB che esponeva oltre 512.000 righe di codice TypeScript del suo assistente AI basato su riga di comando (CLI, command-line interface).

Il materiale apparso online non includeva modelli o credenziali, ma conteneva abbastanza dettagli da mostrare architettura, componenti interni, funzionalità non ancora rilasciate e meccanismi operativi: tanto che è nata la rappresentazione visuale Claude Code Unpacked. In poche ore il codice circolava su GitHub, mentre repository derivati e riscritture in Python attiravano migliaia di sviluppatori. Anthropic ha reagito con una serie di richieste di rimozione dei contenuti ai senso della disposizione statunitense DMCA a tutela del copyright.

Il codice di programmazione non è solo una sequenza di istruzioni eseguibili, ma anche un’opera espressiva quando riflette scelte umane. Dagli anni ’80 in poi, licenze come GPL, LGPL, MIT e Apache hanno costruito gran parte dell’economia del software su questa premessa. L’arrivo dei generatori di codice basati su AI ha modificato quegli equilibri.

Il nodo giuridico: l’autore deve essere umano

La posizione del Copyright Office statunitense è chiara da tempo: un’opera priva di autorialità umana non può ottenere alcuna tutela. Il report “Copyright and Artificial Intelligence, Part 2: Copyrightability” del 2025 ribadisce che l’uso assistivo dell’AI non esclude la protezione sul diritto d’autore, ma la protezione riguarda le parti in cui una persona ha compiuto scelte creative riconoscibili. Un prompt inviato a un modello generativo, anche articolato (si pensi al fenomeno del vibe coding), non sempre è sufficiente: contano selezione, coordinamento, arrangiamento, riscrittura, direzione espressiva.

Il punto di vista europeo, in breve

In Europa la logica non cambia, anche se il riferimento normativo è diverso. La Corte di Giustizia dell’Unione Europea ha costruito il criterio dell’opera come “creazione intellettuale propria dell’autore“. Il punto è che deve emergere una traccia riconoscibile di libertà creativa umana: senza questa componente, non si attiva la tutela del diritto d’autore secondo la direttiva 2001/29/CE.

Va detto però che il diritto europeo non richiede originalità in senso artistico o uno sviluppo prevalentemente indipendente del codice. Basta che l’autore abbia compiuto scelte libere e creative, anche minime, purché non puramente meccaniche. Quando l’output è il risultato diretto di un sistema che decide struttura, naming, flussi logici e gestione degli errori, lo spazio per identificare una “impronta personale” diventa ridotto o assente.

L’utilizzo dell’AI nei progetti software europei

Per gli sviluppatori tutto questo ha delle conseguenze evidenti: se un tool genera un file e il maintainer di un progetto software lo accetta senza modifiche significative, quel file potrebbe avere una protezione debole o nulla. Se invece lo sviluppatore definisce l’architettura, scarta soluzioni, riscrive funzioni critiche, cambia la gestione degli errori e documenta le decisioni, la posizione cambia.

In Europa anche la struttura di un programma, l’organizzazione dei moduli e alcune scelte di design possono essere protette se riflettono decisioni creative. Si apre così uno scenario in cui parti non generate – come architettura, documentazione tecnica, test e orchestrazione dei componenti – possono avere una tutela autonoma, anche quando singoli blocchi di codice derivano da output AI.

Su entrambe le sponde dell’Atlantico, la domanda non è più “hai usato l’AI?” per sviluppatore il progetto, ma “dove si vede che hai deciso tu?”.

Perché il caso Claude Code è più delicato di un normale leak

Claude Code non è solo un prodotto software; è un assistente di coding che, secondo diverse ricostruzioni pubbliche, contiene parti sviluppate con ampio uso degli stessi modelli Anthropic. Se una quota sostanziale del codice nasce da output AI, la società può comunque rivendicare diritti su tutto? La risposta breve è: probabilmente su alcune parti sì, su altre la questione resta aperta.

Un repository reale non contiene solo funzioni generate: contiene nomi, organizzazione dei moduli, commenti, scelte di packaging, configurazioni, test, UI testuale, logica di telemetria, integrazioni con il terminale e politiche di esecuzione dei tool. Molti di questi elementi possono riflettere decisioni umane.

Nel caso Claude Code, il leak ha esposto un’applicazione CLI complessa: gestione sessione, invocazione dei tool, interfaccia terminale, memoria, fallback e funzionalità sperimentali. Anche se parti del codice derivassero da generazione automatica, non ne consegue automaticamente che l’intero prodotto cada fuori da ogni tutela.

Codice AI-assisted: dove nasce la prova della creatività

La formula decisiva è il concetto di meaningful human authorship ovvero “contributo umano significativo“.

Non esiste una soglia numerica: nessuna regola dice che il 30% di modifiche rende un file tutelabile o che 600 prompt bastino sempre. Il Copyright Office USA ha evitato proprio di “dare i numeri” perché il giudizio dipende dalla natura delle scelte.

Un cambiamento puramente estetico ha un impatto molto inferiore rispetto a una revisione profonda dell’architettura software; cambiare il nome delle variabili non è paragonabile alla progettazione di un sistema articolato.

Un esempio concreto può aiutare. Immaginiamo uno sviluppatore che chieda a Claude Code: “crea un modulo di rate limiting per la mia API“. L’agente genera 5 file: middleware HTTP, store Redis (il sistema di archiviazione dati), test, configurazione e documentazione. Il developer esegue i test e fa merge: in questo caso, ovviamente, il contributo umano è del tutto minimo.

Se invece lo stesso sviluppatore “ci mette farina del suo sacco“, ad esempio prevedendo una strategia di tipo token bucket (un meccanismo che limita il numero di richieste distribuendole nel tempo), evita di usare memoria locale per prevenire problemi di coerenza quando l’applicazione gira su più istanze, riorganizza la gestione delle chiavi in Redis, imposta tempi di scadenza (TTL) allineati alla finestra temporale prevista e documenta la decisione in un ADR (Architectural Decision Record, cioè un documento che registra le scelte architetturali), il comportamento complessivo cambia in modo significativo.

Ovviamente possono crearsi anche situazioni ambigue in cui gli enti chiamati all’intervento in materia di copyright riconoscano tutele per alcune parti dell’opera e non per altre.

Il rischio open source: la “contaminazione” non si vede a occhio

Una sfaccettatura importante è correlata con li tema delle licenze software: i modelli AI hanno infatti appreso, in fase di addestramento, “conoscenza” da enormi quantità di codice pubblico, incluso software distribuito sotto licenze GPL, LGPL, AGPL e altre copyleft. La questione non è se un output “assomiglia” a codice GPL dal punto di vista funzionale; non è vietato reimplementare le stesse idee. Il rischio nasce quando l’output riproduce porzioni sostanziali e riconoscibili di codice protetto, soprattutto se lo fa in modo quasi pedissequo.

GitHub Copilot ha introdotto funzioni di rilevamento delle corrispondenze con codice pubblico: il sistema può confrontare il suggerimento offerto allo sviluppatore e circa 150 caratteri circostanti con codice pubblico su GitHub.

Un controllo di questo tipo può ridurre l’accettazione di frammenti molto simili a codice già partorito da altri sviluppatori, ma non è ovviamente una garanzia assoluta.

Malus.sh è un progetto volutamente provocatorio che sostiene di riscrivere il funzionamento di software liberi e progetti open source senza violare le corrispondenti licenze.

Certo è che l’avvento dell’AI sta portando tanti soggetti a muoversi con sempre maggiori cautele. Ecco che oggi si richiedono sempre più evidenze sull’eventuale uso dell’AI, scansioni open source, si impongono policy interne e verifiche sulla provenienza del codice. Un acquirente non vuole scoprire, magari dopo un accordo economico, che un componente core contiene frammenti copyleft non dichiarati o output generati senza una minima traccia di revisione umana.

Come ridurre il rischio senza bloccare lo sviluppo

La prima misura concreta è una scansione delle licenze con strumenti come FOSSA, Snyk Open Source, Black Duck o soluzioni equivalenti. Sono strumenti che confrontano dipendenze, file e pattern con database di componenti open source; segnalano licenze, obblighi, vulnerabilità note e possibili corrispondenze sospette. Non sono infallibili, ma offrono una base molto più solida rispetto a un’analisi manuale svolta a campione.

La seconda misura riguarda i log. Conservare prompt, output intermedi e decisioni può sembrare qualcosa di meramente burocratico, ma in caso di vertenze legali tutto questo si trasforma in una prova. Un commit contenente una descrizione esplicita, in linguaggio naturale, può raccontare la sussistenza di un contributo umano ben preciso.

Ed è ancora più utile quando il documento che registra le decisioni progettuali include i vincoli del sistema, le possibili soluzioni considerate ma poi escluse e le conseguenze della scelta finale.

Il codice AI-assisted va trattato come codice con provenienza da dimostrare: chi mantiene con cura ogni traccia si troverà in posizione molto diversa da chi dovrà ricostruire  tutto in caso di necessità.

Conclusioni

Il caso Claude Code ha costretto tutti a guardare un problema che fino a poco tempo fa restava sullo sfondo: il codice generato o assistito da AI non è solo una questione tecnica perché introduce una fitta trama di concetti legati al diritto d’autore, alla responsabilità contrattuale e alla gestione del rischio open source.

Non basta dire “l’ha scritto l’AI” per escludere la tutela, così come non basta dire “l’ho fatto io” per rivendicarla. Tutto ruota attorno alla capacità di dimostrare dove e come interviene lo sviluppatore: qui si gioca la differenza tra un output generico e un’opera riconducibile a una persona.

Cambia il modo in cui va interpretato il lavoro dello sviluppatore: scrivere codice non significa produrre istruzioni, ma soprattutto progettare, selezionare, rifiutare, riscrivere e soprattutto lasciare traccia di queste decisioni. Alla fine non è quello che ha sempre sostenuto Leslie Lamport dicendo che coding e programmazione sono due concetti molto diversi?

L’obiettivo non deve certo essere quello di proibire l’uso dell’AI: sarebbe irrealistico oltre che controproducente. Il valore aggiunto deriva dal modo con cui questi strumenti sono integrati nel flusso di lavoro dello sviluppatore: ci vogliono uso consapevole, separazione degli ambienti, controllo delle licenze e disciplina nella documentazione.