Modelli GPAI e l’AI Act: guida alla compliance dell’IA generativa

Il 92% delle PMI usa almeno un sistema di intelligenza artificiale generativa per le proprie attività quotidiane. ChatGPT per scrivere contenuti, Claude per analizzare documenti, Midjourney per creare immagini. Ma quante sanno che dal 2 agosto 2025 questi strumenti, tecnicamente GPAI o General Purpose AI,  sono soggetti a obblighi specifici dell’AI Act?

A differenza dei sistemi ad alto rischio, che hanno 36 mesi per adeguarsi, i fornitori di GPAI hanno avuto solo 12 mesi.

Questa scelta riflette l’intento del legislatore europeo di intervenire direttamente sul livello tecnologico più strategico dell’intero ecosistema: i modelli di base. I modelli fondazionali, infatti, sono il punto nevralgico dell’intero ecosistema IA. Chi li controlla, controlla, indirettamente, anche le applicazioni che ne derivano: chatbot, content automation, analisi semantica, generazione testi o immagini.

Ecco perché l’AI Act non si limita a regolamentare gli sviluppatori: interessa anche chi integra, personalizza o distribuisce modelli GPAI all’interno di servizi digitali.
Usi un modello via API per generare contenuti o automatizzare task? Allora potresti avere gli stessi obblighi di trasparenza, documentazione e copyright previsti per i fornitori.

In questa guida analizziamo chi è legalmente un fornitore GPAI, quali obblighi derivano dal Regolamento, e cosa tutto questo significa per te.

Che cosa si intende per General Purpose AI Model (GPAI)

Un GPAI (General Purpose AI Model) è un modello di intelligenza artificiale progettato per svolgere compiti diversificati senza essere ottimizzato per una funzione specifica. L’articolo 3 dell’AI Act lo definisce come un modello addestrato su grandi quantità di dati che mostra “significativa generalità” e può essere adattato a molteplici scopi.

​​Questa definizione include i cosiddetti modelli foundation: strutture addestrate su grandi volumi di dati, in grado di generare o comprendere testo, immagini, suoni o video, e impiegate come base tecnologica per un’ampia gamma di soluzioni. Un esempio? Modelli come GPT-4, Claude, Gemini o LLaMA: nessuno di questi nasce per un solo compito, ma possono essere adattati a chatbot, assistenti virtuali, motori di sintesi, strumenti di analisi, automazioni e molto altro.

Per circoscrivere il perimetro di applicazione, la Commissione Europea ha introdotto un primo criterio indicativo: la soglia di 10 FLOP (floating point operations), corrispondente alla capacità computazionale impiegata per addestrare il modello.

Questa soglia è una presunzione legale. Un modello che supera questa soglia e dimostra capacità generative (come la generazione di testo, immagini o video) è presunto essere un GPAI e soggetto agli obblighi dedicati. Tuttavia, la classificazione non è rigida: un modello sotto questa soglia che dimostra comunque la “generalità significativa” richiesta dalla definizione legale rientra ugualmente negli obblighi

GPAI vs AI verticale: cosa cambia per la compliance

Caratteristica	GPAI (es. ChatGPT, Claude)	IA verticale (es. traduttore, antispam)
Versatilità	Multi-task, adattabile	Funzione singola
Training	Miliardi di parametri, dati generalisti	Dataset specifico, ottimizzato
Obblighi AI Act	Trasparenza rafforzata, documentazione origine	Obblighi base legati alla categoria di rischio
Responsabilità deployer	Verifica uso conforme per ogni applicazione	Conformità per uso specifico
Costi di compliance	Variabili, dipendono dai use case	Fissi e prevedibili

Quando un modello è GPAI: i 3 criteri pratici

Se ti stai chiedendo se lo strumento AI che usi è un GPAI, verifica queste condizioni:

