AI Act e Decreto 231/2001: integrare la compliance in un sistema unico

L'introduzione del Regolamento (UE) 2024/1689 — l'AI Act — non sostituisce il quadro italiano di responsabilità degli enti delineato dal Decreto Legislativo 8 giugno 2001, n. 231. Lo amplia, lo intercetta e, in alcune fattispecie, lo rende strutturalmente più rigoroso. Per le organizzazioni che già operano con un Modello di Organizzazione, Gestione e Controllo (MOG) ai sensi del 231, la domanda non è se integrare i due perimetri, ma come farlo senza generare duplicazioni documentali, sovrapposizioni di ruoli o, peggio, zone grigie nelle quali un sistema di intelligenza artificiale possa essere utilizzato per realizzare un reato-presupposto senza che il Modello lo abbia previsto.

Questo articolo affronta il tema dal punto di vista di un'azienda italiana mid-market: 200 dipendenti, MOG-231 adottato e periodicamente aggiornato, Organismo di Vigilanza (OdV) operativo, certificazione ISO/IEC 27001 in essere, percorso di certificazione ISO/IEC 42001 avviato. È il profilo tipico di una PMI manifatturiera, di servizi B2B o di società di consulenza che si trova oggi a dover dimostrare conformità su tre fronti contemporaneamente — AI Act, 231 e ISO 42001 — senza moltiplicare le funzioni di controllo. L'obiettivo è ricondurre questi tre fronti a un unico sistema di gestione del rischio.

Il Decreto 231/2001 in sintesi: cosa stabilisce e perché entra nel perimetro AI

Il Decreto Legislativo 231/2001 ha introdotto nell'ordinamento italiano la responsabilità amministrativa degli enti — società, associazioni, fondazioni — per reati commessi nel loro interesse o vantaggio da soggetti apicali o sottoposti. Si tratta di una responsabilità autonoma rispetto a quella penale della persona fisica: l'ente risponde con sanzioni pecuniarie, interdittive (sospensione di attività, divieto di contrattare con la PA, esclusione da agevolazioni), confisca e pubblicazione della sentenza.

L'ente può andare esente da responsabilità se dimostra di aver adottato ed efficacemente attuato, prima della commissione del fatto, un Modello di Organizzazione, Gestione e Controllo idoneo a prevenire reati della specie di quello verificatosi, e di aver affidato a un Organismo di Vigilanza dotato di autonomi poteri il compito di vigilare sul funzionamento del Modello. Il catalogo dei reati-presupposto si è progressivamente ampliato dal 2001: oggi comprende, fra gli altri, reati contro la pubblica amministrazione, reati societari, reati informatici e di trattamento illecito di dati, reati di ricettazione, riciclaggio e autoriciclaggio, abuso di informazioni privilegiate e manipolazione del mercato, reati tributari, reati ambientali, reati in materia di salute e sicurezza sul lavoro, reati di criminalità organizzata transnazionale.

Il punto di contatto con l'intelligenza artificiale è strutturale, non eventuale. Un sistema di AI che prende decisioni, suggerisce decisioni a un operatore umano, automatizza comunicazioni o elabora dati è uno strumento attraverso il quale un reato-presupposto può essere commesso. Non importa che la condotta tecnica sia generata da un modello statistico: se l'esito è una frode informatica, un riciclaggio, un abuso informativo o una comunicazione ingannevole alla pubblica amministrazione, la responsabilità ricade comunque sull'ente, salvo prova dell'idoneità del Modello.

Reati-presupposto rilevanti per l'AI: una mappatura ragionata

Non tutti i reati del catalogo 231 hanno la stessa esposizione rispetto ai sistemi di intelligenza artificiale. Una mappatura ragionata aiuta a concentrare lo sforzo di aggiornamento del MOG sulle aree dove il rischio è effettivo.

Frode informatica e accesso abusivo a sistemi informatici (artt. 24-bis e 25-octies.1). L'AI generativa abbassa drasticamente il costo di produzione di contenuti credibili — voci sintetiche, video deepfake, e-mail di spear phishing personalizzate. Un'azienda che impiega questi sistemi per qualsiasi finalità deve presidiare il rischio che gli stessi modelli, o derivazioni di essi, vengano utilizzati internamente o da terzi per condotte fraudolente. La superficie di attacco non è più "il sistema informatico altrui" ma "il modello aziendale impiegato come vettore".

