AI Act: guida completa a obblighi, responsabilità e dati

L'AI Act non è una norma tecnica per addetti ai lavori: è la cornice che decide quali sistemi di intelligenza artificiale un'azienda può mettere sul mercato o usare in Europa, con quali controlli e con quale catena di responsabilità. Questa guida raccoglie in un unico punto le definizioni, la classificazione del rischio, gli obblighi per ruolo, il trattamento dei dati e i diritti delle persone, il calendario applicativo e le sanzioni. È pensata per chi deve prendere decisioni: direzione generale, legale, compliance, data protection, IT e business owner dei progetti AI.

1. Cos'è l'AI Act e a chi si applica

Il Regolamento (UE) 2024/1689 è il primo quadro normativo orizzontale al mondo sull'intelligenza artificiale. Non regola una tecnologia specifica ma il modo in cui i sistemi di AI vengono immessi sul mercato, messi in servizio e utilizzati, applicando obblighi proporzionati al rischio che generano per la salute, la sicurezza e i diritti fondamentali.

Definizione di sistema di AI. Un sistema automatizzato progettato per operare con livelli variabili di autonomia, che può mostrare adattività dopo la messa in servizio e che, a partire dagli input ricevuti, deduce come generare output (previsioni, contenuti, raccomandazioni, decisioni) capaci di influenzare ambienti fisici o virtuali. La deduzione è l'elemento discriminante: un software che applica regole deterministiche scritte da una persona non rientra nel perimetro, un modello che apprende relazioni dai dati sì.

Modelli per finalità generali (GPAI). I modelli generativi di grandi dimensioni hanno un capitolo dedicato, con obblighi di documentazione tecnica, informativa a valle, politica di rispetto del diritto d'autore e sintesi pubblica dei dati di addestramento. Per i modelli che presentano rischio sistemico si aggiungono valutazione avversariale, mitigazione dei rischi, tracciamento degli incidenti gravi e sicurezza informatica rafforzata.

Ambito extraterritoriale. Il regolamento si applica a fornitori stabiliti fuori dall'Unione quando l'output del sistema viene utilizzato nell'Unione. Una società italiana che integra un modello sviluppato negli Stati Uniti non trasferisce il rischio al fornitore: assume obblighi propri come deployer e, in certi casi, diventa essa stessa fornitore.

Cosa resta fuori. Sistemi usati esclusivamente per scopi militari, di difesa o sicurezza nazionale; attività di ricerca e sviluppo prima dell'immissione sul mercato; uso strettamente personale non professionale; componenti rilasciate con licenza libera e open source, salvo quando ricadono in categorie vietate o ad alto rischio.

Rapporto con il Digital Omnibus. Il pacchetto di semplificazione ha ricalibrato tempi e adempimenti su alcuni fronti, ma non ha modificato l'impianto: divieti, classificazione del rischio, obblighi per i sistemi ad alto rischio e regime GPAI restano il centro della norma. Ne abbiamo scritto in dettaglio nell'analisi sul Digital Omnibus e nel punto sulle scadenze del 2 agosto 2026.

2. Le quattro classi di rischio

La classificazione è il primo esercizio operativo: senza di essa ogni valutazione successiva è arbitraria.

Classe	Esempi aziendali	Conseguenza
Rischio inaccettabile	Social scoring, riconoscimento delle emozioni sul posto di lavoro, tecniche manipolative, scraping non mirato di volti per costruire database biometrici	Divieto assoluto, già applicabile
Alto rischio	Screening e selezione dei candidati, valutazione delle prestazioni e promozioni, scoring creditizio, pricing e sottoscrizione assicurativa vita e salute, componenti di sicurezza di prodotti regolamentati, sistemi usati in istruzione, servizi essenziali, giustizia	Regime completo di conformità, valutazione di conformità, marcatura CE, registrazione
Rischio limitato	Chatbot verso il cliente, generazione di contenuti sintetici, deepfake, sistemi che interagiscono con persone fisiche	Obblighi di trasparenza e marcatura dei contenuti
Rischio minimo	Filtri antispam, ottimizzazione logistica interna, suggerimenti di prodotto non determinanti	Nessun obbligo specifico, codici di condotta volontari

Due precisazioni che generano la maggior parte degli errori di classificazione. La prima: un sistema elencato tra quelli ad alto rischio può essere declassato se svolge un compito procedurale ristretto, migliora il risultato di un'attività umana già completata, rileva soltanto deviazioni da schemi decisionali senza sostituire la valutazione umana o esegue un compito preparatorio. Il declassamento va documentato, non presunto, e cade comunque quando il sistema effettua profilazione di persone fisiche. La seconda: la classe dipende dalla finalità d'uso, non dalla tecnologia. Lo stesso modello linguistico è a rischio limitato in un chatbot informativo e ad alto rischio se filtra curricula.

