AI Act in Italia: la guida completa per aziende, professionisti e pubbliche amministrazioni

Per capire davvero l’AI Act bisogna eliminare subito un equivoco. Non è una legge destinata soltanto a OpenAI, Google, Anthropic, Microsoft o alle società che addestrano grandi modelli linguistici. Può riguardare anche un’azienda italiana che acquista un software per selezionare candidati, un ospedale che usa un sistema predittivo, una banca che valuta l’affidabilità creditizia, un Comune che introduce un assistente virtuale, un’agenzia che realizza chatbot per i clienti o una software house che integra un modello esterno in un prodotto venduto con il proprio marchio.

Il punto non è semplicemente: “Uso ChatGPT?”. Le domande corrette sono altre: quale sistema sto usando, per quale finalità, su quali persone produce effetti, che grado di autonomia possiede, chi lo ha sviluppato, chi lo commercializza e chi prende la decisione finale?

Il Regolamento (UE) 2024/1689, conosciuto come AI Act, crea un sistema di regole basato soprattutto sul rischio e sul ruolo ricoperto lungo la catena del valore. È entrato in vigore il 1° agosto 2024, è direttamente applicabile negli Stati membri e, dopo l’entrata in vigore dell’AI Omnibus il 27 luglio 2026, segue un calendario parzialmente diverso da quello contenuto nelle prime guide pubblicate sul tema. Il testo ufficiale consolidato è disponibile su EUR-Lex, mentre la Commissione europea mantiene una pagina operativa sull’AI Act.

In Italia si aggiunge la legge 23 settembre 2025, n. 132, entrata in vigore il 10 ottobre 2025. La legge nazionale non sostituisce il regolamento europeo e non crea un “AI Act italiano” alternativo: stabilisce principi, disciplina alcuni settori, individua le autorità nazionali e introduce disposizioni penali e sul diritto d’autore. Il testo è pubblicato nella Gazzetta Ufficiale.

Il risultato è un quadro a più livelli. Chi utilizza l’intelligenza artificiale in Italia deve considerare almeno:

• AI Act e atti europei di attuazione;
• legge italiana n. 132/2025;
• GDPR e Codice privacy;
• diritto del lavoro e Statuto dei lavoratori;
• regole su consumatori, copyright, prodotti e responsabilità;
• NIS2, Cyber Resilience Act e norme settoriali, quando applicabili.

La conformità, quindi, non si risolve aggiungendo una frase nell’informativa privacy o facendo firmare al personale una policy generica.

Che cos’è un sistema di intelligenza artificiale secondo la legge

La definizione giuridica è più importante dell’etichetta commerciale. Un fornitore può chiamare un prodotto “automazione intelligente”, “motore predittivo” o “copilota”: se il funzionamento rientra nella definizione dell’AI Act, il nome scelto dal marketing non cambia la sostanza.

In sintesi, un sistema di IA è un sistema basato su macchine, progettato per operare con diversi livelli di autonomia, che può mostrare capacità di adattamento dopo la diffusione e che, per obiettivi espliciti o impliciti, deduce dagli input come generare output. Gli output possono essere previsioni, contenuti, raccomandazioni o decisioni capaci di influenzare ambienti fisici o virtuali.

Non ogni formula matematica e non ogni software tradizionale diventano automaticamente IA. Un foglio Excel che applica una regola fissa non è la stessa cosa di un sistema che inferisce pattern e produce una valutazione. Nei casi di confine serve un’analisi tecnica reale: architettura, dati, logica, autonomia e finalità prevista.

A chi si applica l’AI Act

L’ambito territoriale è ampio. Il regolamento riguarda:

• i fornitori che immettono sul mercato o mettono in servizio sistemi o modelli di IA nell’Unione, anche se stabiliti fuori dall’UE;
• i deployer, cioè soggetti che usano un sistema di IA sotto la propria autorità per un’attività professionale;
• importatori e distributori;
• fabbricanti che incorporano un sistema di IA in un prodotto commercializzato con il proprio nome o marchio;
• rappresentanti autorizzati di fornitori extra-UE;
• soggetti stabiliti fuori dall’Unione quando l’output del sistema viene utilizzato nell’UE.

È il cosiddetto effetto extraterritoriale. Una piattaforma statunitense non può ignorare il regolamento solo perché i server o la sede legale si trovano fuori dall’Europa, se offre il sistema nel mercato europeo o se qui vengono usati i risultati.

Fornitore e deployer: la distinzione che cambia tutto

Il fornitore sviluppa un sistema o un modello, oppure lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio. Il deployer lo utilizza nell’ambito della propria attività.

Una società italiana che usa un chatbot di terzi per aiutare il personale è normalmente deployer. Se prende un modello, lo integra profondamente, ne modifica la finalità, lo commercializza come prodotto proprio o apporta una modifica sostanziale, può assumere gli obblighi del fornitore.

È qui che molti progetti SaaS sbagliano classificazione. Dire “il modello non è nostro” non basta. La responsabilità non coincide con la proprietà dei pesi del modello. Contano il prodotto immesso sul mercato, il controllo sulla finalità e le modifiche effettuate.

Le principali esclusioni

