AI Act: governance interna oltre la formazione

L’AI Act non si esaurisce con un corso al personale. Per essere in regola, un’impresa deve costruire un sistema documentato che colleghi formazione, policy operative e presidio delle responsabilità. Chi tratta questi tre elementi come adempimenti separati rischia di restare esposto.

In sintesi

  • L’articolo 4 del Regolamento UE 2024/1689 (AI Act) impone un obbligo di alfabetizzazione AI a carico di fornitori e deployer (imprese che usano sistemi AI nei propri processi).
  • La formazione da sola non basta: il Regolamento richiede governance documentata, ruoli definiti e procedure di controllo interno integrate.
  • Le sanzioni per i deployer che non rispettano gli obblighi arrivano fino a 15 milioni di euro o al 3% del fatturato annuo globale (Art. 99 Reg. UE 2024/1689).
  • Il sistema di governance AI deve essere coerente con i controlli già esistenti in azienda — privacy, sicurezza, compliance — non costruito in parallelo.
  • La decisione finale su come usare un sistema AI resta sempre in capo a una persona: l’AI non è un decisore autonomo né un soggetto responsabile.

Formazione AI: obbligo reale, perimetro spesso frainteso

L’articolo 4 del Regolamento UE 2024/1689, entrato in vigore il 2 agosto 2024 con applicazione progressiva, stabilisce che fornitori e deployer (chiunque utilizzi un sistema AI in un contesto professionale o commerciale) devono adoperarsi perché il proprio personale sia alfabetizzato in materia di intelligenza artificiale. Il testo oggi vigente, riscritto dal Digital Omnibus, non impone un livello specifico per nessuna persona: dove fermarsi lo decide chi guida l’organizzazione. Uno studio legale che usa uno strumento di analisi documentale è un deployer. Lo è anche una clinica che adotta software di supporto alla diagnosi, o un hotel che impiega un sistema di gestione dinamica dei prezzi.

Molte imprese interpretano l’obbligo come “fare un corso”. Non funziona così. L’alfabetizzazione AI, nel senso del Regolamento, riguarda la capacità di comprendere come funziona il sistema usato, quali sono i suoi limiti, e come intervenire quando produce risultati inattesi. Non è un attestato da archiviare.

Un esempio concreto. Uno studio di commercialisti che usa un software AI per la riconciliazione contabile, cioè il confronto automatico tra movimenti bancari e registrazioni contabili, deve poter dimostrare che chi usa quello strumento sa riconoscere un’anomalia nell’output, sa quando non fidarsi del risultato e sa a chi segnalarlo internamente. Se questo non è documentato, davanti a un controllo la formazione non si può dimostrare, ed è come non averla fatta.

L’obbligo di alfabetizzazione AI dell’articolo 4 è applicabile dal 2 febbraio 2025. Non è una scadenza futura. Per capire esattamente cosa prevede e come documentarlo, la guida all’articolo 4 dell’AI Act offre un riferimento operativo aggiornato.

Governance AI: cosa deve esistere oltre la formazione

La formazione è il punto di ingresso. Non il punto di arrivo.

L’AI Act, in particolare per i sistemi ad alto rischio elencati nell’Allegato III del Regolamento, richiede ai deployer una struttura di controllo interno con almeno tre elementi distinti. Nessuno dei tre è particolarmente complesso da costruire. Tutti e tre devono esistere per iscritto.

Primo: assegnazione dei ruoli. Chi in azienda valuta se un sistema AI è adeguato all’uso previsto? Chi autorizza l’adozione di un nuovo strumento? Chi gestisce le segnalazioni di malfunzionamento? In un ecommerce da 20 dipendenti che usa un sistema di raccomandazione prodotti, queste domande non possono avere risposta “ce ne occupiamo tutti”: devono avere un nome e un cognome scritti da qualche parte.

Secondo: documentazione d’uso. Per i sistemi ad alto rischio, il deployer deve conservare i log, cioè i registri automatici delle operazioni, per almeno sei mesi (Art. 26, par. 5, Reg. UE 2024/1689). Ma anche per i sistemi a rischio limitato, avere una traccia di come vengono usati i sistemi AI è una protezione concreta in caso di contestazione.

Terzo: procedura di escalation, cioè il percorso definito che un dipendente deve seguire quando rileva un problema nell’output di un sistema AI. Un’agenzia immobiliare che usa uno strumento AI per stimare i valori degli immobili deve stabilire in anticipo cosa fa l’agente che si accorge di stime sistematicamente distorte per una certa area geografica: segnala a chi, con quale formato, entro quanto tempo. Senza questa procedura scritta, ogni dipendente si comporterà diversamente, e nessuno dei comportamenti sarà difendibile in sede di ispezione.

Questi tre elementi non richiedono strutture complesse. Per molte realtà operative bastano poche pagine di policy interna, un registro aggiornato e una procedura di segnalazione chiara. Il punto è che devono esistere e devono essere coerenti tra loro.

Responsabilità operative: chi risponde e di cosa

