La nuova guida di Singapore sull’IA ai consigli di amministrazione: cosa devono fare ora i consiglieri

Questo significa distinguere gli indicatori di performance dai semplici segnali di attività. Il numero di progetti pilota avviati, di licenze acquistate o di dipendenti formati può dimostrare che l’azienda si sta muovendo, ma non prova che un programma di IA stia generando valore. Il consiglio dovrebbe chiedere al management di presentare risultati ottenuti, costi, limiti e rischi insieme ai dati sull’adozione.

Un simile approccio aiuta anche a evitare due errori opposti: approvare esperimenti scollegati, senza un percorso per portarli su scala, oppure frenare applicazioni utili perché nessuno ha definito in anticipo che cosa significhi “successo”. L’attenzione della guida alla strategia, alla scelta dei casi d’uso e ai ritorni economici serve proprio a collegare la spesa per l’IA alle priorità complessive dell’organizzazione.

L’uso informale dei dipendenti deve entrare nel perimetro della governance

I dipendenti potrebbero già utilizzare strumenti di IA o sviluppare flussi di lavoro propri. Secondo la guida, la risposta non dovrebbe essere ignorare queste iniziative, ma trasformare la sperimentazione utile in una capacità organizzativa gestita.

Il consiglio dovrebbe aspettarsi che il management sappia quali strumenti e casi d’uso sono in circolazione, chi ne è responsabile, quali dati trattano e quali controlli si applicano. Tra le considerazioni indicate figurano la documentazione degli strumenti creati con l’IA, la definizione di regole per il loro utilizzo e il rispetto dei requisiti di sicurezza.

In concreto, servono regole aziendali su strumenti autorizzati, informazioni sensibili, responsabilità, monitoraggio e procedure di escalation. È altrettanto importante riconoscere e sviluppare le competenze già presenti nella forza lavoro, invece di considerare l’adozione come un processo imposto esclusivamente dall’alto.

Una strategia priva di un piano per le competenze, di un modello di responsabilità e di una disciplina operativa difficilmente passerà in modo affidabile dalla sperimentazione all’esecuzione.

Tutto il consiglio deve avere una conoscenza sufficiente dell’IA per sfidare il management

La guida considera l’alfabetizzazione sull’IA una competenza del consiglio. Non tutti i consiglieri devono diventare ingegneri del machine learning, ma l’organo nel suo complesso dovrebbe comprendere come l’IA può cambiare settori, modelli operativi, dinamiche competitive, processi decisionali e profili di rischio.

Alcuni consiglieri devono essere in grado di mettere in discussione le ipotesi del management, le stime di valore e le valutazioni dei rischi. Il consiglio dovrebbe inoltre poter contare almeno su una persona — un consigliere, un consulente o un membro di comitato — con una profondità tecnica sufficiente per esaminare scelte relative a sistemi, dati, test e controlli.

È un’impostazione più ambiziosa del semplice affidamento dell’IA a un comitato tecnologico, con aggiornamenti periodici. La tecnologia entra così nella supervisione strategica e fiduciaria del consiglio, senza eliminare la necessità di ricorrere a specialisti quando le questioni tecniche superano le competenze interne.

I diritti decisionali vanno stabiliti prima del lancio

La governance dell’IA diventa concreta quando l’organizzazione stabilisce chi può approvare, gestire, monitorare e fermare un sistema. I consigli dovrebbero richiedere confini decisionali proporzionati al rischio, distinguendo tra:

• decisioni che il management può prendere entro limiti già approvati;
• decisioni che richiedono l’escalation al consiglio o a un comitato;
• decisioni che l’IA non deve prendere autonomamente.

Quanto più gravi sono le possibili conseguenze, tanto più rigorosi devono essere i controlli. Per gli impieghi ad alto impatto in ambito lavorativo — tra cui selezione, promozioni, licenziamenti e valutazioni delle performance — i consigli dovrebbero fissare limiti netti: deve esserci un controllo umano significativo e un responsabile identificabile della decisione finale. L’output di un sistema di IA non dovrebbe trasformarsi in una determinazione automatica e incontestabile sul sostentamento di una persona.

Il principio è coerente con l’aspettativa più ampia secondo cui l’IA dovrebbe assistere, non sostituire silenziosamente, il giudizio umano. Prima che un sistema entri in funzione devono essere quindi chiari il titolare della responsabilità, la soglia di approvazione, il momento del controllo umano e la procedura per interromperlo.

Servono test su equità, qualità dei dati e possibilità di contestazione

Un processo di approvazione responsabile non può fermarsi alla domanda se un modello funzioni bene “in media”. Il consiglio dovrebbe chiedere come l’organizzazione verifica la qualità dei dati, documenta i limiti del sistema, esamina possibili bias e controlla le prestazioni dopo l’implementazione.

