Modello 231 e Intelligenza Artificiale:dai 10 controlli a un sistema di governance realmente efficace

Approfondimento operativo: come trasformare i principi di controllo in procedure, responsabilità, evidenze e flussi verso l’Organismo di Vigilanza

L’intelligenza artificiale sta entrando nei processi aziendali con una velocità superiore a quella con cui, tradizionalmente, vengono aggiornati procedure, deleghe, sistemi di controllo e Modelli di Organizzazione, Gestione e Controllo. È proprio questo disallineamento a rappresentare uno dei principali punti di attenzione per le imprese.

Nel precedente approfondimento FEDIMI «Modello 231 e IA: 10 controlli per le imprese» abbiamo individuato dieci presidi essenziali: mappatura dei sistemi, valutazione dei rischi, regole di utilizzo, protezione dei dati, controllo dei fornitori, tracciabilità, formazione, gestione degli incidenti, ruolo dell’Organismo di Vigilanza e revisione periodica. Il passaggio successivo è comprendere come questi controlli possano diventare un sistema organizzativo concreto, proporzionato e verificabile.

Il punto di partenza resta l’articolo 6 del D.Lgs. 231/2001: il Modello deve individuare le attività nel cui ambito possono essere commessi reati, prevedere protocolli per la formazione e l’attuazione delle decisioni, stabilire obblighi informativi verso l’Organismo di Vigilanza e disporre di un sistema disciplinare. L’ingresso dell’IA nei processi aziendali non modifica questa architettura: modifica, però, il modo in cui alcuni processi funzionano e quindi può rendere necessario riesaminarne rischi e presidi.

1. Dalla mappatura degli strumenti alla mappatura dei processi

Un semplice elenco dei software di IA non è sufficiente. La mappatura deve collegare ogni sistema al processo aziendale nel quale viene utilizzato. Lo stesso strumento generativo può avere un rischio molto basso se impiegato per predisporre una bozza interna e un rischio sensibilmente maggiore se viene utilizzato per elaborare dati finanziari, predisporre documenti destinati alla pubblica amministrazione, trattare informazioni riservate o supportare decisioni sul personale.

Per ogni sistema sarebbe opportuno registrare almeno: funzione aziendale utilizzatrice, finalità, categorie di dati trattati, eventuale accesso a sistemi interni, capacità di compiere azioni autonome, destinatari degli output, presenza di controllo umano e referente responsabile.

Questa mappatura consente di individuare anche il cosiddetto shadow AI: l’impiego di strumenti non autorizzati o non conosciuti dall’organizzazione, spesso introdotti autonomamente dai singoli lavoratori.

2. La valutazione del rischio IA deve dialogare con la risk assessment 231

L’AI risk assessment e la risk assessment 231 non dovrebbero procedere su binari separati. Occorre chiedersi se l’introduzione dell’IA abbia modificato probabilità, modalità o conseguenze di condotte già considerate dal Modello.

Tra le aree che possono richiedere particolare attenzione rientrano i reati informatici, i reati societari, gli abusi di mercato, i delitti in materia di diritto d’autore e proprietà intellettuale, i processi che coinvolgono la pubblica amministrazione e, più in generale, le attività nelle quali l’automazione può incidere sulla formazione, verifica o trasmissione di informazioni rilevanti.

La corretta domanda non è quindi «l’IA è un nuovo reato 231?», ma «l’utilizzo dell’IA modifica un processo nel quale potrebbe essere commesso un reato-presupposto già previsto dal decreto?».

3. Regole di utilizzo: dalla policy generale ai protocolli per processo

Una policy aziendale sull’IA rappresenta un primo presidio, ma non può esaurire il sistema di controllo. Le regole devono diventare più specifiche quando l’IA entra in processi sensibili.

Una disciplina efficace dovrebbe distinguere almeno tre livelli: utilizzi liberamente consentiti entro regole predefinite; utilizzi consentiti soltanto con strumenti aziendali autorizzati; utilizzi che richiedono una preventiva autorizzazione o una verifica qualificata.

