Numerosi ricercatori di intelligenza artificiale hanno fatto tesoro delle lezioni imparate in un altro campo dell’informatica: quello della cybersecurity.
Nella sicurezza informatica ormai da molti anni vi sono interi settori dove procedure come gli audit del codice eseguiti da aziende terze, attacchi in condizioni di sicurezza condotti da cosiddetti “red team” e – non ultime – iniziative di “bug bounty” (veri e propri concorsi dove chiunque può partecipare per scoprire bug software) sono la normalità.
Ed è proprio questa mentalità che, secondo gli autori di un documento pubblicato in questi giorni su Arxiv, farebbe bene anche al settore dell’intelligenza artificiale. Il mondo, l’industria, ma soprattutto la società civile chiede con sempre maggiore insistenza che i sistemi AI siano affidabili, robusti e sicuri.
Concetti che non si limitano alla resistenza agli attacchi hacker o ai bug, anche se questo fa ovviamente parte delle richieste, ma che includono anche l’assenza di bias, di squilibri di qualsiasi genere che rendono il sistema di intelligenza artificiale poco affidabile.
I bias possono annidarsi ovunque, basti pensare a un software AI che favorisce solo una parte della popolazione, come quelli usati in molti ospedali degli Stati Uniti che assegnavano cure prioritarie ai pazienti bianchi, per fare un esempio su tutti.
Rientrano nei casi in esame ovviamente anche i bug e i difetti di programmazione, come quello che nel 2018 portò un’auto a guida autonoma di Uber a non riconoscere una donna che attraversava la strada con la sua bicicletta, investendola e uccidendola.
Ma poiché questi errori sono spesso evasivi, sfuggenti, non tutti gli sviluppatori di progetti AI hanno la giusta dotazione (formazione, tempo, procedure e software adeguati, per non parlare della forma mentis) per accorgersene mentre realizzano il sistema, o per scorgerli quando preparano il dataset. O magari per individuarli una volta che il sistema è in produzione e usato dal pubblico.
Ecco quindi che qualcosa di sbagliato passa, si insinua, forse un errore o semplicemente la mancanza di una protezione, con il potere non solo di distruggere il sistema creato con tanta fatica (qualcuno si ricorderà di Tay, il chatbot di Microsoft che dopo poche ore su Twitter si trasformò in un ripetitore di insulti misogini e nazisti) ma anche di abbassare la fiducia del pubblico nei sistemi di intelligenza artificiale. Senza contare che per molte persone vedere un computer che sbaglia è fonte di grande soddisfazione, e storie dove sistemi AI sputano risultati comici o irrazionali sono ovunque su Internet.
La soluzione per questi ricercatori, fra i quali vi sono molte firme eccellenti e organizzazioni di primo piano come OpenAI, Mila, Intel, Google oltre che diverse università, è quella di condurre bug bounty, attacchi di redteam, audit esterni, adottando inoltre procedure di condivisione degli incidenti.
Per quest’ultima possibilità Partnership on AI (una coalizione di aziende fra cui Amazon, Facebook, Microsoft, IBM, Google, Apple, Baidu) si è messa avanti creando l’AI Incident Registry.
Una soluzione che potrebbe funzionare. Chi scrive viene da trent’anni di esperienza nella sicurezza informatica e sappiamo bene come la sicurezza venga spesso vista come un ostacolo alla semplicità, all’immediatezza, un inutile girare intorno là dove molti andrebbero semplicemente in linea retta.
Con product manager, supervisori, capi di tutti i livelli che premono per fare in fretta, spesso gli sviluppatori sono disincentivati a inserire meccanismi di protezione che prendono tempo, vanno testati, e nel migliore dei casi non faranno mai parlare di sé, perché un attacco impedito da una misura di sicurezza non fa notizia. In troppe aziende il concetto di security by design resta una chimera, e dove esiste è solo perché imposto da pressioni esterne (leggi, regolamenti, gare, ecc).
Ecco quindi che il ricorso a team esterni e a concorsi di bug hunting per testare la sicurezza di una tecnologia ha senso, primo perché l’interesse esclusivo di chi partecipa sarà trovare bug e vulnerabilità, senza essere distratti da altri fattori come tempi di consegna, nuove features o gli impliciti desiderata dei capi. Secondo perché chi sceglie una carriera nel redteaming ha la formazione e l’esperienza adeguata a trovare falle, conseguenze indesiderate di una funzione, sequenze improbabili che portano a errori mai riscontrati prima.
A volte in buona fede, come quando in un ospedale di Chicago tolsero dai fattori decisionali qualsiasi riferimento alla razza dei pazienti, ma poiché la città aveva molti quartieri dalla composizione razziale ben definita (quartieri di bianchi e quartieri di neri) il bias razziale riuscì a insinuarsi lo stesso attraverso il codice postale: l’AI dava priorità ai residenti dei quartieri bianchi a scapito dei residenti dei quartieri neri. Per fortuna in quel caso il team dell’ospedale si accorse dell’errore in tempo.
Soluzioni aggressive come gli esercizi di red team o creative come i bug bounty potrebbero consentire alle aziende e ai laboratori di ricerca di gettare luce sui cosiddetti “unknown unknowns“, i problemi che non si sa di avere, prima che questi raggiungano il pubblico.
Sistemi di intelligenza artificiale più solidi, equi e sicuri faranno nascere meno “storie dell’orrore” come quella dell’auto autonoma che uccide i pedoni, dell’intelligenza artificiale usata dalle corti statunitensi che assegna pene carcerarie più severe ai neri rispetto ai bianchi, o dell’AI ospedaliera che complica la vita a chi abita in un quartiere povero.
L’intelligenza artificiale con meno errori e meno bias aumenterà la fiducia dei cittadini e contribuirà a una sua più rapida accettazione da parte della società.
Il documento Toward Trustworthy AI Development: Mechanisms for Supporting Verifiable Claims è disponibile qui (pdf).