Quando un sistema di IA incide in modo rilevante sulle persone, chi subisce la decisione dovrebbe avere un modo concreto per comprenderla, contestarne l’esito e chiedere una revisione umana. Le spiegazioni non devono necessariamente rivelare dettagli tecnici proprietari, ma devono essere sufficienti per consentire una verifica, una responsabilizzazione e un eventuale ricorso.

Si tratta di una componente di un ambiente di controllo più ampio. I materiali di Singapore sulla corporate governance sottolineano l’importanza di decisioni sull’IA trasparenti e responsabili, oltre al rispetto degli standard normativi ed etici. Il compito del consiglio è fare in modo che queste aspettative si traducano in processi documentati, con responsabili ed evidenze verificabili.

L’IA è anche una questione di sicurezza informatica e resilienza operativa

L’IA crea un problema di sicurezza a doppio senso. Le organizzazioni devono prepararsi a phishing, ingegneria sociale, frodi, attacchi automatizzati e individuazione più rapida delle vulnerabilità potenziati dall’IA. Allo stesso tempo, devono proteggere gli stessi sistemi di IA da fughe di dati, prompt injection, manipolazione dei modelli e debolezze introdotte da fornitori o terze parti.

Per questo i rischi legati all’IA dovrebbero comparire nei report sulla resilienza informatica, nelle attività di assurance e nei piani di risposta agli incidenti, non restare confinati in un silo tecnologico. Le domande pratiche includono: chi può disattivare un sistema? Come vengono segnalati gli incidenti? Come si indagano i dati e le decisioni coinvolti? Come recupera l’organizzazione se un servizio di IA diventa indisponibile o viene compromesso?

L’impostazione estende le aspettative già esistenti sulla resilienza informatica e sulla gestione dei rischi. Anche la guida del SID sulla sicurezza informatica considera la resilienza un elemento da integrare nella strategia aziendale, non un compito esclusivamente tecnico.

Per i sistemi critici, i requisiti devono essere più severi

Le conseguenze di un errore dell’IA cambiano molto a seconda del caso d’uso. Uno strumento interno a basso rischio per aumentare la produttività non richiede lo stesso livello di supervisione di un sistema che supporta servizi essenziali, infrastrutture critiche o altre attività ad alto impatto.

In questi contesti, i consigli dovrebbero pretendere requisiti più stringenti per resilienza, sicurezza, test, monitoraggio, escalation e ripristino. Un guasto o una compromissione potrebbero infatti andare oltre le perdite finanziarie o reputazionali immediate dell’organizzazione, arrivando a interrompere servizi importanti o produrre conseguenze operative più ampie.

L’approccio basato sul rischio evita di trattare ogni applicazione di IA allo stesso modo. Chiede invece di commisurare poteri e controlli al possibile impatto di un guasto.

Un cruscotto pratico per il consiglio

Le raccomandazioni della guida possono essere tradotte in un registro o cruscotto dedicato ai casi d’uso rilevanti. Per ogni applicazione significativa, il management dovrebbe poter indicare:

1. Il responsabile, cioè la persona accountable per il sistema e i suoi risultati.
2. Il risultato aziendale atteso, con il metodo per misurare il successo.
3. I diritti decisionali e le soglie di escalation.
4. Le fonti dei dati e le regole di trattamento applicate.
5. La classe di rischio e le motivazioni della sua assegnazione.
6. I controlli, comprese le verifiche su sicurezza, equità e qualità dei dati.
7. Il punto di supervisione umana e la persona responsabile della decisione finale.
8. I risultati dei test e del monitoraggio, inclusi i limiti noti.
9. Gli incidenti, i reclami o i ricorsi e il modo in cui sono stati risolti.
10. La data della prossima revisione o l’evento che la rende necessaria.

Questa struttura mette nello stesso documento creazione di valore e gestione del rischio. Offre inoltre ai consiglieri elementi concreti da esaminare, invece di costringerli a fare affidamento su dichiarazioni generiche secondo cui l’organizzazione starebbe “usando l’IA in modo responsabile”.

La conclusione per i consiglieri

La guida del SID non presenta l’adozione dell’IA e la sua governance come due obiettivi in conflitto. Chiede ai consigli di perseguire applicazioni utili con la stessa disciplina riservata agli altri investimenti strategici rilevanti: definire il valore, assegnare le responsabilità, comprendere i rischi, testare i controlli e verificare i risultati.

Il passo immediato per i consiglieri è portare l’IA nell’agenda ordinaria del consiglio, esaminare i casi d’uso più rilevanti e individuare eventuali lacune in competenze, responsabilità, diritti decisionali, supervisione umana, test e resilienza.

La strategia migliore non è quella che genera più attività. È quella che il consiglio sa spiegare, misurare e governare.