La classificazione va tenuta in un registro dei sistemi AI, con owner, finalità, dati trattati, ruolo dell'azienda e classe di rischio. È il punto di partenza dell'AI Assessment e la base su cui costruiamo l'AI Rating.

3. Ruoli e responsabilità lungo la catena

L'AI Act distribuisce gli obblighi su cinque ruoli. Un'azienda può ricoprirne più di uno contemporaneamente, per sistemi diversi o addirittura per lo stesso sistema in mercati diversi.

Ruolo	Chi è	Obblighi principali
Fornitore	Sviluppa il sistema o lo fa sviluppare e lo immette sul mercato con il proprio nome o marchio	Sistema di gestione della qualità e del rischio, documentazione tecnica, valutazione di conformità, marcatura CE, registrazione nella banca dati UE, monitoraggio post commercializzazione, segnalazione degli incidenti gravi
Deployer	Utilizza il sistema sotto la propria autorità nell'ambito di un'attività professionale	Uso conforme alle istruzioni, sorveglianza umana con persone competenti, qualità dei dati di input controllabili, conservazione dei log, informativa ai lavoratori e agli interessati, valutazione d'impatto sui diritti fondamentali nei casi previsti
Importatore	Immette sul mercato UE un sistema di un fornitore extra UE	Verifica di conformità, documentazione, tracciabilità, cooperazione con le autorità
Distributore	Rende disponibile il sistema sul mercato senza esserne fornitore o importatore	Verifica di marcatura e documentazione, sospensione della distribuzione in caso di non conformità
Rappresentante autorizzato	Soggetto nell'Unione designato da un fornitore extra UE	Custodia della documentazione, interfaccia con le autorità

Quando un deployer diventa fornitore. È lo scenario più sottovalutato e il più frequente nelle aziende che adottano AI senza svilupparla. Si diventa fornitori quando si appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, quando si modifica sostanzialmente un sistema ad alto rischio già in uso, oppure quando si modifica la finalità di un sistema in modo che diventi ad alto rischio. Un esempio concreto: un modello generale integrato in un flusso di valutazione dei candidati e riesposto internamente come strumento HR aziendale trasforma il deployer in fornitore, con l'intero pacchetto di obblighi che ne consegue.

Su questo punto la governance vale più della tecnologia: serve una regola interna che stabilisca chi autorizza integrazioni e modifiche e con quale istruttoria. È il lavoro che facciamo nel percorso di AI Governance e nella definizione della AI Strategy.

4. Obblighi operativi per i sistemi ad alto rischio

Per i sistemi in classe alta il regolamento richiede un sistema di conformità permanente, non un adempimento una tantum.

Sistema di gestione del rischio. Processo iterativo che copre l'intero ciclo di vita: identificazione dei rischi ragionevolmente prevedibili per salute, sicurezza e diritti fondamentali, stima dei rischi in condizioni d'uso previste e di uso improprio prevedibile, adozione di misure di mitigazione, test con metriche e soglie definite in anticipo.

Governance dei dati. I set di addestramento, validazione e test devono essere pertinenti, sufficientemente rappresentativi e, per quanto possibile, privi di errori e completi rispetto alla finalità. Vanno esaminate le possibili distorsioni che incidono su salute, sicurezza e diritti, con misure di rilevazione e correzione. Questo è il capitolo che collega direttamente l'AI Act al lavoro sui dati che trattiamo in AI Data.

Documentazione tecnica e registrazione automatica. La documentazione deve dimostrare la conformità prima dell'immissione sul mercato e restare aggiornata. I sistemi devono registrare automaticamente gli eventi lungo il ciclo di vita, con log conservati per un periodo adeguato alla finalità e comunque non inferiore a sei mesi salvo diversa previsione.

Trasparenza verso il deployer. Istruzioni per l'uso chiare, con caratteristiche, capacità, limiti di prestazione, livelli di accuratezza attesi, condizioni che possono generare rischi, misure di sorveglianza umana previste e vita utile attesa.

Sorveglianza umana. Il sistema deve essere progettato perché una persona possa comprenderne le capacità e i limiti, interpretarne correttamente l'output, decidere di non usarlo, ignorarne il risultato o interromperne il funzionamento. La sorveglianza umana non è una firma finale su un output già formato: se chi supervisiona non ha il tempo, l'informazione e l'autorità per dissentire, l'obbligo non è soddisfatto.

Accuratezza, robustezza e cybersicurezza. Livelli adeguati e coerenti lungo il ciclo di vita, con resilienza a errori, guasti, incoerenze e tentativi di manipolazione dei dati o del modello, incluso il data poisoning e gli attacchi avversariali.

Valutazione di conformità e marcatura CE. A seconda del caso, controllo interno o intervento di un organismo notificato, seguito da dichiarazione di conformità UE, marcatura CE e registrazione nella banca dati europea.

