AI Act per le aziende italiane: guida pratica alla conformità

L'intelligenza artificiale fa già parte delle attività quotidiane di molte aziende italiane. Un team commerciale prepara risposte con uno strumento di IA generalista, il servizio clienti sintetizza le chiamate, una fabbrica prevede la manutenzione e le risorse umane usano software per ordinare le candidature. La domanda giuridica non è più se un'azienda usi l'IA, ma se sappia che cosa utilizza, in quale ruolo, quali rischi ne derivino e quali prove possa produrre quando qualcuno le chiede.

Questa guida è destinata a manager, responsabili compliance, team di prodotto e operations delle aziende italiane. È pratica e non costituisce consulenza legale. Il quadro normativo cambia: occorre verificare con professionisti qualificati le date di applicazione, gli obblighi settoriali e il proprio ruolo specifico. La situazione descritta è aggiornata a settembre 2026 e distingue tra norme vincolanti, indicazioni e dettagli applicativi ancora in definizione.

La mappa normativa in una pagina

Lo strumento centrale è il Regolamento (UE) 2024/1689, comunemente chiamato AI Act dell'UE. Si applica a fornitori, deployer, importatori, distributori, produttori di prodotti e altri soggetti i cui sistemi sono immessi sul mercato dell'Unione, messi in servizio nell'Unione o producono output utilizzati nell'Unione. Il testo ufficiale è disponibile su EUR-Lex AI Act. È un regolamento direttamente applicabile, ma molti obblighi dipendono dalla categoria del sistema, dal ruolo dell'attore e dalla data.

La modifica del 2026, il Regolamento (UE) 2026/1744, cambia diverse date e disposizioni transitorie, compreso il calendario di alcuni sistemi ad alto rischio. Consultate il testo ufficiale della modifica insieme all'AI Act consolidato e ai materiali della Commissione applicabili. Non copiate un vecchio calendario in una policy: le nuove date per l'alto rischio possono dipendere dal fatto che il sistema sia integrato in un prodotto regolamentato, dalla disponibilità del relativo regime di approvazione e dalla disposizione transitoria applicabile.

Il quadro normativo della Commissione per l'IA è una fonte utile per informazioni applicative, linee guida, codici, standard e aggiornamenti istituzionali. Questi materiali aiutano a capire come conformarsi, ma una guida non equivale a un nuovo obbligo vincolante. Registrate se ogni documento è obbligatorio, volontario, in sviluppo o puramente esplicativo.

L'Italia dispone inoltre della Legge 132/2025, in vigore dal 10 ottobre 2025. Il testo Normattiva è il riferimento autorevole per verificare disposizioni e formulazione italiana. La legge definisce un quadro nazionale e assegna ruoli alle istituzioni italiane, interagendo con il regolamento europeo direttamente applicabile. Non trasforma ogni dettaglio operativo in un decreto italiano già completato: parte del lavoro istituzionale, tecnico e settoriale è ancora in evoluzione.

Date, obblighi e cosa è cambiato nel 2026

L'AI Act entra in vigore per fasi. I divieti e gli obblighi di alfabetizzazione sull'IA sono rilevanti prima del regime completo per i sistemi ad alto rischio. Trasparenza e governance seguono date proprie, mentre l'alto rischio prevede disposizioni transitorie. La domanda non è semplicemente «l'AI Act è in vigore?», ma «quale disposizione si applica a questo sistema, per quale ruolo, in quale data e con quale transizione?».

Un registro delle transizioni dovrebbe contenere data originaria, data modificata, fattore che la determina, link alla fonte, responsabile e azione necessaria. Indicate come vincolanti le date del regolamento o della modifica e separate linee guida, codici volontari, standard e obiettivi interni. Questa disciplina evita di trattare una pagina riassuntiva come se fosse il testo di legge o una proposta futura come diritto vigente.

Partite dall'inventario dell'IA, non da una policy

Una policy scritta prima della discovery descrive spesso un'azienda immaginaria. L'inventario deve includere software acquistati, esperimenti, funzionalità integrate, API, strumenti browser, modelli open source, fogli di calcolo con componenti IA e usi introdotti dai dipendenti senza approvazione procurement. Per ogni funzione rilevate strumento, scopo, utenti, dati, fornitore, modello o funzionalità, Paesi coinvolti e impatto su persone, prodotti, sicurezza o obblighi giuridici.

