Code of Practice GPAI: cosa hanno sottoscritto OpenAI, Anthropic, Google

L’AI Office UE ha pubblicato a luglio 2025 la versione finale del Code of Practice per i modelli AI di scopo generale, dopo dodici mesi di consultazioni con provider, esperti accademici, società civile. Tredici aziende hanno aderito subito, due hanno preso tempo e una si è chiamata fuori in modo platealmente pubblico. La firma di Meta che mancava all’appello ha innescato una catena di valutazioni nei team compliance delle aziende europee che usano Llama in produzione. Il punto operativo, per chi non segue solo le polemiche, è capire cosa cambia per i deployer downstream.

Il documento conta. Ma le implicazioni reali sono meno raccontate di quanto i comunicati stampa lasciavano intendere.

Cosa è il Code of Practice e perché esiste

Per inquadrare il posizionamento competitivo dei provider, è utile l’analisi sul routing automatico tra modelli. L’articolo 56 dell’AI Act prevede che la Commissione promuova codici di condotta per facilitare l’applicazione concreta degli obblighi sui GPAI. Il razionale è semplice: gli articoli 53 e 55 fissano principi generali (trasparenza sui dati di training, valutazione del rischio sistemico, segnalazione degli incidenti), ma l’implementazione tecnica concreta richiede dettaglio operativo che la legge non può anticipare.

Il Code of Practice è quel dettaglio operativo. Definisce formati standard per la documentazione tecnica, template per i riassunti dei dati di training, metodologie per la valutazione dei rischi sistemici, processi di segnalazione degli incidenti. Per i provider che vi aderiscono c’è una presunzione di conformità: chi rispetta il Code è considerato in regola con gli obblighi corrispondenti dell’AI Act, salvo prova contraria.

Per i provider che non aderiscono il quadro non cambia formalmente. Devono comunque rispettare gli articoli 53 e 55, ma devono dimostrare conformità con metodi alternativi. L’onere documentale e probatorio sale, l’esposizione al rischio normativo cresce.

Chi ha firmato e in quale capitolo

Il Code è strutturato in tre capitoli che corrispondono a tre famiglie di obblighi. Trasparenza e copyright, applicabile a tutti i GPAI. Safety e security per i modelli con rischio sistemico. Governance e processi interni.

L’evoluzione del mercato AI sotto la spinta di nuovi player complica ulteriormente la scelta del fornitore. Hanno aderito a tutti e tre i capitoli: OpenAI, Anthropic, Google DeepMind, Microsoft (per i modelli proprietari), Amazon, Cohere, IBM, Mistral, Adobe (per Firefly come parte sostanziale). Aleph Alpha e Cohere hanno aderito a tutti i capitoli con clausole interpretative su specifici punti tecnici. Apple si è iscritta nel 2026 dopo aver inizialmente preso tempo.

Meta ha rifiutato pubblicamente l’adesione. xAI di Elon Musk non ha aderito. Il rifiuto Meta è stato motivato da Mark Zuckerberg come “eccesso regolatorio incompatibile con l’innovazione open-source”. Il rifiuto xAI non ha avuto motivazioni formali pubbliche, ma è coerente con la linea generale dell’azienda di muoversi più liberamente sui temi di safety e governance.

Cosa cambia per chi usa Llama in produzione

La domanda concreta per le aziende italiane è questa. Continuare a usare Llama (modello open-weight di Meta) ha implicazioni di compliance. Vediamole.

Primo, gli obblighi di chi deploya Llama non cambiano formalmente. L’azienda italiana resta deployer e ha i suoi obblighi indipendentemente dal Code. Secondo, la documentazione di base fornita da Meta è considerata insufficiente da una parte dell’industria compliance: non rispetta i template del Code of Practice, manca di alcune sezioni che il Code richiede ai provider firmatari. Terzo, in caso di controllo l’azienda italiana che usa Llama dovrà documentare di più, da sé, per coprire le lacune.

Tradotto operativamente: usare un modello firmatario del Code riduce il costo compliance del deployer. Usare un modello non firmatario lo aumenta. Non è una preclusione legale, è una preferenza di efficienza documentale. Per una PMI italiana con risorse compliance limitate, la scelta del modello firmatario può essere economicamente sensata anche se le performance del modello non firmatario sono comparabili.

Trasparenza sui dati di training: la sezione più interessante

Il capitolo trasparenza del Code richiede ai provider di pubblicare riassunti sufficientemente dettagliati dei dati usati per il training. Il template definito a fine 2025 include categorie di fonti (web scraping, dataset aperti, contenuti licenziati, dati sintetici, dati di feedback umano), quantità approssimative per categoria, lingue principali coperte, presenza di filtri applicati (rimozione di contenuti illegali, di dati personali, di contenuti protetti da copyright).

