Chi deve essere formato e su cosa: la matrice ruoli-competenze per l'AI

In sintesi. Un piano di formazione AI costruito per reparto forma due volte alcune persone e ne lascia scoperte altre. La clausola 7 di ISO/IEC 42001 chiede competenze legate al ruolo, e per la maggior parte delle organizzazioni bastano tre livelli: chi governa e approva, chi possiede il rischio di un sistema specifico, chi usa gli strumenti nel lavoro quotidiano. La matrice ruoli-competenze collega ogni ruolo a ciò che deve saper fare, al formato della formazione, all'evidenza da conservare per l'audit e alla frequenza di aggiornamento.

Dopo aver capito che la clausola 7 chiede più di un corso uguale per tutti, molte aziende passano a percorsi diversi ma continuano a decidere i contenuti per dipartimento. Capita così che un responsabile di processo e un addetto dello stesso ufficio seguano lo stesso corso, anche se rispetto al sistema AI uno decide e l'altro esegue, mentre persone di altri reparti che firmano valutazioni di rischio restano fuori dal percorso giusto.

Il criterio che funziona guarda a ciò che la persona deve decidere o fare rispetto a un sistema specifico, e l'organigramma diventa un dato di partenza da incrociare con l'inventario.

I livelli di competenza

Il board e l'alta direzione approvano l'adozione dei sistemi, accettano i rischi residui e rispondono delle scelte davanti a soci e autorità. I risk owner sono le persone a cui è assegnato il rischio di un sistema preciso, tengono aggiornata la valutazione e avviano l'escalation quando qualcosa cambia. Gli utenti operativi usano gli strumenti ogni giorno, e sono il punto in cui un errore del sistema diventa un errore del processo.

Ogni livello richiede una profondità diversa, e un corso unico annoia il primo gruppo e lascia impreparato il terzo, e nessuno dei due problemi emerge finché un auditor non comincia a fare domande.

La matrice

Ruolo	Cosa deve saper fare	Formato	Evidenza per l'audit	Aggiornamento
Board e alta direzione	Leggere un rating AI, chiedere perché un rischio è stato accettato, capire le responsabilità legate all'approvazione	Sessione di alcune ore su casi aziendali	Verbale con domande poste e decisioni prese	Annuale e a ogni nuovo sistema ad alto rischio
Risk owner	Condurre e aggiornare la valutazione del rischio, riconoscere un cambiamento sostanziale, attivare l'escalation	Laboratorio operativo sui sistemi in inventario	Valutazioni firmate e aggiornate, escalation registrate	A ogni modifica del sistema e almeno una volta l'anno
Utenti operativi	Riconoscere quando un output richiede verifica, sapere a chi segnalare un'anomalia	Moduli brevi nel contesto dello strumento	Registro di partecipazione collegato al ruolo, verifica pratica	All'adozione e a ogni cambio di versione
Funzioni di controllo	Verificare la coerenza tra inventario, rischi e controlli	Percorso tecnico e normativo	Piano di audit interno e rapporti	Annuale
Contractor con accesso ai sistemi	Rispettare procedure e limiti d'uso definiti	Clausole contrattuali e briefing	Accettazione documentata	A ogni rinnovo del contratto

Il board

Chi siede in consiglio non deve saper leggere un modello, deve saper leggere un rapporto di rating AI e chiedere perché un certo rischio è stato accettato invece che mitigato, con la consapevolezza di cosa comporta firmare un'approvazione senza aver posto quella domanda. La formazione a questo livello dura ore e si misura sulla qualità delle domande che il board pone nelle riunioni successive, più che sui minuti di corso completati.

I risk owner

Un risk owner non può limitarsi a firmare una valutazione preparata da un consulente esterno. Deve riconoscere quando il sistema che possiede è cambiato abbastanza da richiedere un'analisi nuova, per esempio dopo un aggiornamento del modello o un'estensione a una nuova categoria di utenti, e deve sapere come attivare l'escalation prima che il problema emerga da solo. Qui la formazione lavora sui sistemi presenti nell'inventario aziendale, perché gli esempi generici non preparano a riconoscere i segnali del proprio contesto.

Gli utenti operativi

L'operatore che usa uno strumento assistito dall'AI ha bisogno di sapere quando un output richiede una verifica umana prima di procedere e a chi segnalare un comportamento anomalo, con esempi presi dal suo lavoro. È il livello più numeroso e spesso il più trascurato, anche se è quello a contatto quotidiano con l'errore reale.

Un esempio ipotetico

Una compagnia assicurativa con quattro sistemi AI in inventario, tra cui uno che assiste la valutazione dei sinistri, costruisce la matrice incrociando l'organigramma con l'elenco dei sistemi. Il responsabile liquidazioni, che in un piano per reparto avrebbe seguito il corso degli utenti, risulta risk owner del sistema sui sinistri e passa al laboratorio sulla valutazione del rischio, mentre i liquidatori del suo team ricevono moduli brevi sulla verifica degli output e sulla segnalazione delle anomalie. L'esempio è illustrativo e non descrive un caso reale.

Errori da evitare

• Assegnare i contenuti in base al reparto senza guardare al ruolo rispetto al sistema.
• Trattare il board come destinatario secondario perché la sua formazione è breve.
• Dimenticare i contractor che operano sui sistemi.
• Registrare la presenza senza collegarla al ruolo ricoperto.
• Costruire la matrice una volta e non aggiornarla quando cambiano persone o sistemi.

Il passo successivo

La matrice parte dall'elenco dei sistemi e dei ruoli che li toccano, e il metodo per costruirlo è nella guida all'inventario dei sistemi AI, mentre i requisiti completi della clausola 7 sono descritti in la clausola 7 di ISO/IEC 42001 spiegata senza gergo.

L'approccio con cui impostiamo i percorsi per ruolo è descritto nella pagina AI Training. Per costruire la matrice sulla tua organizzazione puoi fissare un incontro di valutazione.