L’AI Act distingue con precisione il fornitore, chi sviluppa o mette sul mercato un sistema AI, dal deployer, chi lo usa in contesto professionale. Questa distinzione determina chi è soggetto a quali obblighi e, in caso di danno, chi risponde.

Un ristorante che adotta un sistema AI per la gestione degli ordini è un deployer. Se quel sistema produce un errore che causa un danno al cliente, la responsabilità operativa del titolare dipende da come ha configurato il sistema, se ha formato il personale, se ha mantenuto la supervisione umana sulle decisioni critiche. Il fornitore del software risponde di eventuali difetti del sistema. Il deployer risponde di come lo ha integrato e gestito.

Resta il fatto che né il titolare né il direttore operativo possono delegare interamente la responsabilità AI al fornitore tecnologico, né al responsabile IT. La governance AI tocca processi decisionali che riguardano clienti, dipendenti e terzi: è una responsabilità di chi guida l’organizzazione.

Le sanzioni per i deployer che violano gli obblighi dell’articolo 26 del Regolamento arrivano fino a 15 milioni di euro o al 3% del fatturato annuo globale (Art. 99 Reg. UE 2024/1689). Per una realtà operativa di medie dimensioni, anche la soglia percentuale può rappresentare un importo rilevante.

Integrare la governance AI nei controlli già esistenti

Costruire la compliance AI come sistema separato dagli altri controlli interni è un errore frequente. Genera duplicazioni, incongruenze e documenti che nessuno aggiorna. Non è quello che chiede il Regolamento, ed è un costo organizzativo evitabile.

La governance AI si integra con tre aree già presidiate in molte imprese.

La prima è la privacy. Il GDPR, Regolamento UE 2016/679 relativo alla protezione dei dati personali, impone già regole su come i dati vengono trattati nei processi automatizzati. Un sistema AI che elabora dati personali va valutato sia sotto il profilo GDPR sia sotto il profilo AI Act, con una documentazione che tenga insieme i due livelli. Una clinica che usa un software AI per la gestione delle cartelle cliniche ha già un data protection officer (responsabile della protezione dei dati): è quella la figura che coordina anche la valutazione AI, non una nuova.

La seconda è la sicurezza informatica. I sistemi AI sono superfici di attacco, cioè punti attraverso cui un sistema può essere compromesso o manipolato. Chi ha già una policy di sicurezza deve estenderla ai nuovi strumenti AI adottati, verificando in particolare come vengono gestiti gli accessi e come vengono conservati i dati di input e output.

La terza è la gestione del rischio operativo. Molte imprese strutturate hanno già un registro dei rischi. I rischi legati all’uso di sistemi AI, come errori sistematici nell’output, bias algoritmico (distorsioni nei risultati prodotte da dati di addestramento non rappresentativi della realtà), o interruzioni del servizio, vanno aggiunti a quel registro con le relative misure di mitigazione.

Un hotel con 50 dipendenti che usa tre strumenti AI diversi, per la gestione prezzi, la risposta automatica alle recensioni e la selezione dei fornitori, non ha bisogno di un ufficio compliance dedicato. Ha bisogno di una persona che coordini questi tre livelli e di documenti che dimostrino che il coordinamento esiste. La differenza tra essere esposti e non esserlo, in sede di ispezione, passa spesso da un foglio scritto.

Domande correlate

Cosa rischia un’impresa che ha fatto solo formazione senza governance?

Un’impresa che ha erogato formazione ma non ha definito ruoli, procedure e documentazione d’uso non soddisfa gli obblighi del Regolamento UE 2024/1689 per i sistemi ad alto rischio. In caso di ispezione o contestazione, l’assenza di governance documentata è considerata inadempimento autonomo, indipendente dalla formazione svolta.

Chi è il deployer secondo l’AI Act?

Il deployer è qualsiasi soggetto, privato o professionale, che usa un sistema AI sviluppato da altri nell’ambito della propria attività. Uno studio medico che usa un software di supporto diagnostico, un’agenzia immobiliare che usa uno strumento di valutazione automatica, un ecommerce che usa un sistema di raccomandazione prodotti: tutti sono deployer ai sensi dell’articolo 3 del Regolamento.

I log dei sistemi AI vanno conservati obbligatoriamente?

Per i sistemi ad alto rischio elencati nell’Allegato III del Regolamento UE 2024/1689, l’articolo 26, paragrafo 5 impone al deployer di conservare i log generati automaticamente per almeno sei mesi, salvo obblighi più stringenti previsti da altre normative applicabili.

La responsabilità AI può essere trasferita al fornitore del software?

No, non interamente. Il fornitore risponde dei difetti del sistema; il deployer risponde di come lo ha integrato, configurato e supervisionato. Contratti che trasferiscono ogni responsabilità al fornitore non eliminano la posizione di garanzia del deployer prevista dal Regolamento.

Quando entra in vigore l’obbligo di governance per i deployer?

L’AI Act è in vigore dal 2 agosto 2024. Gli obblighi per i sistemi ad alto rischio diventano pienamente applicabili il 2 agosto 2026. L’obbligo di alfabetizzazione AI dell’articolo 4 è applicabile dal 2 febbraio 2025.


Non costituisce parere legale.

Fonti: