AI Act e imprese: cosa prevedono le Linee guida europee e come rispettarle

Chi è considerato fornitore di IA e quali responsabilità ha secondo l’AI Act?

Le Linee guida della Commissione europea del 18 luglio 2025 non creano nuove regole, ma spiegano come interpretare e applicare quelle già fissate dall’AI Act per i modelli di IA di uso generale. Sono quindi un documento “interpretativo”, non vincolante sul piano formale, ma che in pratica orienta sia i fornitori sia le autorità di vigilanza.

Ecco i punti principali:

 1. Quando un modello è davvero un GPAI?

Un modello rientra nella categoria “general-purpose” se combina due elementi:

• potenza computazionale: è stato addestrato con oltre 10²³ FLOP, cioè la soglia tipica per modelli da almeno un miliardo di parametri;
• versatilità: è capace di generare linguaggio (testo o audio) oppure contenuti visivi (immagini o video) con un’ampia gamma di usi.

La soglia dei FLOP è un criterio indicativo, non assoluto: se un modello è molto potente ma serve solo a un compito ristretto (es. trascrizione vocale), non è GPAI. Viceversa, un modello più piccolo ma molto versatile può esserlo.

2.  GPAI con rischio sistemico

Non tutti i modelli general-purpose sono uguali. Se l’addestramento supera i 10²⁵ FLOP oppure se la Commissione lo designa come “ad alto impatto”, il modello è classificato come con rischio sistemico. In quel caso scattano obblighi extra: valutazioni periodiche dei rischi, misure di mitigazione, report degli incidenti e cybersecurity rafforzata.

3. Chi è il “fornitore”?

Il provider è chi sviluppa un GPAI o lo fa sviluppare e lo immette sul mercato europeo con il proprio nome, anche gratuitamente e a prescindere dal luogo in cui ha sede. Anche chi modifica in modo sostanziale un modello esistente (ad esempio con un fine-tuning molto esteso) può diventare a sua volta fornitore, con tutti gli obblighi conseguenti.

4. Eccezioni per l’open-source

Le Linee guida chiariscono che alcuni obblighi (documentazione tecnica e rappresentanza in UE) non si applicano ai modelli rilasciati sotto licenza davvero libera e senza monetizzazione, a condizione che vengano resi pubblici i pesi, l’architettura e le istruzioni d’uso. Restano comunque obbligatorie la policy sul copyright e la pubblicazione di un riepilogo dei dati di training.

5. Tempistiche e sanzioni

Dal 2 agosto 2025 tutti i fornitori di GPAI devono rispettare gli obblighi previsti dall’AI Act. Le sanzioni scatteranno però solo dal 2 agosto 2026: da quella data la Commissione potrà imporre multe fino a 15 milioni di euro o al 3% del fatturato annuo globale, a seconda del valore più elevato. Nel frattempo l’AI Office europeo adotterà un approccio collaborativo, per accompagnare i provider in un’applicazione graduale delle regole. Per i modelli già sul mercato prima dell’agosto 2025 è previsto infine un periodo transitorio, con termine ultimo per adeguarsi fissato al 2 agosto 2027.

Chi integra l’IA nei propri servizi ha obblighi legali?

La maggior parte delle imprese italiane non sviluppa modelli di intelligenza artificiale “general-purpose”. Li prende da fornitori upstream (OpenAI, Google, Anthropic…) e li integra in prodotti o servizi verticali: un gestionale per la logistica, una piattaforma di documentazione, un chatbot settoriale.

Per queste realtà il messaggio delle Linee guida è un altro: anche se non siete provider di GPAI e quindi non avete gli obblighi del Capo V dell’AI Act, non potete ignorarli. Perché?

• Da un lato, i vostri fornitori upstream (chi sviluppa i GPAI, come OpenAI o Gemini) devono consegnarvi documentazione, summary dei dati di training, policy sul copyright.
• Dall’altro, voi dovrete pretendere queste informazioni e integrarle nei vostri processi di compliance, perché i vostri prodotti rientrano comunque nella categoria degli AI systems regolati dall’AI Act.

In pratica: le Linee guida vi dicono cosa chiedere a chi vi fornisce il modello di base. Senza quelle informazioni, non potreste rispettare i vostri obblighi come sviluppatori di sistemi di IA settoriali, adeguando contratti e processi.

È un effetto a cascata: la regolazione parte dai grandi modelli, ma arriva fino alle PMI che li usano e li distribuiscono in soluzioni concrete. Per questo è fondamentale che le imprese non si limitino a “comprare tecnologia”, ma sappiano anche:

• verificare i fornitori, controllando che il provider GPAI metta a disposizione documentazione tecnica, policy sul copyright e summary dei dati di training;
• integrare le informazioni ricevute nei propri processi interni e negli audit di compliance, valutando i rischi specifici del settore in cui operano;
• adeguare i contratti, inserendo almeno richiami standard all’AI Act e documentando le verifiche minime effettuate;
• formare i team, chiarendo la distinzione tra modello di base e sistema verticale e informando gli utenti finali sui limiti e le condizioni d’uso.

