Un Codice per domarli tutti: sono arrivate le “buone pratiche” UE per i modelli IA di uso generale

Il Codice elenca anche una serie di capacità ad alto impatto (Appendice 1.3), tra cui:

• autonomia del modello,
• capacità di eludere il controllo umano,
• generazione di disinformazione,
• accesso ad altri sistemi,
• impatto su settori critici (sanità, finanza, istruzione…).

Anche un sistema basato su un modello di terzi può innescare obblighi da “rischio sistemico” se usato in modo non controllato o in contesti sensibili.

Resta quindi estremamente importante capire dove si ricade, in quale fascia di obblighi. Il Codice distingue con chiarezza:

1. Obblighi generali (trasparenza, copyright): valgono per tutti i fornitori di modelli GPAI (salvo open source “puri”, ex art. 53.2).
2. Obblighi rafforzati (safety, reporting, notifiche): valgono solo per i fornitori di modelli con rischio sistemico (art. 55 AI Act).

Per una PMI o un’università, la priorità quindi è capire:

• se è fornitore di un modello (e quindi soggetto all’art. 53),
• oppure fornitore di un sistema basato su modelli altrui, nel qual caso entra in gioco il Titolo III dell’AI Act, e servono le informazioni dal fornitore originario, destinatario dell’obbligo.

Per molte PMI o enti accademici, questo significa iniziare a:

• selezionare consapevolmente i modelli in base alla disponibilità di documentazione tecnica;
• documentare l’integrazione in modo tracciabile;
• richiedere esplicitamente le informazioni necessarie ai fornitori del modello, per non trovarsi esposti a responsabilità.

Nel prossimo paragrafo vedremo in concreto cosa prevede l’AI Act in materia di trasparenza:  quali documenti servono, chi li deve compilare, quando vanno condivisi — e perché anche chi non sviluppa modelli da zero non può permettersi di ignorare queste regole.

La trasparenza dei modelli non è (più) un'opzione

Fra i pilastri dell’AI Act, la trasparenza è probabilmente il più immediatamente operativo. Non a caso è stata trattata nel primo capitolo del GPAI Code of Practice, pubblicato il 10 luglio 2025. E non è un caso nemmeno che si applichi a tutti i fornitori di modelli GPAI, indipendentemente dal livello di rischio.

In pratica, se metti sul mercato un modello di intelligenza artificiale di uso generale, devi essere in grado di documentarlo, spiegarlo e renderlo… trasparente.

E sì, anche se ti chiami OpenAI, Google o Anthropic.

Ma non erano open source? No. Nonostante il nome OpenAI, né GPT-4, né Gemini, né Claude sono davvero open source nel senso richiesto dall’art. 53, comma 2 dell’AI Act. I loro pesi non sono liberamente accessibili, né le licenze consentono un riuso, modifica o distribuzione aperta.

Di conseguenza, questi fornitori sono tenuti al rispetto pieno dell’art. 53 AI Act, che impone:

1. la redazione di una documentazione tecnica completa del modello (lett. a),
2. la messa a disposizione della documentazione su richiesta dell’AI Office o delle autorità nazionali (lett. b),
3. la pubblicazione di una sintesi sui dati usati per l’addestramento (lett. d).

A chi si applica davvero l’obbligo di trasparenza? A chi sviluppa o mette sul mercato un modello GPAI, anche se lo fa internamente o per conto di terzi.

Non si applica a chi usa un modello di terzi via API, salvo che:

• lo modifichi strutturalmente (es. fine-tuning rilevante),
• o redistribuisca il modello sotto altro nome.

Per le PMI e le università che usano modelli esterni per sviluppare chatbot, tool di analisi o servizi digitali, la trasparenza resta comunque un tema centrale, perché:

• devono assicurarsi che il fornitore del modello sia conforme,
• e devono poter fornire informazioni minime ai propri clienti o partner.

Il capitolo “Transparency” del Codice di condotta chiarisce, finalmente, cosa significa “essere trasparenti” secondo l’AI Act ovvero:

Measure 1.1 – Compilare una documentazione tecnica del modello. Il fornitore deve raccogliere in un unico documento (o usare il Model Documentation Form allegato al Codice):

• nome, versione, architettura e dimensioni del modello (es. numero di parametri);
• modalità di accesso/distribuzione (API, software, SDK, ecc.);
• licenza applicata e condizioni d’uso;
• usi previsti e vietati;
• provenienza dei dati di addestramento (web, dataset pubblici, generati internamente…);
• metodi di filtraggio, annotazione e pulizia;
• misure adottate contro bias e contenuti inappropriati;
• consumi energetici e risorse computazionali impiegate per training e inferenza.

Questi dati vanno aggiornati nel tempo, e conservati per almeno 10 anni come prova di conformità (art. 78 AI Act).