Reati di riciclaggio, autoriciclaggio e impiego di denaro di provenienza illecita (art. 25-octies). I sistemi AI applicati ad antiriciclaggio (transaction monitoring, screening clienti, analisi comportamentale) sono al tempo stesso strumento di prevenzione e fonte di rischio: un modello mal calibrato che genera falsi negativi sistematici espone l'ente a una contestazione di omessa segnalazione. Un modello mal addestrato che discrimina su base geografica o etnica espone a un duplice rischio — sanzionatorio sotto l'AI Act e reputazionale sotto il 231.

Abuso di informazioni privilegiate e manipolazione del mercato (art. 25-sexies). Per le società quotate o per gli intermediari finanziari, l'uso di sistemi AI nell'analisi predittiva, nel trading algoritmico o nella generazione di research va presidiato con presidi specifici. Un modello che apprende da flussi non autorizzati di informazioni privilegiate, o che genera segnali correlati a dati non pubblici, costituisce un'esposizione 231 oggettiva.

Reati societari (art. 25-ter). Le false comunicazioni sociali e le altre fattispecie societarie possono essere agevolate da sistemi AI che producono reportistica, analisi gestionali o documenti destinati a soci e creditori. Se l'AI genera contenuti che entrano nel perimetro di una comunicazione societaria, il Modello deve disciplinare la verifica umana sostanziale prima della firma.

Reati contro la pubblica amministrazione (artt. 24 e 25). L'uso di AI nella partecipazione a gare pubbliche, nella compilazione di documentazione amministrativa, nei rapporti con autorità di vigilanza è oggi diffusissimo. Un sistema che genera attestazioni, autocertificazioni o offerte tecniche destinate alla PA introduce nel processo un attore non umano la cui affidabilità va presidiata, perché l'eventuale falsità — anche colposa nella catena di controllo — ricade sull'ente. Il tema è strettamente legato a quanto descritto nella nostra analisi su Consip, MePA e SDAPA: come l'AI cambia la compilazione delle gare pubbliche.

Reati di trattamento illecito di dati (art. 25-undecies e correlati). L'AI Act non assorbe il GDPR. Un sistema AI che tratta dati personali in violazione dei principi di liceità, minimizzazione, esattezza e limitazione delle finalità espone l'ente sia alla sanzione del Garante sia al rischio 231 ove la condotta integri uno dei reati informatici previsti.

Come l'AI Act amplia il rischio 231

Il Regolamento (UE) 2024/1689 introduce obblighi che modificano in profondità il modo in cui un'azienda deve costruire i propri presidi sui sistemi di intelligenza artificiale. Tre aree, in particolare, riverberano direttamente sul perimetro 231.

Classificazione dei sistemi e obblighi differenziati. L'AI Act distingue sistemi a rischio inaccettabile (vietati), ad alto rischio (con obblighi pieni di gestione del rischio, governance dei dati, documentazione tecnica, trasparenza, sorveglianza umana, accuratezza e robustezza), a rischio limitato (obblighi di trasparenza), a rischio minimo. La classificazione non è negoziabile: è una qualificazione giuridica del sistema in base alla finalità e al contesto d'uso. Un MOG aggiornato deve disciplinare il processo interno con cui si stabilisce — e si rivede — la classificazione di ogni sistema AI in uso. Una classificazione errata, anche in buona fede, è un fatto che l'OdV deve poter rilevare. Per un inquadramento puntuale del Regolamento e delle sue scadenze rinviamo alla guida completa all'AI Act per le aziende italiane e all'analisi delle scadenze 2026-2027.

Documentazione tecnica e tracciabilità. L'AI Act richiede, per i sistemi ad alto rischio, una documentazione tecnica strutturata (Allegato IV), un sistema di registrazione automatica degli eventi (logging) e una catena di tracciabilità che consenta la ricostruzione ex post delle decisioni. Questa infrastruttura documentale è esattamente ciò di cui l'OdV ha bisogno per esercitare la propria vigilanza: senza log, senza dataset documentati, senza versioning del modello, l'OdV non può accertare se un evento sia il risultato di un comportamento conforme o di una deviazione rispetto al Modello. L'AI Act, in altre parole, consegna al 231 strumenti probatori che prima erano lasciati alla discrezione tecnica del fornitore.