Sono esclusi, entro limiti precisi, gli impieghi esclusivamente militari, di difesa o sicurezza nazionale; determinate attività di ricerca scientifica; le fasi di ricerca, test e sviluppo precedenti all’immissione sul mercato, salvo le prove in condizioni reali; l’uso puramente personale e non professionale da parte di persone fisiche. Alcuni componenti open source beneficiano di regole specifiche, ma “open source” non è un lasciapassare generale e le eccezioni si restringono per i modelli con rischio sistemico e per alcuni obblighi di trasparenza e copyright.

Il cuore dell’AI Act: il rischio dipende dall’uso concreto

L’AI Act viene spesso riassunto con una piramide a quattro livelli: rischio inaccettabile, alto rischio, rischio di trasparenza e rischio minimo. È utile come mappa iniziale, ma può diventare fuorviante se trattata come un’etichetta applicata una volta per tutte a un prodotto.

Lo stesso modello linguistico può essere usato per correggere la grammatica di una newsletter oppure per classificare candidati a un posto di lavoro. Il primo impiego sarà normalmente a rischio limitato; il secondo può entrare nell’alto rischio. La classificazione nasce dall’intended purpose, cioè dalla finalità prevista, e dal contesto reale di utilizzo.

Per questo un inventario che riporti soltanto “ChatGPT”, “Copilot” o “Gemini” è insufficiente. Bisogna registrare i casi d’uso: generazione di testi commerciali, analisi dei CV, sintesi delle cartelle cliniche, scoring dei clienti, assistenza telefonica, rilevazione delle frodi e così via.

Pratiche di IA vietate

I divieti dell’articolo 5 sono applicabili dal 2 febbraio 2025. Riguardano gli usi considerati incompatibili con i diritti e i valori dell’Unione, pur con eccezioni e condizioni che vanno lette nel testo normativo.

Tra le pratiche vietate rientrano:

1. Manipolazione dannosa. Sistemi che impiegano tecniche subliminali o deliberatamente manipolative o ingannevoli per alterare in modo significativo il comportamento, compromettendo la capacità di prendere una decisione informata e causando o potendo ragionevolmente causare un danno significativo.
2. Sfruttamento delle vulnerabilità. IA che sfrutta vulnerabilità legate a età, disabilità o specifica situazione sociale o economica per distorcere il comportamento in modo dannoso.
3. Social scoring. Valutazione o classificazione delle persone in base al comportamento sociale o a caratteristiche personali quando produce trattamenti pregiudizievoli ingiustificati o sproporzionati, oppure in contesti non collegati ai dati raccolti.
4. Previsione individuale del rischio criminale, quando fondata unicamente sulla profilazione o sulla valutazione di tratti e caratteristiche della personalità. Rimane possibile supportare una valutazione umana già basata su fatti oggettivi e verificabili direttamente collegati a un’attività criminale.
5. Creazione indiscriminata di database di riconoscimento facciale mediante scraping non mirato di immagini facciali da internet o da telecamere a circuito chiuso.
6. Riconoscimento delle emozioni sul lavoro e nelle scuole, salvo ragioni mediche o di sicurezza.
7. Categorizzazione biometrica sensibile, quando deduce razza, opinioni politiche, appartenenza sindacale, convinzioni religiose o filosofiche, vita sessuale o orientamento sessuale dai dati biometrici.
8. Identificazione biometrica remota in tempo reale negli spazi accessibili al pubblico da parte delle forze dell’ordine, salvo eccezioni molto ristrette e soggette a garanzie.

L’AI Omnibus ha inoltre introdotto il divieto dei sistemi destinati a generare materiale sessualmente esplicito o intimo non consensuale e materiale di abuso sessuale sui minori, comprendendo le cosiddette applicazioni di “nudificazione”. La Commissione ha riassunto le novità nella comunicazione ufficiale sull’entrata in vigore dell’AI Omnibus.

Non basta verificare il nome della funzione. Un sistema di neuromarketing, un giocattolo conversazionale o un assistente destinato a persone fragili deve essere valutato rispetto al modo in cui influenza il comportamento e al danno ragionevolmente prevedibile.

Sistemi ad alto rischio: quali sono

Esistono due grandi famiglie.

IA incorporata in prodotti regolamentati

La prima comprende sistemi che sono componenti di sicurezza di prodotti, o sono essi stessi prodotti, coperti dalla normativa europea elencata nell’allegato I e soggetti a valutazione di conformità di terza parte. Gli esempi comprendono, a seconda della normativa settoriale applicabile, macchinari, dispositivi medici, giocattoli, ascensori e altri prodotti regolamentati.

Dopo l’AI Omnibus, le regole specifiche per questa famiglia si applicano dal 2 agosto 2028.

Casi d’uso elencati nell’allegato III

La seconda famiglia comprende impieghi in aree nelle quali una decisione automatizzata può incidere pesantemente sulla vita delle persone:

• biometria, nei casi previsti;
• gestione e funzionamento di infrastrutture critiche;
• istruzione e formazione professionale, per ammissione, valutazione, assegnazione o monitoraggio durante gli esami;
• occupazione e gestione dei lavoratori, come selezione dei CV, ranking dei candidati, promozioni, assegnazione dei compiti e valutazione delle prestazioni;
• accesso a servizi essenziali pubblici e privati, compresi alcuni sistemi di valutazione del credito e del rischio assicurativo;
• attività di contrasto;
• migrazione, asilo e controllo delle frontiere;
• amministrazione della giustizia e processi democratici.

Per questi sistemi le regole sull’alto rischio si applicano, secondo il calendario aggiornato, dal 2 dicembre 2027.

Non tutto ciò che compare nell’allegato III è automaticamente alto rischio

