Il fascicolo di approvvigionamento è il sistema di governance

Di Heather Grizzle, Novara Consulting Group

Sintesi esecutiva

La governance dell'intelligenza artificiale si esprime sempre più attraverso politiche, comitati, principi, inventari e classificazioni del rischio. Queste strutture sono importanti. Ma quando un'istituzione pubblica acquista e implementa effettivamente un sistema di IA, la governance deve a un certo punto diventare qualcosa di molto meno astratto. Deve diventare un documento.

Qualcuno deve descrivere cosa il sistema può fare. Qualcuno deve decidere quali prove siano sufficienti a sostenere le affermazioni del fornitore. Qualcuno deve identificare le persone che potrebbero subire un danno se il sistema fallisce. Qualcuno deve stabilire quali guasti richiedono l'intervento umano, quali cambiamenti richiedono una rivalutazione e quali condizioni richiedono la sospensione del sistema. Se queste decisioni non vengono documentate prima dell'implementazione, una politica di governance dell'IA non colma l'omissione. Il fascicolo di approvvigionamento è il luogo in cui i principi istituzionali diventano impegni operativi.

La governance deve alla fine raggiungere la transazione

Una soluzione di riserva è una garanzia solo se la persona che ne ha bisogno può effettivamente utilizzarla.

Heather Grizzle

Le organizzazioni stanno costruendo strutture di governance dell'IA sempre più sofisticate. Stabiliscono principi di IA responsabile, creano comitati di revisione, mantengono inventari e classificano i sistemi in base al rischio. Adottano politiche che richiedono equità, trasparenza, responsabilità, privacy, accessibilità e supervisione umana. Poi inizia l'approvvigionamento. Un fornitore risponde a un bando. Vengono programmate dimostrazioni del prodotto. Viene raccolta la documentazione sull'accessibilità. Vengono completati i questionari sulla sicurezza. Vengono negoziati i termini legali. I responsabili aziendali descrivono le efficienze che si aspettano. La tecnologia supera i controlli stabiliti dall'istituzione ed entra in servizio.

L'esistenza di questi controlli può generare una notevole fiducia istituzionale, ma la fiducia non è la stessa cosa di una decisione difendibile. La domanda cruciale per la governance non è semplicemente se il sistema abbia superato il processo richiesto. È se il documento risultante contenga le prove necessarie a giustificare la specifica implementazione approvata.

Questa distinzione diventa particolarmente importante quando l'IA media l'accesso per le persone con disabilità. Un sistema può riassumere informazioni, comunicare con i pazienti, valutare i candidati, tradurre una lingua, generare materiale didattico, dare priorità ai casi, assistere i dipendenti, autenticare gli utenti, rispondere a domande o, sempre più spesso, agire per conto di un'istituzione. In ogni caso, l'accessibilità non è semplicemente una caratteristica dell'interfaccia. È parte dell'architettura decisionale. Una persona con disabilità può interagire con un sistema in modo diverso rispetto alla popolazione per cui è stato principalmente progettato, testato o convalidato, e un guasto di accessibilità può alterare le informazioni che quella persona riceve, le scelte a sua disposizione, la sua capacità di rispondere o l'interpretazione del suo comportamento da parte dell'istituzione. Il documento di approvvigionamento deve quindi stabilire più del semplice fatto che l'accessibilità sia stata considerata. Deve stabilire cosa è stato considerato, cosa è stato testato, cosa rimane sconosciuto e cosa l'istituzione ha deciso di fare riguardo all'incertezza.

Il fascicolo di approvvigionamento come strumento di responsabilità

I fascicoli di approvvigionamento sono spesso intesi principalmente come documenti amministrativi. Per l'IA, dovrebbero essere sempre più intesi come strumenti di governance. Un documento maturo di approvvigionamento dell'IA dovrebbe consentire a un revisore indipendente di ricostruire il ragionamento dell'istituzione senza fare affidamento sulla memoria istituzionale delle persone che hanno partecipato all'acquisto. Ciò significa che il documento dovrebbe rispondere a diverse domande:

1. Cosa esattamente è stato acquistato il sistema per fare?
2. Cosa gli era esplicitamente vietato fare?
3. Quali popolazioni si prevedeva lo avrebbero incontrato?
4. Quali prove sostenevano le affermazioni su cui si è basata l'approvazione, e chi ha prodotto tali prove?
5. Quali limitazioni erano note e quali limitazioni rimanevano sconosciute?
6. Cosa succedeva quando il sistema era incerto o sbagliava?
7. Chi manteneva l'autorità di annullare le sue decisioni?
8. In che modo una persona interessata poteva contestare il suo output?
9. Cosa avrebbe indotto l'istituzione a riconsiderare l'implementazione?
10. Chi aveva l'autorità di fermarlo?

