AI governance: come usare l'intelligenza artificiale in azienda in modo sicuro e responsabile

La domanda che fa emergere il problema arriva di solito in riunione, per caso: «chi ha approvato lo strumento che l'ufficio marketing usa per riassumere le email dei clienti?». Silenzio. Non c'è un contratto, non c'è una valutazione, non c'è traccia di quali dati siano passati fuori. Nessuno ha deciso niente: lo strumento è entrato in azienda un martedì pomeriggio, quando qualcuno ha provato la versione gratuita ed è rimasto soddisfatto.

Questa è la situazione da cui parte quasi sempre un progetto di AI governance, e spiega perché i documenti di principi servono a poco. La governance non è una dichiarazione su quanto crediamo nell'etica: è un insieme di registri, decisioni e responsabilità che rendono impossibile quella scena.

Perché il 2026 cambia il tono della discussione

Fino a un paio d'anni fa la governance dell'AI era un tema di posizionamento. Oggi è un tema di calendario. Il regolamento europeo sull'intelligenza artificiale (Regolamento UE 2024/1689) è in vigore dal 1° agosto 2024 ed è applicabile dal 2 agosto 2026, con un percorso applicativo già iniziato prima:

• 2 febbraio 2025: sono diventati applicabili i divieti sulle pratiche vietate e gli obblighi di alfabetizzazione all'AI per chi fornisce o impiega sistemi.
• 2 agosto 2025: regole di governance e obblighi per i modelli di uso generale (GPAI).
• 2 agosto 2026: applicazione generale del regolamento e avvio del sistema di vigilanza, con l'AI Office competente sui modelli GPAI.
• dicembre 2026: entra in vigore il divieto dei sistemi che generano contenuti intimi non consensuali, introdotto dall'Omnibus AI.
• 2 dicembre 2027 e 2 agosto 2028: obblighi per i sistemi ad alto rischio, rispettivamente per gli usi elencati nell'Allegato III e per i prodotti regolati dell'Allegato I.

Le due date finali sono il risultato del cosiddetto AI Omnibus, il regolamento di semplificazione adottato il 19 novembre 2025, con accordo politico il 7 maggio 2026 ed entrata in vigore il 27 luglio 2026. Ha spostato in avanti gli obblighi sui sistemi ad alto rischio e ha rafforzato i poteri dell'AI Office.

La conseguenza pratica per un'azienda italiana è che il tempo delle slide è finito. Non serve aver letto il regolamento articolo per articolo, ma serve sapere in quale categoria ricadono i propri casi d'uso e chi risponde di ognuno.

Tre strumenti che non sono alternativi

Chi arriva al tema trova tre riferimenti che sembrano in concorrenza. Non lo sono: coprono livelli diversi.

Il regolamento dice cosa è obbligatorio, con quali scadenze e con quali sanzioni. È il vincolo esterno, e si applica per classificazione del rischio, non per dimensione aziendale.

Lo standard ISO/IEC 42001, pubblicato nel dicembre 2023, dice come organizzare un sistema di gestione dell'AI: requisiti per stabilire, attuare, mantenere e migliorare un AI Management System, con l'impostazione Pianifica-Agisce-Verifica-Intervieni tipica degli standard di management. Non dice se il regolamento europeo è rispettato; dice se in azienda esistono responsabilità, processi e riesame periodico. Serve a chi vuole dimostrare di aver messo in piedi un sistema, e per questo è certificabile.

Il NIST AI Risk Management Framework, pubblicato il 26 gennaio 2023 e di uso volontario, dice come si ragiona sul rischio di un singolo caso d'uso, con quattro funzioni: governare, mappare, misurare, gestire. Nel luglio 2024 NIST ha aggiunto il profilo specifico per l'AI generativa. Attenzione al contesto: il framework è in revisione nell'ambito dell'AI Action Plan statunitense, e ad aprile 2026 NIST ha pubblicato una nota di concetto per un profilo dedicato alle infrastrutture critiche. Va usato come metodo, non come testo immutabile.

In una frase: il regolamento definisce il perimetro, lo standard costruisce il sistema, il framework dà le pratiche per valutare i singoli casi.

I cinque registri che rendono la governance verificabile

Se il sistema di gestione è l'ossatura, i documenti operativi sono le articolazioni. Cinque bastano per partire, e nessuno richiede software dedicato.

1. Registro dei casi d'uso. Un foglio con una riga per ogni uso di AI: cosa fa, chi lo usa, quale dato tocca, chi è il responsabile. Senza questo elenco ogni altra valutazione è casuale.

2. Valutazione del rischio per caso d'uso. Non serve un documento di venti pagine: serve rispondere a quattro domande. Che cosa succede se il sistema sbaglia? Chi può essere danneggiato? L'output viene verificato da una persona prima di avere effetti? I dati in ingresso contengono informazioni personali o segreti industriali?

3. Policy d'uso accettabile. Cosa è consentito con gli strumenti pubblici, cosa richiede un contratto, cosa è vietato. Il divieto più utile da scrivere è quello che nessuno ha voglia di scrivere: i dati dei clienti non si incollano nei chatbot senza contratto.

4. Registro dei fornitori. Per ogni strumento: chi tratta i dati, con quale accordo, dove finiscono i dati, per quanto tempo restano. È la parte che incrocia il GDPR e che spesso manca anche quando il contratto esiste.

5. Registro degli incidenti. Un output palesemente sbagliato, un uso non autorizzato scoperto tardi, una fuga di dati in un prompt. Registrare questi eventi è l'unico modo per capire se il sistema funziona; il piano di incident response va esteso per includerli, perché un incidente AI non ha quasi mai un orario di inizio chiaro.