Il regolamento prevede una possibile esclusione quando il sistema non presenta un rischio significativo per salute, sicurezza o diritti fondamentali e non influenza materialmente il risultato della decisione. Può accadere, per esempio, se il sistema svolge un compito procedurale ristretto, migliora il risultato di un’attività umana già completata, individua pattern senza sostituire o influenzare la valutazione umana oppure prepara un compito valutativo.

Ma c’è una barriera importante: se il sistema effettua profilazione di persone fisiche, viene comunque considerato ad alto rischio. Inoltre il fornitore che ritiene applicabile l’eccezione deve documentare la valutazione. Non è una formula da inserire nei termini del servizio, ma una conclusione da sostenere con prove.

Cosa deve fare il fornitore di un sistema ad alto rischio

Gli obblighi sono costruiti sul ciclo di vita, non su un controllo isolato prima del lancio.

Sistema di gestione del rischio

Il fornitore deve istituire un processo continuo e iterativo: identificare i rischi noti e prevedibili, stimare quelli che possono emergere nell’uso corretto e nell’uso improprio ragionevolmente prevedibile, adottare misure di mitigazione, testarle e aggiornarle. Il rischio residuo deve essere giudicato accettabile, considerando anche l’interazione complessiva con l’ambiente in cui il sistema verrà usato.

Governance dei dati

I set di dati di addestramento, validazione e test devono essere soggetti a pratiche adeguate di governance. Occorre valutarne origine, pertinenza, rappresentatività, completezza, qualità, possibili bias e idoneità rispetto alla finalità e alle persone interessate. La conformità non significa promettere dati “perfettamente privi di bias”, obiettivo spesso irrealistico; significa dimostrare un processo serio di individuazione, misurazione e mitigazione dei rischi discriminatori.

Documentazione tecnica

La documentazione deve consentire alle autorità e agli organismi competenti di valutare la conformità. Deve descrivere finalità, architettura, sviluppo, dati, metriche, prestazioni, limiti, gestione del rischio, controlli e modifiche. Se il prodotto cambia continuamente, anche la documentazione deve vivere insieme al prodotto.

Registrazione automatica degli eventi

Il sistema deve permettere la generazione di log sufficienti a ricostruire il funzionamento, controllare situazioni di rischio e facilitare la sorveglianza successiva all’immissione sul mercato. Una chat salvata casualmente non equivale a un sistema di tracciabilità progettato.

Trasparenza verso il deployer

Chi usa il sistema deve ricevere istruzioni comprensibili: finalità, livello di accuratezza, metriche rilevanti, limiti, rischi noti, requisiti di input, modalità di supervisione umana, manutenzione e gestione dei log.

Supervisione umana

Il controllo umano deve essere effettivo. La persona incaricata deve avere competenza, autorità e possibilità concreta di comprendere il sistema, evitare l’automation bias, ignorare o correggere l’output e interrompere l’uso quando necessario. Un pulsante che nessuno può premere senza subire conseguenze organizzative non è una vera supervisione.

Accuratezza, robustezza e cybersicurezza

Le prestazioni devono essere adeguate alla finalità e mantenute lungo il ciclo di vita. Vanno gestiti errori, degrado, attacchi avversari, data poisoning, prompt injection, compromissione dei modelli e uso improprio. Per gli agenti capaci di chiamare strumenti, inviare messaggi, spostare denaro o modificare database, la superficie di rischio cresce: non si tratta più soltanto di verificare se una risposta è corretta, ma quali azioni il sistema può compiere e con quali autorizzazioni.

Sistema di qualità, valutazione di conformità e marcatura CE

Il fornitore deve disporre di un sistema di gestione della qualità, eseguire la procedura di valutazione di conformità prevista, predisporre la dichiarazione UE di conformità, applicare la marcatura CE quando richiesta e registrare il sistema. La procedura può essere interna o richiedere un organismo notificato a seconda della categoria e delle condizioni normative.

Monitoraggio post-commercializzazione e incidenti

Dopo il lancio occorre raccogliere e analizzare dati sulle prestazioni reali, gestire non conformità, adottare azioni correttive e notificare gli incidenti gravi secondo le procedure applicabili. Il rilascio non chiude il processo: lo apre.

Obblighi del deployer: cosa deve fare chi compra o usa l’IA

Il deployer non può scaricare ogni responsabilità sul produttore. Per i sistemi ad alto rischio deve, tra l’altro:

• seguire le istruzioni d’uso;
• assegnare la supervisione a persone competenti e dotate di autorità;
• controllare, per quanto gli compete, pertinenza e sufficiente rappresentatività dei dati di input;
• monitorare il funzionamento e comunicare rischi o incidenti al fornitore e alle autorità nei casi previsti;
• conservare i log sotto il proprio controllo per il periodo richiesto;
• informare i lavoratori e i loro rappresentanti prima dell’uso sul luogo di lavoro;
• informare le persone quando un sistema ad alto rischio prende o assiste decisioni che le riguardano;
• cooperare con le autorità.

In alcuni casi il deployer deve svolgere una valutazione d’impatto sui diritti fondamentali prima dell’impiego. L’obbligo riguarda, in particolare, organismi di diritto pubblico e operatori privati che forniscono determinati servizi pubblici, nonché specifici utilizzi nell’accesso a servizi essenziali. Se il sistema tratta dati personali, può essere necessaria anche la valutazione d’impatto privacy prevista dall’articolo 35 GDPR. Le due valutazioni possono essere coordinate, ma non sono la stessa cosa.