Queste non sono domande per l'indagine sull'incidente dopo un guasto. Sono domande di approvvigionamento.

1. Uso previsto e uso vietato

Il primo requisito è ingannevolmente semplice: definire cosa l'istituzione sta acquistando. I sistemi di IA vengono spesso acquistati tramite descrizioni di capacità generiche. Un sistema può essere descritto come un assistente, un traduttore, uno strumento di accessibilità, un sistema di supporto decisionale, un chatbot, un agente, uno strumento di screening o una piattaforma di produttività. Queste etichette sono specifiche di governance inadeguate. Il documento di approvvigionamento dovrebbe identificare la funzione istituzionale effettiva.

Uno strumento di comunicazione utilizzato per aiutare qualcuno a navigare in un sito web presenta un rischio diverso rispetto alla stessa tecnologia utilizzata durante l'accettazione medica. Un sistema di trascrizione automatica utilizzato per generare verbali di riunioni presenta un rischio diverso rispetto a uno utilizzato per creare il verbale ufficiale di un procedimento disciplinare. Un sistema di riconoscimento della lingua dei segni utilizzato sperimentalmente da un individuo non equivale a uno che un'istituzione presenta come sostituto di un altro mezzo di accesso alla comunicazione. La stessa tecnologia può quindi spostarsi tra categorie di rischio senza alcun cambiamento nel suo modello sottostante, perché il contesto di implementazione è cambiato.

2. Analisi della popolazione interessata

L'approvvigionamento tecnologico tradizionale chiede chi utilizzerà il sistema. La governance dell'IA deve anche chiedere chi ne sarà interessato, e queste popolazioni non sono necessariamente le stesse. Un dipendente può utilizzare un sistema di IA mentre un paziente, uno studente, un candidato, un residente, un cliente o un beneficiario di prestazioni ne subisce le conseguenze. Le persone con disabilità possono essere particolarmente difficili da identificare attraverso l'analisi convenzionale degli utenti, perché la disabilità modifica spesso il percorso attraverso un sistema piuttosto che la categoria nominale di utente.

Il documento di approvvigionamento dovrebbe quindi identificare le interazioni di accessibilità prevedibili. Il sistema elabora il parlato? Genera o interpreta il linguaggio? Dipende dalla vista, dall'udito, dalla destrezza, dalla cognizione, dai tempi, da caratteristiche biometriche o da una particolare modalità di comunicazione? Deduce intenzioni o competenze da comportamenti che la disabilità potrebbe influenzare? Un output inaccessibile altera la capacità di una persona di partecipare a una decisione successiva? Queste domande trasformano l'accessibilità da un artefatto di conformità a un'indagine sul rischio del sistema.

3. Il registro delle affermazioni del fornitore

Ogni affermazione rilevante del fornitore su cui ci si è basati durante l'approvvigionamento dovrebbe avere uno stato probatorio. Non tutte le affermazioni richiedono test indipendenti, ma le istituzioni dovrebbero distinguere tra almeno tre categorie. Una capacità è dichiarata quando il fornitore afferma che esiste. È dimostrata quando le prove mostrano che è stata osservata in condizioni specificate. È stabilita per l'implementazione quando le prove sostengono ragionevolmente l'affidamento su di essa nel contesto previsto dall'istituzione. Queste categorie non sono intercambiabili.

Una dimostrazione può stabilire che un sistema è capace di produrre un output. Non stabilisce necessariamente con quale affidabilità produce quell'output tra popolazioni, ambienti o casi d'uso rilevanti. Allo stesso modo, la documentazione può stabilire cosa un fornitore dichiara riguardo al proprio sistema. Non può stabilire autonomamente che la dichiarazione sia corretta. Il fascicolo di approvvigionamento dovrebbe preservare questa distinzione. Altrimenti, le affermazioni diventano gradualmente conclusioni semplicemente perché sono state ripetute in abbastanza documenti.

Stabilita per l'implementazione

Uno stato di affermazione del fornitore che indica che le prove sostengono ragionevolmente l'affidamento sulla capacità nel contesto effettivo e previsto dall'istituzione, non semplicemente che la capacità è stata osservata in condizioni dimostrative.

4. Garanzia indipendente

Le prove del fornitore hanno un ruolo legittimo nell'approvvigionamento. I fornitori conoscono i propri sistemi meglio degli acquirenti e ci si dovrebbe aspettare che rivelino test, architettura, limitazioni, condizioni di guasto note e prove di prestazioni rilevanti. Ma il rapporto commerciale è importante. La parte che cerca il contratto non dovrebbe essere l'unica parte a determinare se le prove sono sufficienti per aggiudicarlo.

