L'AI Governance e' una responsabilita' del CdA, non una delega tecnica al CIO. Il board deve conoscere gli use case AI in produzione, approvare la policy aziendale, presidiare il modello di rischio e ricevere un report periodico misurabile. Senza questi quattro elementi, l'azienda usa intelligenza artificiale ma non la governa: nel 2026 questa distinzione fa la differenza tra un asset competitivo e una passivita' latente.
Negli ultimi diciotto mesi ho seguito quattro programmi di AI Governance in Mid-Cap e una Enterprise (Finance, InsurTech, manifatturiero). Nei CdA italiani il quadro e' eterogeneo: alcuni hanno integrato l'AI nel comitato rischi, molti la trattano in modo episodico, qualcuno l'ha scoperta solo dopo un near-miss. Questo articolo e' una guida direzionale per amministratori non tecnici che firmano decisioni su un dominio dove legge, tecnologia e mercato si muovono in tre direzioni diverse.
Perche' l'AI non e' delegabile al CIO
Il primo riflesso di molti CdA italiani e' trattare l'AI come una tecnologia, e quindi delegarla all'IT. E' un errore di categoria. L'AI non e' un'infrastruttura, e' una decisione automatizzata. Quando un sistema AI decide a chi concedere un mutuo, quale candidato scartare in una selezione o quale fornitore privilegiare, esercita una porzione di potere discrezionale che fino a ieri richiedeva una persona con catena di responsabilita' chiara.
Il diritto e' netto: l'art. 2381 c.c. imputa al CdA il dovere di vigilare sull'adeguatezza degli assetti organizzativi. L'AI Act (Reg. UE 2024/1689) aggiunge un livello: chi mette in servizio sistemi AI ad alto rischio deve garantire sorveglianza umana, valutazioni d'impatto, formazione. Sono responsabilita' imputate al deployer come soggetto giuridico, non al singolo dirigente IT. Le ricerche di MIT Sloan Management Review e Deloitte convergono: dove il board e' attivamente coinvolto, la generazione di valore dai progetti AI in produzione e' piu' alta. Coincide con quello che vedo sul campo.
Le tre domande che ogni amministratore deve saper rispondere
Se sei in un CdA e non sai rispondere a queste tre, hai un problema di governance strutturale.
1. Chi possiede gli use case AI in azienda?
Accettabile: il CIO mantiene l'inventario tecnico, ogni use case ha un business owner nominato (Direttore HR per lo screening CV, CFO per il credit scoring, COO per la manutenzione predittiva). Inaccettabile: "Ogni reparto usa quello che vuole". Senza ownership chiara, nessun rischio puo' essere gestito.
2. Chi risponde se l'AI sbaglia?
Accettabile: la responsabilita' legale resta dell'azienda (e del CdA), quella operativa del business owner, quella tecnica del CIO, le rivalse sul fornitore sono regolate da contratto. Inaccettabile: "Lo decide il fornitore". I vendor AI limitano la responsabilita' fino al massimo consentito. Se non hai letto la sezione limitation of liability del contratto del tuo fornitore strategico, fallo prima della prossima seduta.
3. Come misuriamo il valore?
Accettabile: ogni use case in produzione ha un KPI di business (margine, tempo di lavorazione, NPS, accuracy contro processo manuale) e un costo totale tracciato (licenze, compute, integrazione, ore interne). Inaccettabile: "Stiamo facendo tante cose con l'AI". L'AI senza misurazione e' un centro di costo travestito da innovazione.
Framework operativo AI Governance: i cinque pilastri
Il framework che propongo ai CdA si ispira al NIST AI Risk Management Framework e ai principi OECD sull'AI, semplificati per essere leggibili da un board non tecnico. Cinque pilastri, ognuno con un output documentale specifico.
1. Strategia AI
Dove vogliamo arrivare con l'AI in 18-36 mesi, quali ambiti del business sono in scope, quale ambizione di valore. Output: documento di strategia AI di 5-8 pagine approvato dal board, aggiornato annualmente. Senza questo, ogni use case e' una decisione tattica scollegata.
2. Risk Management AI
Tassonomia dei rischi AI (bias, drift, sicurezza, privacy, reputazionale, compliance), livelli di accettabilita', soglie di escalation. Output: AI Risk Register integrato con l'ERM. Per chi e' soggetto a DORA e NIS2, l'AI Risk Register e' componente del Risk Register operativo complessivo.
3. Policy AI
Le regole interne: chi puo' usare quali sistemi, per quali finalita', con quali dati, quali divieti esistono (es. dati sensibili su tool pubblici), come si approva un nuovo use case. Output: documento di 4-8 pagine firmato dalla direzione e adottato dal CdA con delibera formale, aggiornato almeno annualmente.
4. Controllo e audit
Meccanismi di sorveglianza: chi controlla i log, chi fa l'audit periodico, come si segnalano gli incidenti, come si misurano le anomalie. Output: piano di audit AI annuale, calendario di revisione degli use case ad alto rischio, procedura incidenti. Integrabile con l'internal audit esistente.
5. Capability building
L'art. 4 dell'AI Act impone alfabetizzazione AI per chi sviluppa, utilizza o supervisiona sistemi AI. Output: piano di formazione differenziato per ruolo, registro delle sessioni svolte, valutazione di efficacia. Per il CdA stesso, almeno una sessione annuale di aggiornamento di 2 ore.
Il modello a tre livelli di delega
L'AI Governance non puo' vivere al solo livello del board: il CdA non ha la frequenza per le decisioni operative. Serve un modello a tre livelli con RACI esplicito.
Livello 1 - Board (CdA)
Responsabilita': indirizzo strategico, approvazione policy AI, vigilanza sull'adeguatezza degli assetti, ricezione report periodici, decisioni su use case ad alto rischio o ad alto impatto reputazionale.
Frequenza: sessione AI dedicata almeno quadrimestrale. Output tipici: delibera di adozione policy AI, approvazione strategia AI annuale, decisioni straordinarie su incidenti gravi.
Livello 2 - Comitato AI / Risk
Responsabilita': presidio della strategia AI tra una seduta e l'altra, validazione delle classificazioni di rischio, approvazione operativa dei nuovi use case secondo soglie definite, escalation al board.
Composizione Mid-Cap: un amministratore non esecutivo (chair), CFO, CIO, Risk Officer o DPO, eventualmente un consulente esterno. Composizione Enterprise: sotto-comitato del Comitato Controllo e Rischi con Chief Risk Officer, CIO, Head of Compliance, consigliere indipendente con competenza tecnologica. Frequenza: mensile o bimestrale.
Livello 3 - Operativo (AI Office / IT)
Responsabilita': esecuzione operativa, mantenimento inventario, gestione tecnica dei sistemi AI, formazione, predisposizione report al comitato AI, gestione fornitori, audit di primo livello.
Composizione: CIO/CTO come responsabile, AI Lead o Data Lead, security manager, DPO per le interazioni con dati personali. Frequenza: riunione settimanale, sintesi mensile al comitato AI.
Un RACI funzionante distingue: il board approva (Accountable), il comitato AI raccomanda (Responsible tattico), l'operativo esegue (Responsible tecnico), legale e DPO consultano (Consulted), gli stakeholder interessati ricevono informazione (Informed). Senza segregazione, le decisioni AI restano in un limbo dove tutti pensano sia compito di qualcun altro.
Sette domande da fare al CIO al prossimo CdA
Queste sette domande al CIO o al CTO ti danno un termometro della maturita' AI in 30 minuti. Se non sa rispondere a piu' di tre, non e' colpa sua: e' un segnale che la governance non e' stata ancora impostata.
- Quanti sistemi AI usiamo oggi, e quali sono ad alto rischio secondo l'AI Act? Risposta attesa: un numero preciso e un elenco breve, non un "molti".
- Quale e' il singolo use case AI con il maggior impatto economico o reputazionale potenziale? Capisci se il CIO ragiona per impatto o per volume.
- Abbiamo una policy AI firmata dalla direzione e quando e' stata aggiornata? Se la risposta e' "ci stiamo lavorando", la governance e' indietro.
- Quanti incident AI abbiamo registrato negli ultimi 12 mesi e come sono stati gestiti? Zero incident non e' una buona notizia: il sistema di rilevazione non funziona o nessuno guarda.
- Quale e' il livello di dipendenza da un singolo vendor AI? Lock-in tecnologico e contrattuale sono rischi di board.
- Come stiamo formando le persone sull'uso responsabile dell'AI? L'art. 4 AI Act richiede alfabetizzazione documentata.
- Quale e' la nostra esposizione se l'AI del fornitore strategico smette di funzionare o cambia condizioni d'uso? Continuita' operativa e dipendenza fornitori sono temi di board.
Errori frequenti dei board sull'AI
Errore 1: pensare che l'AI sia "solo IT"
Il classico errore di chi associa AI a software. L'AI non e' software: e' decisione automatizzata. Il software gestisce un processo definito, l'AI fa una scelta probabilistica su un input. Regimi di rischio, audit e responsabilita' diversi. Trattare l'AI come l'ennesimo applicativo significa usare il framework sbagliato.
Errore 2: delegare senza framework
Alcuni CdA delegano l'AI al CIO senza definire cosa si deleghi e cosa no. Risultato: nessuno sa quando un tema diventa di livello board. Si arriva al limite per inerzia (niente arriva mai in CdA) o per panico (tutto arriva insieme dopo un incidente). La delega senza framework non e' delega: e' abdicazione.
Errore 3: evitare il tema fino a un incidente
Esempio dal campo: in un CdA di un gruppo industriale Mid-Cap che seguo, l'AI era stata menzionata due volte in tre anni, sempre come "argomento futuro". Settembre 2025: il presidente riceve una chiamata, un fornitore di chatbot pubblico ha subito un data breach, e in chiaro ci sono conversazioni di un dipendente che aveva incollato dati di un fornitore strategico per stilare un'offerta. Nessuna sanzione, ma una settimana di crisi reputazionale. Da allora l'AI Governance e' al primo punto di ogni seduta. Il near-miss e' stato il vero capo progetto.
Errore 4: confondere AI Governance con AI Ethics
L'AI Ethics e' un dibattito sui principi (equita', non discriminazione, trasparenza). L'AI Governance e' la traduzione operativa di quei principi in regole, ruoli, controlli, report. Un comitato etico senza framework produce documenti; un framework senza base etica produce burocrazia. Il board ha bisogno di entrambi, ma non puo' confonderli.
Cosa il board firma personalmente: AI Act, NIS2, DORA
Le tre normative europee piu' rilevanti per le aziende Mid-Cap e Enterprise nel 2026 sono AI Act, NIS2 e DORA (quest'ultimo per le entita' finanziarie). Hanno in comune un dettaglio rilevante per i CdA: chiamano in causa l'organo amministrativo come destinatario diretto di obblighi.
AI Act. Sorveglianza umana, FRIA (valutazione d'impatto sui diritti fondamentali) e formazione del personale ricadono sul deployer come soggetto giuridico. Il CdA approva la policy AI, riceve evidenza che le FRIA sono state svolte, e in caso di contestazione risponde dell'adeguatezza degli assetti. La delibera della policy AI deve essere a verbale di seduta dedicata.
NIS2. La Direttiva 2022/2555 (art. 20) prevede la responsabilita' diretta degli organi di gestione: il management approva le misure di gestione del rischio cyber e ne sorveglia l'attuazione. Se l'azienda usa AI nei processi critici, l'AI rientra nel perimetro NIS2. Il D.Lgs. 138/2024 prevede obblighi formativi specifici per i membri dell'organo amministrativo.
DORA. Per banche, assicurazioni e gestori di fondi, il Reg. 2022/2554 impone al management body la responsabilita' diretta del framework di gestione del rischio ICT, che include l'AI nei processi critici. L'AI Risk Register del pilastro 2 e' lo stesso che entra nel reporting DORA: un'entita' finanziaria che non ha mappato l'AI nel rischio ICT non e' DORA compliant. In pratica, presidente o AD firmano personalmente policy AI, delibere sugli use case ad alto rischio, attestazioni NIS2/DORA. Non e' un atto formale: impegna la persona, non solo l'organo.
Domande frequenti
Il CdA puo' delegare interamente l'AI Governance al CIO?
No. Il board puo' delegare l'esecuzione operativa, ma non la responsabilita' di indirizzo, supervisione e firma della policy. AI Act, art. 2381 c.c. e principi di Corporate Governance imputano al CdA il dovere di vigilanza sull'adeguatezza degli assetti. L'AI ricade pienamente in questo perimetro.
Serve un comitato AI dedicato o basta il comitato rischi?
Dipende dalla dimensione e dall'esposizione AI. Per Mid-Cap con uso AI ancora limitato, basta integrare l'AI nel Comitato Controllo e Rischi. Per Enterprise con use case ad alto rischio (Finance, InsurTech, sanita'), un comitato AI dedicato e' opportuno, anche in forma di sotto-comitato.
Con che frequenza il board deve ricevere un report AI?
Minimo quadrimestrale. Per aziende con use case ad alto rischio o regolamentati, trimestrale allineato col ciclo dei comitati rischi. Eventi straordinari (incidente, near-miss, nuova policy del regolatore) richiedono comunicazione fuori ciclo.
Cosa firma personalmente il presidente del CdA?
La policy AI aziendale, la dichiarazione di rischio AI annessa al bilancio (dove applicabile), le delibere di approvazione degli use case ad alto rischio, e in regime NIS2/DORA le attestazioni di adeguatezza degli assetti di sicurezza che includono l'AI.
Il board deve sapere quali modelli AI usa l'azienda?
Non a livello di singolo vendor o modello, ma a livello di categoria, rischio e impatto sul business. Inventario aggregato, classificazione di rischio, e tre-cinque use case piu' rilevanti per impatto economico o reputazionale.
Come si misura l'efficacia dell'AI Governance dal board?
Tre indicatori sintetici: copertura (percentuale di use case AI censiti con valutazione di rischio formale), tempo di risposta a incidenti (mediana tra rilevamento e contenimento), valore generato (margine o efficienza misurabile sui progetti in produzione). Il board legge indicatori manageriali, non KPI tecnici.
Cosa portare al prossimo CdA
Per mettere l'AI Governance all'ordine del giorno della prossima seduta, parti da tre cose: inventario degli use case AI in produzione, adozione formale di una policy AI, composizione di un comitato AI di livello 2. Decisioni che il board prende in una seduta, e che fissano il punto fermo dopo il quale tutto il resto e' esecuzione.
Nel mio lavoro con l'AI Portfolio & Governance Sprint, accompagno il board con un mandato tipico di 12-18 mesi: gap analysis di 4-6 settimane, impostazione del framework e del comitato, supervisione continuativa. Spesso in parallelo con AI Strategy & Roadmap sul portafoglio e con la regia di delivery PMO sui progetti AI piu' critici.
Il punto non e' avere un'AI Governance perfetta dal giorno uno. E' partire con un framework che il board comprende, controlla e fa evolvere. La perfezione regolatoria non esiste; la negligenza documentata, invece, e' un rischio concreto.