L’Artificial Intelligence Act, più spesso chiamato AI Act, è il regolamento dell’Unione europea che disciplina lo sviluppo, la commercializzazione e l’utilizzo dei sistemi di intelligenza artificiale. Il riferimento normativo è il Regolamento (UE) 2024/1689, costruito attorno a un principio semplice: più un sistema AI può incidere sulla sicurezza, sui diritti o sulle persone, maggiori sono gli obblighi da rispettare.
Non significa che qualsiasi software con una funzione AI diventi improvvisamente “ad alto rischio”. Non significa neppure che usare ChatGPT in azienda richieda gli stessi adempimenti di un sistema che seleziona candidati, valuta l’accesso a un servizio essenziale o viene incorporato in un dispositivo medico.
Il punto è proprio questo: per capire cosa impone l’AI Act bisogna partire dal ruolo dell’organizzazione, dall’uso concreto del sistema e dal livello di rischio, non dal fatto che un prodotto abbia semplicemente un’etichetta “AI”.
Il quadro, inoltre, è già operativo in numerose sue parti ed è stato modificato dal Digital Omnibus on AI, che ha cambiato soprattutto il calendario dei sistemi ad alto rischio. In questa guida vediamo quindi non soltanto cosa prevedeva il regolamento originario, ma cosa deve considerare oggi un’azienda che sviluppa o utilizza intelligenza artificiale in Europa.
Questa guida ha finalità informative e non sostituisce una valutazione legale o di compliance sul singolo sistema, settore o caso d’uso.
Cos’è l’Artificial Intelligence Act
L’Artificial Intelligence Act è il primo quadro normativo europeo orizzontale specificamente dedicato all’intelligenza artificiale. Non regolamenta una singola tecnologia o un singolo prodotto: definisce regole che possono applicarsi a categorie molto diverse di sistemi AI.
Se vuoi partire dalla base tecnica, nella guida dedicata spieghiamo cos’è l’intelligenza artificiale e come funziona un sistema AI. Qui il problema è diverso: quando un sistema rientra nell’AI Act e quali conseguenze normative ne derivano.
Quali sono gli obiettivi del Regolamento UE 2024/1689
Il regolamento stabilisce, fra le altre cose:
- regole armonizzate per l’immissione sul mercato, la messa in servizio e l’uso dei sistemi AI nell’Unione;
- il divieto di determinate pratiche considerate incompatibili con i diritti e i valori europei;
- requisiti specifici per i sistemi classificati ad alto rischio;
- obblighi di trasparenza per particolari categorie di sistemi e contenuti;
- obblighi per i provider di modelli di intelligenza artificiale per finalità generali;
- regole sulla governance, sulla vigilanza e sull’applicazione delle sanzioni.
La logica non è quindi “regolare l’AI in generale”, ma differenziare gli obblighi in base alla funzione e al rischio.
Questo aspetto evita due semplificazioni opposte: pensare che l’AI Act vieti l’intelligenza artificiale oppure, all’estremo contrario, considerarlo rilevante soltanto per le grandi aziende tecnologiche.
A chi si applica l’AI Act
L’ambito è ampio.
Il regolamento riguarda i provider che immettono sistemi AI o modelli GPAI sul mercato europeo, i deployer che li utilizzano nell’Unione, importatori, distributori e alcuni produttori che integrano sistemi AI nei propri prodotti.
Può inoltre raggiungere operatori stabiliti fuori dall’Unione quando l’output prodotto dal sistema viene utilizzato nell’UE.
Per una normale azienda italiana il caso più frequente non sarà quello di costruire un foundation model, ma quello di utilizzare sistemi sviluppati da altri all’interno dei propri processi.
Ed è qui che diventa importante il concetto di deployer.
Provider e deployer: perché il ruolo cambia gli obblighi
Nel linguaggio dell’AI Act i ruoli non sono intercambiabili.
Un provider sviluppa un sistema AI, oppure lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio.
Un deployer utilizza invece un sistema AI sotto la propria autorità nell’ambito della propria attività, escludendo normalmente l’uso personale e non professionale.
Prendiamo due scenari.
Un’azienda sviluppa una piattaforma AI per valutare candidature e la vende ad altre imprese: può assumere il ruolo di provider.
Un’impresa acquista quella piattaforma e la utilizza per il proprio recruiting: può essere deployer.
Lo stesso sistema genera quindi obblighi differenti lungo la catena.
Ecco perché una checklist di conformità che parte dal nome del software è poco utile. La prima domanda dovrebbe essere:
che ruolo abbiamo rispetto a questo sistema e per quale scopo lo stiamo utilizzando?
Come funziona l’approccio basato sul rischio dell’AI Act
L’AI Act adotta un approccio risk-based. Nella pratica conviene distinguere almeno quattro grandi situazioni.
| Categoria | Esempio indicativo | Conseguenza principale |
|---|---|---|
| Pratiche vietate | social scoring o determinati usi manipolativi | utilizzo vietato salvo specifiche eccezioni previste dal regolamento |
| Alto rischio | alcuni sistemi usati per occupazione, istruzione, servizi essenziali o biometria | requisiti e obblighi molto più stringenti |
| Rischio di trasparenza | chatbot, deepfake e determinati contenuti sintetici | obblighi di informazione, disclosure o marcatura |
| Rischio minimo o nullo | molti videogiochi, filtri antispam e normali applicazioni AI | nessun regime high-risk specifico dell’AI Act |
La tabella è una mappa mentale, non un classificatore automatico. Un sistema deve essere valutato rispetto alle condizioni previste dal regolamento e al proprio uso previsto.
Pratiche di intelligenza artificiale vietate
L’articolo 5 vieta alcune pratiche considerate incompatibili con i diritti fondamentali o caratterizzate da un rischio inaccettabile.
Tra gli esempi più rilevanti rientrano determinati sistemi che:
- utilizzano tecniche manipolative o ingannevoli capaci di provocare un danno significativo;
- sfruttano vulnerabilità legate, per esempio, all’età, alla disabilità o a particolari condizioni sociali o economiche;
- realizzano forme di social scoring con conseguenze ingiustificate o sproporzionate;
- stimano il rischio che una persona commetta un reato basandosi esclusivamente sulla profilazione o su caratteristiche personali;
- creano o ampliano database di riconoscimento facciale attraverso scraping indiscriminato di immagini da Internet o sistemi CCTV;
- inferiscono emozioni nei luoghi di lavoro o negli istituti di istruzione, salvo specifiche finalità mediche o di sicurezza;
- utilizzano determinate categorizzazioni biometriche per dedurre caratteristiche particolarmente sensibili.
L’identificazione biometrica remota in tempo reale negli spazi pubblicamente accessibili per finalità di law enforcement è anch’essa fortemente limitata, con eccezioni e condizioni specifiche.
Il dettaglio è importante: “vietato dall’AI Act” non significa semplicemente “AI che non ci piace”. Il divieto deriva da fattispecie precise e deve essere verificato rispetto all’articolo 5 e al caso concreto.
Sistemi AI ad alto rischio
Un secondo livello riguarda i sistemi definiti high-risk.
Una prima categoria comprende sistemi AI utilizzati come componenti di sicurezza, o che costituiscono essi stessi prodotti, disciplinati da specifica normativa europea dell’Allegato I e soggetti a valutazione di conformità da parte di terzi.
L’altra grande categoria deriva dall’Allegato III e comprende determinati impieghi in aree sensibili come:
- biometria;
- infrastrutture critiche;
- istruzione e formazione professionale;
- occupazione e gestione dei lavoratori;
- accesso ad alcuni servizi essenziali;
- law enforcement;
- migrazione, asilo e controllo delle frontiere;
- amministrazione della giustizia e determinati processi democratici.
Non basta però trovare la propria attività in questa lista e fermarsi.
L’articolo 6 dell’AI Act prevede infatti condizioni in cui un sistema elencato nell’Allegato III può non essere classificato ad alto rischio quando non presenta un rischio significativo per salute, sicurezza o diritti fondamentali e svolge determinate funzioni limitate.
C’è però una distinzione importante: se un sistema dell’Allegato III effettua profilazione di persone fisiche, resta considerato high-risk.
Questo è uno dei motivi per cui la classificazione dovrebbe essere documentata e non decisa sulla base di formule generiche.
Sistemi soggetti a obblighi di trasparenza
Esistono poi sistemi che non devono necessariamente essere classificati ad alto rischio, ma per i quali il regolamento considera essenziale sapere quando stiamo interagendo con un’AI o quando un contenuto è stato generato o manipolato artificialmente.
Qui rientrano gli obblighi dell’articolo 50, che approfondiremo più avanti.
Sistemi a rischio minimo o nullo
La maggior parte degli utilizzi quotidiani dell’intelligenza artificiale non diventa automaticamente high-risk.
Un filtro antispam, un sistema AI inserito in un videogioco o numerosi strumenti di produttività possono restare al di fuori del regime più stringente, salvo che caratteristiche, finalità o modalità di impiego facciano scattare altre disposizioni.
Questa distinzione è essenziale anche per le PMI: l’AI Act non richiede di trattare allo stesso modo ogni singola funzione AI utilizzata in azienda.
General Purpose AI e modelli con rischio sistemico
La crescita dei modelli generativi ha reso necessario un livello ulteriore.
Il regolamento disciplina infatti i General-Purpose AI models, o GPAI: modelli caratterizzati da una generalità significativa, capaci di svolgere un’ampia varietà di compiti e di essere integrati in numerosi sistemi o applicazioni downstream.
Un modello GPAI e un sistema high-risk non sono la stessa cosa.
Un modello general purpose può diventare una componente di moltissimi prodotti diversi. Il suo provider ha quindi obblighi propri, mentre chi utilizza quel modello per costruire un sistema destinato a uno specifico scenario può assumere ulteriori responsabilità.
Quali obblighi hanno i provider GPAI
Secondo la Commissione europea sugli obblighi GPAI, i provider interessati devono affrontare requisiti che comprendono:
- documentazione tecnica del modello;
- informazioni utili ai provider downstream;
- una policy per il rispetto della normativa europea sul copyright;
- una sintesi sufficientemente dettagliata dei contenuti utilizzati per l’addestramento.
Il General-Purpose AI Code of Practice può inoltre essere utilizzato come strumento volontario per aiutare i provider a dimostrare il rispetto di determinate disposizioni.
Quando un modello GPAI presenta rischio sistemico
Per i modelli considerati a rischio sistemico entrano in gioco misure ulteriori.
Tra queste troviamo valutazione e mitigazione dei rischi sistemici, model evaluation, adversarial testing, gestione e segnalazione degli incidenti seri e adeguate protezioni di cybersicurezza.
È un regime rivolto soprattutto ai provider dei modelli più rilevanti, non un pacchetto di adempimenti che si trasferisce automaticamente alla piccola azienda che utilizza un chatbot commerciale.
Il punto da ricordare è:
GPAI descrive il modello e i suoi obblighi; high-risk descrive un’altra parte della classificazione normativa e non va usata come sinonimo.
Cosa è già obbligatorio nell’AI Act
Parlare dell’AI Act come di una normativa “che entrerà in vigore in futuro” è ormai fuorviante.
Diverse disposizioni sono già applicabili, tra cui le regole sulle pratiche vietate, l’AI literacy, la governance, gli obblighi relativi ai modelli GPAI e gli obblighi di trasparenza per determinati sistemi.
Per molte aziende significa che il momento utile per iniziare a classificare gli strumenti utilizzati non coincide con l’arrivo delle regole high-risk.
Se i dipendenti utilizzano AI generativa, se l’azienda mette a disposizione chatbot, genera contenuti sintetici, sviluppa soluzioni AI o incorpora sistemi intelligenti in processi decisionali, esistono già domande a cui conviene rispondere.
La prima è molto semplice:
sappiamo quali sistemi AI stiamo realmente utilizzando e per quali processi?
Se la risposta è no, è difficile anche determinare quali disposizioni siano applicabili.
AI literacy: cosa richiede davvero l’AI Act
L’AI literacy, o alfabetizzazione in materia di intelligenza artificiale, è uno dei punti più fraintesi.
Dopo le modifiche introdotte dal Digital Omnibus, provider e deployer devono adottare misure che sostengano lo sviluppo delle competenze e della comprensione necessarie per le persone che operano con i sistemi AI per loro conto.
La FAQ aggiornata della Commissione sull’AI literacy chiarisce però un punto fondamentale: non viene imposto uno specifico livello universale di alfabetizzazione e non esiste un unico corso standard obbligatorio valido per qualsiasi organizzazione.
Chi deve occuparsene
L’obbligo riguarda provider e deployer e deve essere calibrato considerando elementi come:
- conoscenze tecniche;
- esperienza;
- istruzione e formazione;
- sistema utilizzato;
- contesto di impiego;
- rischi collegati all’uso.
Un copywriter che utilizza un generatore di testo ha esigenze diverse da un responsabile HR che lavora con un sistema destinato alla valutazione dei candidati.
Un tecnico che integra modelli all’interno di un prodotto avrà esigenze ancora differenti.
Usare ChatGPT richiede AI literacy?
La Commissione affronta esplicitamente anche casi ordinari di utilizzo dell’AI generativa.
Un’azienda i cui dipendenti utilizzano strumenti come ChatGPT per scrivere testi pubblicitari o tradurre contenuti rientra comunque nel ragionamento sull’AI literacy: le persone dovrebbero comprendere i rischi rilevanti, come la possibilità di generare informazioni errate.
Non significa organizzare necessariamente un corso di quaranta ore.
Può significare invece definire istruzioni interne sensate su:
- quali dati possono essere inseriti nei sistemi;
- quali output devono essere verificati;
- quali usi richiedono supervisione;
- come gestire errori e hallucination;
- quando è necessario un controllo umano;
- quali strumenti sono autorizzati.
L’errore sarebbe trasformare l’obbligo in una casella da spuntare.
AI literacy non significa accumulare attestati: significa rendere le persone sufficientemente preparate rispetto ai sistemi che utilizzano e ai rischi che devono gestire.
Obblighi di trasparenza: chatbot, deepfake e contenuti generati con l’AI
L’articolo 50 affronta una questione diversa: quando una persona deve essere informata che sta interagendo con un sistema AI o che un contenuto è artificiale.
Le linee guida della Commissione sugli obblighi di trasparenza distinguono responsabilità diverse per provider e deployer.
Quando bisogna dichiarare che l’utente sta interagendo con un sistema AI
I provider di sistemi destinati a interagire direttamente con persone devono progettare il sistema in modo che l’utente sia informato di trovarsi di fronte a un’AI, salvo i casi in cui ciò risulti evidente a una persona ragionevolmente informata e attenta.
Il classico caso è il chatbot.
La trasparenza serve a impedire che una persona attribuisca erroneamente l’interazione a un essere umano quando questo può influenzare le sue decisioni.
Marcatura dei contenuti sintetici
Per determinati sistemi capaci di generare o manipolare testo, immagini, audio o video esistono anche obblighi rivolti ai provider affinché gli output siano identificabili come generati o manipolati artificialmente, secondo i requisiti previsti dalla normativa.
È un livello diverso dalla semplice etichetta visibile sul sito: il regolamento contempla anche la rilevabilità tecnica del contenuto.
Deepfake e contenuti destinati a informare il pubblico
Per i deployer entrano in gioco ulteriori obblighi quando vengono utilizzati sistemi per creare o manipolare deepfake e, in determinate circostanze, testi pubblicati allo scopo di informare il pubblico su questioni di interesse pubblico.
Le condizioni e le eccezioni contano.
Per questo non è corretto trasformare l’articolo 50 nella regola:
“qualsiasi testo scritto con AI deve essere etichettato come generato dall’intelligenza artificiale”.
Il regolamento distingue il tipo di contenuto, il soggetto responsabile, la finalità e le eventuali forme di controllo editoriale.
Sistemi AI ad alto rischio: quali sono davvero
La classificazione high-risk è probabilmente la parte più complessa dell’AI Act perché non dipende esclusivamente dalla tecnologia.
Conta soprattutto cosa fa il sistema e in quale contesto viene utilizzato.
Un modello capace di analizzare testi potrebbe essere impiegato per riassumere documenti interni oppure diventare una componente di un sistema che valuta persone in un processo di selezione.
La tecnologia di base può essere simile. Il rischio normativo no.
Lavoro e selezione del personale
L’occupazione è uno degli ambiti più evidenti.
Possono rientrare nella classificazione prevista dal regolamento sistemi destinati, per esempio, al recruiting, alla selezione di candidati, all’assegnazione di compiti o alla valutazione di determinati aspetti del rapporto di lavoro.
Qui il rischio non deriva dal fatto che “l’algoritmo è avanzato”, ma dalla possibilità che il sistema influenzi concretamente opportunità e diritti delle persone.
I problemi di discriminazione sono inoltre strettamente collegati al tema dei bias nei sistemi di intelligenza artificiale: dati e modelli possono riprodurre o amplificare disparità esistenti se non vengono governati correttamente.
Istruzione e formazione
Anche alcuni sistemi destinati all’istruzione o alla formazione professionale possono rientrare nell’Allegato III, soprattutto quando incidono sull’accesso, sulla valutazione o sul percorso delle persone.
Un assistente AI usato da uno studente per riassumere un testo non equivale quindi automaticamente a un sistema che determina l’accesso a un percorso educativo.
Servizi essenziali e altre aree sensibili
Il quadro comprende inoltre specifici utilizzi collegati a servizi pubblici o privati essenziali, law enforcement, migrazione, amministrazione della giustizia, biometria e altre aree dettagliate nell’Allegato III.
La lezione pratica è sempre la stessa:
la categoria “AI” è troppo larga per stabilire il rischio. Serve identificare l’esatto intended purpose e l’impatto del sistema.
Quali obblighi hanno provider e deployer dei sistemi ad alto rischio
Una volta classificato un sistema come high-risk, il livello di governance cresce sensibilmente.
Provider e deployer non hanno però gli stessi compiti.
| Area | Provider | Deployer |
|---|---|---|
| Sistema di gestione del rischio | responsabilità centrale nella progettazione e conformità | utilizzo coerente con le istruzioni e monitoraggio operativo |
| Dati e governance | requisiti sui dataset pertinenti al sistema | controllo dei dati di input quando sotto il proprio controllo |
| Documentazione | documentazione tecnica e informazioni per la conformità | conservazione delle informazioni necessarie relative all’uso |
| Logging | progettazione per consentire la registrazione | conservazione dei log quando applicabile |
| Sorveglianza umana | sistema progettato per consentirla | persone competenti, formate e dotate dell’autorità necessaria |
| Monitoraggio | post-market monitoring e altri obblighi del provider | verifica del funzionamento e gestione di rischi o incidenti |
Tra i requisiti dei sistemi ad alto rischio rientrano gestione dei rischi, governance dei dati, documentazione tecnica, registrazione degli eventi, trasparenza verso il deployer, sorveglianza umana, accuratezza, robustezza e cybersicurezza.
Per i deployer la sorveglianza umana merita particolare attenzione.
Non basta inserire una persona formalmente “nel loop”. La persona deve disporre della competenza, della formazione, dell’autorità e del supporto necessari per intervenire davvero.
Se il sistema suggerisce una decisione e l’operatore si limita ad approvarla sistematicamente senza comprenderla, il controllo umano rischia di diventare puramente nominale.
Quando si applica l’AI Act: il calendario da conoscere
Il calendario è uno dei punti su cui molti contenuti online stanno diventando rapidamente obsoleti.
Il piano originario è stato modificato dal Digital Omnibus on AI. La timeline ufficiale dell’AI Act distingue oggi tra disposizioni già operative e regole high-risk differite.
| Data / stato | Cosa cambia |
|---|---|
| 2 febbraio 2025 | diventano applicabili divieti, definizioni e disposizioni sull’AI literacy |
| 2 agosto 2025 | entrano in applicazione governance e obblighi per i modelli GPAI |
| Già applicabile | gran parte del regolamento, compresi gli obblighi di trasparenza e i relativi poteri di enforcement |
| 2 dicembre 2027 | entrano in applicazione le regole per i sistemi high-risk dell’Allegato III |
| 2 agosto 2028 | entrano in applicazione le regole per i sistemi high-risk incorporati nei prodotti regolamentati dell’Allegato I |
Il punto da non sbagliare è questo:
il rinvio delle regole high-risk non equivale al rinvio dell’AI Act.
Divieti, AI literacy, GPAI, trasparenza, governance e altre disposizioni sono già rilevanti.
Per un’azienda che aspetta il 2027 per iniziare a mappare i propri sistemi AI, quindi, il rischio è partire dalla scadenza sbagliata.
AI Act in Italia: cosa cambia con la legge 132/2025
Essendo un regolamento europeo, l’AI Act è direttamente applicabile nell’Unione. L’Italia ha però adottato anche la Legge 23 settembre 2025, n. 132, entrata in vigore il 10 ottobre 2025.
Il testo della legge italiana sull’intelligenza artificiale specifica che le disposizioni nazionali devono essere interpretate e applicate conformemente al Regolamento (UE) 2024/1689.
Non esiste quindi un “AI Act italiano” alternativo al regolamento europeo.
Esiste un quadro nazionale che si coordina con quello europeo e interviene anche su autorità, settori specifici, strategia nazionale, tutela degli utenti e altre materie.
Il ruolo di AgID e ACN
La legge italiana individua AgID e ACN come Autorità nazionali per l’intelligenza artificiale, con funzioni differenti.
AgID è coinvolta nella promozione dell’innovazione e dello sviluppo dell’AI e svolge, tra le altre, funzioni relative a notifica, valutazione, accreditamento e monitoraggio dei soggetti incaricati delle verifiche di conformità.
ACN assume invece il ruolo di vigilanza del mercato previsto dalla disciplina nazionale, comprese attività ispettive e sanzionatorie, oltre alle competenze collegate alla cybersicurezza.
La legge mantiene inoltre competenze specifiche di altre autorità.
Per esempio, Banca d’Italia, CONSOB e IVASS conservano il proprio ruolo di vigilanza del mercato negli ambiti previsti dal regolamento. Restano ferme anche le competenze del Garante per la protezione dei dati personali.
Questo dettaglio è particolarmente importante per settori già fortemente regolamentati: la compliance AI non sostituisce le autorità e le normative che già governano il settore.
Quali sanzioni prevede l’AI Act
L’AI Act prevede un sistema sanzionatorio consistente, ma anche qui bisogna evitare di ridurlo a un singolo numero.
L’articolo 99 sulle sanzioni distingue diverse fattispecie.
| Violazione | Massimo previsto |
|---|---|
| Violazione delle pratiche AI vietate | 35 milioni di euro o 7% del fatturato mondiale annuo, nei casi previsti |
| Violazione di determinati obblighi del regolamento | 15 milioni di euro o 3% del fatturato mondiale annuo, nei casi previsti |
| Informazioni inesatte, incomplete o fuorvianti fornite alle autorità | 7,5 milioni di euro o 1% del fatturato mondiale annuo, nei casi previsti |
La formula concreta dipende dalla natura del soggetto e dalle regole applicabili. Il regolamento prevede inoltre principi di proporzionalità e disposizioni specifiche per realtà di dimensioni inferiori.
Le percentuali non vanno quindi lette come una multa automatica applicata a qualsiasi errore.
Nella determinazione delle sanzioni entrano in gioco il tipo di violazione, le circostanze e le regole nazionali di enforcement.
Il messaggio utile per un’azienda non è “rischi sempre il 7%”.
È piuttosto:
quando l’AI entra in processi regolamentati, la governance deve essere dimostrabile e non soltanto dichiarata.
Cosa deve fare concretamente un’azienda che utilizza l’intelligenza artificiale
Per molte organizzazioni il problema non è ancora “compilare la documentazione high-risk”.
Il problema viene prima: non esiste un inventario affidabile degli strumenti e degli usi AI interni.
Una sequenza di lavoro sensata parte da qui.
1. Inventariare sistemi e use case AI
Non limitarti agli strumenti acquistati centralmente dall’IT.
Considera anche software SaaS con funzioni AI, chatbot, strumenti generativi, plugin, piattaforme HR, sistemi di analytics, automazioni, servizi di traduzione, generatori di immagini e funzionalità AI integrate in prodotti già utilizzati.
Per ogni sistema registra almeno:
- prodotto o servizio;
- provider;
- funzione AI utilizzata;
- persone o reparti che lo usano;
- dati inseriti;
- output prodotti;
- decisioni che può influenzare;
- eventuali persone interessate dagli output.
Questa mappa vale più di una policy generica scritta senza sapere quali strumenti vengono effettivamente usati.
2. Identificare il proprio ruolo
Per ciascun sistema chiediti se l’organizzazione è provider, deployer, importatore, distributore o assume un altro ruolo nella catena.
Nella maggior parte delle normali attività aziendali il punto di partenza sarà il deployer, ma non bisogna darlo per scontato.
Personalizzazioni profonde, rebranding, sviluppo di sistemi propri o modifiche sostanziali possono cambiare il quadro.
3. Classificare l’uso, non il marchio
Un errore frequente sarebbe dire:
utilizziamo il prodotto X, quindi siamo a rischio minimo.
La classificazione riguarda l’uso concreto del sistema.
Lo stesso modello può essere utilizzato per generare una bozza di email oppure essere integrato in un processo che influenza decisioni su persone.
Il secondo scenario richiede un’analisi completamente diversa.
4. Definire AI literacy e responsabilità
Stabilisci chi può utilizzare quali strumenti e con quali regole.
Non è necessario creare burocrazia inutile. È però utile definire:
- strumenti autorizzati;
- dati vietati o sensibili;
- requisiti di verifica degli output;
- procedure di escalation;
- responsabilità;
- regole per supervisione umana;
- formazione o guidance adeguata al ruolo.
5. Verificare gli obblighi di trasparenza
Se utilizzi chatbot rivolti agli utenti, contenuti sintetici, generatori di immagini, video o audio, oppure sistemi che manipolano contenuti, controlla se ricadi nelle disposizioni dell’articolo 50.
Non affidarti a una regola unica come “mettiamo scritto AI generated ovunque”.
La disclosure deve essere coerente con la fattispecie che si applica davvero.
6. Verificare fornitori e contratti
La compliance non dipende soltanto da ciò che avviene dentro l’azienda.
Può essere necessario capire:
- chi è il provider;
- quale documentazione mette a disposizione;
- quali limiti dichiara;
- quali dati utilizza;
- dove vengono trattati;
- quali controlli e misure di sicurezza offre;
- come gestisce incidenti e cambiamenti del sistema.
Nel caso dei sistemi più sensibili, il rapporto con il fornitore diventa parte della governance.
7. Collegare AI Act, privacy e sicurezza
L’AI Act non vive isolato.
Un sistema AI può contemporaneamente coinvolgere normativa sulla protezione dei dati, cybersecurity, diritto del lavoro, tutela dei consumatori, proprietà intellettuale o normative settoriali.
Per questo una governance efficace dovrebbe evitare silos come:
l’AI la gestisce l’IT, la privacy il DPO e la sicurezza qualcun altro.
Le responsabilità restano differenti, ma i flussi di dati, le decisioni e i rischi attraversano più aree contemporaneamente.
AI Act e GDPR: sono la stessa cosa?
No.
L’AI Act e il GDPR sono due regolamenti differenti e rispondono a problemi differenti.
Il GDPR disciplina il trattamento dei dati personali.
L’AI Act disciplina invece sistemi e modelli di intelligenza artificiale attraverso regole che comprendono classificazione del rischio, obblighi degli operatori, trasparenza, GPAI, pratiche vietate e governance.
Possono però applicarsi contemporaneamente.
Immagina un sistema AI utilizzato per analizzare candidature.
Se tratta dati personali entra in gioco il GDPR.
Se, per finalità e caratteristiche, rientra nella classificazione high-risk dell’AI Act, entrano in gioco anche i requisiti specifici del regolamento sull’intelligenza artificiale.
Rispettare uno dei due quadri non significa automaticamente rispettare l’altro.
Lo stesso vale per cybersecurity, diritto del lavoro e altre normative settoriali.
Per questo, quando l’AI incide su persone o processi sensibili, la domanda utile non è:
siamo conformi all’AI Act?
ma:
quali normative si applicano a questo specifico processo e dove si sovrappongono gli obblighi?
Conclusione
L’Artificial Intelligence Act non è più una normativa da osservare a distanza aspettando che “entri in vigore”.
Una parte importante del quadro è già applicabile: pratiche vietate, AI literacy, obblighi GPAI, trasparenza e governance richiedono già attenzione. Le regole più complesse per i sistemi high-risk arriveranno invece secondo il calendario aggiornato, con scadenze differenti per l’Allegato III e per l’AI integrata nei prodotti regolamentati.
Per un’azienda la priorità, quindi, non dovrebbe essere partire dalle sanzioni.
Dovrebbe essere sapere quali sistemi AI utilizza, per quali finalità, con quali dati, su quali persone possono produrre effetti e quale ruolo assume l’organizzazione.
Da quella mappa discendono classificazione del rischio, formazione, trasparenza, controllo umano, documentazione e rapporti con i fornitori.
Ed è anche il modo più concreto per evitare l’errore opposto: trattare ogni uso dell’intelligenza artificiale come high-risk oppure, al contrario, considerare l’AI Act un problema riservato alle aziende che sviluppano modelli.
La norma è costruita proprio per distinguere questi scenari.