La garanzia indipendente non significa ricreare il programma di ingegneria del fornitore. Significa testare le affermazioni rilevanti per la decisione di acquisto in condizioni capaci di confutarle. Per l'IA legata all'accessibilità, ciò può richiedere una valutazione che coinvolga persone con la disabilità rilevante e, laddove sia coinvolto l'accesso linguistico, membri qualificati della comunità linguistica. L'obiettivo non è una partecipazione cerimoniale. È l'autorità probatoria. Le persone capaci di identificare un guasto rilevante devono disporre di un meccanismo che consenta a quel guasto di influenzare la decisione di approvvigionamento. Altrimenti, la partecipazione esiste senza governance.

5. Architettura di errore e di ripiego

Ogni appalto in materia di intelligenza artificiale dovrebbe contenere una risposta scritta a una singola domanda: cosa succede quando il sistema non funziona? “Un essere umano nel ciclo” non è una risposta adeguata. Il verbale dovrebbe identificare la persona responsabile, il fattore scatenante, l’autorità competente, i tempi di risposta e il percorso alternativo disponibile per la persona interessata.

Per gli utenti disabili, anche il ripiego stesso deve essere accessibile. Un sistema di comunicazione basato sull’IA che fallisce e indirizza una persona Deaf a effettuare una telefonata non ha prodotto un ripiego. Un processo digitale automatizzato che diventa inaccessibile e richiede a un utente non vedente di completare la stessa interfaccia inaccessibile non ha trasferito la persona a una supervisione umana in alcun senso significativo.

Una soluzione di riserva è una garanzia solo se la persona che ne ha bisogno può effettivamente utilizzarla.

Heather Grizzle

6. Limiti prestazionali e incognite note

I documenti di appalto tendono a registrare ciò che i prodotti sono in grado di fare. I verbali di governance devono anche indicare dove finisce l’affidabilità. Le prestazioni dell’IA sono condizionate. Possono variare in base alla lingua, al dialetto, all’accento, allo stile di segnalazione, all’illuminazione, alla posizione della telecamera, alla disabilità, al dispositivo, all’ambiente, alla terminologia di settore, alla durata dell’interazione, alle caratteristiche demografiche o a innumerevoli altre variabili. Le istituzioni dovrebbero richiedere ai fornitori di dichiarare i limiti prestazionali noti e dovrebbero documentare separatamente le aree che non sono state valutate.

Questa distinzione è importante. “Non valutato” non è lo stesso risultato di “fallito”, ma non è nemmeno lo stesso risultato di “sicuro”. L’incertezza non è un difetto dell’appalto se viene riconosciuta e gestita. L’incertezza non documentata lo è.

7. Registrazione, tracciabilità e ricostruzione

Quando un’interazione mediata dall’IA produce un danno, l’istituzione dovrebbe essere in grado di ricostruire quanto accaduto, e ciò richiede decisioni sulla registrazione prima della distribuzione. Quale versione del sistema era in funzione? Quali input sono stati ricevuti? Quale output è stato generato? L’output è stato modificato? Un essere umano lo ha esaminato? Quali informazioni ha visto tale revisore? Quale azione ne è seguita? L’istituzione può riprodurre l’evento senza conservare dati che non avrebbero mai dovuto essere conservati?

Tracciabilità e privacy possono creare legittime esigenze contrastanti. Tale conflitto dovrebbe essere risolto attraverso la progettazione del sistema e la governance, piuttosto che essere scoperto durante un contenzioso, un reclamo in materia di accessibilità o un’indagine interna. Il fascicolo dell’appalto dovrebbe documentare la soluzione adottata.

8. Reclamo, contestabilità e riparazione

Una persona colpita dall’IA ha bisogno di più di un meccanismo per segnalare un problema tecnico. Potrebbe aver bisogno di contestare ciò che l’istituzione ha fatto a causa del sistema, e questa è una funzione diversa. Se un sistema di IA traduce in modo errato una comunicazione, caratterizza in modo scorretto un comportamento, produce informazioni inaccessibili, genera un’inferenza falsa o contribuisce a un’azione istituzionale avversa, la persona interessata ha bisogno di un percorso per contestare la decisione risultante.

L’istituzione dovrebbe sapere, prima della distribuzione, chi riceve la contestazione, chi la indaga, quali prove vengono conservate, se l’output contestato dell’IA rimane operativo durante il riesame, quali rimedi sono disponibili e con quale rapidità l’istituzione deve rispondere.

9. Modifica del modello e nuova convalida

Gli appalti in materia di IA creano un problema che i contratti software tradizionali non erano particolarmente progettati per gestire: il prodotto che è stato valutato potrebbe non rimanere il prodotto che viene distribuito. I modelli vengono aggiornati. Le misure di salvaguardia cambiano. I dati di addestramento cambiano. Le interfacce cambiano. Le dipendenze di terze parti cambiano. I fornitori sostituiscono i modelli sottostanti. Le prestazioni possono migliorare in un ambito e peggiorare in un altro senza che l’istituzione acquirente avvii alcun cambiamento di propria iniziativa.