Measure 1.2 – condividere la documentazione con chi ne ha diritto:

• Downstream providers (clienti, integratori): vanno informati attivamente, con documentazione chiara.
• AI Office o autorità nazionali competenti: possono richiedere accesso alla documentazione in qualsiasi momento, e il fornitore deve rispondere entro i termini indicati.

Il Codice prevede che la documentazione possa includere informazioni riservate (es. IP aziendale), ma queste sono protette da segreto industriale e non devono essere pubblicate se non strettamente necessario.

Measure 1.3 – Garantire la qualità e l’integrità della documentazione. Il fornitore deve:

• evitare modifiche accidentali,
• storicizzare le versioni,
• proteggere i file da accessi non autorizzati,
• mantenere tracciabilità sulle revisioni.

Sono raccomandati strumenti come versioning documentale, firma digitale, repository sicuri.

E chi non è fornitore di modello? Una PMI che sviluppa un’app basata su GPT-4 o un’università che usa Mistral per un progetto, non è fornitore del modello GPAI, ma potrebbe comunque:

• essere fornitore di un sistema di IA ad alto rischio (vedi Capo III AI Act),
• o avere l’obbligo di informare l’utente finale (art. 50 AI Act – sistemi a rischio limitato).

In entrambi i casi, deve chiedere la documentazione al fornitore del modello, e documentare l’integrazione nel proprio sistema in modo tracciabile.

Insomma, la trasparenza è diventata legge, ma la pratica è ancora complessa. Il Codice di condotta europeo ha avuto il merito di chiarire gli obblighi di trasparenza previsti dall’AI Act.

Ma per chi opera in una catena del valore destrutturata — come molte PMI e università — resta difficile applicarli senza supporto.

• Chi usa un modello via API non sempre riceve le informazioni minime necessarie.
• Chi integra modelli esterni non sa se e quando deve assumersi la responsabilità documentale.
• Mancano strumenti pratici (moduli digitali, flussi decisionali pubblici, esempi per settore).
• Chi vende soluzioni IA a clienti pubblici o corporate si troverà a breve obbligato a fornire risposte concrete.

Per questo, oggi, essere genericamente “trasparenti” non basta a essere conformi. Serve un quadro operativo, bisogna studiare a fondo e – spesso – anche una figura terza che aiuti l’impresa a documentare ciò che sta effettivamente facendo.

Il diritto d’autore entra nel cuore dell’intelligenza artificiale

Nel dibattito sull’IA, il diritto d’autore è rimasto a lungo sullo sfondo. Oscurato da parole come trasparenza, bias, sicurezza, è riemerso con forza solo quando autori, editori, giornalisti e creativi hanno iniziato a domandarsi – legittimamente – da dove arrivano i dati con cui vengono addestrati i modelli generativi (cfr. L’AI Act ha ucciso il Copyright? Riflessioni sul plagio nell’era dell’AI – Canella Camaiora) .

L’AI Act risponde a questa domanda in modo esplicito. E lo fa all’articolo 53, lettera c): chi mette sul mercato un modello di IA di uso generale deve adottare una policy per garantire il rispetto del diritto d’autore.

Il Codice di condotta europeo del 10 luglio 2025, nel suo capitolo dedicato al copyright, non si limita a ribadire il principio: lo traduce in cinque misure operative. È qui che il tema, da accademico, diventa aziendale.

Chi fornisce un modello, anche open source, anche gratuito, anche per uso accademico, deve poter dimostrare di:

• non aver violato i diritti d’autore durante il training;
• aver rispettato eventuali riserve di diritto (opt-out) espresse dagli autori;
• aver preso precauzioni per evitare output illeciti;
• essere contattabile in caso di reclamo da parte dei titolari dei diritti.

Non basta evitare il plagio. Serve una policy, un metodo, tracking documentale.

Insomma, la sintesi “sufficientemente dettagliata” è diventata… un po’ più chiara. Uno degli aspetti più dibattuti dell’AI Acr in rapporto al diritto d’autore era – ed è – l’obbligo di redigere e pubblicare una sintesi dei contenuti utilizzati per l’addestramento del modello (art. 53.1, lett. d). Il testo dell’AI Act parlava di qualcosa di “sufficientemente dettagliato”, ma nessuno sapeva davvero cosa significasse.

Il Codice di condotta ha fatto un primo passo. Senza dettare uno standard rigido, riconosce che la sintesi deve essere leggibile, informativa e utile per i titolari dei diritti.

Non basta dire “web data”. Non basta dire “Wikipedia e Common Crawl”. La sintesi deve dare conto delle fonti, delle tipologie di contenuti, dei criteri usati per selezionarli, ripulirli o filtrarli.