Monitoraggio post commercializzazione. Raccolta e analisi sistematica dei dati sulle prestazioni reali, con obbligo di segnalare gli incidenti gravi alle autorità entro termini stretti.

5. Dati e diritti delle persone

L'AI Act non sostituisce il GDPR: si sovrappone. Ogni sistema che tratta dati personali deve soddisfare entrambi i regimi, e nella pratica è qui che si concentrano i contenziosi e le contestazioni interne.

Base giuridica e minimizzazione. Prima di ogni valutazione tecnica serve una base giuridica valida per l'addestramento, per il fine tuning e per l'inferenza, con finalità distinte e documentate. Riusare dati raccolti per l'erogazione di un servizio per addestrare un modello è un cambio di finalità che va giustificato, non una prosecuzione naturale.

Decisioni automatizzate. L'articolo 22 del GDPR limita le decisioni interamente automatizzate che producono effetti giuridici o incidono in modo analogamente significativo sulla persona. Non basta inserire un revisore formale: serve un intervento umano significativo. Abbiamo approfondito il tema nell'articolo sull'articolo 22 del GDPR nelle decisioni aziendali.

DPIA e valutazione d'impatto sui diritti fondamentali. La DPIA resta l'obbligo del GDPR quando il trattamento presenta rischi elevati. La FRIA è l'obbligo dell'AI Act per determinati deployer di sistemi ad alto rischio, in particolare organismi pubblici e soggetti che erogano servizi pubblici essenziali oltre a specifici casi in ambito creditizio e assicurativo. Sono strumenti distinti ma con evidenze in larga parte comuni: conviene progettarli come un unico fascicolo con due viste, non come due esercizi paralleli.

Trasparenza verso le persone. Chi interagisce con un sistema di AI deve saperlo, salvo che sia palese dal contesto. I contenuti sintetici vanno marcati in formato leggibile dalla macchina. I deepfake e i testi pubblicati per informare il pubblico su questioni di interesse generale richiedono dichiarazione esplicita. Nei luoghi di lavoro, i lavoratori e i loro rappresentanti vanno informati prima della messa in servizio di un sistema ad alto rischio.

Diritto alla spiegazione. La persona soggetta a una decisione presa da un sistema ad alto rischio che produce effetti giuridici o incide significativamente su di lei ha diritto a ottenere dal deployer spiegazioni chiare e significative sul ruolo del sistema nella decisione e sui principali elementi che l'hanno determinata. Tradotto in requisito tecnico: servono log a livello di singola decisione, versionamento del modello e delle regole, e una spiegazione comprensibile senza gergo statistico.

Dati nei modelli e diritti degli interessati. Cancellazione, rettifica e opposizione vanno gestite anche quando i dati sono confluiti nell'addestramento. Le strade praticabili sono la filtrazione a monte, la separazione fra base di conoscenza recuperabile e pesi del modello, e la scelta architetturale del recupero documentale rispetto al fine tuning quando i dati personali sono in gioco.

6. AI literacy e obblighi trasversali

L'obbligo di alfabetizzazione riguarda tutti i fornitori e i deployer, indipendentemente dalla classe di rischio dei sistemi utilizzati: il personale che si occupa del funzionamento e dell'uso dei sistemi deve avere un livello sufficiente di competenza, tenuto conto del contesto e delle persone su cui il sistema incide. Non è un corso una tantum ma un programma proporzionato al ruolo: chi seleziona i fornitori, chi supervisiona gli output e chi progetta i processi hanno bisogni formativi diversi. È esattamente la logica dei percorsi AI Training e dei corsi e workshop aziendali.

7. Sanzioni e calendario

Violazione	Massimale
Pratiche vietate	35 milioni di euro o 7% del fatturato mondiale annuo
Violazione degli obblighi su sistemi ad alto rischio, trasparenza, GPAI	15 milioni di euro o 3% del fatturato
Informazioni inesatte, incomplete o fuorvianti alle autorità	7,5 milioni di euro o 1% del fatturato

Si applica il valore più elevato tra importo fisso e percentuale, con soglie ridotte per le PMI. Il calendario è scaglionato: i divieti e gli obblighi di alfabetizzazione sono già applicabili, il regime GPAI è entrato in vigore nella seconda fase, gli obblighi sui sistemi ad alto rischio seguono con tempi differenziati fra i sistemi elencati negli allegati e quelli che sono componenti di sicurezza di prodotti già regolamentati. In Italia si aggiunge il quadro nazionale, con la legge 132/2025 e l'estensione della responsabilità amministrativa degli enti attraverso il nuovo articolo 25-vicies del D.Lgs. 231/2001: un profilo che sposta il tema dal budget della compliance a quello del consiglio di amministrazione.

