Responsabilità in caso di errore delle applicazioni di AI

Un'applicazione di AI commette un errore. Una decisione non è corretta, un consiglio è fuorviante, un cliente viene respinto a torto. La domanda che segue non è solo tecnica. Chi avrebbe dovuto prevederlo, chi gestiva il sistema, e chi può spiegare perché è stato impiegato nel modo in cui è stato impiegato.

Quella risposta non esiste indipendentemente da un registro. La responsabilità presuppone che qualcuno sappia che un'applicazione esiste, a cosa serve e chi ne è responsabile. Senza questa base, la domanda sulla responsabilità è retorica: non c'è nessuno che lo sa, quindi non c'è nessuno che può spiegarlo.

Cosa risolve un inventario e cosa non risolve

Uno Responsible AI Scan mappa cosa è in funzione, chi lo usa e con quale livello di rischio questo va di pari passo. Questo è un punto di partenza, non un giudizio sulla colpa. La scansione classifica un'applicazione in base al ruolo e al rischio; non valuta se una singola decisione fosse corretta. Quella valutazione appartiene all'incidente stesso, non all'inventario che lo precedeva.

Quello che la scansione fa è fornire la struttura all'interno della quale quella valutazione può essere effettuata in seguito. Se è noto chi ha acquistato un'applicazione, chi la gestisce e per quale scopo è stata approvata, esiste una linea a cui poter fare riferimento. Se questa struttura manca, la domanda sulla responsabilità si riduce a supposizioni a posteriori.

L'elenco IT non è la prassi

La maggior parte delle organizzazioni ha una panoramica del software approvato. Quella panoramica non è quasi mai completa. I dipendenti usano strumenti che nessuno ha registrato, spesso perché il lavoro va più velocemente e nessuno lo ha chiesto. Questo non è per definizione un comportamento irresponsabile; è ciò che accade quando un'organizzazione non offre un'altra via.

Chi vuole sapere cosa viene effettivamente usato, deve chiederlo. E questo funziona solo se chiedere non ha conseguenze. Non appena un dipendente sospetta che una risposta onesta porti a un colloquio correttivo, la risposta si ferma. Cosa fa con i dipendenti che usano uno strumento che nessuno ha approvato parla esattamente di questo meccanismo: l'inventario è tanto buono quanto la fiducia con cui viene raccolto.

A questo si aggiunge anche la domanda su cosa succede alle informazioni aziendali non appena vengono digitate in una finestra esterna. Cosa fa con i dati aziendali in una finestra di chat gratuita descrive un rischio indipendente dalla malafede: qualcuno vuole semplicemente far controllare un testo, e nel farlo digita qualcosa che non avrebbe dovuto.

Dimostrabilità, non garanzia

Un set di governance che segue un inventario stabilisce chi approva un'applicazione, chi ne esercita la supervisione e come questo viene documentato. Questo si collega alla struttura di rischio che un'organizzazione ha già per altri ambiti: gli stessi comitati, le stesse linee di rendicontazione, gli stessi percorsi di escalation. Non nasce un nuovo apparato accanto a quello esistente; si aggiunge una categoria a ciò che già esiste.

Questo produce dimostrabilità: un consiglio di amministrazione può dimostrare che si è guardato, classificato e organizzata la supervisione. Non produce alcuna garanzia che un'applicazione non commetterà mai più un errore. Le due cose sono distinte e la scansione non si esprime sulla seconda. Ciò che offre è una base su cui un consiglio può spiegare cosa è stato fatto, non un'assicurazione contro ciò che potrà ancora accadere.

Perché un secondo processo di solito non regge

Un errore che viene commesso spesso è impostare un processo AI separato, indipendente dalla struttura di rischio e compliance esistente. Quel processo riceve attenzione all'inizio e poi scompare in secondo piano, perché nessuno continua a mantenere un secondo sistema accanto al primo. Perché un secondo processo accanto a quello esistente viene ignorato spiega perché il collegamento con le strutture esistenti non è una questione di efficienza, ma una condizione per far esistere qualcosa.

A questo appartiene anche il fatto che un inventario è un momento, non un punto finale. Nuove applicazioni si aggiungono, quelle esistenti cambiano funzione, e una classificazione corretta al momento della consegna non è automaticamente ancora corretta un anno dopo. Quanto spesso deve riclassificare e come mantiene aggiornato un registro AI descrivono cosa richiede in pratica quella manutenzione, e perché un registro compilato una sola volta non corrisponde più alla realtà entro breve tempo.

Le persone che lavorano con queste applicazioni sono inoltre parte della soluzione, non solo un rischio da gestire. Ciò che i dipendenti capiscono o non capiscono dei sistemi che usano determina se un set di governance significa qualcosa nella pratica. Cosa significa l'alfabetizzazione sull'AI per i suoi dipendenti approfondisce questo aspetto.

La domanda successiva

Chi sa finalmente quali applicazioni di AI sono in funzione e chi ne è responsabile, si trova inevitabilmente di fronte a una domanda successiva: quale parte del lavoro che ora si svolge manualmente è in realtà adatta a essere affidata a un'applicazione di AI. Questa è una domanda diversa dalla responsabilità, ma che si basa sullo stesso inventario. La scansione del lavoro di FTE TO AI calcola per compito quale parte del lavoro può essere assunta dall'AI, come passo successivo dopo che è chiaro cosa è già in funzione e chi ne decide.