Chatbot, deepfake e contenuti generati: gli obblighi di trasparenza

Dal 2 agosto 2026 sono applicabili gli obblighi dell’articolo 50. La Commissione ha pubblicato linee guida specifiche sulle regole di trasparenza per fornitori e deployer.

Quando una persona parla con un’IA

I sistemi destinati a interagire direttamente con persone devono essere progettati in modo che l’utente sia informato di stare interagendo con un’IA, salvo che ciò sia evidente a una persona ragionevolmente informata, attenta e avveduta, considerate le circostanze e il contesto.

Per un assistente telefonico la comunicazione deve arrivare all’inizio della conversazione, non essere nascosta in una pagina legale. Una formula chiara può essere: “Sono l’assistente virtuale dello studio, basato su intelligenza artificiale. Posso aiutarla con informazioni e prenotazioni; se necessario posso trasferire la richiesta a un operatore”.

Contenuti sintetici e marcatura leggibile dalle macchine

I fornitori di sistemi che generano contenuti sintetici audio, immagini, video o testo devono rendere gli output identificabili come generati o manipolati artificialmente, anche mediante soluzioni tecniche leggibili dalle macchine, efficaci e interoperabili per quanto tecnicamente possibile.

Deepfake

Chi utilizza un sistema per creare o manipolare immagini, audio o video che costituiscono un deepfake deve dichiarare che il contenuto è stato generato o alterato artificialmente. Per opere manifestamente artistiche, creative, satiriche o di fantasia l’obbligo deve essere attuato senza ostacolare indebitamente la fruizione dell’opera.

Testi su questioni di interesse pubblico

Il deployer che pubblica testo generato o manipolato artificialmente per informare il pubblico su questioni di interesse pubblico deve dichiararlo, salvo che il contenuto sia stato sottoposto a revisione umana o controllo editoriale e una persona fisica o giuridica ne assuma la responsabilità editoriale.

Questo passaggio è decisivo per editori e testate. L’AI Act non dice che ogni articolo scritto con un qualsiasi supporto di IA debba avere automaticamente un’etichetta visibile. Se esistono controllo editoriale umano e responsabilità sul contenuto, opera l’eccezione prevista. Resta però prudente conservare un processo interno che dimostri chi ha verificato fonti, dati, citazioni, titoli e versione finale.

La Commissione ha confermato che dal 2 agosto 2026 chat e contenuti sintetici sono entrati nella fase di applicazione e controllo, spiegando anche l’obbligo di segnalare chatbot e deepfake nella comunicazione sull’avvio dell’enforcement.

IA generativa e modelli per finalità generali

L’AI Act distingue il modello GPAI dal sistema o prodotto che lo utilizza. Un modello per finalità generali può svolgere una pluralità di compiti ed essere integrato in numerosi sistemi a valle.

I fornitori di GPAI devono mantenere documentazione tecnica, fornire informazioni ai soggetti che integrano il modello, adottare una politica per rispettare il diritto d’autore europeo e pubblicare una sintesi sufficientemente dettagliata dei contenuti usati per l’addestramento secondo il modello predisposto dall’AI Office.

Per i modelli con rischio sistemico, normalmente legato a capacità di impatto elevato e ai criteri previsti dal regolamento, si aggiungono obblighi su valutazioni del modello, rischi sistemici, test avversariali, mitigazioni, segnalazione degli incidenti gravi e sicurezza informatica.

Il General-Purpose AI Code of Practice è volontario, ma serve a dimostrare in modo più prevedibile il rispetto di trasparenza, copyright, sicurezza e gestione dei rischi. Non firmarlo non rende il modello illegale; obbliga però il fornitore a dimostrare la conformità con strumenti alternativi.

Per la maggior parte delle imprese italiane che acquistano API, la questione pratica è contrattuale e tecnica: il fornitore del modello consegna informazioni sufficienti? Quali dati conserva? Gli output possono essere riutilizzati? Sono disponibili controlli, versioning, log e notifiche sulle modifiche? La documentazione a monte condiziona la possibilità di essere conformi a valle.

AI literacy: formare le persone senza trasformare tutto in burocrazia

La versione originaria dell’articolo 4 imponeva a fornitori e deployer di adottare misure per assicurare un livello sufficiente di alfabetizzazione in materia di IA del personale e delle persone che operano per loro conto. L’AI Omnibus del 2026 ha semplificato l’impianto, attribuendo alla Commissione e agli Stati membri un ruolo più forte nella promozione dell’AI literacy.

Semplificare non significa che un’azienda possa mettere strumenti potenti nelle mani del personale senza formazione. La competenza resta essenziale per rispettare supervisione, sicurezza, privacy, doveri professionali e prevenzione degli errori. Una policy non letta e un corso identico per tutti non bastano.

La formazione dovrebbe cambiare per ruolo:

• tutto il personale: dati che non possono essere inseriti, verifica degli output, phishing e contenuti sintetici;
• sviluppatori: valutazione, logging, sicurezza, data governance, controllo delle dipendenze e modifiche sostanziali;
• risorse umane: discriminazione, alto rischio, informazione ai lavoratori e limiti del decision-making automatizzato;
• marketing ed editoria: trasparenza, copyright, deepfake e responsabilità editoriale;
• management: classificazione dei rischi, accettazione del rischio residuo, responsabilità e budget;
• operatori di sistemi ad alto rischio: limiti noti, interpretazione dell’output, override e procedure di escalation.