Sorveglianza umana significativa. Il Regolamento impone, per i sistemi ad alto rischio, una sorveglianza umana che sia effettiva, non meramente formale. Il presidio "umano nel loop" non è soddisfatto da una firma a valle: richiede che l'operatore comprenda i limiti del sistema, possa intervenire, possa decidere di non usare l'output. Per il MOG-231 questa è una linea guida operativa preziosa: ogni processo nel quale un sistema AI partecipa alla formazione di un atto rilevante per il 231 deve definire chi è il sorvegliante umano, quali competenze possiede, come è documentato il suo intervento.

MOG-231 AI-aware: cosa cambia nella struttura del Modello

Un MOG idoneo a presidiare il rischio AI non è un nuovo Modello: è un Modello la cui parte speciale è stata aggiornata su tre direttrici.

Mappatura delle attività sensibili integrata con il registro dei sistemi AI. Il MOG già contiene una mappatura delle attività a rischio rispetto a ciascun reato-presupposto. La novità è collegare questa mappatura al registro dei sistemi AI in uso (richiesto dall'AI Act per i sistemi ad alto rischio, raccomandato per tutti gli altri). Per ogni attività sensibile va indicato se uno o più sistemi AI vi partecipano, con quale ruolo, su quale fonte dati, con quale livello di sorveglianza umana. Il registro AI diventa così un'appendice tecnica della parte speciale.

Protocolli di formazione delle decisioni. I protocolli che il 231 chiede di adottare (separazione delle funzioni, doppia firma, autorizzazioni gerarchiche, segregazione delle informazioni sensibili) vanno riletti alla luce della partecipazione di sistemi AI al processo. Un protocollo che prescrive la "validazione del responsabile" è insufficiente se la validazione si limita alla firma di un output generato da un modello: il protocollo deve specificare che cosa il responsabile deve verificare, su quali metriche, con quale evidenza documentale del controllo effettuato. Su questo punto consigliamo l'approfondimento sulla checklist di conformità AI per le aziende italiane nel 2026.

Flussi informativi verso l'OdV. L'OdV deve ricevere flussi informativi periodici sui sistemi AI: incidenti rilevati, deviazioni di performance, segnalazioni di errori, richieste di explainability ricevute dagli interessati, esiti delle revisioni di rischio. Questi flussi sono in larga parte già richiesti dall'AI Act per i sistemi ad alto rischio (post-market monitoring, segnalazione di incidenti gravi alle autorità competenti); il MOG si limita a stabilire la frequenza, il formato e il destinatario interno.

Procedure disciplinari e codice etico. Il codice etico aziendale e l'apparato sanzionatorio interno vanno aggiornati con condotte specifiche relative all'uso dell'AI: divieto di by-pass dei sistemi di sorveglianza, divieto di utilizzo di sistemi non autorizzati ("shadow AI"), obbligo di segnalazione di anomalie o di output palesemente errati, divieto di alimentazione del modello con dati raccolti in violazione delle policy interne. Senza queste previsioni, una condotta colposa o dolosa di un dipendente che usi l'AI in modo improprio non è disciplinarmente sanzionabile, e il Modello diventa contestabile sotto il profilo dell'efficacia.

OdV e competenze AI: come evolve l'Organismo di Vigilanza

L'Organismo di Vigilanza è il presidio chiave di idoneità del Modello. La sua composizione classica — membro legale, membro contabile, membro interno con competenze di compliance — non è più sufficiente quando l'ente impiega sistemi AI ad alto rischio.

L'integrazione può avvenire per via diretta (un membro dell'OdV con competenze tecniche AI) o indiretta (un comitato tecnico permanente di supporto all'OdV, con competenze di data science, sicurezza informatica, etica algoritmica, che riferisce all'Organismo). La seconda strada è in genere preferibile per aziende mid-market, perché mantiene la composizione tradizionale dell'OdV e affianca un presidio tecnico stabile senza alterarne la natura collegiale.

In entrambi i casi, l'OdV deve essere messo in grado di:

• accedere ai log dei sistemi AI ad alto rischio;
• chiedere e ottenere la documentazione tecnica (data sheets, model cards, risk assessment);
• ricevere notifica entro tempi prefissati di ogni incidente rilevante (drift di performance, output anomali, contestazioni esterne, segnalazioni del Garante o di altre autorità);
• effettuare audit indipendenti, anche con il supporto di un revisore esterno specializzato;
• proporre al Consiglio di Amministrazione modifiche al Modello quando l'evoluzione tecnologica o normativa lo renda necessario.

L'OdV non è chiamato a fare data science: è chiamato a sapere quali domande porre, a chi rivolgerle, e a valutare se le risposte sono coerenti con il Modello. Questa è la differenza fra un OdV passivo che ratifica e un OdV efficace che vigila.

Caso pratico: PMI manifatturiera 200 dipendenti — integrazione MOG-231 + AI Act + ISO 42001

Per concretizzare, descriviamo il percorso tipo di una PMI italiana mid-market — 200 dipendenti, fatturato fra 40 e 80 milioni di euro, mercati B2B europei, MOG-231 in essere dal 2014 e ultimo aggiornamento 2022, ISO/IEC 27001 certificata, percorso ISO/IEC 42001 avviato a inizio 2026. L'azienda ha introdotto negli ultimi diciotto mesi un sistema AI per qualificazione lead commerciali, un sistema AI per analisi predittiva di manutenzione su linee produttive, un sistema AI per supporto alla compilazione di offerte tecniche destinate sia a clienti privati sia a stazioni appaltanti pubbliche.

Fase 1 — Inventario unico dei sistemi. Il primo passo è la costruzione di un registro unico dei sistemi AI in uso, alimentato congiuntamente da CIO, DPO e responsabile compliance. Il registro contiene, per ogni sistema: finalità, fornitore, dati trattati, processi aziendali coinvolti, classificazione AI Act (alto/limitato/minimo rischio), classificazione 231 (quali reati-presupposto possono essere realizzati attraverso il sistema), classificazione GDPR (DPIA effettuata o motivata esclusione). Il registro è uno solo: è un punto cieco se ogni funzione ne tiene una copia parziale.

Fase 2 — Risk assessment integrato. Il rischio AI Act, il rischio 231 e il rischio ISO 42001 vengono valutati nello stesso esercizio annuale. La metodologia 42001 (Annex A) offre la struttura, l'AI Act fornisce gli obblighi minimi non negoziabili, il 231 contribuisce con la lista dei reati-presupposto da presidiare. Per il sistema di compilazione offerte verso PA, l'esercizio fa emergere un'esposizione contemporanea su reati contro la PA (231), su requisiti di trasparenza (AI Act, sistema a rischio limitato per interazione con utente professionale), e su sorveglianza umana significativa nella firma dell'offerta. La risposta non è triplice: è un singolo controllo — verifica documentata del responsabile commerciale prima dell'invio, con check-list specifica e log conservato.

Fase 3 — Aggiornamento del MOG. Il consulente legale aggiorna la parte speciale del Modello introducendo un capitolo "Sistemi di intelligenza artificiale" che richiama il registro AI, definisce i protocolli di sorveglianza umana per ciascun sistema ad alto rischio o a rischio rilevante 231, integra il codice etico con le condotte specifiche menzionate sopra, prevede flussi informativi trimestrali verso l'OdV. La revisione è approvata dal Consiglio di Amministrazione e pubblicata internamente.

Fase 4 — Estensione dell'OdV. L'azienda istituisce un Comitato AI di supporto all'OdV, composto da CIO, DPO, responsabile sicurezza informatica e un consulente esterno di etica algoritmica. Il Comitato si riunisce quattro volte l'anno e, su richiesta, in via straordinaria. L'OdV mantiene la propria composizione collegiale ma acquisisce un canale tecnico stabile.

Fase 5 — Documentazione unificata. La documentazione tecnica richiesta dall'AI Act per i sistemi ad alto rischio (Allegato IV), le evidenze di controllo richieste dalla ISO 42001, gli atti di vigilanza dell'OdV vivono in un unico repository documentale, con tassonomia comune. Una stessa evidenza — ad esempio il log di un intervento umano correttivo su un output del modello manutentivo — soddisfa tre requirement diversi senza essere duplicata.

Fase 6 — Formazione integrata. La formazione 231 obbligatoria, la formazione GDPR e la formazione sull'uso responsabile dell'AI vengono erogate in modo coordinato, con un modulo unico per il personale operativo e moduli specialistici per i ruoli con responsabilità AI (data owner, model owner, sorveglianti umani designati). La formazione è tracciata e ripetuta annualmente.