Nei processi 231 più sensibili dovrebbe essere chiarito chi può utilizzare il sistema, quali dati possono essere inseriti, quali verifiche devono essere effettuate sugli output, chi approva il risultato finale e quale evidenza deve essere conservata.

4. Protezione dei dati e delle informazioni: non solo GDPR

La protezione delle informazioni deve essere affrontata in senso più ampio rispetto alla sola disciplina dei dati personali. Un prompt può contenere segreti commerciali, informazioni strategiche, documenti contrattuali, dati tecnici, credenziali, informazioni privilegiate o materiale di terzi protetto da obblighi di riservatezza.

Per questo l’impresa dovrebbe classificare le informazioni che non possono essere caricate in servizi esterni non autorizzati e stabilire regole specifiche per documenti, allegati, immagini, registrazioni e database. Il controllo deve estendersi anche alle modalità con cui il fornitore del sistema utilizza o conserva gli input e gli output.

5. Fornitori di IA e terze parti: il rischio entra anche dalla supply chain

Molti sistemi di IA vengono acquistati come servizi cloud oppure incorporati in software già utilizzati dall’impresa. Il rischio non dipende quindi soltanto dal comportamento interno, ma anche dalle caratteristiche del fornitore e della catena tecnologica.

La due diligence dovrebbe essere proporzionata alla criticità del sistema e considerare almeno: condizioni contrattuali, localizzazione e utilizzo dei dati, misure di sicurezza, gestione degli incidenti, subfornitori, continuità operativa, possibilità di audit, modifiche unilaterali del servizio e procedure per la cessazione del rapporto.

Per i sistemi più sensibili può essere opportuno prevedere clausole che impongano tempestiva comunicazione di incidenti, vulnerabilità o modifiche sostanziali delle funzionalità.

6. Tracciabilità: documentare ciò che conta, senza creare burocrazia inutile

La tracciabilità non significa conservare indiscriminatamente ogni prompt. Significa essere in grado di ricostruire le attività rilevanti quando l’IA interviene in un processo sensibile.

L’impresa dovrebbe poter documentare, in modo proporzionato, chi ha utilizzato il sistema, quale versione o servizio era impiegato, quale finalità aveva l’operazione, chi ha verificato l’output e quale decisione è stata successivamente adottata.

La qualità della prova organizzativa diventa particolarmente importante: un controllo non documentato può essere molto più difficile da dimostrare ex post.

7. Formazione e AI literacy: dalla conoscenza tecnica alla consapevolezza del rischio

L’articolo 4 dell’AI Act attribuisce rilievo all’alfabetizzazione in materia di IA. Per le imprese, questo principio dovrebbe tradursi in una formazione differenziata per ruolo e rischio.

Un lavoratore che utilizza strumenti generativi per attività ordinarie necessita di regole chiare su riservatezza, verifica degli output e utilizzi vietati. Chi opera in amministrazione, finanza, HR, IT, legale o compliance può invece richiedere una formazione più approfondita, collegata ai processi e ai rischi specifici.

La formazione dovrebbe comprendere anche il limite intrinseco degli output: errori, contenuti non verificati, bias, informazioni inventate o non aggiornate. L’utilizzo professionale dell’IA non può prescindere dalla verifica umana quando l’output incide su decisioni o documenti rilevanti.

8. Incidenti IA: creare un percorso di escalation

Un incidente collegato all’IA può assumere forme molto diverse: divulgazione involontaria di dati, utilizzo non autorizzato, output discriminatorio, generazione di informazioni errate poi utilizzate dall’impresa, compromissione di un account, automazione di un’operazione non prevista o mancato rispetto delle regole di trasparenza.

L’impresa dovrebbe quindi definire un percorso di escalation: chi riceve la segnalazione, chi effettua la prima valutazione, quando coinvolgere IT/cybersecurity, privacy, legale, HR, compliance e Organismo di Vigilanza, e quali misure adottare per sospendere o limitare temporaneamente il sistema.

