Prima di chiedersi se l’AI può fare una cosa, un’organizzazione deve stabilire chi ne risponde quando la fa male.
Non è una precauzione formale. È la domanda che, se posta all’inizio, determina la maggior parte delle scelte tecniche successive: quali azioni il sistema può eseguire, dove si ferma, che cosa viene registrato, quali verifiche sono obbligatorie.
Se viene posta alla fine, tipicamente in occasione del primo errore rilevante, le risposte sono già state date implicitamente dall’architettura. E raramente sono quelle che l’organizzazione avrebbe scelto.
I ruoli minimi
La governance non richiede una struttura dedicata. Richiede che tre responsabilità siano attribuite a persone individuate, anche part time e anche in organizzazioni piccole.
Il proprietario del processo. È chi risponde del risultato del processo in cui il sistema opera, e continua a risponderne dopo l’introduzione del sistema. Decide quali attività possono essere assistite, quali soglie applicare, quando sospendere l’uso.
È il ruolo che viene più spesso lasciato indefinito, perché sembra assorbito dal progetto. Non lo è: un progetto ha un capo progetto, che termina con il rilascio. Il processo ha un proprietario, che resta.
Il referente tecnico. Presidia il funzionamento: monitoraggio, aggiornamenti, gestione degli incidenti, rapporto con il fornitore. Deve conoscere l’architettura abbastanza da diagnosticare un comportamento anomalo e da valutare l’impatto di una modifica.
Il referente compliance. Verifica la conformità rispetto a protezione dei dati, normativa di settore e AI Act, e mantiene la documentazione. Nella maggior parte delle organizzazioni è un ruolo già esistente, a cui si aggiunge un ambito.
A questi si affianca, dove l’output incide su persone, il coinvolgimento di chi rappresenta gli utilizzatori. Non è un ruolo di controllo, ma di rilevazione: gli errori sistematici li nota per primo chi usa lo strumento ogni giorno.
Il criterio di verifica è semplice. Se di fronte a un errore rilevante non è immediatamente chiaro chi convoca chi, i ruoli non sono definiti.
Che cosa deve essere documentato
Cinque elementi, mantenuti aggiornati e non ricostruiti a posteriori.
I dati. Quali fonti alimentano il sistema, con quale base giuridica, con quali permessi, per quanto tempo conservate. È il punto di raccordo con la documentazione GDPR già esistente e non va duplicato: va collegato.
Le versioni. Quale configurazione è attiva, quale modello, quale corpus documentale, da quando. Senza versionamento è impossibile stabilire se un errore rilevato oggi riguardi anche gli output prodotti tre mesi fa.
I criteri. Le soglie di confidenza, le regole di instradamento, i casi in cui è obbligatoria la conferma umana. Vanno scritti in un linguaggio comprensibile a chi non ha competenze tecniche, perché sono decisioni di governo che si esprimono in parametri.
I casi di scarto. Gli output rifiutati o corretti dagli operatori, con la motivazione. È la documentazione più utile e la più trascurata: alimenta il miglioramento e costituisce l’evidenza che la supervisione umana è effettiva e non nominale.
Gli incidenti. Che cosa è accaduto, quale impatto, quale intervento, quale misura correttiva. Con una definizione preventiva di che cosa costituisce un incidente, altrimenti nulla viene registrato.
Il registro dei sistemi di AI come strumento di lavoro
L’AI Act ha reso il registro un tema noto. Il rischio è che venga compilato come adempimento, tenuto da una funzione e ignorato dalle altre.
Un registro utile risponde a cinque domande per ciascun sistema in uso: a che cosa serve, chi ne è proprietario, quali dati tratta, quale classificazione di rischio ha, quando è stato verificato l’ultima volta.
Il primo esercizio di compilazione produce quasi sempre due risultati non attesi.
Emergono strumenti adottati autonomamente da singoli uffici, non noti alla direzione né alla funzione IT. È l’esito più frequente e il più utile: non si governa ciò che non si conosce.
E si scopre che alcuni sistemi ritenuti critici ricadono nel rischio limitato, mentre altri considerati marginali toccano ambiti più sensibili di quanto si pensasse.
Sul piano normativo va tenuto presente che il quadro è stato modificato di recente. Gli obblighi per i sistemi ad alto rischio dell’Allegato III, originariamente previsti per agosto 2026, decorrono dal 2 dicembre 2027 a seguito delle modifiche introdotte nel luglio 2026, mentre trasparenza, vigilanza e sanzioni sono già applicabili. La qualificazione dei propri sistemi va comunque verificata con la funzione legale sul testo consolidato.
Il rinvio non è una ragione per rimandare il censimento. Sedici mesi sono pochi per un’organizzazione che deve rilevare i sistemi in uso, classificarli, adeguare la documentazione e formare i responsabili.
Come avviare la governance con risorse limitate
Un percorso in quattro passi, sostenibile anche senza strutture dedicate.
Censire i sistemi in uso, inclusi quelli adottati informalmente. Un foglio condiviso è sufficiente per iniziare.
Attribuire un proprietario a ciascuno. Un nome, non una funzione.
Classificare per conseguenza, prima che per tecnologia: che cosa accadrebbe se l’output fosse sbagliato e nessuno se ne accorgesse. È una domanda che chiunque conosca il processo sa affrontare, e produce una graduatoria di priorità immediata.
Definire i controlli solo per i sistemi in cima alla graduatoria. Un controllo effettivo su tre sistemi rilevanti vale più di una procedura formale su venti.
Che cosa la governance non fa
Non rende accurato un sistema inaccurato. Sono verifiche distinte: la governance riguarda ruoli, documentazione e controlli, l’accuratezza si misura sui casi reali.
Non elimina la responsabilità, la rende esplicita e tracciabile. In caso di errore l’organizzazione risponde comunque; con una governance definita può dimostrare quali misure aveva adottato.
Non sostituisce il buon senso operativo. Nessuna procedura copre tutti i casi, e la capacità delle persone di riconoscere una situazione anomala resta il controllo più efficace.
E non funziona se resta un documento. Una governance che non produce revisioni periodiche, registrazioni di scarto e decisioni tracciate esiste solo sulla carta.
In chiusura
La governance dell’AI non è un capitolo separato: è il modo in cui un’organizzazione decide che cosa delegare e con quali garanzie. Costa poco avviarla e molto recuperarla.
Il punto di partenza è un censimento onesto e l’attribuzione di un proprietario a ciascun sistema. Da lì il resto è ordinabile.
Se state affrontando questo tema, siamo disponibili a un confronto su governance e conformità applicate al vostro contesto, a partire dai sistemi già in uso.