Manca ancora il template ufficiale dell’AI Office, promesso ma non ancora pubblicato. Ma il segnale politico è chiaro: la sintesi non è un esercizio cosmetico. È una misura concreta di trasparenza verso autori, editori e creativi. In Europa, i loro diritti vanno rispettati.

La Direttiva (UE) 2019/790, già recepita negli Stati membri, riconosce ai titolari dei diritti la possibilità di escludere le proprie opere dal text and data mining, anche se accessibili pubblicamente. È il cosiddetto opt-out.

Il Codice impone ai fornitori di modelli di riconoscere e rispettare questi segnali, se sono espressi in forma leggibile dalle macchine (robots.txt, metadati, header HTTP).

E qui sta il nodo: quanti crawler rispettano davvero l’opt-out? Quanti modelli sono addestrati su contenuti il cui uso era stato esplicitamente vietato? La responsabilità – secondo il Codice – è in capo al fornitore del modello, che deve poter dimostrare di aver adottato “tecnologie allo stato dell’arte” per identificare e filtrare le riserve di diritto.

È una sfida tecnica, non solo giuridica. Ma chi sviluppa o commercializza IA non può più ignorarla.

Ma l’attenzione non può limitarsi alla fase di training.  Il Codice chiarisce che anche l’output del modello può generare responsabilità, ad esempio se riproduce in modo sostanziale una fotografia, un testo, una melodia protetta da copyright.

Per questo, le misure raccomandano di:

• implementare barriere tecniche per evitare output che ricalchino i dati di training;
• vietare esplicitamente gli usi illeciti nei termini di servizio del modello;
• informare l’utente (soprattutto se il modello è open) dei limiti imposti dal diritto d’autore.

Non importa chi ha scritto il prompt (indipendentemente dalle liberatorie contenute nei termini di servizio). Se il modello genera un contenuto illecito, la catena delle responsabilità si attiva.

Il Codice non obbliga i fornitori a fare miracoli, ma a fare il possibile per ascoltare i titolari dei diritti. Serve quindi:

• un punto di contatto elettronico, chiaro e visibile;
• una procedura per ricevere e gestire reclami fondati;
• una risposta diligente e non arbitraria o superficiale…

Se un autore scopre che una sua opera è stata utilizzata (o rigenerata) dal modello, deve avere la possibilità di segnalare l’accaduto e ricevere risposta.

Chi usa modelli esterni – via API, come plugin, o integrati in sistemi verticali – non è obbligato a redigere una copyright policy, ma non è al riparo da rischi.

Se il tuo sistema genera un output che replica un’opera altrui, o se sei tu a distribuirlo a clienti o utenti finali, devi essere in grado di mostrare che il tuo fornitore (es. OpenAI, Google, Mistral…) ha fatto la sua parte. E se non ti fornisce prove sufficienti, forse è il caso di cambiare fornitore, o quantomeno di rivedere il contratto.

Il Codice ha fatto chiarezza, ma non ha semplificato la vita delle piccole imprese o degli enti accademici. Non esistono ancora:

• standard uniformi per esprimere l’opt-out;
• strumenti per verificare la provenienza dei dati nei modelli chiusi;
• check automatici sugli output;
• moduli semplificati per raccogliere e pubblicare la famosa “sintesi”.

Chi lavora in modo serio, oggi, ha solo due scelte: documentare tutto da sé, oppure farsi aiutare. Ma anche per chi è esperto di Copyright, come noi, non è sempre facile capire come muoversi… e ora ci resta da affrontare il tema più importante, quello della sicurezza e del rischio sistemico: un’area che, per ora, riguarda pochi. Ma che domani potrebbe toccare anche chi – come molti oggi – si sente solo un utilizzatore passivo.

Sicurezza e rischio sistemico: il cuore del nuovo regime europeo sull’IA

È questo il vero punto di svolta. Fino al 10 luglio 2025, la nozione di rischio sistemico nell’AI Act sembrava appartenere solo ai laboratori più avanzati, ai centri di supercalcolo, ai modelli capaci di rispondere a domande in tutte le lingue del mondo o di ragionare in modo autonomo.

Eppure, con la pubblicazione del Capitolo “Safety and Security” del GPAI Code of Practice, qualcosa è cambiato. La sicurezza è diventata metodo, documentazione, responsabilità. E la soglia per capire se un modello è “sistemicamente rischioso” si è abbassata un po’ – almeno sul piano dell’analisi tecnica.

Che cos’è davvero un “rischio sistemico”? L’articolo 3, punto 65 dell’AI Act definisce rischio sistemico come un rischio derivante da “capacità ad alto impatto” che possono causare effetti negativi su scala europea, in particolare sulla salute, la sicurezza, i diritti fondamentali o la stabilità della società.