Questo è ciò che le Linee guida chiariscono: non solo cosa devono fare i grandi fornitori di GPAI, ma anche quali ricadute indirette toccano chi integra questi modelli nei propri sistemi. Ed è proprio a partire da queste aspettative che si comprende l’utilità di uno strumento parallelo, il General-Purpose AI Code of Practice, pubblicato pochi giorni prima delle Linee guida: un documento volontario che non crea nuovi obblighi, ma offre indicazioni pratiche su come rispettarli.

Come si applicano concretamente gli obblighi dell’AI Act nelle imprese?

Se le Linee guida della Commissione europea chiariscono i concetti e le definizioni dell’AI Act, il General-Purpose AI Code of Practice pubblicato il 10 luglio 2025 traduce quegli obblighi in procedure concrete. Ne ho parlato anche in un mio precedente articolo, “Un Codice per domarli tutti”, sottolineando come trasparenza, copyright e sicurezza siano diventati i tre pilastri di una nuova stagione di responsabilità per chi sviluppa o integra modelli di IA di uso generale.

Il Codice è uno strumento volontario, nato da un processo multi-stakeholder promosso dall’AI Office europeo e riconosciuto dalla Commissione e dall’AI Board come “mezzo adeguato” per dimostrare la conformità agli articoli 53 e 55 dell’AI Act. Non crea nuovi obblighi, ma li rende operativi: checklist, template e pratiche standardizzate che riducono l’incertezza giuridica e alleggeriscono il carico amministrativo.

Il documento si concentra sugli stessi tre pilastri già presenti nell’AI Act, ma li rende molto più concreti:

Trasparenza – con il Model Documentation Form, una “carta d’identità estesa” che obbliga i provider a descrivere architettura, dati di training, modalità di accesso e limiti del modello. Per le imprese downstream significa poter ricevere informazioni uniformi e comparabili, indispensabili per integrare i modelli in sicurezza e spiegare ai clienti come funziona davvero il servizio.

Domanda: A cosa serve, in concreto, questa documentazione?

Risposta: A prevenire rischi, a delimitare le responsabilità e a dare a chi integra AI nei propri prodotti strumenti chiari per erogare servizi trasparenti e sicuri. Per approfondire: Transparency Chapter del GPAI Code of Practice (PDF).

Copyright – con una policy aziendale e un summary leggibile dei dataset usati per l’addestramento, oltre al rispetto dell’opt-out dal text and data mining. Questo permette agli integratori di ridurre i rischi di responsabilità indiretta, perché possono dimostrare che il loro fornitore ha fatto le verifiche sui diritti d’autore.

Domanda: Se un modello genera un output che riproduce un’opera protetta, chi risponde?

Risposta: Non solo il provider del modello, ma tutta la filiera: l’integratore deve poter dimostrare di aver scelto un fornitore conforme, e l’utente finale risponde se usa l’output in modo illecito.

Per approfondire: Copyright Chapter del GPAI Code of Practice (PDF).

Sicurezza – con procedure ingegneristiche di gestione del rischio sistemico: valutazioni tecniche, audit periodici, reporting obbligatorio di incidenti e misure di cybersecurity. Per chi integra significa una cosa semplice: sapere che il modello di base non può essere immesso sul mercato se i rischi non sono mitigati, e poter contare su un fornitore che deve notificare eventuali incidenti all’AI Office.

Domanda: E se un modello può essere usato per attacchi di cybersicurezza avanzati?

Risposta: Il provider è obbligato a mitigare il rischio (filtri, restrizioni d’uso, sicurezza rafforzata) e, se non riesce, non può mettere il modello sul mercato.

Per approfondire: Safety and Security Chapter del GPAI Code of Practice (PDF).

L’adesione al Codice è volontaria, ma la lista dei primi firmatari dimostra che è destinato a diventare uno standard di fatto. Alla data di pubblicazione di questo articolo hanno aderito: Accexible, AI Alignment Solutions, Aleph Alpha, Almawave, Amazon, Anthropic, Bria AI, Cohere, Cyber Institute, Domyn, Dweve, Euc Inovação Portugal, Fastweb, Google, Humane Technology, IBM, Lawise, LINAGORA, Microsoft, Mistral AI, Open Hippo, OpenAI, Pleias, re-inventa, ServiceNow, Virtuo Turing, WRITER.

Per l’elenco completo e aggiornato nel tempo si rimanda al sito ufficiale della Commissione europea.

In definitiva, le Linee guida spiegano cosa chiede la legge, mentre il Codice mostra come rispettarla in pratica.

Per tutte le imprese italiane – anche per chi non sviluppa modelli foundation ma li integra in sistemi verticali – questo significa non poter più considerarsi semplici “utilizzatori passivi”. Il Codice è utile perché traduce gli obblighi dei provider in strumenti che ricadono a beneficio dell’intera filiera: la trasparenza per scegliere meglio i fornitori, la tutela del copyright per proteggere i clienti, la sicurezza per ridurre i rischi di incidenti.

Ecco perché Linee guida e Codice non sono soltanto strumenti normativi: sono alleati strategici per trasformare la compliance in un vantaggio competitivo, capace di generare fiducia, distinguersi sul mercato e consolidare le relazioni lungo tutta la catena del valore.