1. È multitask? Lo strumento può svolgere compiti diversi da quelli previsti inizialmente? Se sì, è GPAI.
2. Si evolve nel tempo? Viene aggiornato con nuove funzionalità (es. GPT-3.5 non leggeva immagini, GPT-4 sì)? Allora è GPAI.
3. È personalizzabile via prompt? Se basta cambiare le istruzioni testuali per modificarne il comportamento, è quasi certamente GPAI.

Esempio: la tua agenzia usa Claude API per creare testi pubblicitari. Lo stesso modello, con prompt diversi, analizza recensioni clienti e genera report. È GPAI. E ha obblighi che un correttore ortografico AI non ha.

Modello vs sistema: due livelli normativi distinti

Infine, è importante distinguere tra:

• il modello GPAI: l’architettura addestrata (es. GPT-4),
• il sistema IA: l’applicazione concreta che lo incorpora (es. un chatbot per l’e-commerce o una dashboard di analytics).

Il Regolamento interviene su entrambi i livelli, ma con regole diverse: qui ci occupiamo del primo livello, che rappresenta la base tecnologica su cui molti operatori digitali costruiscono i propri servizi.

Chi è “fornitore” e quando si applicano gli obblighi dell’AI Act

Nel quadro normativo dell’AI Act, non è necessario essere gli sviluppatori originari di un modello GPAI per ricadere negli obblighi previsti. La definizione di “fornitore” adottata dal Regolamento è ampia e funzionale alla tracciabilità della responsabilità lungo tutta la catena del valore.

Secondo il testo dell’art. 3, è considerato fornitore chi:

• sviluppa un modello GPAI,
• oppure lo immette sul mercato o lo mette in servizio a proprio nome o marchio,
• oppure modifica in modo sostanziale un modello esistente (inclusi quelli open-source).

Questo significa che un’impresa può essere considerata fornitore anche senza aver addestrato direttamente il modello, ma semplicemente distribuendolo, integrandolo in un sistema proprietario, o rendendolo accessibile a terzi.

Per un approfondimento più dettagliato sui ruoli, vedi anche: Fornitore o utilizzatore? Le due qualifiche nel Regolamento AI 

Immissione sul mercato: cosa significa operativamente

Un altro concetto chiave è quello di “immissione sul mercato dell’Unione”. Si considera tale qualsiasi forma di messa a disposizione, anche gratuita, di un modello GPAI nei confronti di soggetti stabiliti nell’UE.
Questo include, ad esempio:

• l’offerta tramite API,
• la distribuzione del codice sorgente in ambienti pubblici (es. GitHub),
• il rilascio commerciale all’interno di un servizio più ampio,
• l’integrazione in sistemi digitali destinati al mercato europeo.

Il luogo in cui il fornitore ha sede legale non è determinante: un soggetto extra-UE che rende disponibile un modello a operatori europei è comunque soggetto agli obblighi del Regolamento e deve nominare un rappresentante autorizzato nell’Unione, come previsto dall’art. 54.

Quando si applicano gli obblighi?

Gli obblighi per i fornitori GPAI decorrono:

• dal 2 agosto 2025 per i modelli immessi sul mercato dopo l’entrata in vigore del Regolamento,
• dal 2 agosto 2027 per i modelli già presenti sul mercato prima di quella data (obbligo di aggiornamento e conformità retroattiva),
• dal 2 agosto 2026 decorrono le sanzioni.

Sono esclusi solo i casi in cui il modello:

• è sviluppato e usato internamente, senza essere messo a disposizione di terzi,
• o non rientra nei criteri tecnici (es. sotto soglia computazionale, non multimodale).

Obblighi per i fornitori di modelli GPAI 

Il Regolamento AI non si limita a identificare i modelli GPAI, ma definisce un insieme di obblighi che si applicano a chi li immette sul mercato dell’Unione Europea, indipendentemente dal fatto che si tratti di un modello proprietario o open-source, gratuito o a pagamento.

L’articolo 53 è il fulcro di questo sistema: introduce un regime rafforzato di trasparenza per tutti i fornitori, con l’obiettivo di rendere il comportamento dei modelli più prevedibile, tracciabile e valutabile anche da soggetti terzi.

