C'è una confusione molto diffusa nel modo in cui si parla di intelligenza artificiale, e riguarda qualcosa di fondamentale: cosa significa "fare un'AI". Non è una distinzione tecnica fatta per il gusto di essere precisi. È una distinzione che, sotto l'AI Act europeo, determina chi sei, che obblighi hai, e di cosa puoi essere ritenuto responsabile se qualcosa va storto.
Ritengo che il punto di partenza per capire le implicazioni legali sia tecnico: bisogna chiarire cosa c'è dietro queste diverse modalità, prima ancora di ragionare su chi risponde di cosa.
Il pre-training: dove nasce davvero un modello
Alla base di tutto c'è l'addestramento iniziale, il cosiddetto pre-training. È il processo in cui un modello viene addestrato da zero su quantità enormi di testo: miliardi di pagine web, libri, articoli, codice sorgente. Questo processo richiede infrastrutture di calcolo che costano decine o centinaia di milioni di euro, cluster di migliaia di GPU che girano per settimane o mesi, e team specializzati di ricercatori e ingegneri.
Nella pratica, questo è territorio riservato a un piccolo numero di attori: OpenAI con GPT, Google con Gemini, Meta con Llama, Anthropic con Claude, Mistral con i propri modelli europei. Dire "addestro un modello da zero" per una startup o un singolo sviluppatore è tecnicamente possibile solo per modelli molto piccoli e limitati. Per i modelli linguistici di grandi dimensioni, il pre-training è fuori portata al di fuori delle Big Tech.
Questo livello è anche quello con la maggiore esposizione legale nella filiera. È qui che nascono i problemi di copyright sui dati di training, che le cause intentate da editori e artisti contro OpenAI, Google e altri stanno cercando di definire. È qui che si determina il comportamento di base del modello, incluse le sue tendenze, i suoi bias, le sue lacune.
Il fine-tuning: adattare senza ricreare
Il passo successivo nella catena è il fine-tuning. Invece di addestrare tutto da zero, si prende un modello già addestrato e lo si adatta a un compito specifico usando un dataset molto più piccolo e mirato. Un modello fine-tunato su contratti legali italiani risponderà in modo molto più preciso a domande di diritto contrattuale italiano di quanto farebbe il modello base. Un modello fine-tunato su referti medici capirà meglio il linguaggio clinico.
Tecnicamente, le tecniche moderne di fine-tuning come LoRA (Low-Rank Adaptation) rendono questo processo accessibile anche con risorse limitate: invece di modificare tutti i miliardi di parametri del modello base, si aggiungono piccoli strati di pesi aggiuntivi che vengono addestrati sul nuovo dataset, mentre i parametri originali restano congelati. Il risultato è un modello specializzato che richiede una frazione del calcolo di un training completo.
Dal punto di vista giuridico, questa è la zona più complessa e meno regolata. Chi fa fine-tuning non ha costruito il modello base, ma lo ha modificato in modo significativo. Sotto l'AI Act, se hai fatto fine-tuning in modo sostanziale su un modello pre-esistente, puoi essere classificato come provider del sistema risultante, con tutti gli obblighi che ne derivano. Non sei più solo un deployer che usa uno strumento altrui: sei diventato responsabile di una parte di come il modello si comporta.
RAG e prompt engineering: usare senza modificare
Un terzo livello di intervento, sempre più diffuso, è quello che non tocca il modello base in alcun modo. Il RAG (Retrieval Augmented Generation) è una tecnica in cui si fornisce al modello, insieme alla domanda, del contesto rilevante recuperato in tempo reale da una base di dati esterna. Non si modifica come il modello ragiona: si modifica solo quale informazione ha a disposizione nel momento in cui elabora la risposta. Il prompt engineering è ancora un passo più indietro: si lavora esclusivamente su come si formula la domanda, senza toccare né il modello né la sua conoscenza.
Chi usa questi approcci è tipicamente un deployer sotto l'AI Act, non un provider. Non ha modificato il sistema AI, lo ha integrato in un contesto. Ha comunque obblighi, soprattutto per i sistemi ad alto rischio: trasparenza verso gli utenti, supervisione umana, documentazione. Ma la catena di responsabilità è diversa da quella di chi ha fatto fine-tuning.
L'open source che non è open source
C'è un ultimo aspetto che vale la pena capire bene prima di prendere decisioni su quale modello usare. Non tutti i modelli "open source" sono uguali, e la differenza non è solo tecnica.
Un modello davvero open source dovrebbe rendere accessibili: il codice di addestramento, i dati usati per addestrarlo, i pesi risultanti. Nella realtà, quasi nessun modello rilascia tutto questo. Molti rilasciano solo i pesi, che permettono di usare e fine-tunare il modello ma non di sapere su quali dati è stato addestrato. Meta con Llama, per esempio, rilascia i pesi ma con restrizioni commerciali per le piattaforme con oltre 700 milioni di utenti mensili, e non ha mai divulgato completamente i dati di training.
In ricerca accademica questo fenomeno viene già chiamato open washing: dichiarare un modello open source principalmente per ragioni di marketing, mantenendo opacità sulle componenti più sensibili. Per chi usa questi modelli in produzione, l'opacità sui dati di training significa esposizione a rischi legali che non si conoscono. Se il modello è stato addestrato su materiale coperto da copyright senza licenza, chi lo usa potrebbe ritrovarsi coinvolto in dispute che riguardano decisioni prese molto a monte della propria catena di sviluppo.
Prendere un modello "open source" e metterlo online non è una zona franca. Si ereditano potenzialmente tutti i problemi legali del modello base, compresi quelli che il suo creatore non ha mai divulgato.
Il difetto strutturale che la letteratura già segnala
L'AI Act europeo regolamenta i sistemi AI principalmente in base al loro livello di rischio: alto rischio, rischio limitato, rischio minimo. Questa classificazione ha senso per determinare quali misure di sicurezza adottare. Il problema, segnalato già in diversi studi istituzionali europei e accademici, è che due sistemi con lo stesso profilo di rischio percepito possono avere catene di responsabilità completamente diverse in base a come sono stati costruiti.
Un sistema di raccomandazione ad alto rischio sviluppato da zero da una grande azienda tecnologica e uno sviluppato da una startup tramite fine-tuning di Llama su dati proprietari sono tecnicamente nella stessa categoria di rischio. Ma il primo ha una filiera di responsabilità interna e compatta, mentre il secondo distribuisce la responsabilità tra il creatore del modello base, chi ha fatto il fine-tuning, chi ha costruito l'applicazione e chi la usa. Le garanzie che la norma richiede sono le stesse sulla carta, ma la capacità concreta di farle rispettare e di attribuire responsabilità quando qualcosa va storto è radicalmente diversa.
Questa è una delle ragioni per cui, come analizzato nell'articolo su chi risponde quando l'AI sbaglia, costruire un sistema di risarcimento civile che funzioni davvero è più complicato di quanto possa sembrare guardando solo le categorie di rischio. E perché conoscere la differenza tra training, fine-tuning e deployment non è solo un esercizio di curiosità tecnica: è il prerequisito per capire dove si posiziona la propria responsabilità nella catena, e dove finisce quella di qualcun altro. Come ha già mostrato il caso degli agenti AI autonomi, quando la catena di sviluppo è opaca, le responsabilità si moltiplicano senza che nessuno le abbia davvero previste.