I primi riassunti pubblicati a inizio 2026 da OpenAI, Anthropic, Google sono documenti di 30-80 pagine ciascuno. Forniscono informazioni utili senza rivelare segreti commerciali. Per gli editori italiani sono diventati materiale di lavoro: SIAE, FIEG, gruppi editoriali stanno usando queste informazioni per impostare richieste di opt-out o di licensing strutturate.

Per chi vuole verificare se il proprio sito è stato usato per training, lo strumento principale è il file robots.txt aggiornato con direttive specifiche per gli AI crawler (GPTBot di OpenAI, ClaudeBot di Anthropic, Google-Extended di Google). Il Code richiede ai provider di rispettare queste direttive almeno per i crawl successivi all’opt-out, ma il quadro storico (cosa è già stato scrapato) resta complesso.

Safety e rischi sistemici: il capitolo più tecnico

Il secondo capitolo si applica solo ai GPAI con rischio sistemico (oltre 10^25 FLOPS cumulativi). Definisce categorie di rischi sistemici da valutare: capabilità di abuso (CBRN, cyber, manipolazione), rischi di perdita di controllo, rischi di concentrazione di mercato. Per ciascuna categoria definisce metodologie di valutazione, soglie di severità, processi di mitigazione.

Sono i sistemi che i provider chiamano frontier models. GPT-5 e successivi, Claude 3 Opus e successivi, Gemini Ultra, Llama 4 (se Meta lo riconoscesse) sono nel perimetro. I provider firmatari si impegnano a Red Team test indipendenti, scenari di stress su capabilities pericolose, dialogo strutturato con AI Office su risultati e mitigazioni.

Per le aziende italiane che usano questi modelli, le implicazioni sono indirette ma sostanziali. Un modello che ha superato i Red Team test indipendenti è documentalmente più solido. Un modello su cui questi test non sono stati fatti o non sono stati pubblicizzati lascia più zone grigie nella documentazione di compliance del deployer. La community AIPIA ha pubblicato a inizio 2026 una nota tecnica per i soci che operano in settori regolamentati su come integrare queste informazioni nella propria valutazione del rischio.

Il punto cieco italiano: serve un Code Application Plan

Tra i temi di policy europea poco discussi in Italia c’è la dimensione applicativa del Code. Aderire al Code è una cosa. Applicarlo in pratica con processi documentati, controlli interni, audit indipendenti, è altra cosa. La Commissione sta lavorando su un sistema di monitoraggio dell’applicazione che diventerà operativo nel 2027.

Per le aziende italiane deployer la mossa intelligente è iniziare a chiedere ai propri fornitori non solo “avete aderito al Code” ma “potete mostrarci la vostra Code Application documentation”. I provider seri hanno già materiali pronti. Quelli meno seri si avvalgono dell’adesione formale senza investire nell’applicazione operativa. La differenza la vedrà solo chi pone la domanda giusta.

L’effetto cascata sui contratti enterprise

Quello che noto nei contratti che stanno girando dal 2026 è una clausola ricorrente che chiede al fornitore di sistemi AI di dichiarare se i modelli usati provengono da provider aderenti al Code of Practice e di committarsi a notificare al cliente eventuali cambi di fornitore. Sono clausole che le imprese più strutturate stanno mettendo nei capitolati standard, non più solo come optional.

Per chi sviluppa prodotti AI in Italia, la conseguenza pratica è la trasparenza sulla propria stack tecnologica diventa elemento commerciale. Cambiare modello sottostante non è più solo decisione tecnica, è cambio che impatta i contratti enterprise. Questo crea stabilità nel mercato ma anche rigidità per le software house.

Cosa fare entro fine 2026

Quattro azioni operative per chi opera in Italia con prodotti che integrano GPAI. Mappare quali modelli si usano e se i provider sono firmatari del Code. Per i modelli di provider non firmatari, costruire documentazione di compliance autonoma più solida. Aggiornare i contratti con clienti e fornitori per riflettere le nuove richieste di trasparenza. Predisporre risposte standard alle domande compliance che inevitabilmente arriveranno dai clienti enterprise.

Il Code of Practice non è una legge. Ha però la capacità di standardizzare aspettative di mercato in modo più rapido di quanto faccia la normativa primaria. Le aziende italiane che ne fanno strumento di lavoro hanno vantaggio competitivo, quelle che lo trattano come PR esterna restano esposte alle prossime ondate di richieste compliance.