TL;DR: sul copyright dei dati AI non esiste una risposta unica valida per ogni progetto. Training, fine-tuning e RAG copiano contenuti in modi diversi; fonte, licenza, finalità e rischio di sostituzione cambiano il quadro. Per una PMI la difesa più concreta è un registro delle fonti, un gate prima dell’ingestione e un contratto che chiarisca provenienza, cancellazione e responsabilità del fornitore.

La domanda “questo modello è stato addestrato legalmente?” sembra precisa, ma non basta per decidere se portare un sistema AI in azienda. Mescola almeno quattro problemi: come il provider ha costruito il modello, quali documenti aggiunge il cliente, cosa può riprodurre l’output e in quale mercato verrà usato.

Il 23 agosto 2026 TechCrunch ha ricostruito i primi casi statunitensi sul training con libri protetti. La conclusione utile non è che il training sia sempre consentito o sempre illecito. I tribunali stanno distinguendo origine delle copie, scopo dell’uso e rapporto con il mercato delle opere.

Questa è una guida operativa, non un parere legale. Serve per capire quando un progetto può proseguire con controlli normali e quando la documentazione va fermata e passata a chi segue contratti e proprietà intellettuale.

Il caso Anthropic: training e provenienza non sono la stessa cosa

Nel caso Bartz v. Anthropic, il giudice William Alsup ha separato il training dei modelli dalla creazione di una biblioteca permanente di libri. Nel giugno 2025 ha ritenuto il training un fair use nel perimetro esaminato, ma non ha esteso quella protezione alle copie scaricate da librerie pirata e conservate come raccolta. Il 20 luglio 2026 il tribunale ha dato l’approvazione finale a un accordo da 1,5 miliardi di dollari relativo alle opere incluse nella class action.

Il punto operativo è secco: una finalità trasformativa non ripulisce automaticamente una filiera di acquisizione sbagliata. Comprare, scaricare, scansionare, conservare e usare per il training sono atti distinti. Un team tecnico che registra soltanto il nome del dataset perde proprio l’informazione che serve quando arriva una contestazione: da dove proveniva ogni blocco di contenuto e con quale diritto è entrato nel sistema.

Un altro caso mostra l’altra metà del problema. Nel febbraio 2025 il District Court del Delaware ha deciso Thomson Reuters v. ROSS Intelligence. ROSS aveva usato materiale collegato a Westlaw per costruire uno strumento concorrente. Il giudice ha respinto la difesa di fair use per quel riuso. Non era un foundation model generativo paragonabile a Claude o GPT, quindi non va usato come sentenza universale sul training. Mostra però quanto pesino finalità e sostituzione commerciale.

Anche il Copyright Office statunitense, nel rapporto sul generative AI training, evita formule assolute. Indica che alcuni usi potranno rientrare nel fair use e altri no. Suggerisce di guardare quali opere sono state usate, da quale fonte, per quale scopo e con quali controlli sugli output.

Prima scelta: identifica quale sistema stai davvero costruendo

In azienda si chiama spesso “training” qualsiasi caricamento di documenti. È un errore tecnico prima ancora che giuridico. Le quattro configurazioni più comuni hanno flussi diversi.

  • Uso di un modello via chat o API: l’azienda non costruisce il modello, ma deve governare prompt, allegati, condizioni del servizio e riuso dei dati inviati.
  • RAG: i documenti vengono estratti, suddivisi e indicizzati; al momento della domanda, i frammenti pertinenti entrano nel contesto del modello. Non modificano i pesi del foundation model.
  • Fine-tuning: esempi selezionati cambiano il comportamento del modello. Provenienza e qualità del corpus diventano parte della release.
  • Training da zero o pre-training aggiuntivo: scala, copie e dipendenze aumentano. Qui serve una vera governance del dataset, non un foglio preparato a fine progetto.

La distinzione incide sul controllo da applicare. In un RAG per assistenza clienti il rischio immediato può essere l’accesso a documenti riservati da parte dell’utente sbagliato. In un fine-tuning su manuali di terzi emerge anche la domanda se la licenza consenta quell’uso e la distribuzione del risultato. Nel training di un modello destinato al mercato entrano obblighi e contenziosi che un semplice utilizzatore API normalmente non gestisce.

In Europa il provider deve mostrare più prove

Nell’Unione europea l’articolo 53 dell’AI Act richiede ai provider di modelli general-purpose di adottare una policy per rispettare il diritto d’autore dell’Unione e di pubblicare una sintesi sufficientemente dettagliata dei contenuti usati per il training. Questi obblighi si applicano dal 2 agosto 2025. La Commissione ha anche pubblicato un template comune per la sintesi dei dati di training.

La direttiva 2019/790 sul copyright nel mercato unico digitale prevede un’eccezione per text and data mining su opere accessibili lecitamente, purché il titolare non abbia riservato i diritti in modo appropriato. Per i contenuti pubblicati online, la direttiva cita anche mezzi leggibili dalle macchine.

Per una PMI che compra un servizio, questi documenti sono segnali di procurement. Non sostituiscono il contratto e non provano da soli che ogni singola opera sia stata trattata correttamente. Permettono però di distinguere il fornitore che espone fonti, categorie, policy e limiti da quello che risponde con una frase generica sul “web pubblico”.

Essere autorizzati a fare crawling non equivale ad avere una licenza per ogni uso successivo. Vale anche il contrario: un blocco tecnico non descrive da solo tutti i diritti sull’opera. Il registro deve quindi separare accessibilità tecnica, base contrattuale, eventuale opt-out e uso previsto.

Il registro minimo dei dati AI

