Prima del rollout, il consiglio di amministrazione dovrebbe vedere cinque cose nero su bianco: quali flussi di lavoro toccherà l'AI, chi ne approva l'output, cosa viene registrato, quale framework di rischio segue la valutazione e come l'azienda ferma un flusso di lavoro. Insieme formano un piano di governance sintetico che il management mantiene aggiornato, non una policy scritta una volta e archiviata.
#Punti chiave
- La governance parte da un inventario: il CdA non può supervisionare un'AI di cui non conosce l'esistenza.
- Ogni flusso di lavoro richiede una persona indicata per nome che approva l'output dell'AI e può correggerlo.
- I log devono permettere a un revisore di ricostruire cosa ha fatto il sistema, con quali input e chi lo ha approvato.
- Indicate un framework riconosciuto, come il NIST AI Risk Management Framework o la ISO/IEC 42001, così il CdA non deve valutarne uno fatto in casa.
- Le aziende regolamentate rispondono anche alle proprie autorità di settore, le cui regole si aggiungono a quelle generali.
#Quale governance deve essere in atto prima del rollout dell'AI?
- Un inventario di ogni flusso di lavoro in cui l'AI produce o modifica qualcosa, compresi gli strumenti che il personale usa di propria iniziativa.
- Un approvatore indicato per nome per ogni flusso di lavoro, con l'autorità di respingere o correggere l'output.
- Una valutazione del rischio per ogni flusso di lavoro rispetto a un framework dichiarato, conservata insieme all'inventario.
- Una registrazione di input, output, versioni del modello e approvazioni.
- Un interruttore di spegnimento: chi può fermare un flusso di lavoro, come, e cosa fa il team a mano mentre è fermo.
- Una data di revisione fissata dal CdA, in cui inventario e valutazioni vengono ricontrollati.
È l'elenco che Stennir inserisce in ogni incarico di consulenza. Abbiamo spiegato il perché in perché consegniamo un piano di governance con ogni incarico di consulenza.
#Su quali framework di rischio dovrebbe informarsi il CdA?
Due sono ampiamente utilizzati. Il NIST AI Risk Management Framework considera la supervisione umana e la responsabilità parte della gestione del rischio AI (NIST, gennaio 2023). La ISO/IEC 42001 è lo standard internazionale per un sistema di gestione dell'AI (ISO, dicembre 2023), rispetto al quale un'azienda può essere certificata.
Sul fronte della sicurezza, la OWASP Top 10 for LLM Applications mette al primo posto la prompt injection: il testo di un cliente o di un documento può tentare di cambiare ciò che fa il modello. Il CdA non ha bisogno dei dettagli tecnici, solo della conferma che qualcuno lo abbia testato su ogni flusso di lavoro.
#Cosa cambia per un'azienda finanziaria regolamentata?
Le autorità di settore, come SAMA e NCA, fissano regole proprie: verificatele. Si aggiungono alla normativa generale sulla protezione dei dati, quindi un flusso di lavoro che supera una revisione generale può comunque richiedere di più per una banca o un'assicurazione. Chiedete alla funzione compliance di confrontare ogni flusso di lavoro con i requisiti pubblicati dall'autorità prima di usare qualsiasi dato dei clienti.
Questo articolo non costituisce consulenza legale o regolamentare; verificate con i vostri legali e la funzione compliance. Ciò che Stennir aggiunge è il dettaglio del flusso di lavoro di cui hanno bisogno per decidere: i dati che ogni passaggio tocca, dove vengono trattati, chi approva il risultato e cosa viene registrato.
#Cosa registrare per verificare cosa ha fatto un sistema AI?
- L'input ricevuto dal sistema, o un riferimento a esso se non è consentito conservare il testo completo.
- Il modello e la versione, e la versione delle istruzioni che ha ricevuto.
- I documenti o i record recuperati per produrre la risposta.
- L'output prodotto, prima di qualsiasi modifica umana.
- Chi lo ha approvato, modificato o respinto, con data e ora.
- Cosa è successo dopo nel sistema a valle, ad esempio un record aggiornato o un messaggio inviato.
Con questi sei elementi, un revisore può ricostruire qualsiasi decisione a posteriori. Senza la riga dell'approvazione, nessuno può dire chi era responsabile quando qualcosa va storto.
We are
Stennir inserisce inventario, approvatori, registrazione e interruttore di spegnimento in ogni flusso di lavoro prima che entri in funzione, e lascia a voi la proprietà di account, log e interruttore.
We aren't
Stennir non è uno studio legale né un ente di certificazione e non sostituisce la vostra funzione compliance o la revisione della vostra autorità di vigilanza.
#Cosa dovrebbe fare ora un CdA o un comitato rischi?
Chiedete prima al management l'inventario: ogni punto in cui l'AI tocca già il lavoro, compresi gli strumenti adottati dal personale di propria iniziativa. Poi chiedete un approvatore e un progetto di registrazione per ciascuno. La consulenza AI produce entrambi, e AI per la compliance mostra come funzionano i flussi di revisione. Fate la valutazione di prontezza gratuita oppure prenotate una chiamata di 30 minuti.
#Domande frequenti
Il CdA deve approvare ogni flusso di lavoro AI?
No. Il CdA approva il piano di governance e la propensione al rischio, e vede l'inventario. Il management approva i singoli flussi di lavoro entro quelle regole. Il CdA va informato quando un flusso di lavoro tocca dati dei clienti, prende una decisione su una persona o ricade sotto un'autorità di settore, perché sono i casi a più alto rischio.
Chi approva ciò che l'AI produce?
Una persona indicata per nome nell'area di business che già è responsabile di quel lavoro, come il responsabile del team sinistri o del team finance. Può respingere o correggere qualsiasi output e la sua decisione viene registrata. Stennir non assume quel ruolo, perché la responsabilità deve restare all'interno della vostra azienda.
Cosa resta a noi?
Tutto ciò che conta per un audit: gli account, i dati, i log, le istruzioni date al modello e l'interruttore di spegnimento. Stennir li configura a vostro nome. Se smettete di lavorare con noi, i log e la documentazione di governance restano leggibili dal vostro team e dai vostri revisori.
Cosa potrebbe andare storto?
Gli errori tipici sono un inventario che non include gli strumenti adottati dal personale di propria iniziativa, approvazioni che diventano un clic senza un vero controllo e log che registrano l'output ma non chi lo ha approvato. Ciascuno è facile da individuare con un audit di prova prima del rollout, e molto più difficile da spiegare dopo.