L’AI Act e il GDPR non sono la stessa legge

Un sistema può essere conforme all’AI Act e violare il GDPR, o viceversa. L’AI Act disciplina il prodotto, il sistema, gli operatori e i rischi per sicurezza e diritti fondamentali. Il GDPR disciplina il trattamento dei dati personali.

Quando un progetto utilizza dati personali vanno esaminati almeno:

• base giuridica del trattamento;
• finalità e compatibilità degli usi successivi;
• minimizzazione dei dati;
• informativa e diritti degli interessati;
• tempi di conservazione;
• trasferimenti internazionali;
• rapporti tra titolare e responsabile;
• sicurezza;
• eventuale DPIA;
• decisioni unicamente automatizzate con effetti giuridici o analogamente significativi, ai sensi dell’articolo 22 GDPR.

L’errore tipico è raccogliere più dati “perché potrebbero servire al modello”. La logica corretta è opposta: definire ciò che serve, dimostrare perché serve e limitare accesso e conservazione.

IA sul lavoro: selezione, controllo e valutazione dei dipendenti

Recruiting e gestione dei lavoratori sono tra gli ambiti più sensibili. Un sistema che filtra CV, assegna punteggi ai candidati, raccomanda licenziamenti, valuta performance o distribuisce incarichi può rientrare nell’alto rischio.

In Italia si sommano le regole sul lavoro. Se una tecnologia consente controllo a distanza, può entrare in gioco l’articolo 4 dello Statuto dei lavoratori. Devono essere valutati anche obblighi informativi, contrattazione o accordi, protezione dei dati, non discriminazione e trasparenza delle decisioni automatizzate.

La presenza di un recruiter che clicca “approva” non risolve il problema se, in concreto, accetta quasi sempre il ranking senza comprenderlo. È il fenomeno dell’automation bias. La supervisione umana deve poter cambiare davvero l’esito.

Sanità e professioni mediche

In sanità bisogna distinguere l’assistenza amministrativa dalla decisione clinica. Un chatbot che raccoglie una richiesta di appuntamento non è automaticamente un dispositivo medico ad alto rischio. Se però suggerisce diagnosi, priorità cliniche o terapie, può entrare nel perimetro dei dispositivi medici e dell’alto rischio, oltre a coinvolgere dati sanitari e responsabilità professionale.

La legge italiana n. 132/2025 ribadisce la centralità della decisione del professionista e disciplina l’uso dell’IA in sanità. Il sistema deve avere funzione di supporto; la decisione resta del medico. Servono qualità dei dati, validazione clinica, sicurezza, informazione del paziente e una chiara gestione degli errori.

Per studi medici e odontoiatrici che vogliono introdurre assistenti vocali, un’impostazione prudente separa nettamente prenotazione e informazioni organizzative da triage e raccomandazioni sanitarie. Nei casi urgenti il sistema deve indirizzare a canali appropriati, non improvvisare una valutazione clinica.

Pubblica amministrazione

La PA non è esentata. Quando usa sistemi ad alto rischio può avere obblighi rafforzati: valutazione d’impatto sui diritti fondamentali, registrazione, trasparenza, supervisione e regole per gli appalti.

Un ente pubblico dovrebbe evitare gare costruite sulla sola demo. Il capitolato deve richiedere almeno classificazione normativa, documentazione, localizzazione e flussi dei dati, misure di sicurezza, auditabilità, gestione delle versioni, uscita dal servizio, accesso ai log, responsabilità dei subfornitori e cooperazione in caso di incidente.

La legge italiana affida alla strategia nazionale il coordinamento dell’adozione e della ricerca. La strategia viene aggiornata almeno ogni due anni e monitorata con il coinvolgimento di AgID e ACN, come stabilito dall’articolo 19 della legge n. 132/2025.

Le autorità italiane: chi controlla cosa

La legge n. 132/2025 designa AgID e ACN come autorità nazionali per l’intelligenza artificiale:

• AgID promuove innovazione e sviluppo e svolge funzioni collegate a notifica, valutazione, accreditamento e monitoraggio dei soggetti che verificano la conformità;
• ACN è responsabile della vigilanza, comprese attività ispettive e sanzionatorie, e dei profili di cybersicurezza; è anche il punto di contatto unico con le istituzioni UE;
• Banca d’Italia, Consob e IVASS conservano ruoli di vigilanza nei settori di competenza;
• restano ferme le attribuzioni del Garante per la protezione dei dati personali e di AGCOM.

La ripartizione è contenuta nell’articolo 20 della legge italiana sull’IA.

A livello europeo, l’AI Office controlla in particolare i modelli GPAI e, dopo l’Omnibus, dispone di poteri rafforzati su alcuni sistemi costruiti su tali modelli. La governance è quindi distribuita: un progetto può essere interessato contemporaneamente da ACN, Garante privacy, autorità settoriale e Commissione.

Legge italiana n. 132/2025: cosa aggiunge

La legge nazionale è composta da principi e disposizioni settoriali. Tra i temi principali:

• uso antropocentrico, trasparente, sicuro e non discriminatorio dell’IA;
• protezione dei dati, sovranità e cybersicurezza;
• impiego dell’IA in sanità e ricerca scientifica;
• lavoro e professioni intellettuali;
• pubblica amministrazione e attività giudiziaria;
• strategia nazionale e autorità competenti;
• diritto d’autore;
• tutela penale contro determinati abusi.

