La governance responsabile dell’IA non dovrebbe iniziare — tanto meno finire — con la conformità legale
Negli ultimi tempi, i clienti hanno cominciato a porre una versione della stessa domanda: “Se il nostro sistema non è considerato ‘ad alto rischio’ secondo il Regolamento sull’intelligenza artificiale dell’UE o il Colorado AI Act, perché dovremmo fare qualcosa al riguardo?”
L’assunzione è che il rischio sia quello che le normative definiscono — e solo quello. Ma questa visione è ristretta, non sicura per i consumatori e dannosa per le aziende.
Il contesto della governance dell’IA
Molti anni fa, le aziende iniziavano a implementare modelli predittivi di IA sempre più complessi nelle loro operazioni e servizi. Le aziende faticavano a comprendere questi sistemi — come valutare i rischi coinvolti e come gestirli per trarne beneficio senza arrecare danno ai clienti, imbarazzi pubblici o responsabilità legali.
In quel periodo di incertezza, molti avvocati e scienziati dei dati, nonché accademici e altri professionisti, si sono messi al lavoro per definire cosa potesse significare una governance responsabile dell’IA. Alcuni di loro hanno collaborato a un progetto con il National Institute of Standards and Technology (NIST), dando vita al Framework di gestione del rischio dell’IA.
Sebbene non sia uno standard di conformità, questo framework è diventato il riferimento nella gestione dell’IA, almeno negli Stati Uniti. Un framework simile, basato sul rischio, è stato sviluppato a Singapore; l’Organizzazione Internazionale per la Standardizzazione ha elaborato uno standard specifico per la governance responsabile dell’IA.
Rischio e governance
Tutti questi sistemi offrono alle aziende un modo per valutare il rischio connesso all’uso di qualsiasi sistema. Sebbene riconoscano che i requisiti legali dovrebbero essere un fattore in tale valutazione, nessuno inizia o finisce lì.
In termini semplificati, questa sequenza storica ha fornito alle aziende un modo per gestire i rischi dell’IA in modo strutturato e completo. Come riconosce il NIST AI RMF, “Le pratiche di IA responsabile possono aiutare ad allineare le decisioni riguardanti la progettazione, lo sviluppo e l’uso dei sistemi di IA con gli obiettivi e i valori previsti”.
Il rischio è definito come la probabilità che si verifichi un danno identificato moltiplicata per la gravità del danno se si verificasse. Sebbene gli impatti legali siano parte della misura della “gravità”, non sono tutto. Ogni azienda deve valutare il rischio di ogni sistema di IA in modo indipendente, basandosi sulla propria industria, valori, obblighi aziendali e requisiti normativi.
Il pensiero limitato alla conformità
Due leggi chiave, il Regolamento sull’intelligenza artificiale dell’UE e il Colorado AI Act, seguono questo approccio basato sul rischio. Poiché sono leggi e devono avere un ambito definito, queste leggi tracciano linee chiare attorno a determinati casi d’uso “ad alto rischio”. Queste linee sono utili, ma non esaustive.
Le leggi si concentrano su categorie che i regolatori danno priorità e fanno rispettare. Non tentano di affermare che queste categorie siano l’estensione totale dei rischi che le aziende possono affrontare utilizzando altri sistemi di IA. Le fonti di esposizione aziendale vanno oltre: decisioni sbagliate, modalità di fallimento trascurate, impatti distorti, affermazioni ingannevoli, incidenti di sicurezza evitabili, perdita di fiducia dei clienti e altri rischi di contenzioso che non dipendono dall’IA presente nella normativa.
Tipologie di sistemi che meritano attenzione
La tolleranza al rischio è intrinsecamente soggettiva e determinata dalle singole aziende, anche quelle nello stesso settore. Così è anche la mitigazione del rischio: possono trasferire il rischio, assicurarsi contro di esso o rivedere il contesto in qualche modo.
Il punto dell’approccio alla gestione del rischio è che le aziende devono determinare quali siano i potenziali danni derivanti da un dato sistema di IA utilizzando i propri criteri selezionati, strutturati e stabiliti — e quindi valutare i rischi legati all’implementazione di quel sistema.
Si vedono esempi di questi sistemi ogni giorno con i clienti.
Strumenti per il feedback dei dipendenti, le prestazioni e il coaching. Potrebbero non essere necessariamente parte di una decisione lavorativa significativa da attivare leggi sull’IA o sul lavoro, ma influenzano le valutazioni e le opportunità. Le aziende possono stare certe che i dipendenti osserveranno questi strumenti per risultati scarsi, ingiusti o inaffidabili.
Strumenti per la valutazione del sentiment dei clienti e della qualità. Questi strumenti possono influenzare la compensazione dei dipendenti, guidare decisioni sul personale, decidere l’escalation per determinati casi e informare più in generale la strategia aziendale. Se sono inaccurati o incoerenti, possono portare a dipendenti scontenti, cattive decisioni aziendali e ridotta fiducia dei clienti.
Chatbot a contatto con i clienti. Sebbene la maggior parte dei chatbot non sia probabilmente considerata ad alto rischio secondo le leggi sull’IA, un chatbot che produce contenuti tossici o pericolosi frustrerà i clienti e attirerà attenzioni indesiderate, come screenshot virali. Dichiarazioni infondate da parte di un chatbot sulla propria azienda o affermazioni denigratorie sui concorrenti possono persino portare a controlli normativi e rischi di contenzioso.
Un approccio pratico alla governance informata dal rischio
È vero che non ogni sistema necessita di “tutte” le prove, la supervisione e la documentazione. Questo non sarebbe fattibile per alcuna azienda. Per sviluppare un processo di governance semplice che vada oltre le categorie legali ad alto rischio, è possibile immergersi in uno dei framework menzionati o partire dalle basi.
Per prima cosa, valutare il livello di rischio per il sistema. Definire l’intero caso d’uso per il contesto e determinare cosa sia in gioco identificando chi è coinvolto, quali decisioni sono influenzate e quale potrebbe essere il peggior esito possibile.
Considerare l’esposizione normativa se rientra già in una categoria ad alto rischio statutaria, ma anche l’esposizione aziendale. Potrebbe causare danni materiali, pregiudizi, danni reputazionali o interruzioni operative? Questa triage iniziale del rischio consente alle aziende di assegnare risorse in modo appropriato.
In sintesi:
- I sistemi a basso rischio richiedono test funzionali di base e documentazione che delinei il loro uso previsto e i limiti.
- I sistemi a medio rischio dovrebbero subire test di prestazione e monitoraggio, includere controlli mirati di equità e avere un piano di rollback in atto.
- I sistemi ad alto rischio richiedono una validazione pre-distribuzione estesa, esercizi di red teaming, controlli umani, test regolari post-distribuzione e monitoraggio continuo, un piano di risposta agli incidenti stabilito e meccanismi di revisione indipendenti.
Successivamente, dimostrare che funziona. Ci sono schede modello e altri approcci disponibili, ma tutti affrontano sostanzialmente gli stessi contenuti. Documentare quali dataset sono stati utilizzati, protocolli di test, metriche, risultati a livello di coorte, limitazioni note e mitigazioni accettate o rinviate — con motivazione. Stabilire soglie di deriva delle prestazioni accettabili e attivatori di incidenti.
Comunicare onestamente. Rivelare capacità e limiti agli utenti e ai decisori; evitare affermazioni esagerate; e allineare il marketing con la realtà tecnica. Rivalutare ad ogni cambiamento o aggiornamento importante. Un nuovo modello, una nuova fonte di dati o un nuovo contesto significa una nuova revisione del rischio.
Funziona “in modo equo?” Questa non è solo una questione legale di discriminazione. Esiti iniqui possono verificarsi in base a qualsiasi fattore o caratteristica, non solo quelli protetti dalla legge sui diritti civili. In entrambi i casi, le priorità operative e reputazionali dell’organizzazione saranno influenzate tanto quanto la conformità.
Definire i gruppi rilevanti per il contesto del sistema particolare — ad esempio, geografia, anzianità, lingua, tipo di dispositivo e classi protette quando appropriato e lecito per la valutazione. Confrontare le distribuzioni degli errori e dei risultati tra questi gruppi utilizzando metriche corrispondenti al compito, come precisione/richiamo, tassi di falsi positivi/negativi e calibrazione.
Documentare chiaramente i compromessi. Se migliorare il richiamo aumenta i falsi positivi, spiegare perché l’azienda accetta quel compromesso in questo caso d’uso e come verrà monitorato.
E infine, aggiungere una revisione umana dove appropriato. Ciò significa assegnare responsabilità chiare e rendere il revisore responsabile, non un semplice timbro di approvazione.
Conclusione
Le leggi sulla governance dell’intelligenza artificiale creano determinate categorie in cui la valutazione, il testing e la documentazione sono obbligatori. Sono certamente importanti. Ma queste soglie non possono definire l’atteggiamento complessivo al rischio di un’azienda che costruisce, acquista o opera l’IA in modi integrali alle sue operazioni.
La migliore prassi per qualsiasi sistema significativo rimane, per i modelli di IA come per qualsiasi altra cosa, dimostrare che funziona per il suo uso previsto, monitorarlo nel mondo reale e risolvere i problemi prima che diventino danni.
La necessità di comprendere dove e come questi sistemi influenzano le loro operazioni complessive non è cambiata. Sebbene ora ci siano leggi che si applicano in modo più diretto, queste dovrebbero essere viste come un’aggiunta ai requisiti di governance, non come un loro sostituto.
Gli dirigenti aziendali di tanto in tanto preferiscono rispondere ai costi di ritardo, ai costi di errore e ai costi di rimedio sotto forma di prevenzione. La governance non è una burocrazia inutile; è il modo per muoversi più velocemente senza rompere le cose che contano.