Fin qui, nulla di nuovo. Ma il Codice ha introdotto criteri più operativi:

• una lista concreta di capacità pericolose (Appendice 1.3): come la possibilità di ingannare gli umani, eludere il controllo umano, replicarsi da soli, o automatizzare la R&S in campo biologico o nucleare;
• una lista di propensioni e configurazioni di rischio: ad esempio modelli con tendenza alla disinformazione, alla collusione, o che agiscono in ambienti non supervisionati;
• e soprattutto, un messaggio molto chiaro: anche un modello di terzi, usato male o in contesto critico, può attivare obblighi da rischio sistemico.

Ma quindi… chi è obbligato? 

Gli obblighi di sicurezza e mitigazione dei rischi sistemici valgono solo per chi è fornitore di un modello GPAI “con rischio sistemico” (art. 55 AI Act). Non per chi fornisce semplici sistemi basati su questi modelli, né per chi li usa in azienda.

Ma attenzione: il confine è sottile. Se distribuisci un tuo modello derivato (es. con fine-tuning su dati speciali), o se usi un modello in modo tale da abilitarne funzioni ad alto impatto (es. automazione decisionale in campo sanitario o militare), potresti dover rispondere come “fornitore di un modello sistemico”.

E anche se non sei tu il fornitore originario, l’AI Act ti chiederà conto di ciò che sapevi — o dovevi sapere.

Cosa prevede concretamente il Codice? Il Codice impone ai fornitori dei modelli più avanzati di:

• creare un Framework di sicurezza (artt. 55 e 56 AI Act);
• identificare e documentare tutti i rischi sistemici rilevanti, anche latenti o in evoluzione;
• adottare criteri oggettivi per decidere se un rischio è accettabile o meno (Measure 4.1);
• effettuare valutazioni indipendenti, con modelli a rischio “elicited” cioè spinti al massimo delle loro capacità;
• documentare e notificare incidenti gravi, anche potenziali (art. 73 AI Act);
• non commercializzare il modello se i rischi non sono stati mitigati.

E tutto questo va fatto prima della messa sul mercato del modello. Poi aggiornato ogni 6 o 12 mesi. Poi notificato all’AI Office.

Il Codice rovescia la logica classica del “test finale”. Non basta fare un audit prima del lancio. Serve monitoraggio continuo, analisi retrospettiva, rivalutazione periodica. Se cambiano i dati, se cambia l’uso, se emergono incidenti (es. deepfake, attacchi hacker, jailbreak), il modello va rivalutato.

E se le mitigazioni non bastano, il modello va ritirato dal mercato.

Ma cosa sono le “mitigazioni”?  Le mitigazioni o “misure di sicurezza”, in concreto, si dividono in:

• safety mitigations (es. filtri, prompt di sicurezza, limitazioni d’uso, strumenti per terze parti),
• e security mitigations (es. crittografia dei pesi, accessi protetti, protezione da insider threats, bug bounty, logging delle interazioni).

Una parte importante è dedicata al rischio di (self-)exfiltration, ovvero modelli che “scappano” o che vengono trafugati e usati impropriamente da attori esterni.

E le PMI? Hanno delle esenzioni? Sì, almeno in parte. Il Codice riconosce (p. 4) che le PMI e le SMC possono:

• essere esonerate da alcuni obblighi di reporting,
• semplificare il proprio Framework di sicurezza,
• chiedere supporto all’AI Office.

Ma resta intatto l’obbligo di non mettere sul mercato modelli pericolosi. E la trasparenza minima non può essere elusa.

E per chi integra modelli altrui?

Qui si apre una zona grigia. L’AI Act non impone a chi integra modelli di valutare direttamente i rischi sistemici, ma il Codice è chiaro:

“La valutazione del rischio dovrebbe includere anche il contesto d’uso, l’architettura del sistema e le risorse disponibili in fase di inferenza.” (Principio b, p. 3 del Codice).

Se sviluppi un sistema che, combinando strumenti e accessi esterni, potenzia un modello di terzi oltre i limiti originari, potresti innescare conseguenze giuridiche — o quantomeno richieste di chiarimento da parte di clienti, enti pubblici o autorità.

In sintesi, il GPAI Code of Practice ha trasformato il concetto di rischio sistemico da formula astratta a procedura ingegneristica, tracciabile, ciclica.

Per i grandi provider, è uno spartiacque. Per le PMI e gli integratori, un campanello d’allarme: i modelli avanzati non sono più “solo strumenti”. Sono entità che vanno valutate per la loro potenziale pericolosità.

Tutte queste misure — trasparenza, copyright, sicurezza — si collegano in un modello operativo di accountability, che chiama in causa intere filiere e catene di fornitura.

Perché nell’era dell’IA, nessuno è davvero un utilizzatore passivo.