Professioni intellettuali

L’impiego dell’IA nelle professioni intellettuali deve essere finalizzato all’esercizio delle attività strumentali e di supporto. La prestazione deve restare prevalentemente intellettuale e il professionista deve comunicare al cliente, con linguaggio chiaro, le informazioni sull’uso di sistemi di IA.

Per avvocati, commercialisti, consulenti, architetti e altri professionisti, questo significa che l’IA può assistere ricerca, analisi e redazione, ma non cancella responsabilità, segreto professionale, diligenza e verifica personale.

Diritto d’autore

La legge interviene sulla disciplina italiana specificando il ruolo dell’apporto umano nelle opere create con l’ausilio dell’IA. Non basta premere un pulsante e dichiararsi automaticamente autori di qualsiasi output: la protezione resta legata al contributo creativo umano.

Sul versante dell’addestramento, il text and data mining deve rispettare la normativa europea e le riserve dei titolari dei diritti. Le questioni contrattuali, la provenienza dei dataset e la possibilità di riutilizzare gli output vanno documentate.

Deepfake e responsabilità penale

La legge ha introdotto l’articolo 612-quater del codice penale. Punisce, in presenza delle condizioni previste, chi cagiona un danno ingiusto diffondendo senza consenso immagini, video o voci falsificati o alterati mediante IA e idonei a ingannare sulla loro genuinità. L’articolo 26 della legge n. 132/2025 introduce inoltre aggravanti e modifiche per reati commessi con l’impiego dell’intelligenza artificiale.

Calendario aggiornato al 2026

Il calendario è uno dei punti in cui circolano più informazioni superate.

Attenzione alle disposizioni transitorie. Data di immissione sul mercato, modifiche sostanziali e categoria del sistema possono cambiare il termine concreto. Il calendario generale non sostituisce l’analisi del singolo prodotto.

Sanzioni: quanto si rischia

Le sanzioni massime europee sono elevate:

• fino a 35 milioni di euro o al 7% del fatturato mondiale annuo, se superiore, per la violazione delle pratiche vietate;
• fino a 15 milioni di euro o al 3% del fatturato mondiale annuo per la violazione di altri obblighi rilevanti, compresi quelli di fornitori, importatori, distributori, deployer e trasparenza;
• fino a 7,5 milioni di euro o all’1% del fatturato mondiale annuo per informazioni inesatte, incomplete o fuorvianti fornite alle autorità o agli organismi notificati;
• per i fornitori di GPAI, specifiche sanzioni della Commissione fino a 15 milioni di euro o al 3% del fatturato mondiale annuo.

Per PMI e startup il meccanismo del tetto è più favorevole: si applica il valore massimo inferiore tra percentuale e importo fisso. Non significa impunità. Le autorità valutano gravità, durata, persone coinvolte, danno, intenzionalità, cooperazione, misure adottate e capacità economica. I massimali ufficiali sono stabiliti dall’articolo 99 del regolamento.

Il costo di una violazione non è soltanto la multa. Possono aggiungersi blocco del sistema, ritiro dal mercato, contenzioso, responsabilità contrattuale, danno reputazionale e sanzioni previste da GDPR o altre norme.

Dodici errori che vedo più spesso nelle aziende

1. Pensare che l’abbonamento Enterprise renda automaticamente conformi. Le garanzie del fornitore aiutano, ma non risolvono finalità, dati, informazione, controllo e processi interni.
2. Classificare il marchio anziché il caso d’uso. “Usiamo Copilot” non dice nulla sul rischio concreto.
3. Non sapere quali strumenti usa il personale. La Shadow AI porta dati aziendali in servizi non autorizzati e rende impossibile governare il rischio.
4. Affidarsi solo al consenso privacy. Il consenso non rende lecito un sistema vietato, non elimina gli obblighi dell’AI Act e spesso non è neppure la base giuridica corretta.
5. Confondere revisione umana e supervisione reale. Se la persona non ha tempo, competenza o autorità per contestare l’output, il controllo è apparente.
6. Comprare software senza clausole sull’AI Act. Mancano documentazione, log, audit, notifica degli incidenti, versione del modello e gestione dell’uscita.
7. Non gestire gli aggiornamenti. Un cambio di modello o finalità può alterare prestazioni e classificazione e, nei casi previsti, costituire modifica sostanziale.
8. Usare dati reali in fase di test senza regole. Il prototipo non è una zona franca per privacy, segreto aziendale o diritto d’autore.
9. Etichettare tutto o nulla. La trasparenza dipende dal tipo di sistema, contenuto e contesto; servono regole editoriali, non bollini casuali.
10. Dimenticare i subfornitori. Dietro una singola interfaccia possono esserci modello, vector database, speech-to-text, hosting, analytics e moderazione.
11. Trattare la sicurezza come un test una tantum. Prompt injection, abuso degli strumenti e cambiamenti del modello richiedono monitoraggio continuo.
12. Aspettare la scadenza. Inventario, contratti, formazione, logging e governance richiedono mesi; non si improvvisano il giorno prima.

Come adeguarsi: un percorso pratico in dieci fasi

1. Istituire una responsabilità chiara