Il registro degli incidenti può diventare uno strumento prezioso per la revisione periodica della risk assessment e per individuare near miss organizzativi prima che producano conseguenze più gravi.

9. Il ruolo dell’Organismo di Vigilanza: controllo sul sistema, non gestione tecnica dell’IA

L’Organismo di Vigilanza non deve trasformarsi in un ufficio informatico né assumere la responsabilità operativa della governance dell’IA. Il suo compito resta quello previsto dal D.Lgs. 231/2001: vigilare sul funzionamento e sull’osservanza del Modello e curarne l’aggiornamento nell’ambito delle proprie attribuzioni.

Per svolgere questa funzione, tuttavia, l’OdV deve ricevere informazioni adeguate quando l’IA incide sui processi sensibili. I flussi informativi possono riguardare nuovi sistemi rilevanti, variazioni significative degli utilizzi, incidenti, violazioni della policy, risultati di audit, formazione effettuata e aggiornamenti della mappatura.

L’OdV dovrebbe inoltre poter verificare a campione l’effettiva applicazione dei protocolli, senza sostituirsi alle funzioni aziendali responsabili dei controlli di primo e secondo livello.

10. Revisione periodica: il vero punto critico è la velocità del cambiamento

Un sistema di IA può cambiare funzionalità anche senza che l’impresa acquisti un nuovo software. Aggiornamenti del fornitore possono introdurre agenti, connessioni con banche dati, capacità di eseguire azioni, nuovi modelli o differenti condizioni di trattamento delle informazioni.

Per questo la revisione non dovrebbe essere legata soltanto a una scadenza annuale. È opportuno prevedere anche eventi che attivino un riesame: introduzione di nuove funzioni, accesso a nuove categorie di dati, integrazione con sistemi aziendali, ampliamento degli utenti, incidenti significativi, variazioni normative o passaggio da una funzione assistiva a una funzione maggiormente autonoma.

Un modello operativo: quattro livelli di controllo

Per rendere il sistema concretamente gestibile, FEDIMI propone di organizzare i dieci controlli in quattro livelli tra loro collegati:

Una possibile matrice di classificazione

Per le PMI può essere utile adottare una classificazione semplice, evitando sistemi eccessivamente complessi. Ad esempio:

• Livello basso: IA utilizzata per attività ausiliarie, senza dati riservati e senza effetti diretti su decisioni o processi sensibili.
• Livello medio: IA utilizzata in processi aziendali con dati interni o con output destinati a influenzare attività operative; richiesta verifica umana e utilizzo di strumenti autorizzati.
• Livello alto: IA impiegata in processi sensibili 231, su dati particolarmente rilevanti, per decisioni sul personale, attività finanziarie, rapporti con autorità o operazioni automatizzate; richiesta preventiva valutazione, responsabilità formalizzate, tracciabilità e controlli rafforzati.

Le evidenze documentali che un’impresa dovrebbe poter mostrare

Un sistema efficace deve poter essere dimostrato. In caso di audit interno, verifica dell’OdV o analisi successiva a un incidente, l’impresa dovrebbe poter produrre evidenze coerenti con la propria dimensione e il livello di rischio.

• registro dei sistemi di IA autorizzati e relativi referenti;
• valutazioni dei rischi e decisioni di classificazione;
• policy e protocolli applicabili ai processi sensibili;
• approvazioni per gli utilizzi ad alto rischio;
• documentazione di due diligence dei fornitori;
• registri o evidenze dei controlli effettuati;
• formazione e iniziative di AI literacy;
• segnalazioni, incidenti, near miss e relative azioni correttive;
• flussi informativi e report verso l’Organismo di Vigilanza;
• verbali o evidenze delle revisioni periodiche.

AI Act, Legge 132/2025 e Modello 231: evitare duplicazioni