• Identificate sistema e funzionalità, compresi versione del modello, interfaccia, API, plug-in, agenti, fonti di retrieval e azioni collegate.
• Registrate provider, rivenditore, importatore, distributore, sede di hosting, referente contrattuale, assistenza e sub-responsabili noti.
• Descrivete lo scopo operativo: selezione di candidati, approvazione del credito, previsione della domanda, risposta ai clienti o redazione di testi marketing.
• Mappate dati in ingresso e destinatari dell'output. Segnalate dati personali, categorie particolari, informazioni riservate, segreti commerciali, dati finanziari, dati di minori e informazioni rilevanti per la sicurezza.
• Documentate le decisioni umane, chi revisiona e può annullare, chi è responsabile, cosa accade con bassa confidenza e se il sistema agisce automaticamente.
• Catturate stato del ciclo di vita, popolazione interessata, Paesi, settore, incidenti, limiti noti, metriche di monitoraggio e data prevista di dismissione.

Non aspettate una discovery tecnica perfetta. Assegnate a ogni voce un responsabile e un livello di affidabilità. Una fattura procurement può dimostrare che uno strumento esiste anche quando nessuno conosce la versione del modello: è un punto da risolvere, non da omettere. Confrontate l'inventario con identità e accessi, software asset management, costi cloud, registri dei trattamenti, questionari di sicurezza, roadmap prodotto e note spese.

Mappate i ruoli prima di assegnare i controlli

La stessa azienda può ricoprire più ruoli dell'AI Act. Un'impresa che costruisce un assistente rivolto ai clienti può essere provider dell'assistente, deployer di un modello di base acquistato da terzi e importatore o distributore di un dispositivo con componente IA. La mappatura va fatta sistema per sistema.

• Provider: soggetto che sviluppa un sistema IA o un modello di IA per finalità generali e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio. Una modifica sostanziale può cambiare l'analisi.
• Deployer: organizzazione o persona che usa un sistema sotto la propria autorità, salvo l'uso personale non professionale. La maggior parte degli utenti aziendali interni è deployer, anche con un SaaS già pronto.
• Importatore: soggetto stabilito nell'Unione che immette sul mercato dell'Unione un sistema proveniente da un Paese terzo. Contano distribuzione e accordi contrattuali.
• Distributore: soggetto della catena di fornitura diverso da provider o importatore che rende disponibile il sistema nell'Unione.
• Produttore di prodotto: produttore che immette sistema e prodotto con il proprio nome o marchio, o li mette in servizio come prodotto coperto dalla normativa dell'Unione.
• Datore di lavoro e operatore: l'uso nell'occupazione, nella gestione del luogo di lavoro, nell'accesso al lavoro o nel monitoraggio dei lavoratori può aggiungere obblighi. Verificate insieme AI Act, diritto del lavoro italiano, accordi collettivi, privacy e requisiti settoriali.

Un contratto con il fornitore non trasferisce ogni responsabilità. Il SaaS può essere provider del proprio sistema, mentre il cliente italiano resta deployer responsabile di uso lecito, istruzioni, supervisione umana, monitoraggio e registri sotto il suo controllo. Rendete esplicita la conclusione nell'inventario e fate approvare i casi insoliti da legale, compliance, procurement, sicurezza e prodotto.

I divieti richiedono un controllo immediato

La prima verifica sostanziale non è un punteggio di rischio, ma lo screening delle pratiche vietate dall'articolo 5. L'AI Act vieta, tra l'altro, alcune tecniche manipolative o ingannevoli, lo sfruttamento delle vulnerabilità, il social scoring e determinate forme di categorizzazione biometrica o inferenza delle emozioni. Dettagli ed eccezioni sono importanti: «analisi del benessere» e «prevenzione frodi» non bastano a dimostrare che un uso sia sicuro.

Create un gate di lancio e modifica con domande semplici: il sistema condiziona il comportamento con tecniche subliminali o manipolative? Sfrutta età, disabilità o condizioni sociali ed economiche? Valuta persone nel tempo causando trattamenti ingiustamente sfavorevoli? Deduce attributi sensibili o emozioni in un contesto vietato? Usa identificazione o categorizzazione biometrica in un ambiente limitato? Se non è chiaro, fermate il rilascio ed effettuate un'escalation. Un uso vietato non diventa lecito aggiungendo un revisore o un disclaimer.

L'alfabetizzazione sull'IA è già un requisito operativo

L'articolo 4 impone a provider e deployer di adottare misure per assicurare, per quanto possibile, un livello sufficiente di alfabetizzazione sull'IA a chi opera o utilizza l'IA per loro conto. Non basta inviare una presentazione generica una volta l'anno. La formazione deve riflettere sistema e ruolo: il servizio clienti deve riconoscere risposte inventate, gestire divulgazione ed escalation; l'ingegnere deve conoscere valutazione, sicurezza, documentazione e rilascio; il manager deve capire responsabilità e limiti dell'automazione.