Nominare un referente o un comitato proporzionato alle dimensioni. Devono essere coinvolti direzione, legale, privacy, sicurezza, IT e funzioni che usano il sistema. Il responsabile non deve diventare il parafulmine unico: le decisioni di rischio devono risalire al management.

2. Creare un inventario dei sistemi e dei casi d’uso

Per ogni utilizzo registrare proprietario interno, finalità, utenti, persone interessate, input, output, dati personali, fornitore, modello, integrazioni, autonomia, decisioni influenzate e stato del progetto.

3. Stabilire il ruolo giuridico

Determinare se l’organizzazione è fornitore, deployer, importatore, distributore o fabbricante. Riesaminare il ruolo se il sistema viene rimarchiato, modificato o destinato a un nuovo uso.

4. Classificare rischio e obblighi

Verificare: pratica vietata; alto rischio; obbligo di trasparenza; GPAI; rischio minimo. Annotare motivazione, versione normativa e data del riesame.

5. Mappare dati e fornitori

Disegnare i flussi: da dove arrivano i dati, dove transitano, chi li conserva, per quanto tempo e per quali ulteriori finalità. Controllare sub-responsabili, trasferimenti e opzioni di addestramento sui dati del cliente.

6. Valutare impatti e rischi

Coordinare valutazione AI, DPIA privacy, sicurezza, diritti fondamentali e analisi settoriali. Includere uso improprio prevedibile, gruppi vulnerabili, errori, discriminazione, disponibilità del servizio e dipendenza dal fornitore.

7. Definire controlli tecnici e umani

Limitare autorizzazioni e strumenti, predisporre logging, test, metriche, soglie, fallback, kill switch, revisione umana e procedure di escalation. Per agenti autonomi applicare il principio del minimo privilegio e richiedere conferma umana prima delle azioni ad alto impatto.

8. Correggere contratti e procurement

Chiedere classificazione, documentazione, livelli di servizio, sicurezza, gestione degli incidenti, accesso ai log, localizzazione dei dati, politica sugli aggiornamenti, audit, cooperazione regolatoria, proprietà intellettuale e cancellazione dei dati alla cessazione.

9. Formare per ruolo e documentare

Conservare programma, partecipanti, contenuti e verifiche. Aggiornare la formazione quando cambiano prodotto, rischio o norme.

10. Monitorare e riesaminare

Stabilire indicatori, segnalazione interna, gestione degli incidenti, verifiche periodiche, controllo dei bias e revisione in caso di modifica. Una scheda approvata oggi può diventare obsoleta al prossimo aggiornamento del modello.

Checklist essenziale per una PMI italiana

• Abbiamo un elenco aggiornato di tutti gli strumenti di IA, compresi quelli sperimentali?
• Per ogni strumento abbiamo descritto il caso d’uso reale?
• Abbiamo individuato il nostro ruolo giuridico?
• Abbiamo escluso pratiche vietate?
• Abbiamo verificato se il caso rientra nell’alto rischio o nell’articolo 50?
• Sappiamo quali dati entrano nel sistema e dove vengono trattati?
• Esistono regole chiare per dati personali, riservati e dei clienti?
• Il contratto con il fornitore copre sicurezza, incidenti, log, modifiche e uscita?
• Gli utenti sanno quando interagiscono con un’IA?
• I deepfake e i contenuti sintetici vengono segnalati quando richiesto?
• Esiste una persona che può controllare, correggere o fermare l’output?
• Abbiamo testato accuratezza, errori prevedibili, bias e prompt injection?
• Il personale ha ricevuto formazione coerente con il proprio ruolo?
• Abbiamo un processo per segnalare incidenti e non conformità?
• La direzione approva e riesamina i casi a impatto elevato?

Domande frequenti

Una piccola impresa deve rispettare l’AI Act?

Sì. Dimensione e fatturato incidono sulla proporzionalità e sul regime sanzionatorio, non creano un’esenzione generale.

Usare ChatGPT per scrivere email è alto rischio?

Normalmente no. Restano però privacy, riservatezza, sicurezza, diritto d’autore, verifica degli output e policy aziendale.

Devo scrivere “creato con IA” sotto ogni immagine?

Non in modo indistinto. Bisogna distinguere obblighi tecnici del fornitore, disclosure del deployer, deepfake e contesto artistico o informativo. Dal 2 agosto 2026 le regole dell’articolo 50 sono operative.

Un chatbot deve dichiarare di essere artificiale?

Sì, salvo che sia evidente nelle circostanze. La comunicazione deve arrivare al più tardi alla prima interazione.

Se il fornitore è conforme, lo sono anch’io?

No. Il deployer conserva obblighi propri sull’uso, i dati, la supervisione, il monitoraggio e l’informazione.

ISO/IEC 42001 rende automaticamente conformi?

No. Può offrire un ottimo sistema di gestione dell’IA e produrre evidenze utili, ma non sostituisce classificazione, requisiti specifici, valutazione di conformità e obblighi di legge.

Posso vietare completamente l’IA ai dipendenti?

È possibile limitarne l’uso, ma un divieto puramente formale spesso spinge verso strumenti clandestini. È più efficace autorizzare strumenti e casi d’uso precisi, accompagnandoli con formazione, controlli e canali sicuri.

Il mio commento: l’Europa ha ragione sul principio, ma non può trasformare la fiducia in una montagna di carta

Commento di Francesco Giuliani, Founder & CEO di Faraday AI Studio