Questi registri hanno una proprietà poco appariscente ma decisiva: sono verificabili. Un revisore, un cliente o un'autorità possono chiedere una riga e vedere se esiste. Un documento di principi non lo permette.

Il ruolo di IT e sicurezza, che nessuno vuole scrivere nero su bianco

Nella pratica la governance dell'AI finisce sulle spalle dell'IT per una ragione semplice: è l'unica funzione che vede il traffico. Ed è lì che emergono i problemi più concreti.

Il primo è lo shadow AI: strumenti usati senza che nessuno li abbia approvati. Non si risolve con il divieto, si risolve con un'alternativa approvata che funziona bene almeno quanto quella non approvata.

Il secondo è il dato in ingresso. Un prompt è un trasferimento di dati: se contiene nomi, diagnosi, contratti, il trattamento va valutato come qualsiasi altro. La classificazione dei dati che già esiste per il resto dell'azienda vale anche qui, e vale la pena riusarla invece di inventarne una nuova.

Il terzo sono i log. Sapere quali richieste sono passate, da chi e verso quale servizio è la differenza tra ricostruire un incidente e ipotizzarlo. Attenzione al rovescio della medaglia: i log dei prompt contengono spesso dati personali, quindi conservarli "tutti e per sempre" crea un problema nuovo.

Il quarto è la valutazione del fornitore, che non è solo una firma sul contratto: un modello che cambia versione senza preavviso cambia anche i suoi rischi. Chi approva un caso d'uso dovrebbe sapere con quale frequenza può accadere.

La formazione non è un accessorio

L'alfabetizzazione all'AI è un obbligo in vigore dal 2 febbraio 2025 per chi fornisce o impiega sistemi di AI nell'Unione: un requisito normativo, non un'iniziativa di welfare aziendale. Ma la parte interessante non è l'obbligo, è che senza formazione la governance non regge.

Un registro dei casi d'uso compilato da persone che non sanno distinguere un modello generativo da un classificatore non serve a nulla. Una policy che nessuno ha capito produce comportamenti opposti: chi è prudente smette di usare gli strumenti, chi è entusiasta li usa di nascosto.

La formazione utile ha tre caratteristiche: è specifica per ruolo (chi scrive prompt, chi approva, chi gestisce i dati), è basata su casi reali dell'azienda e non su esempi da conferenza, e si ripete quando cambiano gli strumenti. Un corso unico all'inizio dell'anno, con attestato e nessun seguito, non riduce nessun rischio.

Gli errori che si vedono più spesso

Governance confusa con la conformità. Un'azienda può avere un registro dei trattamenti perfetto e nessuna idea di quali strumenti AI usino i dipendenti.

Comitato senza poteri. Un gruppo che si riunisce ogni trimestre e non può bloccare un progetto non è governance, è un osservatorio.

Policy senza registro. Le regole scritte senza l'elenco dei casi d'uso non si applicano a niente di concreto.

"Abbiamo firmato il contratto, quindi siamo a posto". Il contratto è la premessa. Restano da valutare il caso d'uso, i dati, l'output e il monitoraggio.

Inventario fatto una volta. L'AI in azienda cambia ogni trimestre: il registro va aggiornato con la stessa frequenza con cui si aggiornano gli accessi.

Come si misura se funziona

Quattro indicatori, tutti ricavabili dai registri.

• Percentuale di casi d'uso censiti che hanno un responsabile nominato.
• Percentuale di fornitori con valutazione completata e data di revisione.
• Tempo medio tra la segnalazione di un nuovo strumento e la decisione di approvarlo o bloccarlo. Se è di mesi, la governance sta spingendo le persone a non chiedere.
• Numero di incidenti registrati e quanti hanno portato a una modifica della policy.

L'ultimo è il più onesto: un registro degli incidenti sempre vuoto in un'azienda che usa l'AI tutti i giorni non significa che non accada nulla. Significa che nessuno segnala.

Da dove iniziare, in pratica

La sequenza che funziona è noiosa: censire, classificare, decidere, scrivere, ripetere. Nell'ordine.

Censire significa chiedere alle funzioni quali strumenti usano, senza tono accusatorio. Classificare significa collocare ogni caso nelle categorie di rischio del regolamento e capire quali obblighi già applicabili lo riguardano. Decidere significa stabilire chi approva che cosa. Scrivere significa produrre i cinque registri, non un manifesto. Ripetere significa fissare una revisione periodica, con una persona che ne risponde.

Un'azienda che in tre mesi arriva ad avere il registro dei casi d'uso popolato e una policy applicata è più avanti di un'azienda che ha approvato un documento di principi etici in consiglio di amministrazione. Il secondo è più bello da comunicare; il primo regge la prima domanda scomoda.

Le competenze che servono

La governance dell'AI richiede un mix che raramente sta in una persona sola: chi conosce il processo di business, chi sa valutare un rischio, chi sa leggere un contratto e un flusso di dati, chi sa spiegare i limiti di un modello a chi lo usa. Le figure tecniche servono, ma senza chi sappia tradurre il regolamento in decisioni operative il sistema resta un elenco di buone intenzioni. Chi lavora in ambienti regolati lo sa già: è la stessa logica dei ruoli e delle responsabilità richiesti dalla NIS2, applicata a un perimetro che cambia più in fretta.

Se il team deve costruire questa base — capire i modelli, valutarne i rischi, tradurre gli obblighi in processi e formare le persone che li useranno — nel catalogo dei corsi Digital Lab trovate i percorsi su AI, sicurezza e governance, con laboratori e casi applicati.