Esito a dodici mesi. L'azienda ha un MOG-231 idoneo a coprire il perimetro AI, una ISO/IEC 42001 in fase finale di certificazione, una conformità AI Act documentata sui due sistemi classificati a rischio non minimo, e — soprattutto — un'unica governance del rischio. Il costo complessivo dell'integrazione, distribuito su consulenza legale, consulenza tecnica AI, formazione e adeguamento documentale, è risultato significativamente inferiore alla somma dei tre percorsi separati che l'azienda aveva inizialmente preventivato.

Quattro errori ricorrenti da evitare

Nei progetti di integrazione che osserviamo si ripresentano alcuni errori sistematici.

Il primo è considerare l'AI Act come tema "tecnico" del CIO e il 231 come tema "legale" del Consiglio di Amministrazione, mantenendoli su binari paralleli. È la garanzia di duplicare lo sforzo e generare incoerenze.

Il secondo è aggiornare il MOG con una formula generica del tipo "i sistemi di intelligenza artificiale sono utilizzati nel rispetto della normativa vigente". Una clausola di stile non è un protocollo, e l'OdV non ha appigli per vigilare su una formula vuota.

Il terzo è affidare la classificazione AI Act al solo fornitore del sistema. La qualificazione giuridica del rischio è responsabilità dell'utilizzatore (deployer) nei contesti in cui la normativa la attribuisce a quest'ultimo: delegarla al vendor produce documenti inutilizzabili in fase di accertamento.

Il quarto è separare il registro dei trattamenti GDPR, il registro dei sistemi AI, l'inventario asset ISO 27001 e la mappatura delle attività sensibili 231. La vista è una sola: l'azienda. Mantenerli separati è l'equivalente operativo di non avere un sistema di gestione del rischio. Per come integrare i diversi standard di gestione AI rinviamo alla guida all'implementazione della ISO/IEC 42001 in Italia e al confronto con la sicurezza informatica nel pezzo dedicato a ISO 42001 e ISO 27001.

L'integrazione come vantaggio competitivo

L'integrazione fra AI Act, 231 e standard ISO non è solo una questione di efficienza compliance. È, in una fase di mercato in cui clienti pubblici e privati stanno introducendo nei propri capitolati requisiti di accountability AI, un fattore competitivo concreto. Un'azienda che presenta un MOG-231 AI-aware, una governance documentata e un OdV con presidio tecnico AI ha argomenti immediati per vincere clausole contrattuali, abilitare gare pubbliche e difendere posizioni in audit di clienti enterprise. La compliance smette di essere un costo difensivo e diventa una credenziale di affidabilità.

Per le PMI italiane mid-market, oggi, il messaggio è chiaro: l'aggiornamento del Modello 231 in chiave AI non è un esercizio facoltativo. È il modo per far sì che gli investimenti in intelligenza artificiale producano valore senza generare un'esposizione di responsabilità che, in caso di incidente, può tradursi in sanzioni pecuniarie pesanti, misure interdittive paralizzanti e un danno reputazionale di lunga durata.

La prospettiva del 2026 e del 2027, con l'entrata in vigore progressiva degli obblighi sui sistemi ad alto rischio, non concede margini di rinvio. Iniziare l'integrazione ora, con un perimetro ancora ridotto di sistemi AI in produzione, è significativamente più semplice che farlo a portafoglio AI maturo. Per orientarsi sulle tempistiche e sulle priorità, il punto di partenza è la nostra guida pratica all'EU AI Act per le aziende.

Disclaimer informativo. Il presente articolo ha finalità divulgativa e non costituisce consulenza legale, fiscale o regolamentare. Le scelte di adeguamento al Decreto Legislativo 231/2001, al Regolamento (UE) 2024/1689 e agli standard ISO/IEC 42001 e 27001 richiedono valutazione professionale qualificata, calibrata sulla specifica realtà aziendale, sui processi interessati e sull'evoluzione normativa e interpretativa. Knowlee.ai è proprietaria delle proprie tecnologie di AI workforce e fornisce strumenti di automazione che possono essere integrati in framework di compliance, senza sostituirsi alla funzione legale e all'Organismo di Vigilanza dell'ente.