Conservate una matrice con ruolo, sistema, obiettivo didattico, data, verifica, evento che richiede aggiornamento e prova. Includete collaboratori e interinali. Verificate competenze pratiche con scenari brevi: riconoscere un prompt injection, non incollare un cedolino in uno strumento non approvato, contestare una raccomandazione distorta o segnalare un'azione autonoma inattesa.

Trasparenza e articolo 50 nel lavoro quotidiano

Gli obblighi di trasparenza dipendono dall'uso e dal sistema. L'articolo 50 riguarda, tra l'altro, l'informazione alle persone che interagiscono con determinati sistemi IA, l'identificabilità di contenuti generati o manipolati e la comunicazione di specifici contenuti. Ambito, eccezioni, fattibilità tecnica e date vanno verificati sul testo vigente e sui materiali applicativi. Non riducete l'articolo 50 a un'unica etichetta su ogni output.

Per un assistente clienti, comunicate al momento dell'interazione che la persona sta parlando con un sistema IA, salvo che il contesto renda già evidente la situazione o si applichi un'eccezione. Per i contenuti generati stabilite quando servano metadati di provenienza, avviso visibile o registro interno. Audio, immagini e video sintetici devono passare da una revisione prima della pubblicazione, soprattutto se possono trarre in inganno.

La trasparenza è anche una scelta di design. Un disclaimer nascosto nei termini è spesso una cattiva esperienza e una prova debole di informazione significativa. Mostrate l'informazione nel punto in cui avviene la decisione o interazione, usate linguaggio chiaro e consentite il ricorso a una persona. Coordinate avvisi AI Act con GDPR, diritto dei consumatori, pubblicità, proprietà intellettuale e aspettative linguistiche italiane.

Classificate l'alto rischio per funzione e contesto

Le scorciatoie nella classificazione ad alto rischio producono errori costosi. L'AI Act considera componenti di sicurezza di prodotti soggetti a determinate norme dell'Unione e sistemi elencati nell'allegato III. Assunzione, gestione dei lavoratori, accesso a servizi essenziali, merito creditizio, forze dell'ordine, migrazione, giustizia e processi democratici possono essere ad alto rischio quando ricorrono le condizioni. Un modello generalista usato per redigere un'email non è automaticamente ad alto rischio perché è potente.

Usate un albero decisionale documentato: verificate se il sistema è vietato, componente di sicurezza, caso dell'allegato III, modello GPAI, uso soggetto a trasparenza o fuori ambito; poi testate esclusioni e deroghe. Registrate finalità prevista, uso reale, persone coinvolte, autonomia, impatto e legame con un prodotto regolamentato. Ripetete la classificazione dopo modifiche sostanziali, nuove fonti dati, utenti, geografie o azioni downstream.

Per un sistema ad alto rischio costruite il piano sui relativi obblighi, senza aspettare un certificato. Possono servire gestione del rischio, governance dei dati, documentazione tecnica, registri, trasparenza, supervisione umana, accuratezza, robustezza, cybersecurity, qualità, valutazione di conformità, registrazione, monitoraggio post-market e segnalazione incidenti. Il calendario rivisto dal Regolamento 2026/1744 rende essenziale il campo data.

Governance dei dati, logging e supervisione umana

La governance dei dati non consiste solo nel verificare la liceità della fonte. Documentate finalità, provenienza, rilevanza, rappresentatività, etichettatura, preprocessing, lacune, gruppi protetti, conservazione, accesso e test di qualità. Valutate lingua e geografia: un modello può funzionare bene in inglese e male con nomi italiani, dialetti, fatture, indirizzi o terminologia di settore.

Il logging deve consentire una ricostruzione significativa: data e ora, versione, riferimento all'input o fonte, output, confidenza, utente, azione, override, risultato della policy e incidente collegato, secondo necessità. Minimizzate i dati personali, limitate gli accessi, definite la conservazione ed evitate sovrascritture silenziose. Un log che dice solo «modello eseguito correttamente» raramente basta per indagare una decisione errata.

La supervisione umana deve essere reale. Nominate persona o team, definite cosa possono vedere e assicurate tempo e autorità per annullare la raccomandazione. Nei casi ad alto impatto prevedete stop automatici, doppia revisione, soglie di escalation e un percorso per ottenere spiegazione o correzione umana, quando applicabile.

Gli strumenti GPAI di terzi richiedono un confine aziendale

Gli strumenti di IA generalista non sono a basso rischio solo perché venduti come software di produttività. Un'azienda italiana che usa un chatbot GPAI di terzi è di norma deployer e può diventare provider se costruisce e commercializza un sistema sopra di esso, lo modifica sostanzialmente o mette in servizio un sistema con il proprio marchio. Il provider upstream ha i propri obblighi, ma il cliente controlla prompt, dati, accessi, casi d'uso e decisioni downstream.

Definite un catalogo di strumenti approvati con classi dati consentite, attività vietate, conservazione, titolarità degli account, identità, diritti amministrativi, uso dei dati per l'addestramento e regole di esportazione. Distinguete chat pubblica, workspace enterprise, API e condizioni del prodotto integrato. La dichiarazione di un dipendente sul mancato addestramento sui dati non sostituisce la verifica di contratto e configurazione.

• Chiedete al fornitore ruolo IA, famiglia e versioni del modello, finalità, limiti noti e percorso di conformità.
• Richiedete istruzioni e dati tecnici per un deployment sicuro: logging, sicurezza, residenza, conservazione, sub-responsabili e contatti incidenti.
• Definite uso degli input per l'addestramento, cancellazione e rettifica e gestione dei cambiamenti di modello.
• Riservate diritti di audit e accesso alle prove proporzionati al rischio, inclusa la cooperazione con autorità e indagini.
• Stabilite finestre di notifica per disservizi, vulnerabilità, output non autorizzati, esposizione dati, modifiche sostanziali e perdita dello status di conformità.
• Vietate usi estranei delle informazioni riservate e chiedete restituzione o cancellazione all'uscita, quando possibile.

Uso dei dipendenti e uso dei clienti sono flussi diversi

Per i dipendenti pubblicate uno standard breve di uso accettabile sostenuto da controlli tecnici: strumenti approvati, dati vietati, verifica, proprietà intellettuale, disclosure, prompt injection e segnalazioni. Offrite uno spazio sicuro per sperimentare, così gli usi utili non finiscono in account personali. Prima di monitorare persone, coordinatevi con privacy, rappresentanze e requisiti del lavoro.

Per i clienti progettate un percorso che spieghi il ruolo dell'IA, conservi l'escalation umana, impedisca di delegare con leggerezza decisioni sensibili e registri consenso o avviso quando richiesto. L'automazione rivolta al cliente deve avere fallback, rifiuti, copertura linguistica, accessibilità, limiti e correzione dei casi errati.

La gestione degli incidenti inizia prima dell'incidente

Un incidente IA può essere una raccomandazione errata, un pattern discriminatorio, una violazione privacy, un attacco, un'azione autonoma non sicura, media sintetici fuorvianti, perdita di tracciabilità o mancata supervisione. Definite livelli di gravità e un canale unico. Il modulo deve registrare sistema, versione, persone coinvolte, data, riferimenti a input e output, azione, danno, contenimento e segnalante.

Il playbook deve coprire contenimento, sospensione accessi, revisione dei casi, comunicazioni, escalation al fornitore, valutazione legale, notifica alle autorità, causa principale, rimedio e riavvio controllato. Esercitatevi con scenari di chatbot che divulga dati, modello di recruiting con esiti diversi e sistema di fabbrica che suggerisce manutenzione non sicura. Un incontro post-incidente senza modifica dei controlli non è remediation.

Considerazioni settoriali per l'Italia

L'AI Act non sostituisce la regolamentazione settoriale. Finanza deve collegare classificazione IA a banche, pagamenti, assicurazioni, outsourcing, governance, consumatori e requisiti prudenziali. I produttori devono integrare sicurezza prodotto, macchinari, dispositivi medici, cybersecurity industriale e conformità. La sanità deve combinare AI Act con norme su dispositivi, clinica, privacy, professioni e sicurezza del paziente.

Retail e consumer devono rivedere profilazione, prezzi, pubblicità, assistenza e contenuti sintetici. Logistica e utility devono esaminare sicurezza, accesso, infrastrutture e gestione del personale. I fornitori della PA devono comprendere procurement e ruolo dell'ente. Per il contesto italiano consultate i materiali AgID sull'intelligenza artificiale, ricordando che le linee guida AgID non sostituiscono regolamento e legge settoriale.

Un piano realistico a 30, 60 e 90 giorni

Nei primi 30 giorni create visibilità e fermate i rischi evitabili: sponsor esecutivo, responsabile compliance, owner dei sistemi, regola temporanea per dati sensibili e decisioni ad alto impatto, inventario da business, IT, sicurezza, HR, procurement, prodotto e fornitori. Verificate divieti, alto rischio, GPAI, trasparenza e settori regolati; assegnate una data alle incognite.