Non serve partire da un sistema GRC costoso. Per un primo progetto basta un registro che accompagni ogni sorgente prima dell’ingestione. Io userei questi campi:

  1. nome della fonte e proprietario del contenuto;
  2. URL, percorso o sistema di origine;
  3. tipo di contenuto: testo, immagine, audio, codice o dati strutturati;
  4. base d’uso: proprietà interna, licenza, contratto cliente, pubblico dominio o altra autorizzazione documentata;
  5. finalità: ricerca, RAG interno, fine-tuning, valutazione o prodotto venduto;
  6. data di acquisizione, versione e prova della licenza disponibile in quel momento;
  7. restrizioni su conservazione, territori, redistribuzione e contenuti derivati;
  8. responsabile interno e data della prossima revisione;
  9. procedura di cancellazione dal corpus, dall’indice e dai backup;
  10. test previsti per rilevare output troppo vicini alle fonti.

La prova della licenza va conservata. Un link alle condizioni d’uso non basta se la pagina cambia sei mesi dopo. Salva una copia o un hash della versione accettata, la data e il perimetro del consenso. Per i contenuti del cliente, collega il dataset al contratto che autorizza l’elaborazione.

Il registro deve anche seguire la cancellazione. Eliminare un file dalla cartella condivisa non lo rimuove automaticamente dal vector database, dalla cache, dagli snapshot o da un dataset di fine-tuning già esportato. Senza una mappa delle copie, il diritto alla cancellazione resta una promessa difficile da eseguire.

Sette domande da fare al fornitore AI

Le risposte commerciali vanno trasformate in elementi verificabili. Prima del contratto chiederei:

  1. pubblicate una sintesi dei contenuti di training e una policy copyright?
  2. quali fonti sono licenziate, create internamente, pubbliche o raccolte dal web?
  3. come rispettate le riserve di diritti e gli opt-out leggibili dalle macchine?
  4. i prompt e i file del cliente vengono usati per addestrare modelli condivisi?
  5. come si richiede la cancellazione e quali copie restano nei backup?
  6. quali controlli riducono la riproduzione estesa di materiale protetto?
  7. chi gestisce una contestazione e quali indennizzi o limiti di responsabilità prevede il contratto?

Una risposta “usiamo solo dati pubblici” non passa il gate. Pubblico descrive la possibilità di vedere un contenuto, non il diritto di copiarlo per qualunque finalità. Anche “non salviamo i dati” è incompleto se non specifica log, sistemi antifrode, backup e sub-responsabili.

La mia take è questa: la qualità della risposta conta quanto la clausola. Un provider che non sa ricostruire il proprio flusso dati non diventa affidabile perché il contratto ha una pagina in più. Il primo controllo è la tracciabilità tecnica; il secondo è chi si assume il rischio residuo.

Caso studio: una knowledge base AI per un sito WordPress

Immagina un’agenzia che vuole aggiungere a WordPress un assistente capace di rispondere usando pagine del sito, manuali PDF e ticket storici. Il team sceglie un modello via API e costruisce un RAG. Il progetto sembra semplice: esportazione, chunking, embeddings e widget.

Il problema appare nel corpus. Le pagine WordPress appartengono al cliente, ma alcuni articoli contengono immagini con licenza limitata. I manuali includono documenti del produttore utilizzabili dal supporto, non necessariamente redistribuibili. I ticket hanno dati personali e allegati. Copiare tutto nello stesso indice rende impossibile applicare regole diverse.

La soluzione è dividere l’ingestione in tre code. La prima accetta contenuti proprietari approvati e pubblici. La seconda accetta documenti concessi per uso interno, mantiene l’accesso per ruolo e vieta citazioni estese. La terza blocca i file senza base documentata o con dati personali non necessari. Ogni record conserva fonte, versione, permessi e data di scadenza.

Il retrieval deve rispettare gli stessi permessi della sorgente. Non basta proteggere la pagina WordPress se l’indice restituisce un frammento riservato a chiunque interroghi il chatbot. Per questo collegherei identità e ruolo al filtro del vector database, registrerei i documenti recuperati e fermerei la risposta quando la fonte non può essere mostrata all’utente.

Prima del go-live farei tre test: richieste che provano a estrarre interi documenti, domande di utenti con ruolo errato e cancellazione completa di un ticket dal database fino all’indice. L’AI può aiutare a classificare i log, ma pubblicazione, invio email e aggiornamento dei contenuti restano dietro un gate umano. È lo stesso principio del controllo di accessi, costi e dati nei workflow AI.

Quando proseguire e quando fermarsi

Puoi procedere con un pilot se il corpus è circoscritto, i diritti sono documentati, la cancellazione è provata e gli output restano dentro un perimetro controllabile. Parti read-only, misura quante risposte non trovano una fonte e impedisci al sistema di inventare un’autorizzazione mancante.

Fermati se il dataset arriva da raccolte anonime, se la licenza vieta usi derivati o redistribuzione, se il fornitore non chiarisce il riuso dei prompt, oppure se il progetto punta a sostituire direttamente il prodotto editoriale da cui estrae i dati. In questi casi il rischio non si risolve con un disclaimer nel footer.

Se il dubbio riguarda un fornitore, usa un gate di cambio prima di investire nell’integrazione. Ho descritto il metodo nell’articolo sul gate per scegliere o sostituire un fornitore AI. Qui aggiungerei una condizione: nessun modello entra nel percorso critico senza una scheda aggiornata su dati di training, input del cliente e cancellazione.

Il copyright non si gestisce indovinando quale sentenza vincerà. Si gestisce costruendo una filiera che possa essere spiegata, limitata e corretta. Per una PMI è un obiettivo realistico. Costa meno farlo prima dell’ingestione che ricostruire mesi di copie dopo una contestazione.

Fonti

Approfondimenti