Per chi opera a valle, come downstream provider o deployer, questi obblighi non sono un onere indiretto, ma rappresentano diritti informativi e contrattuali da esercitare con consapevolezza. Ecco i quattro obblighi principali:

Documentazione tecnica condivisa

I fornitori devono predisporre una documentazione tecnica completa, che descriva:

• caratteristiche, capacità e limiti del modello,
• modalità di addestramento,
• misure di mitigazione adottate,
• condizioni d’uso raccomandate.

Ma soprattutto, devono rendere disponibili queste informazioni ai soggetti che integrano o distribuiscono il modello.
Se operi come downstream provider, hai diritto a riceverle. E puoi (e devi) richiederle esplicitamente, anche in sede contrattuale. Se il tuo fornitore si rifiuta, è vago, o non garantisce accesso alla documentazione, ti espone a un rischio di non conformità. È un indicatore critico di rischio legale e reputazionale.

Policy sul copyright

Il Regolamento richiede che il fornitore deve dimostrare di aver rispettato le riserve di diritti (gli opt-out) che gli autori e gli editori possono aver espresso sui loro contenuti digitali, come previsto dalla Direttiva UE sul Copyright.
Questo include:

• rispetto dei segnali di opt-out (es. robots.txt o metadati machine-readable),
• esclusione di dataset notoriamente illegali,
• tracciabilità dei contenuti protetti usati nell’addestramento.

Questa clausola segna la fine dell’approccio “tolleranza zero” sul data scraping massivo. Se integri e commercializzi un servizio basato su un modello addestrato su dati palesemente illegali, esponi la tua impresa a rischi legali e reputazionali a cascata.

Riepilogo pubblico dei dataset di training

I fornitori devono pubblicare un riepilogo dettagliato e standardizzato dei dataset usati per addestrare il modello.
Il template è stato definito dalla Commissione Europea nel luglio 2025 e deve contenere:

• tipologia dei dati,
• provenienza,
• eventuali restrizioni d’uso,
• categorie escluse.

L’art. 107 chiarisce che questo riepilogo è pensato anche per titolari di copyright, stakeholder e partner downstream.
Per la tua impresa è uno strumento fondamentale di analisi precontrattuale e audit, soprattutto se offri prodotti basati su contenuti generati.

Rappresentante legale nell’UE per i fornitori extraeuropei

Se il fornitore del modello GPAI non ha una sede nell’Unione Europea, il Regolamento impone la nomina di un rappresentante legale stabilito in uno Stato membro. Questo soggetto funge da punto di contatto ufficiale per le autorità e per eventuali soggetti terzi legittimati a esercitare diritti o sollevare reclami.

L’obbligo è analogo a quanto previsto dal GDPR per i titolari del trattamento extra-UE. In pratica, ogni impresa digitale europea che si interfaccia con fornitori esterni deve verificare che la nomina sia avvenuta e sia formalmente documentata. In assenza di rappresentante, la fornitura non è conforme e il rischio ricade anche sul deployer.

Marcatura automatica dei contenuti sintetici 

Se un modello GPAI produce contenuti (testo, audio, immagini, video) generati artificialmente, il fornitore deve assicurare la possibilità di marcatura machine-readable dell’output.

Questa misura di trasparenza non riguarda solo l’utente finale: è anche un elemento di legal UX, utile per evitare rischi da deepfake o informazioni manipolate.
Il tuo compito come integratore è verificare che il fornitore metta a disposizione le API, tool o istruzioni tecniche necessarie per implementare questa marcatura.

Quando un modello GPAI è considerato a “rischio sistemico”

Il Regolamento AI distingue all’interno dei modelli GPAI una sottocategoria ad alto impatto, definita come modelli GPAI con rischio sistemico (systemic GPAI models).  

Un modello GPAI è presunto sistemico  quando il processo di addestramento ha richiesto una capacità computazionale pari o superiore a 10^25 operazioni floating point (FLOP).   

