Alla scoperta delle norme dedicate all’intelligenza artificiale
Le Linee Guida per i modelli General Purpose
In alcune uscite precedenti abbiamo analizzato il Code of Practice per i modelli General-Purpose AI e le sue sfide implementative.
Oggi completiamo il quadro con l’analisi delle Guidelines pubblicate dalla Commissione Europea il 18 luglio 2025, a pochi giorni dall’entrata in vigore degli obblighi per i fornitori GPAI.
Questo documento rappresenta il tassello mancante per comprendere concretamente chi deve fare cosa e quando nel nuovo ecosistema normativo dell’intelligenza artificiale.
Le Guidelines chiariscono i confini operativi dell’AI Act per i modelli general-purpose, fornendo criteri concreti e soglie quantitative che le aziende attendevano da mesi.
Punti chiave:
- criterio quantitativo: soglia di 10²³ FLOP per identificare i modelli GPAI, con modalità specifiche (linguaggio, text-to-image, text-to-video)
- responsabilità a cascata: chiarimento della value chain dalla progettazione al deployment, con obblighi specifici per ogni attore
- modificatori downstream: nuovo framework per determinare quando chi modifica un modello diventa provider (soglia: 1/3 del compute originale)
- esenzioni open source: condizioni precise per beneficiare delle esenzioni, con limitazioni significative sulla monetizzazione
- enforcement graduale: approccio collaborativo dell’AI Office con poteri sanzionatori dal 2 agosto 2026
Ricordiamo ancora una volta che le aziende hanno fino al 2 agosto per adeguarsi, con un anno di “grace period” per l’enforcement completo (vedi la timeline nell’ultimo numero).
Come sono fatte le Linee Guida
Le Guidelines si articolano in sei sezioni principali; le affrontiamo analizzando definizioni e classificazioni, responsabilità lungo la value chain, regimi di esenzione e framework di compliance ed enforcement.
La definizione operativa dei modelli GPAI
La Commissione supera l’approccio generico dell’AI Act introducendo un criterio quantitativo preciso che combina potenza computazionale e modalità operative.
Il criterio dei 10²³ FLOP
Un modello è considerato general-purpose quando:
- il training compute supera 10²³ FLOP (operazioni in virgola mobile)
- può generare linguaggio (testo o audio), immagini da testo o video da testo
Questa soglia corrisponde all’addestramento di un modello con circa un miliardo di parametri su grandi dataset, un parametro che le aziende possono calcolare concretamente prima dell’avvio del training.
La scelta di includere solo modalità linguistiche e di generazione visuale riflette una valutazione pragmatica: i modelli linguistici mostrano la maggiore versatilità e capacità di ragionamento, mentre quelli text-to-image/video, pur più specializzati, mantengono un’ampiezza di applicazioni sufficiente per essere considerati general-purpose.
Il “training compute” per i modelli di Intelligenza Artificiale per Scopo Generale (GPAI) si riferisce all’enorme quantità di potenza di calcolo necessaria per addestrarli. Questo processo implica l’utilizzo di hardware avanzato, come le GPU, per elaborare vasti set di dati e apprendere pattern complessi. La quantità di calcolo è una metrica chiave che determina la complessità e la capacità del modello finale. Un maggiore “training compute” si traduce generalmente in modelli più potenti e accurati.
Esempi pratici di applicazione
Le Guidelines forniscono casi concreti che aiutano a distinguere i confini:
Modelli GPAI:
- modello linguistico addestrato su 10²⁴ FLOP con dati web generalisti
- modello text-to-image con training compute superiore alla soglia
Modelli NON GPAI:
- modello per trascrizione speech-to-text, anche se addestrato con 10²⁴ FLOP
- modello per gaming o simulazioni fisiche, indipendentemente dalla potenza computazionale
- modelli con training compute inferiore a 10²³ FLOP, anche se versatili.
Questa distinzione aiuta le aziende a valutare rapidamente se i loro modelli rientrano negli obblighi normativi.
Il lifecycle del modello
Un aspetto critico riguarda la continuità degli obblighi durante tutto il ciclo di vita del modello. La Commissione chiarisce che il lifecycle inizia con il pre-training su larga scala e continua attraverso tutte le modifiche successive effettuate dal provider originale.
Questo significa che:
- la documentazione deve essere aggiornata continuamente
- la policy sul copyright si applica a tutto il lifecycle
- le valutazioni di rischio sistemico sono ongoing, non one-shot.
Per le aziende, questo implica strutturare processi di governance che accompagnino il modello dalla progettazione al deployment finale.
Modelli con rischio sistemico: classificazione e procedure
La soglia di 10²⁵ FLOP per i modelli con rischio sistemico introduce obblighi aggiuntivi e procedure specifiche che le aziende devono padroneggiare.
Meccanismi di classificazione
Un modello viene classificato con rischio sistemico attraverso due vie:
- automaticamente in caso di superamento della soglia computazionale di 10²⁵ FLOP
- per designazione della Commissione basata sui criteri dell’Annex XIII, anche sotto soglia.
Il secondo meccanismo è particolarmente rilevante perché permette alla Commissione di catturare modelli che, pur non raggiungendo la soglia computazionale, mostrano capacità o impatti equivalenti.
Obblighi di notifica
La notifica alla Commissione deve avvenire entro due settimane da quando si verifica o si prevede il superamento della soglia. Questo richiede alle aziende di:
- stimare il compute necessario prima dell’avvio del training
- monitorare costantemente l’utilizzo effettivo durante l’addestramento
- sviluppare capacità predittive accurate sui consumi computazionali.
Le Guidelines specificano che la notifica deve includere la stima del compute in FLOP (con due cifre significative) e la metodologia di calcolo utilizzata.
Procedura di contestazione
Un elemento innovativo è la possibilità per i provider di contestare la classificazione presentando argomenti per dimostrare che il modello, nonostante superi la soglia, non presenta rischi sistemici.
La procedura prevede:
- presentazione di argomenti sostanziati insieme alla notifica
- valutazione della Commissione con diritto di essere sentiti
- decisione motivata di accettazione o rigetto.
Tuttavia, la presentazione di argomenti non sospende gli obblighi: il provider deve comunque conformarsi alle regole per modelli con rischio sistemico fino alla decisione finale.
La value chain dei modelli GPAI: responsabilità e ruoli
Le Guidelines affrontano una delle questioni più complesse: chi è responsabile di cosa lungo la catena del valore dell’AI.
Provider e placing on the market
Il concetto di “placing on the market” viene ampliato significativamente rispetto alle interpretazioni tradizionali. Un modello è considerato immesso sul mercato quando:
- viene reso disponibile tramite API
- è caricato su repository pubblici
- viene fornito tramite servizi cloud
- è integrato in chatbot o app mobile
- è usato per processi interni che impattano diritti di persone fisiche nell’UE
Quest’ultimo punto è particolarmente rilevante: anche l’uso interno di modelli GPAI può configurare “placing on the market” se i processi influenzano i diritti dei cittadini europei.
Modelli integrati in sistemi AI
Le Guidelines chiariscono tre scenari critici:
Autointegrazione: quando il provider del modello lo integra nel proprio sistema AI, mantiene tutti gli obblighi GPAI oltre a quelli per sistemi AI
Fornitura a downstream: l’upstream provider mantiene gli obblighi GPAI, il downstream quelli per sistemi AI
Fornitura extra-UE con deployment UE: se l’upstream non ha escluso esplicitamente l’uso UE, rimane provider GPAI; altrimenti la responsabilità passa al downstream
Questo framework aiuta le aziende multinazionali a strutturare accordi contrattuali che allochino chiaramente le responsabilità normative.
Modificatori downstream: la nuova frontiera
Una delle innovazioni più significative riguarda i “modificatori downstream”, ossia gli “attori” che modificano modelli GPAI esistenti.
Criterio di responsabilità
Un modificatore diventa provider del modello modificato quando il compute utilizzato per la modifica supera un terzo del training compute del modello originale.
Se il modificatore non conosce questo valore, si applicano soglie sostitutive:
- 1/3 di 10²⁵ FLOP (circa 3,3×10²⁴) se il modello originale ha rischio sistemico
- 1/3 di 10²³ FLOP (circa 3,3×10²²) negli altri casi.
Obblighi limitati
Quando un modificatore diventa provider, i suoi obblighi sono limitati alla modifica:
- documentazione solo delle modifiche apportate
- policy copyright solo per i dati aggiuntivi utilizzati
- summary del contenuto limitato ai nuovi dati di training.
Questo approccio bilanciato evita di scoraggiare l’innovazione downstream mantenendo la tracciabilità necessaria.
Modelli derivati con rischio sistemico
Se si modifica un modello già classificato con rischio sistemico, il modello risultante è automaticamente classificato con rischio sistemico, richiedendo notifica alla Commissione e compliance completa agli obblighi aggiuntivi.
Esenzioni open source: condizioni e limitazioni
Il regime di esenzioni per modelli open source è più restrittivo di quanto molte aziende potrebbero aspettarsi.
Scope delle esenzioni
Le esenzioni si applicano solo a:
- obbligo di documentazione tecnica (Art. 53(1)(a))
- obbligo di fornire informazioni ai provider downstream (Art. 53(1)(b))
- obbligo di rappresentante autorizzato per provider extra-UE (Art. 54)
Non sono esentate:
- le policy di compliance copyright (Art. 53(1)(c))
- le summary pubbliche del contenuto di training (Art. 53(1)(d)).
Inoltre, nessuna esenzione si applica ai modelli con rischio sistemico, indipendentemente dalla licenza open source.
Condizioni sulla licenza
La licenza deve garantire quattro diritti fondamentali:
- accesso: ottenimento gratuito senza restrizioni discriminatorie
- uso: utilizzo senza limitazioni oltre attribuzione e distribuzione sotto stessi termini
- modifica: alterazione libera del modello
- distribuzione: ridistribuzione del modello originale e derivati
Sono escluse licenze che limitano:
- uso non commerciale o solo ricerca
- distribuzione del modello o componenti
- uso sopra determinate soglie di utenti
- uso commerciale con licenze separate.
Assenza di monetizzazione
Il concetto di monetizzazione è interpretato estensivamente e include:
- modelli dual-license (gratuito accademico/a pagamento commerciale)
- servizi tecnici indispensabili per il funzionamento del modello
- hosting esclusivo su piattaforme a pagamento o con pubblicità
- raccolta di dati personali (trattata come monetizzazione).
Sono invece permessi:
- servizi opzionali che non influenzano l’uso gratuito
- versioni premium con funzionalità aggiuntive
- supporto commerciale facoltativo.
Trasparenza sui parametri
I modelli devono rendere pubblici:
- parametri e pesi del modello
- informazioni sull’architettura
- informazioni sull’uso del modello (modalità input/output, capacità, limitazioni)
- istruzioni tecniche per l’integrazione in sistemi AI
La trasparenza deve essere sufficiente per permettere effettivamente accesso, uso, modifica e distribuzione.
Enforcement e compliance: timeline e approccio
L’AI Office adotta un approccio graduale che bilancia compliance e supporto all’innovazione.
2 agosto 2025: entrata in vigore degli obblighi per provider GPAI
2 agosto 2026: inizio poteri sanzionatori dell’AI Office
2 agosto 2027: compliance completa richiesta per modelli pre-esistenti.
Approccio collaborativo
L’AI Office privilegia:
- cooperazione informale durante il training dei modelli
- reporting proattivo da parte dei provider
- dialogo strutturato nelle procedure formali
Per i modelli con rischio sistemico, l’aspettativa è di cooperazione continua con l’AI Office durante tutto il lifecycle.
Poteri di enforcement
Dal 2026, l’AI Office potrà:
- richiedere informazioni (Art. 91)
- condurre valutazioni dei modelli (Art. 92)
- ordinare misure correttive incluso il ritiro dal mercato (Art. 93)
- infliggere sanzioni fino al 3% del fatturato globale o 15 milioni di euro (Art. 101).
Considerazioni per modelli pre-esistenti
Per i modelli immessi sul mercato prima del 2 agosto 2025, le Guidelines introducono flessibilità significative:
- non è richiesto retraining quando impossibile o sproporzionato
- informazioni mancanti sui dati di training devono essere documentate e giustificate nella policy copyright
- il summary del contenuto può essere incompleto se il recupero comporta oneri sproporzionati-
Tuttavia, queste limitazioni devono essere chiaramente documentate nelle policy aziendali.
Supporto alla compliance
L’AI Office si impegna a:
- supportare provider che anticipano difficoltà di compliance
- considerare la situazione particolare di chi non ha mai immesso modelli con rischio sistemico sul mercato
- monitorare lo sviluppo dell’ecosistema di valutatori esterni.
Per i provider che prevedono difficoltà, l’invito è a contattare proattivamente l’AI Office per definire piani di compliance graduali.
Calcolo del training compute: metodologie pratiche
L’Annex delle Guidelines fornisce indicazioni concrete per stimare il training compute, elemento cruciale per tutte le soglie normative.
Quanto agli approcci di stima, si tratta di una parte del documento decisamente complessa ma, in sostanza, possiamo dire che le aziende possono scegliere tra due metodi principali.
Il primo metodo calcola quanto hanno lavorato effettivamente le GPU: si moltiplicano numero di processori utilizzati, ore di utilizzo, potenza teorica e percentuale di utilizzo effettivo.
Il secondo metodo usa una formula semplificata per modelli linguistici standard: il risultato è circa 6 volte il numero di parametri del modello moltiplicato per i token di addestramento utilizzati.
Per il calcolo bisogna includere tutto il lavoro computazionale che ha effettivamente contribuito al modello finale, compresi i dati sintetici generati internamente (anche quelli poi scartati). Vanno invece esclusi i processi di test, valutazione e ricerca esplorativa che non impattano direttamente il modello.
Le Guidelines accettano un margine di errore del 30%, purché le aziende documentino il metodo usato e le incertezze della stima.
Implicazioni
Le Guidelines completano il framework normativo europeo per l’AI, fornendo la chiarezza operativa che le aziende attendevano. Tuttavia, emergono alcune considerazioni per l’implementazione.
La soglia di 10²⁵ FLOP per i modelli con rischio sistemico potrebbe presto includere centinaia di modelli, snaturando l’intento originario di catturare solo i più avanzati.
L’AI Office riconosce che l’ecosistema di valutatori esterni è ancora in sviluppo, con metodologie potenzialmente inconsistenti.
Le restrizioni sulla monetizzazione e l’esclusione completa per modelli con rischio sistemico potrebbero limitare significativamente lo sviluppo open source di AI avanzata.
Azioni
Come procedere, dunque?
Qui alcuni consigli.
- Assessment: verificare se i modelli attuali o pianificati rientrano nelle soglie GPAI
- Capacity building: sviluppare competenze per calcolare training compute con le metodologie indicate
- Process design: strutturare processi di governance che accompagnino tutto il lifecycle dei modelli
- Value chain mapping: chiarire ruoli e responsabilità con partner upstream e downstream
- Compliance planning: definire piani di adeguamento entro il 2 agosto, considerando il supporto dell’AI Office
Il successo nell’implementazione dipenderà dalla capacità delle organizzazioni di integrare questi requisiti nei processi di sviluppo e business, trasformando la compliance da adempimento a vantaggio competitivo.
👾 👾 👾
La newsletter va in vacanza: ci prendiamo una piccola pausa.
Ci rivediamo a settembre!
👾