Tra il giorno 31 e il 60 trasformate i risultati in controlli: metodo di ruoli e classificazione, standard per dipendenti, formazione, questionari procurement, contratti prioritari, accessi, conservazione, logging, avvisi, revisione umana e intake incidenti. Avviate cartelle delle prove e registro transizioni con il Regolamento 2026/1744. Chiedete parere legale sui casi ambigui.

Tra il giorno 61 e il 90 testate e governate: valutazioni dei sistemi prioritari, bias e performance, esercitazione incidente, campionamento log e override, gate per nuovi modelli, prompt, dati, integrazioni e casi d'uso. Riportate rischi aperti, prove fornitore, formazione, incidenti, qualità delle revisioni e prossime date. Poi impostate una revisione trimestrale.

Checklist delle prove per audit o consiglio di amministrazione

• Inventario IA con owner, ruoli, finalità, versioni, dati, fornitori, utenti, persone interessate e classificazioni.
• Registro di leggi e indicazioni con fonte, natura vincolante, date e responsabile dell'interpretazione.
• Screening dei divieti e valutazione alto rischio con motivazioni e approvazione.
• Programma di alfabetizzazione, presenze, verifiche e aggiornamenti per ruolo.
• Schede dati, provenienza, test qualità, valutazioni, limiti e performance italiana per lingua e gruppi.
• Documentazione tecnica, configurazioni, revisioni accessi, log, conservazione e storia delle modifiche.
• Istruzioni di supervisione, override, escalation e prove di revisione possibile ed efficace.
• Due diligence e clausole fornitore, informazioni modello, subfornitori, sicurezza, incidenti e piano di uscita.
• Avvisi di trasparenza, etichette, script, accessibilità e registri della loro collocazione.
• Registro incidenti, indagini, azioni correttive, comunicazioni e test successivi.

KPI che dimostrano controllo, non burocrazia

Misurate insieme copertura ed efficacia: usi inventariati, owner nominati, classificazioni completate, strumenti approvati, formazione, prove dei fornitori e rollback testati. Aggiungete revisione umana, override per caso, errori per gruppo e lingua, incidenti, tempi di contenimento e percentuale di modifiche valutate prima del rilascio. Ogni metrica deve avere campione qualitativo, soglia, owner e azione.

Errori comuni da evitare

• Trattare la dichiarazione di conformità del fornitore come classificazione, valutazione del rischio o decisione di deployment.
• Supporre che tutta l'IA generativa sia vietata oppure che uno strumento di produttività sia fuori dall'AI Act.
• Scrivere una policy ampia senza configurare accessi, dati, avvisi, logging, revisione e risposta agli incidenti.
• Ignorare lo shadow AI invece di rendere utilizzabile il percorso approvato.
• Chiamare human-in-the-loop chi può solo cliccare «approva» senza comprendere o contestare.
• Usare una tabella date precedente alla modifica 2026 senza verificare le transizioni.
• Presentare guida, standard volontario o decreto italiano pendente come legge vincolante.
• Conservare log per sempre o copiare prompt sensibili nei ticket.
• Lanciare un'esperienza italiana dopo aver testato solo l'inglese.
• Comprare una piattaforma di compliance che crea un secondo inventario isolato.

Sviluppare o acquistare

Acquistate controlli maturi come identità, accessi, discovery, formazione, ticketing, prove, monitoraggio e questionari fornitori. Costruite o configurate ciò che dipende dal vostro giudizio: ruoli, tassonomia, propensione al rischio, gate dei divieti, supervisione, valutazione della lingua italiana, escalation e reporting. Una piattaforma organizza le prove, ma non decide se il recruiting incide sulle persone o se l'operatore può davvero annullare una raccomandazione.

Per una piccola o media impresa bastano inizialmente registro controllato, catalogo approvato, addendum contrattuale, matrice di formazione e workflow incidenti. Per una grande azienda integrate gli stessi controlli con GRC, privacy, sicurezza, qualità, ciclo prodotto e gestione fornitori. L'architettura giusta lascia una traccia responsabile senza aggiungere un foglio di calcolo per ogni nuovo strumento.

Come possiamo aiutarti?

Magna Products aiuta le aziende italiane a trasformare esperimenti IA isolati in attività utili e controllate. Possiamo mappare l'inventario, classificare casi d'uso e ruoli, progettare flussi approvati per strumenti GPAI di terzi, collegare revisione umana e prove ai sistemi già utilizzati e creare dashboard pratiche per responsabili e leadership. Parla con Magna Products per organizzare un workshop di discovery e uscire con un backlog di conformità prioritario a 30, 60 e 90 giorni.