Ho letto molte interpretazioni dell’AI Act che cadono in due estremi opposti. Da una parte c’è chi lo racconta come la fine dell’innovazione europea, una specie di muro burocratico costruito mentre Stati Uniti e Cina corrono. Dall’altra c’è chi ne parla come se bastasse pronunciare parole come “etica”, “trasparenza” e “supervisione umana” per rendere sicuro qualsiasi sistema. Non mi convince nessuna delle due letture.

L’Europa fa bene a stabilire che una macchina non possa decidere in modo opaco chi può lavorare, ottenere un finanziamento, ricevere una cura o accedere a un servizio essenziale. Fa bene a vietare la manipolazione delle persone fragili. Fa bene a pretendere che un cittadino sappia se sta parlando con un essere umano o con un assistente artificiale. E fa bene a introdurre responsabilità lungo tutta la filiera, perché il danno non scompare dividendo un prodotto tra cinque fornitori e tre API.

Lo vediamo ogni giorno nei progetti reali. Un modello linguistico non è soltanto una finestra dove si scrivono domande. Può rispondere al telefono, consultare un CRM, leggere documenti, fissare appuntamenti, classificare richieste, inviare email, generare contratti e attivare processi. Più gli agenti diventano capaci di agire, più la domanda cambia: non è solo “quanto è intelligente?”, ma “che cosa gli abbiamo permesso di fare, con quali dati e chi lo ferma se sbaglia?”. Questa, secondo me, è la parte più moderna dell’intero discorso normativo.

Il problema nasce quando la conformità diventa teatro. Una checklist compilata dopo il lancio, un corso di mezz’ora che nessuno ascolta, una persona messa formalmente “nel loop” e cinquanta pagine di documentazione copiate da un modello non proteggono nessuno. Producono solo l’illusione del controllo. Il rischio è premiare le organizzazioni più brave a scrivere carte e penalizzare quelle che costruiscono davvero sistemi trasparenti, misurabili e sicuri.

Per questo giudico positivamente la scelta del 2026 di rinviare una parte degli obblighi ad alto rischio fino a quando imprese e autorità potranno lavorare con strumenti e standard più maturi. Sarebbe stato assurdo pretendere valutazioni uniformi senza standard sufficientemente chiari. Ma il rinvio non deve diventare una scusa per restare immobili. Una società che oggi usa l’IA per selezionare persone o influenzare decisioni importanti non dovrebbe aspettare dicembre 2027 per capire quali dati utilizza, quanto sbaglia e chi subisce gli errori.

Sono altrettanto netto su un altro punto: non dobbiamo usare l’AI Act come arma commerciale per spaventare le PMI. Dire a ogni ristorante, negozio o studio professionale che rischia immediatamente 35 milioni perché usa un chatbot è scorretto. I massimali esistono e sono seri, ma la norma distingue ruoli, rischi, gravità e dimensioni. La consulenza basata sulla paura crea dipendenza, non cultura.

Serve un modello europeo capace di unire protezione e velocità. Significa template semplici per le piccole imprese, sandbox realmente accessibili, sportelli competenti, standard tecnici utilizzabili, interpretazioni stabili e autorità in grado di distinguere un errore in buona fede da un comportamento deliberatamente irresponsabile. Significa anche investire in infrastruttura, modelli, ricerca e competenze europee. Non possiamo parlare di sovranità digitale se ogni progetto dipende completamente da tecnologie, cloud e capitali esterni.

Nel lavoro che facciamo in Faraday AI Studio, la conformità migliore non arriva alla fine con un timbro. Entra nella progettazione: dati minimi, permessi limitati, tracce verificabili, passaggi umani nei punti critici, canali di emergenza, test reali e contratti che non lascino zone grigie. Quando questo lavoro è fatto bene, l’AI Act non è soltanto un costo. Può diventare un vantaggio competitivo, soprattutto nei progetti enterprise e nella pubblica amministrazione, dove la fiducia è parte del prodotto.

La mia posizione, quindi, è semplice: regole sì, burocrazia cieca no. Non dobbiamo rallentare l’intelligenza artificiale; dobbiamo impedire che la velocità venga scaricata sulle persone sotto forma di discriminazioni, truffe, decisioni incomprensibili e perdita di controllo. Allo stesso tempo, le istituzioni devono avere l’onestà di misurare l’efficacia delle regole. Se un obbligo genera soltanto documenti e non riduce alcun rischio reale, va corretto.

L’AI Act sarà utile se obbligherà aziende e pubbliche amministrazioni a farsi domande migliori prima di automatizzare. Fallirà se diventerà una liturgia per consulenti e uffici legali. La differenza non la farà la quantità di carta prodotta, ma la qualità delle scelte tecniche e umane che saremo capaci di dimostrare.

Fonti normative e istituzionali principali

• Regolamento (UE) 2024/1689 – testo consolidato su EUR-Lex
• Commissione europea – quadro normativo dell’AI Act
• Commissione europea – AI Omnibus entrato in vigore il 27 luglio 2026
• Commissione europea – applicazione delle regole di trasparenza dal 2 agosto 2026
• Commissione europea – linee guida sull’articolo 50
• Legge italiana 23 settembre 2025, n. 132 – Gazzetta Ufficiale

Nota editoriale: il quadro è aggiornato all’8 settembre 2026. L’AI Act è una disciplina in evoluzione, completata da linee guida, codici di pratica, standard armonizzati e atti di esecuzione. La classificazione deve essere verificata sul singolo sistema e sul suo impiego concreto.