8. Dalla norma alla governance interna

La conformità non si ottiene con un documento: si ottiene con un sistema di gestione che produce evidenze in modo ripetibile. ISO/IEC 42001 è oggi lo strumento più efficace per farlo, perché fornisce la struttura organizzativa (politica, ruoli, obiettivi, controlli, audit interni, riesame della direzione) su cui appoggiare i requisiti dell'AI Act. Il confronto puntuale fra i due impianti è nella nostra guida ai framework di AI governance.

Gli elementi minimi di una governance che regge un'ispezione sono cinque: una policy AI approvata dal vertice, un registro dei sistemi con classificazione motivata, un processo di autorizzazione dei nuovi casi d'uso con gate espliciti, log e documentazione conservati per sistema, un ciclo di riesame periodico con owner nominati. Il resto è dettaglio implementativo. Chi vuole misurare la propria distanza da questo punto può partire dal nostro percorso di compliance AI.

9. Un piano operativo per fasi

Prima fase, inventario e classificazione. Censimento di tutti i sistemi di AI in uso, inclusi quelli acquistati come funzionalità dentro software di terze parti e quelli introdotti da singoli team senza autorizzazione. Per ciascuno: finalità, ruolo dell'azienda, dati trattati, classe di rischio, owner. L'output è il registro dei sistemi AI e una lista di priorità.

Seconda fase, gap analysis e decisioni. Confronto fra obblighi applicabili ed evidenze esistenti, per sistema. Decisioni esplicite su cosa dismettere, cosa portare a conformità, cosa rinegoziare con i fornitori. Qui si scrive la policy AI e si definisce il processo di autorizzazione.

Terza fase, remediation e prova. Chiusura dei gap prioritari, attivazione del logging, formalizzazione della sorveglianza umana, avvio del programma di AI literacy, test del processo su un caso reale. La durata di ciascuna fase dipende dal numero di sistemi in uso, dalla maturità dei processi esistenti e dalla disponibilità delle evidenze: quello che conta è l'ordine, non il calendario. Al termine si deve poter rispondere a tre domande con documenti alla mano: quali sistemi usiamo, chi ne risponde, come dimostriamo che sono sotto controllo.

Sul lato adozione il principio è simmetrico: nessun sistema arriva in produzione senza validazione. È la logica del percorso di AI Adoption, della validazione rapida con PROTOT.AI e della messa in esercizio degli agenti AI.

10. Domande frequenti

L'AI Act si applica anche se usiamo solo strumenti di terze parti? Sì. Chi utilizza un sistema di AI nell'ambito di un'attività professionale è un deployer e ha obblighi propri, che non si trasferiscono al fornitore per contratto.

Un chatbot interno è ad alto rischio? Di norma no, se serve a rispondere a domande e non concorre a decisioni su persone. Diventa ad alto rischio se entra in processi di selezione, valutazione, accesso a servizi essenziali o credito.

Basta inserire un revisore umano per uscire dall'alto rischio? No. La sorveglianza umana è un requisito dei sistemi ad alto rischio, non una via di uscita dalla classificazione. Il declassamento è possibile solo nei casi tipizzati e va documentato.

Che differenza c'è fra DPIA e FRIA? La DPIA riguarda i rischi per la protezione dei dati ed è un obbligo GDPR. La FRIA riguarda l'impatto sui diritti fondamentali ed è un obbligo AI Act per determinati deployer di sistemi ad alto rischio. Condividono gran parte delle evidenze.

Se modifichiamo un modello acquistato diventiamo fornitori? Se la modifica è sostanziale su un sistema ad alto rischio, o se cambia la finalità rendendolo ad alto rischio, sì. Anche apporre il proprio marchio produce lo stesso effetto.

Quanto tempo serve per essere conformi? Per un'azienda con pochi sistemi non critici, un trimestre di lavoro strutturato è sufficiente a chiudere l'impianto. Per portafogli con sistemi ad alto rischio i tempi dipendono dalla valutazione di conformità e dal livello di documentazione già disponibile.

Le PMI hanno un regime più leggero? Non sono esentate, ma beneficiano di massimali sanzionatori ridotti, documentazione semplificata in alcuni casi e accesso prioritario alle sandbox normative nazionali.

Il passo successivo

Le organizzazioni che affrontano bene l'AI Act non sono quelle che leggono più articoli del regolamento: sono quelle che trasformano il testo in un registro, un processo di autorizzazione e un insieme di evidenze aggiornate. È un lavoro di governo, non di adempimento.

Se vuoi capire dove si trova la tua azienda rispetto a questo quadro, il modo più veloce è una conversazione di trenta minuti oppure un AI Rating, la nostra valutazione strutturata della maturità e dell'esposizione normativa. Da lì si costruisce un piano che tiene insieme conformità e capacità di portare l'AI in produzione.