Questa soglia costituisce una presunzione legale. Come chiarito nelle Linee guida della Commissione, essa serve a identificare modelli di scala tale da avere un potenziale impatto trasversale sul mercato.   

L’effetto sul piano normativo è un processo amministrativo a più fasi:

1. Una volta superata la soglia, scatta l’obbligo di notifica immediata alla Commissione (AI Office).   
2. La Commissione procede alla designazione formale.   
3. A questo punto si attivano gli obblighi supplementari (Art. 55)  rispetto a quelli già previsti per i GPAI standard.   

È fondamentale notare che, essendo una presunzione, la classificazione può essere contestata dal fornitore (tramite richiesta di nuova valutazione), e, viceversa, la Commissione può designare un modello come sistemico anche sotto la soglia. 

Quali modelli rientrano?

A oggi, secondo le stime pubbliche e la documentazione tecnica disponibile:

• GPT-4 (OpenAI),
• Gemini 1.5 Ultra (Google),
• Claude 3 Opus (Anthropic),
• e modelli sviluppati da Mistral o Meta in versione enterprise,

potrebbero rientrare o rientreranno presto nella soglia sistemica.
In tutti i casi, la valutazione definitiva spetta alla Commissione, che mantiene un registro dei modelli GPAI classificati come sistemici, aggiornato periodicamente.

Obblighi specifici per i modelli sistemici

Chi fornisce un GPAI considerato sistemico è tenuto a rispettare requisiti rafforzati, tra cui:

• Notifica preventiva alla Commissione prima dell’immissione sul mercato,
• Test indipendenti di valutazione (red-teaming),
• Obbligo di documentazione completa sulle fonti di addestramento, struttura e capacità del modello,
• Registrazione presso l’European AI Office,
• Adozione di un sistema di compliance interno (“AI compliance framework”),
• Designazione di un referente interno per l’AI governance (Chief AI Officer o equivalente).

Questi obblighi mirano a garantire che modelli ad alta complessità tecnologica e impatto potenziale siano soggetti a un controllo anticipato, e non semplicemente correttivo o post-evento.

Recap: i 3 capitoli del Codice 

Il Codice è strutturato in tre capitoli principali, che riflettono direttamente gli obblighi di legge:   

1. Trasparenza: spiega come implementare la documentazione richiesta (Art. 53(1)(a-b));
2. Copyright: fornisce misure operative per implementare le policy sul diritto d’autore (Art. 53(1)(c));
3. Sicurezza e protezione: dettaglia la gestione del rischio per i modelli sistemici

Per la tua impresa, questa struttura è una due diligence già pronta:

• I capitoli Trasparenza e Copyright si applicano a TUTTI i fornitori di GPAI;  
• Il capitolo Sicurezza si applica SOLO ai fornitori di GPAI con rischio sistemico.

Tabella di sintesi: obblighi GPAI (Art. 53) vs. GPAI con rischio sistemico (Art. 55)

Caratteristica	GPAI (Tutti i fornitori)	GPAI con Rischio Sistemico
Fonte legale	Art. 53 AI Act	Art. 55 AI Act
Obiettivo	Trasparenza e Copyright	Gestione Rischi ad Alto Impatto
Obblighi principali	1. Documentazione Tecnica (per DPs) 2. Policy Copyright (rispetto opt-out) 3. Riepilogo Dati Training (Pubblico) 4. Marcatura output (Art. 50)	Tutti gli obblighi Art. 53, E IN PIÙ:1. Valutazione Modello (incl. Red Teaming) 2. Mitigazione Rischi Sistemici3. Report Incidenti Gravi (all’AI Office) 4. Cybersecurity avanzata
Soglia (Presunta)	N/A (Tutti i modelli GPAI)	Training > 10^25 FLOPs
Code of Practice	Cap. trasparenza, Cap. copyright	Tutti i 3 Capitoli (incluso sicurezza)

Esenzioni per i modelli open‑source