Il fascicolo dell’appalto necessita quindi di una regola di controllo delle modifiche. La domanda rilevante non è se il fornitore sia autorizzato ad aggiornare il proprio prodotto. È quali modifiche invalidano le prove su cui l’istituzione si è basata. I contratti dovrebbero identificare le modifiche sostanziali che richiedono notifica, nuova valutazione, nuovi test di accettazione o approvazione prima di un uso continuato in contesti specificati. Altrimenti, un’istituzione può svolgere una rigorosa verifica al momento dell’acquisizione e ritrovarsi comunque a gestire, sei mesi dopo, un sistema sostanzialmente diverso, utilizzando prove prodotte per il sistema precedente.

10. Autorità di sospensione e di uscita

Una governance priva di potere di arresto è puramente consultiva. Qualcuno all’interno dell’istituzione deve avere l’autorità di limitare, sospendere o terminare una distribuzione di IA quando le prove non ne sostengono più l’uso, e le condizioni scatenanti non dovrebbero dover essere inventate durante una crisi.

Il verbale dell’appalto dovrebbe identificare sia i fattori scatenanti sia l’autorità decisionale.

Dovrebbe inoltre affrontare l’uscita. Chi possiede o riceve i dati istituzionali quando il rapporto termina? Quali registri devono essere conservati? Cosa deve essere eliminato? Come ripristina l’istituzione il percorso di servizio precedente? Cosa succede alle persone che sono diventate dipendenti dal processo mediato dall’IA? La pianificazione dell’uscita non è semplicemente gestione del fornitore. È pianificazione della continuità dell’accesso.

Dalla politica sull’IA alle prove istituzionali

La sfida emergente per la governance dell’IA non è una carenza di principi. È la traduzione. L’equità deve diventare un criterio di valutazione. La trasparenza deve diventare un obbligo di divulgazione. La supervisione umana deve diventare un’autorità assegnata. L’accessibilità deve diventare una condizione di distribuzione. La responsabilità deve diventare un ufficio designato e un rimedio documentato. Il monitoraggio deve diventare un fattore scatenante per l’azione. E l’IA responsabile deve infine diventare qualcosa che un funzionario addetto agli appalti possa inserire in un fascicolo.

Questo è particolarmente importante nelle istituzioni pubbliche perché l’appalto è il punto in cui gli impegni istituzionali astratti incontrano il denaro, i contratti, i fornitori, gli obblighi di legge e le persone che non possono semplicemente scegliere un altro governo, scuola, ospedale, tribunale o servizio pubblico quando la tecnologia non funziona per loro. Il fascicolo dell’appalto svolge quindi una funzione molto più ampia della semplice tenuta dei registri. Esso stabilisce la teoria del rischio accettabile dell’istituzione.

Posizione politica di NCG

Novara Consulting Group ritiene che i sistemi di IA che riguardano le persone disabili non dovrebbero essere approvati solo perché hanno soddisfatto il processo generale di governance dell’IA di un’organizzazione. Il verbale dell’appalto dovrebbe contenere prove sufficienti per ricostruire e difendere la specifica decisione di distribuzione.

Lo standard non è una conoscenza perfetta. Nessun processo di approvvigionamento può eliminare l'incertezza. Lo standard è un'incertezza governata: sapere cosa è stato stabilito, cosa non lo è stato, quali prove hanno giustificato comunque il procedere e chi si assume la responsabilità della decisione.

Posizione conclusiva

Dopo un fallimento legato all'IA, le istituzioni spesso si chiedono se il fornitore avrebbe dovuto avvertirle. A volte la risposta sarà sì. Ma la responsabilità pubblica richiede un'altra domanda: quali prove ha richiesto l'istituzione prima di accettare di procedere? Quella domanda non può essere esternalizzata. Il fornitore può fornire prove. Un valutatore può valutarle. Un comitato può dare consulenza. Le parti interessate con disabilità possono individuare criticità che altri non riescono a vedere. Gli avvocati possono negoziare la ripartizione del rischio contrattuale. L'istituzione prende comunque la decisione, e il suo fascicolo di approvvigionamento dovrebbe dimostrare che sapeva quale decisione stava prendendo.

Un sistema di IA non è governato perché un'organizzazione ha una politica sull'IA. È governato quando l'istituzione può dimostrare perché a questo sistema, per questo scopo, che riguarda queste persone, in queste condizioni, è stato consentito di operare.

Heather Grizzle

Il fascicolo di approvvigionamento è il punto in cui inizia quella responsabilità.