L’annuncio diceva «AI Governance Manager» e la descrizione era, paragrafo per paragrafo, quella di un responsabile della protezione dei dati con due frasi sull’intelligenza artificiale incollate alla fine. Non è un caso isolato: è lo schema con cui il mercato sta coprendo la funzione. Si dà per scontato che chi viene dalla protezione dei dati o dalla compliance abbia già fatto mezza strada nella governance dell’IA. È mezzo vero e mezza trappola, e la differenza si vede solo da dentro un sistema che gira in produzione da mesi.
La tesi in una riga: le tre funzioni che si confondono ogni giorno — DPO, responsabile compliance e responsabile governance dell’IA — non si delimitano con l’organigramma, si delimitano con l’oggetto che ciascuna vigila. Il dato personale, il quadro normativo, il ciclo di vita del sistema. Confonderle non è un problema di titoli su un biglietto da visita: è la ragione per cui, quando un agente sbaglia, la riunione se ne va quaranta minuti senza che nessuno possa dire chi risponde.
La differenza tra DPO e AI Governance Manager sta nell’oggetto, non nell’organigramma
Le tre funzioni rispondono a domande diverse perché vigilano cose diverse. Il DPO vigila un trattamento: che ci sia una base giuridica, che il dato sia il minimo necessario, che la persona sappia che esiste. Il responsabile compliance vigila un quadro: che l’azienda stia dentro la norma che la obbliga, settoriale, societaria o del lavoro. Il responsabile governance dell’IA vigila un sistema nel tempo: con quali dati è stato costruito, cosa decide, quanto deriva, chi lo approva e chi lo spegne. Tre oggetti e tre orologi diversi.
| Funzione | Oggetto che vigila | Norma di riferimento | Domanda a cui risponde |
|---|---|---|---|
| DPO / Responsabile della protezione dei dati | Il trattamento di dati personali | GDPR, artt. 37-39 | Questo trattamento è lecito e proporzionato? |
| Responsabile compliance | Il quadro normativo che obbliga l’azienda | Settoriale, societario, del lavoro | Stiamo dentro la norma che ci si applica? |
| Responsabile governance dell’IA | Il ciclo di vita del sistema di IA | Regolamento europeo sull’IA, artt. 10 e 26 | Questo sistema si può rilasciare, e chi risponde se sbaglia? |
In un’azienda di sessanta persone le tre possono essere la stessa persona, e va benissimo: la funzione non impone una posizione. Quello che invece si rompe è dare per scontato che coprire un oggetto copra gli altri due. Un trattamento impeccabile dal punto di vista della protezione dei dati può poggiare su un sistema che da quattro mesi sbaglia in un caso su dodici senza che nessuno l’abbia misurato, perché quell’errore non è un problema di dato personale: è un problema di ciclo di vita.
Cosa vigila esattamente un DPO, e dove gli finisce il perimetro
L’articolo 39 del GDPR elenca cinque compiti del responsabile della protezione dei dati: informare e fornire consulenza, sorvegliare l’osservanza della normativa in materia di protezione dei dati, fornire pareri sulla valutazione d’impatto e sorvegliarne lo svolgimento, cooperare con l’autorità di controllo e fungere da punto di contatto per essa. Tutti e cinque pendono dallo stesso oggetto, il trattamento di dati personali. È la delimitazione giuridica, non una nostra lettura: vedi articolo 39 GDPR, compiti del responsabile della protezione dei dati. Ambito: Unione europea.
Ora mettici accanto due guasti reali. Un agente che classifica i ticket in ingresso e ne instrada male uno su dodici, così il cliente aspetta due giorni più del dovuto. Un agente che preventiva con un listino rimasto indietro all’ultima revisione. In nessuno dei due c’è un dato personale a rischio, e in entrambi ci sono soldi e fiducia persi. Il DPO non ha niente da vigilare lì, e non è un fallimento del DPO: il guasto cade fuori dal suo oggetto. Quello che invece cade dentro l’oggetto della governance dell’IA, dal primo giorno, è la portata con cui quell’agente può toccare i tuoi sistemi: il dettaglio è in quali permessi dare a un agente IA.
Perché venire dalla compliance è mezza strada e non la strada intera
Il regolamento europeo sull’IA lo dice con una precisione che vale la pena leggere per intero. L’articolo 26.2 stabilisce che i deployer «affidano la sorveglianza umana a persone fisiche che dispongono della competenza, della formazione e dell’autorità necessarie, nonché del sostegno necessario». Fonte: articolo 26 del regolamento (UE) 2024/1689, testo consolidato. Tre gambe, non una. E la norma non si accontenta che un responsabile esista nell’organigramma: pretende che quella persona capisca il sistema, sia stata formata su quel sistema specifico e possa agire su di esso.
Qui sta la trappola della scorciatoia. Chi viene dalla compliance porta la terza gamba quasi intera — l’autorità, e l’abitudine a metterlo per iscritto, che non è poco — e porta molto della prima quando il rischio è normativo. Quello che non porta per default è la competenza sul sistema: sapere cosa significa un output, in quali condizioni degrada, che faccia ha una risposta plausibile e sbagliata, quanto costa un falso positivo rispetto a un falso negativo in quel processo preciso. Quello non si legge, si acquisisce operando. Quindi «mezza strada» è esatto. Il problema comincia quando si assume come se fosse la strada intera, e il buco si scopre il giorno del primo incidente.
Dove comincia davvero l’obbligo: articoli 10 e 26
La conversazione sulla governance dell’IA parte di solito dall’articolo 10, che disciplina i dati e la loro governance: i set di addestramento, convalida e prova, i loro criteri di qualità, l’esame dei bias e la tracciabilità dell’origine. È un articolo decisivo, ma parla soprattutto di chi costruisce il sistema. E la maggior parte delle aziende non costruisce: rilascia. Compra, configura, collega ai propri dati e lo mette a lavorare. Per loro l’articolo che stringe è il 26, quello dei deployer, e quest’ordine — prima dove ti collochi, poi cosa ti obbliga — è quello che ordina tutto il resto. La versione lunga, con il quadro completo, è nella guida governance e controllo dell’automazione con IA.
Tre commi di quello stesso articolo 26 disegnano la funzione meglio di qualsiasi job description. Il comma 5 obbliga a monitorare il funzionamento, a informare il fornitore e l’autorità di vigilanza del mercato in caso di rischio e a sospendere l’uso del sistema, e a comunicare immediatamente gli incidenti gravi. Il comma 6 obbliga a conservare i log generati automaticamente per almeno sei mesi. E il comma 9 rimanda alla valutazione d’impatto dell’articolo 35 del GDPR. Quest’ultimo è la cucitura: la valutazione d’impatto è l’unico punto in cui i due oggetti si toccano davvero, e per questo è il documento che DPO e governance dell’IA firmano insieme invece che separatamente.
Il rinvio dell’Omnibus non ti regala due anni
Il calendario dell’alto rischio si è spostato. Il regolamento (UE) 2026/1744, l’Omnibus Digitale sull’IA, pubblicato nella Gazzetta ufficiale dell’Unione europea, sposta gli obblighi dei sistemi ad alto rischio autonomi al 2 dicembre 2027 e quelli dei sistemi integrati in prodotti già regolati ad agosto 2028; il monitoraggio del calendario di applicazione pubblicato dal Future of Privacy Forum lo dettaglia blocco per blocco. Quello che è rimasto in piedi ad agosto 2026 l’abbiamo già sviluppato in l’AI Act è stato rinviato, ma il tuo chatbot deve ancora avvisare e qui non lo ripetiamo. Ambito: Unione europea.
Il punto operativo è un altro, e quasi nessuno lo tira fuori dal rinvio: la data che si sposta è quella dell’inadempimento, non quella del problema. E c’è un dettaglio che lo rende urgente comunque. Se la norma ti chiederà almeno sei mesi di log, un sistema che inizia a loggare la settimana in cui l’obbligo entra arriva con il fascicolo vuoto, che in pratica è la stessa cosa che arrivare senza log. L’orologio della prova parte prima di quello della compliance, ed è l’unico argomento che serve per non aspettare il 2027.
Le due domande che delimitano la funzione meglio di qualsiasi job description
Le job description di questa funzione si assomigliano tutte perché sono scritte dalla norma. Se vuoi sapere se l’hai coperta davvero, non guardare il documento: fai due domande su un sistema concreto, quello che muove più soldi, e ascolta se la risposta tarda.
- Chi firma il rilascio? Non chi l’ha approvato in comitato, ma chi ha messo il suo nome sulla decisione che quel sistema andasse in produzione con quella portata e quei permessi. Se la risposta è un organo collegiale, nessuno firma. Se la risposta è «lo certifica il fornitore», nemmeno: il fornitore risponde del prodotto, il deployer risponde dell’uso.
- Chi risponde quando sbaglia? E dentro quella, l’unica che separa davvero la sorveglianza dal teatro: chi può spegnerlo senza chiedere il permesso? L’articolo 26 pretende autorità, e l’autorità senza la facoltà di fermare è una firma decorativa. Se per staccare l’agente bisogna aspettare il comitato di giovedì, il sistema non è sorvegliato: è accompagnato.
Le due domande hanno una proprietà utile: si rispondono con un nome o non si rispondono. Un framework di governance può essere impeccabile in PDF e fallirle entrambe. Se vuoi vedere il salto dalla policy scritta alla policy che si esegue, l’abbiamo sviluppato in la tua policy sull’uso dell’IA è in un PDF e il tuo agente non sa leggerlo.
Quando NON ti serve un AI Governance Manager
Con un sistema in produzione, un processo e un responsabile che lo conosce a memoria, nominare un responsabile governance dell’IA è prematuro, e quello che compri con quella nomina non è un controllo: è un comitato. La governance pesante troppo presto ha un costo concreto e misurabile, quello delle settimane che il primo caso d’uso passa a non uscire mentre si redige il quadro che lo regolerà. Il profilo completo della funzione, con la sua scala di seniority e quello che chiede il mercato, è nella scheda AI Governance Lead.
La soglia non è una cifra di organico, è un sintomo: il giorno in cui nessuno riesce a elencare a memoria tutti gli agenti che girano in azienda, la funzione serve già, con nome o senza. E prima della funzione viene il censimento, perché una policy non si applica a una flotta che nessuno ha contato: ne abbiamo discusso in l’inventario degli agenti che la tua azienda non ha.
Cosa farei lunedì
- Elenca i sistemi di IA che stanno girando e, accanto a ciascuno, un nome. Non il team: la persona. Le caselle vuote sono la tua diagnosi, e di solito sono più di quante ti aspetti.
- Per i due che muovono più soldi, rispondi per iscritto alle due domande. Una frase ciascuna. Se non sta in una frase, non è ancora risposta.
- Separa su un foglio l’oggetto del DPO e l’oggetto della governance dell’IA per quei due sistemi, e segna il punto in cui si incrociano: la valutazione d’impatto. È l’unico documento che firmano in due.
- Accendi l’orologio dei log oggi, anche se l’obbligo è del 2027. Sei mesi di storico non si possono retrodatare, ed è l’unica voce di questa lista che dipende dal calendario e non da te.
La governance dell’IA non si risolve assumendo un titolo, si risolve decidendo chi firma e chi spegne, e lasciando traccia di entrambe le cose. Se vuoi montare quella funzione senza passare sei mesi a scrivere il quadro prima di controllare qualcosa, è esattamente quello che facciamo in governare gli agenti IA della tua azienda: prima la traccia, i permessi e la catena di responsabilità, e il documento dopo, che è l’ordine in cui funziona davvero.