Il Regolamento (UE) 2024/1689 introduce una disciplina europea basata sul rischio e prevede, tra l’altro, obblighi in materia di alfabetizzazione sull’IA e specifiche regole di trasparenza. La Legge 23 settembre 2025, n. 132 promuove in Italia un utilizzo corretto, trasparente e responsabile dell’intelligenza artificiale, coordinato con l’AI Act, e richiama espressamente la cybersicurezza lungo il ciclo di vita dei sistemi.

Il Modello 231 non deve duplicare integralmente questi sistemi normativi. Può invece diventare uno dei punti di raccordo della governance: individua i processi sensibili, assegna responsabilità, disciplina i flussi verso l’OdV e verifica che l’introduzione dell’IA non renda inefficaci i protocolli esistenti.

La stessa logica vale per GDPR, cybersecurity, whistleblowing, sicurezza sul lavoro e procedure HR: l’obiettivo dovrebbe essere costruire un sistema integrato, nel quale ciascun presidio abbia una funzione chiara e le informazioni possano essere condivise tra le funzioni competenti senza sovrapposizioni inutili.

La proposta FEDIMI: un Protocollo IA integrato nel sistema 231

Per le imprese che utilizzano stabilmente strumenti di intelligenza artificiale, FEDIMI ritiene utile valutare l’adozione di un Protocollo IA collegato al Modello 231. Il Protocollo dovrebbe essere breve, operativo e costruito sulla realtà aziendale, non su formule standard.

La sua struttura potrebbe comprendere: ambito di applicazione; ruoli e responsabilità; inventario e classificazione dei sistemi; procedura di autorizzazione; regole sui dati; supervisione umana; tracciabilità; gestione dei fornitori; formazione; incident management; flussi verso l’OdV; sistema disciplinare e revisione periodica.

Nelle organizzazioni più strutturate, il Protocollo potrebbe essere coordinato da un comitato o da una funzione interfunzionale che coinvolga, secondo necessità, IT, cybersecurity, legale, privacy, HR, compliance e risk management. Nelle PMI lo stesso risultato può essere ottenuto con un sistema molto più semplice, purché siano chiare responsabilità e controlli.

Conclusioni: il controllo dell’IA deve essere concreto, non formale

La diffusione dell’intelligenza artificiale non richiede necessariamente di moltiplicare documenti e procedure. Richiede, piuttosto, di aggiornare il modo in cui l’impresa conosce e governa i propri processi.

I dieci controlli proposti da FEDIMI acquistano valore quando diventano un ciclo continuo: conoscere gli strumenti, valutare i rischi, definire le regole, formare le persone, verificare gli utilizzi, gestire gli incidenti e aggiornare il sistema.

Un Modello 231 efficace non dovrebbe limitarsi a descrivere l’organizzazione esistente al momento della sua approvazione. Deve essere capace di intercettare i cambiamenti che modificano realmente i processi aziendali. L’intelligenza artificiale rappresenta oggi uno dei cambiamenti più significativi.

Per questo la domanda centrale per amministratori, dirigenti, funzioni di controllo e Organismi di Vigilanza non è più soltanto se l’impresa utilizzi l’IA, ma se sia in grado di dimostrare di conoscerne gli utilizzi, valutarne i rischi e governarne gli effetti.

Innovare non significa ridurre i controlli. Significa costruire controlli più coerenti con il modo in cui l’impresa opera oggi.

Riferimenti normativi essenziali

• Lgs. 8 giugno 2001, n. 231, in particolare art. 6 – Modelli di organizzazione e di gestione.
• Regolamento (UE) 2024/1689 (AI Act), in particolare art. 4 – Alfabetizzazione in materia di IA e art. 50 – Obblighi di trasparenza.
• Legge 23 settembre 2025, n. 132 – Disposizioni e deleghe al Governo in materia di intelligenza artificiale, testo vigente.

Nota editoriale: il presente contributo ha finalità di approfondimento generale e non sostituisce la valutazione giuridica, tecnica e organizzativa riferita alla singola impresa.

 Lidio Damiano Carboni

Responsabile Rapporti Istituzionali  FEDIMI