«Abbiamo fatto fine-tuning di un modello sui nostri ticket di assistenza: adesso siamo un fornitore di IA come OpenAI?» È una delle domande che sentiamo più spesso. La risposta breve: quasi certamente non sei fornitore del modello, ma quasi certamente sei fornitore di un sistema. Sono due cose diverse, con obblighi diversi, e confonderle porta a sbagliare in entrambe le direzioni: allarmarsi per obblighi che non si hanno, o ignorare quelli che si hanno davvero.
Tre livelli da non confondere
Il Regolamento UE 2024/1689 (AI Act) distingue:
| Livello | Chi è | Quando ci sei dentro |
|---|---|---|
| Modello GPAI | Fornitore del modello per finalità generali (art. 3(63)) | Hai addestrato il modello, o lo hai modificato in modo significativo |
| Sistema di IA | Fornitore del sistema e «fornitore a valle» (art. 3(68)) | Hai costruito un'applicazione su un modello e la metti in servizio a tuo nome |
| Sistema ad alto rischio | Fornitore ai sensi dell'art. 25(1) | Hai cambiato la finalità di un sistema generico rendendolo ad alto rischio |
Una stessa azienda può trovarsi su più livelli contemporaneamente. Vediamoli uno per uno.
Livello 1: il fine-tuning e la soglia di un terzo
Le linee guida della Commissione sugli obblighi dei fornitori di modelli GPAI (18 luglio 2025) chiariscono che chi modifica o fa fine-tuning di un modello di terzi — il «modificatore a valle» — non assume automaticamente gli obblighi del fornitore. Lo diventa solo se la modifica è significativa, e la Commissione la presume tale quando il calcolo usato per la modifica supera un terzo di quello impiegato per addestrare il modello originale.
Se il calcolo originale non è noto, si usano soglie sostitutive: un terzo di 10^23 FLOP (la soglia indicativa per considerare un modello GPAI) oppure, per i modelli a rischio sistemico, un terzo di 10^25 FLOP.
Due conseguenze pratiche:
- Un fine-tuning aziendale tipico — qualche migliaio di esempi su ticket, contratti o schede prodotto — usa in genere una frazione minima del calcolo di addestramento di un grande modello, e resta sotto soglia.
- Anche sopra soglia, per un modello senza rischio sistemico gli obblighi dell'art. 53(1) si limitano alla modifica: documentare i cambiamenti e i nuovi dati di addestramento, adottare una policy sul diritto d'autore, pubblicare la sintesi dei contenuti usati.
RAG e prompt engineering non modificano i pesi e non comportano addestramento: non entrano nel calcolo.
Cosa fare comunque: registra quanto calcolo hai usato e su quale modello di partenza. Se un giorno qualcuno ti chiede perché non ti consideri fornitore del modello, quel numero è la risposta.
Livello 2: chi costruisce l'applicazione è fornitore del sistema
Qui sta l'errore più frequente. Per l'AI Act è fornitore chi sviluppa un sistema di IA e lo immette sul mercato o lo mette in servizio a proprio nome — e la messa in servizio comprende l'uso proprio. Un assistente interno costruito su un LLM via API, un chatbot sul sito, un classificatore di email: se lo hai sviluppato tu (o lo hai fatto sviluppare per te), sei il fornitore di quel sistema e, poiché integra un modello altrui, un fornitore a valle (art. 3(68)).
Non c'è un pacchetto unico di obblighi: dipendono dal rischio del sistema.
Gli obblighi più comuni
- Trasparenza (art. 50(1)): se il sistema interagisce con persone, devono sapere che parlano con un'IA. Si applica ai sistemi immessi sul mercato dal 2 agosto 2026.
- Contenuti sintetici (art. 50(2)): se genera testo, immagini o audio, gli output vanno marcati in formato leggibile da una macchina; per i sistemi già sul mercato prima del 2 agosto 2026 la scadenza è il 2 dicembre 2026.
- Alto rischio: se il sistema rientra nell'Allegato III, si applicano gli obblighi dell'art. 16 dal 2 dicembre 2027, dopo il rinvio introdotto dal Regolamento (UE) 2026/1744.
Il livello di sistema è anche quello in cui vive il GDPR: i dati che passano nei prompt, nei documenti recuperati o nel dataset di fine-tuning restano dati personali, con tutte le basi giuridiche e le valutazioni del caso.
Livello 3: cambiare la finalità può renderti fornitore ad alto rischio
L'art. 25(1)(c) prevede che chi modifica la finalità prevista di un sistema di IA — incluso un sistema per finalità generali — non classificato ad alto rischio, in modo tale che lo diventi, sia considerato fornitore di un sistema ad alto rischio. Il fornitore originario, a quel punto, non è più considerato fornitore di quel sistema specifico (art. 25(2)).
Esempio concreto: usare un assistente generico per selezionare candidati o valutare il merito creditizio dei clienti. Non serve alcun fine-tuning: basta il nuovo uso. Gli altri due casi dell'art. 25(1) riguardano chi appone il proprio nome o marchio su un sistema ad alto rischio già sul mercato e chi vi apporta una modifica sostanziale.
Cosa puoi pretendere dal fornitore del modello
Se integri un modello GPAI, hai diritto a una base documentale. L'art. 53(1)(b) obbliga il fornitore del modello a mettere a disposizione di chi lo integra le informazioni dell'Allegato XII: capacità, limiti e quanto serve per adempiere ai tuoi obblighi.
Gli obblighi dei fornitori GPAI si applicano dal 2 agosto 2025 (per i modelli già sul mercato prima di quella data, entro il 2 agosto 2027) e dal 2 agosto 2026 la Commissione può farli rispettare anche con sanzioni fino al 3% del fatturato mondiale o 15 milioni di euro (art. 101). Tradotto: oggi hai più leva di prima per chiedere quella documentazione — e dovresti archiviarla.
Checklist in cinque passi
- Censisci ogni applicazione che usa un modello GPAI, interna o esterna, e chi l'ha sviluppata.
- Per ogni fine-tuning, annota modello di partenza, dataset e calcolo impiegato, e confrontalo con la soglia di un terzo.
- Qualifica il sistema: interagisce con persone? genera contenuti? rientra nell'Allegato III?
- Verifica la finalità d'uso reale, non quella dichiarata: è lì che scatta l'art. 25(1)(c).
- Raccogli e archivia la documentazione dell'Allegato XII del fornitore del modello, insieme alla tua analisi.
Da dove partire
La classificazione dei ruoli è il primo atto di qualsiasi percorso di conformità: sbagliarla significa costruire tutto il resto su un presupposto falso. Un gap assessment indipendente mappa le tue applicazioni sui tre livelli, verifica le soglie e ti dice con precisione quali obblighi hai davvero — e quali no.