Il Regolamento AI è ambizioso, ma non cieco alla realtà tecnica e all’ecosistema della ricerca. Per questo ha previsto un regime speciale per i modelli GPAI rilasciati come open-source.

Gli articoli 53(2)  e 54(6)  stabiliscono che gli obblighi principali – come la fornitura di documentazione tecnica ai provider a valle e la nomina di un rappresentante autorizzato nell’UE – non si applicano ai fornitori di modelli GPAI open-source, purché siano soddisfatte le condizioni di trasparenza e apertura. 

L’eccezione non si applica ai modelli GPAI open-source che presentano rischi sistemici.

Scegliere un modello GPAI open-source può essere vantaggioso, ma la compliance dipende dalla sua classificazione. Un modello open-source “standard” gode di un regime di trasparenza notevolmente alleggerito. Lo stesso modello, se designato come “sistemico”, rientra pienamente negli obblighi di documentazione e gestione del rischio, indipendentemente dalla sua licenza open-source.

Come dimostrare la conformità?

La Commissione Europea, il 10 luglio 2025, ha pubblicato il Codice di buone pratiche, a cui i fornitori possono aderire volontariamente. Il suo scopo è fornire una guida operativa su come implementare concretamente gli obblighi di legge. L’adesione al Codice non conferisce automaticamente una “presunzione legale di conformità”. Tuttavia, la Commissione Europea e l’AI Board hanno confermato che il Codice è uno strumento volontario adeguato per dimostrare la conformità  e che offre “maggiore certezza legale”.  L’AI Office ha dichiarato che terrà conto dell’adesione di un fornitore al Codice durante il monitoraggio. I fornitori che scelgono di non aderire dovranno dimostrare la conformità con mezzi alternativi, che saranno possibilmente più onerosi e incerti. Il Codice è diventato, fin dal giorno della sua pubblicazione, lo standard industriale de facto per la conformità dei GPAI. 

Implicazioni e rischi per l’ecosistema digitale della tua impresa

Quando si parla di GPAI, il rischio non è astratto né confinato ai laboratori. Se il modello su cui si regge il tuo stack digitale è non conforme, il problema si propaga a catena: governance, marketing, contratti, reputation. È come costruire un’intera infrastruttura su una centrale elettrica difettosa. Quando salta lei, salta tutto il resto.

E questo vale a più livelli:

• Rischio legale: l’AI Act prevede sanzioni fino a 35 milioni di euro o il 7% del fatturato globale, anche per chi integra modelli non conformi. 
• Rischio reputazionale: usare un modello opaco, non etico o privo di tutele per gli utenti finali può erodere la fiducia del mercato in modo irreversibile.
• Rischio tecnologico: se il tuo business dipende da un modello non auditabile, non sostituibile, o non aggiornato con criteri di sicurezza, sei vulnerabile su tutta la linea.

Conformità AI Act: il metodo Legal for Digital

LI modelli generativi sono ormai parte dei processi quotidiani di molte imprese digitali.
Dal 2025, però, la loro gestione dovrà rispettare regole precise: tracciabilità, trasparenza e responsabilità documentata.

Legal for Digital interviene su questi aspetti con un approccio operativo, che integra analisi tecnica e adeguamento giuridico.
L’obiettivo non è “essere conformi”, ma rendere la compliance parte del modo in cui si lavora.

Attività principali

• Analisi dei modelli AI e valutazione del livello di rischio
• Mappatura dei ruoli e delle responsabilità previsti dal Regolamento
• Redazione della documentazione di trasparenza e aggiornamento dei registri interni
• Revisione contrattuale e policy aziendali per uso, addestramento e distribuzione dei modelli
• Formazione mirata dei team digitali e supporto nella gestione degli audit

Gestire correttamente l’AI non è un esercizio burocratico, ma una forma di governo del proprio business digitale.
Legal for Digital ti aiuta a strutturare regole e processi che reggono nel tempo — prima che lo imponga una sanzione.