Un sistema ad alto rischio non è un modello ad alto rischio

Il rischio non vive dentro un modello come un'etichetta di avvertenza. Emerge dallo scopo previsto, dalla distribuzione, dall'autorità, dalle interfacce e...

Un sistema ad alto rischio non è un modello ad alto rischio

L'etichetta è legata a un uso, non a una scatola

Un modello può essere copiato da un server a un altro senza imparare nulla. I suoi pesi, il codice e le capacità pubblicizzate possono rimanere invariati. Eppure la domanda che l'Europa pone sulla cosa che lo circonda può cambiare completamente. A cosa serve? Chi lo usa? Quale posizione può alterare? Quale record entra nel flusso di lavoro? Chi può mettere in discussione la risposta, correggerla, fermarla o scoprire in seguito perché è stata seguita?

Questo non è un tentativo di rendere un argomento semplice più importante di quanto sia. È la differenza ordinaria tra un componente e un sistema. Un disco del freno non è un veicolo stradale. Una formula di foglio di calcolo non è una decisione fiscale. Un modello di IA generico non è, di per sé, ogni sistema di IA che potrà essere costruito attorno ad esso in futuro. La distinzione è facile da approvare con un cenno del capo e sorprendentemente facile da perdere quando una riunione di approvvigionamento inizia a parlare di un modello come se contenesse già l'intera implementazione futura.

L'Artificial Intelligence Act dell'UE mantiene la distinzione in primo piano. Definisce un sistema di IA e definisce separatamente un modello di IA per finalità generali. Le sue regole ad alto rischio riguardano i sistemi di IA in circostanze particolari, inclusi i sistemi che sono componenti di sicurezza di prodotti regolamentati e i sistemi utilizzati in settori elencati. L'Atto rende inoltre la finalità prevista centrale per la classificazione e la documentazione di un sistema di IA. Non invita un team a indicare il nome di un modello, ad applicare un'etichetta rossa, ambra o verde e a dichiarare il lavoro concluso.

Questo dovrebbe essere liberatorio oltre che impegnativo. Un modello non porta un oroscopo morale permanente. Un'analisi attenta può essere ristretta dove la finalità prevista è ristretta, e può diventare seria dove l'autorità, l'esposizione e le conseguenze diventano serie. Il problema è che l'analisi deve seguire il sistema effettivo. Non la demo. Non la presentazione del fornitore. Non il compito innocuo che ha avviato il progetto sei mesi fa. Il sistema che riceverà input, renderà disponibili gli output, darà forma a una decisione e sarà operato in un normale martedì.

Consideriamo un'illustrazione volutamente ipotetica. Lo stesso modello linguistico viene collegato prima a uno strumento interno di ricerca delle conoscenze. Recupera passaggi di policy per un collega formato, che può aprire la fonte originale e scrivere la propria risposta. Successivamente, un'organizzazione collega il modello a un modulo di raccolta, dà alla sua raccomandazione un posto in cima a un record del caso, applica un timer al caso e rende l'accettazione della raccomandazione il modo più rapido per smaltire la coda. Non serve alcun consiglio fittizio, paziente, dipendente o incidente per vedere il cambiamento. Il modello può essere identico. Il ruolo dell'output, il percorso dei dati, l'incentivo, la persona interessata e l'autorità pratica dell'interfaccia non lo sono.

Questo è l'argomento dell'articolo: un sistema ad alto rischio non è un modello ad alto rischio. Un modello può essere una parte importante del sistema e può avere doveri propri. Ma l'analisi del rischio diventa significativa solo quando raggiunge la finalità prevista, il contesto di implementazione, gli utenti, le persone interessate e l'integrazione a valle. Questi dettagli non sono pratiche burocratiche aggiunte dopo l'ingegneria. Sono le circostanze che danno a un output forza istituzionale.

Passa il mouse su un livello o selezionalo. Il modello è un solo livello; la conseguenza emerge solo quando i livelli si incontrano.

L'Europa usa deliberatamente due sostantivi diversi

La distinzione nasce nelle definizioni del regolamento. Un sistema di IA è un sistema basato su macchine progettato per operare con diversi livelli di autonomia e che può mostrare adattività dopo la distribuzione, che deduce dagli input come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali. Un modello di IA per finalità generali è diverso: è un modello di IA in grado di svolgere con competenza un'ampia gamma di compiti distinti, che sia o meno immesso sul mercato, e può essere integrato in una varietà di sistemi o applicazioni a valle.

Queste definizioni si sovrappongono nel linguaggio quotidiano perché la stessa parola, IA, svolge una grande quantità di lavoro non retribuito. Non dovrebbero sovrapporsi in una valutazione. Un modello per finalità generali è fatto per viaggiare. I suoi possibili usi sono volutamente ampi. Un sistema di IA è la disposizione operativa attraverso cui gli output influenzano un ambiente. Ha uno scopo, una configurazione, un'interfaccia e un contesto. Può includere un modello, più modelli, regole deterministiche, database, sensori, persone, procedure e moltissime piccole decisioni che nessuno chiama intelligenza artificiale finché non falliscono.

Per questo un fornitore di un modello di IA per finalità generali e un fornitore o deployer di un sistema di IA non possono semplicemente scambiarsi le checklist. Gli orientamenti della Commissione sui modelli di IA per finalità generali affermano che i fornitori di modelli devono mettere a disposizione dei fornitori di sistemi di IA a valle informazioni e documentazione, così che questi possano comprendere le capacità e i limiti del modello e soddisfare i propri obblighi. Questa frase è più interessante di quanto sembri a prima vista. Presuppone che il fornitore a valle abbia un lavoro che il fornitore del modello non può completare. La documentazione del modello viaggia, ma non conclude il viaggio.

C'è un'umiltà pratica in tutto questo. Un fornitore di modelli può descrivere architettura, processo di addestramento, valutazione, compiti previsti, requisiti di integrazione, input e output, limiti e condizioni note. Un team a valle sa se un utente è uno specialista formato, se una persona interessata può contestare un esito, se una raccomandazione è consultiva nel nome ma vincolante nella pratica, se una chiamata a un servizio esterno modifica un record e se un'azione errata può essere annullata. Nessuna delle due parti ha da sola un quadro completo.

La divisione non è una scappatoia. È una mappa delle responsabilità. Dice che un sistema non può essere governato chiedendo al fornitore del modello di promettere il controllo su una distribuzione che non opera né vede. Dice anche che un integratore non può invocare l'ignoranza dove la documentazione rende visibile un limite importante. Il punto non è creare un passaggio di consegne pulito tra entità giuridiche. È evitare che la questione si perda nello spazio tra loro.

Accanto alla prima distinzione, ce n'è una seconda che vale la pena tenere a mente. Una classificazione ad alto rischio non equivale di per sé a un permesso, né a una garanzia di sicurezza, correttezza o legalità. Nel parere congiunto sulla proposta originaria della Commissione, il Comitato europeo per la protezione dei dati e il Garante europeo della protezione dei dati hanno sottolineato che la classificazione come ad alto rischio non implicava necessariamente che un sistema fosse di per sé legittimo o potesse essere utilizzato come tale dal suo utente. L'atto finale ha modificato il quadro giuridico rispetto a quel parere, ma l'avvertimento di fondo resta valido. La classificazione è una condizione normativa. Non è una ricevuta che attesti che l'istituzione possa smettere di riflettere.

Questo è importante perché un'etichetta ad alto rischio può generare due errori opposti. Un team può trattarla come una macchia permanente su un modello e decidere che la soluzione sia semplicemente non guardare oltre. Un altro può considerare un processo di conformità completato come un lasciapassare per qualsiasi contesto futuro. Entrambi gli approcci sostituiscono un'etichetta a un ragionamento. L'Europa ha scelto un approccio più scomodo: identificare il sistema, la sua finalità e il suo ruolo, quindi esaminare i rischi e gli obblighi pertinenti lungo il suo ciclo di vita.

La finalità prevista è il punto di riferimento dell'analisi

La finalità prevista sembra un concetto modesto, quasi burocratico. Non lo è. L'atto la definisce come l'uso per cui un sistema di IA è destinato dal suo fornitore, compresi il contesto specifico e le condizioni d'uso specificate nelle informazioni fornite dal fornitore. In altre parole, la finalità non è uno slogan su una pagina di prodotto. Include il contesto e le condizioni in cui il fornitore dichiara che il sistema deve essere utilizzato. Una dichiarazione di finalità utile ha dei confini netti. Dice cosa fa il sistema, per chi, con quali input, all'interno di quale flusso di lavoro e dove finisce la sua autorità.

Si confrontino due descrizioni. La prima afferma che un sistema usa l'IA per aiutare le organizzazioni a prendere decisioni migliori. È abbastanza ampia da stare su uno sfondo da conferenza e troppo ampia per essere operativa. La seconda afferma che un sistema presenta bozze di sintesi con fonti citate tratte da un fascicolo esistente a revisori formati; non può prendere, trasmettere o attuare una decisione; il revisore deve verificare le fonti citate prima di utilizzare una sintesi; e la funzione non è disponibile per categorie che richiedono un procedimento normativo separato. La seconda descrizione è meno entusiasmante. È anche qualcosa su cui un ingegnere, un responsabile degli acquisti, un collega della conformità e una persona interessata possono dissentire in termini concreti.

La finalità non deve essere per forza una singola frase. In un sistema serio è di solito un pacchetto compatto: compito, output, utente, popolazione interessata, contesto, autorità, esclusioni, dipendenze e condizioni. I requisiti di documentazione tecnica dell'atto lasciano spazio proprio a questo tipo di descrizione. L'allegato IV chiede una descrizione generale del sistema di IA, inclusa la finalità prevista, le persone e i gruppi su cui è destinato a essere utilizzato e le versioni o forme specifiche in cui è immesso sul mercato. Chiede inoltre descrizioni dell'architettura del sistema, dei requisiti sui dati, delle misure di supervisione umana, del monitoraggio del ciclo di vita e delle misure di gestione dei rischi. La documentazione ha questa ampiezza perché una scheda del modello da sola non può descrivere una distribuzione.

La finalità è anche il punto in cui un team scopre di aver descritto un'ambizione piuttosto che un'operazione. "Aiuteremo gli operatori" può nascondere una dozzina di assetti diversi. Lo strumento cerca documenti, ordina il lavoro, redige una risposta, raccomanda una categoria, respinge una domanda, inoltra un avviso, imposta una priorità o chiama un altro servizio? Il collega lo usa prima o dopo aver formato un'opinione indipendente? L'output è un suggerimento in un pannello laterale o un campo che deve essere compilato prima che il fascicolo possa procedere? L'effetto è immediato, ritardato, reversibile o difficile da individuare? La risposta cambia il sistema anche quando l'interfaccia utente sembra familiare.

Lo scopo dichiarato da un fornitore non può far sparire la realtà. Un team non può attribuire a un sistema un'ampia autorità pratica, descriverlo come un assistente innocuo e aspettarsi che la descrizione chiuda la questione. Ma uno scopo adeguatamente delimitato resta comunque un controllo. Dice agli utenti quali elementi di prova sono stati presi in considerazione, dice agli integratori cosa non devono estendere con leggerezza e dice ai revisori quale modifica riaprirebbe la valutazione. Uno scopo vago trasforma ogni domanda successiva in una discussione su cosa si intendesse. Uno scopo delimitato consente a un'organizzazione di chiedersi se sta ancora facendo ciò che ha approvato.

Questo diventa particolarmente importante quando un'organizzazione apporta una modifica sostanziale. Il Regolamento contiene norme sui casi in cui un distributore, un importatore, un deployer o un altro soggetto terzo può diventare fornitore, anche quando immette un sistema sul mercato con il proprio nome, apporta una modifica sostanziale o modifica lo scopo previsto in un modo che fa sì che il sistema diventi ad alto rischio. L'esatta applicazione giuridica dipende dai fatti e va verificata nel contesto. La lezione operativa è più semplice: una modifica all'integrazione può essere un evento di governance. Spostare l'output di un modello da un riquadro di bozza a una coda di decisione può essere allo stesso tempo una modifica del prodotto, una modifica del flusso di lavoro e una modifica della responsabilità.

Il contesto non è uno sfondo

Il contesto di implementazione è spesso trattato come la parte che arriva dopo il lavoro vero: un elenco di paesi, una scelta di hosting, qualche persona utente, magari un diagramma con frecce che conducono obbligatoriamente da sinistra a destra. Ma il contesto dà forma al rischio. Lo stesso tipo di output può essere scomodo in un contesto e avere conseguenze in un altro. Una risposta errata in un assistente di scrittura può essere corretta nella frase successiva. Una priorità errata in un flusso di lavoro per servizi scarsi può decidere quale file una persona vede per primo. Un punteggio che sembra essere un input tra molti può diventare decisivo se ogni altro input è lento, vago o nascosto dietro un altro team.

L'approccio ad alto rischio del Regolamento riflette questo. L'articolo 6 collega la classificazione ad alto rischio ai sistemi destinati a essere utilizzati come componenti di sicurezza di determinati prodotti o ai sistemi di cui all'allegato III. L'allegato III elenca i settori in cui i sistemi di IA possono essere ad alto rischio perché destinati a usi specifici, come alcuni usi biometrici, le infrastrutture critiche, l'istruzione e la formazione professionale, l'occupazione, l'accesso a servizi e prestazioni essenziali privati e pubblici, l'attività di contrasto, la migrazione e il controllo delle frontiere e l'amministrazione della giustizia e dei processi democratici. Il dettaglio giuridico conta, ma conta anche la grammatica. Non dice che un artefatto tecnico è ad alto rischio in astratto. Dice ripetutamente destinato a essere utilizzato.

L'articolo 6 contiene anche una precisazione per alcuni sistemi di cui all'allegato III: non sono da considerarsi ad alto rischio se non comportano un rischio significativo di danni alla salute, alla sicurezza o ai diritti fondamentali delle persone fisiche, anche non influenzando in modo sostanziale l'esito del processo decisionale. I fornitori devono documentare tale valutazione prima di immettere il sistema sul mercato o metterlo in servizio. Non è una carta di esenzione generale. È un promemoria del fatto che l'effetto reale del sistema conta. Un'analisi utile ha sufficienti dettagli per spiegare perché un sistema influenza o non influenza in modo sostanziale un esito. Se quella spiegazione non può essere scritta senza generalizzazioni vaghe, il team ha imparato qualcosa prima del rilascio.

Il contesto include il tempo. Una raccomandazione all'inizio di un'indagine ampia ha un effetto diverso da una raccomandazione nel momento in cui una persona ha una sola possibilità di fornire materiale mancante. Include il volume. Un singolo revisore può contestare un output quando arrivano cinque casi al giorno e accettarlo per impostazione predefinita quando ne arrivano cinquecento prima di pranzo. Include la lingua. Un revisore che può leggere le prove nella propria lingua di lavoro può esercitare un tipo di controllo diverso da un revisore che riceve un riepilogo assertivo di materiale che non può ispezionare in modo indipendente. Include la procedura locale, i diritti di ricorso, il personale, l'accesso a uno specialista, la disponibilità di un piano di riserva e se un output raggiunge una persona con sufficiente autorità per fare qualcosa di utile.

Niente di tutto ciò richiede che un disastro inventato sia vero. È semplicemente così che funzionano i sistemi. Una politica formale può affermare la presenza di un essere umano nel ciclo, ma il sistema può comunque essere funzionalmente automatico se la persona non ha tempo, informazioni, autorità o una via pratica per dissentire. L'articolo 14 della legge parla quindi di controllo umano efficace e appropriato ai rischi, al livello di autonomia e al contesto d'uso. Richiede che i sistemi ad alto rischio siano progettati e sviluppati in modo che le persone possano comprendere le capacità e le limitazioni pertinenti, rimanere consapevoli della tendenza a fare affidamento automaticamente sugli output, interpretare correttamente gli output, decidere di non usarli, sovrascriverli o annullarli e arrestare il sistema in sicurezza quando opportuno. Queste sono questioni operative. Non possono essere risolte solo con un benchmark di un modello.

Seleziona una modalità di implementazione. Il modello resta al suo posto; il confine del sistema, l'autorità e le prove necessarie non restano tali.

Gli utenti fanno parte della superficie di controllo

È forte la tentazione di parlare degli utenti come se fossero esterni al sistema, con una tastiera in mano, pronti a fare la parte umana. In realtà fanno parte dell'assetto operativo. Le loro conoscenze, il carico di lavoro, l'autorità, gli incentivi e le vie di supporto determinano ciò che l'output produce. Un sistema progettato per uno specialista che può esaminare il materiale di partenza non è automaticamente adatto a un generalista che deve lavorare rapidamente. Uno strumento utile per un revisore che può respingere una raccomandazione non è automaticamente adatto a un collega che può solo cliccare su approva o aspettare qualcun altro.

Questo non significa che un utente debba mettere in discussione ogni componente ogni volta. Sarebbe una strana definizione di tecnologia utile. Significa che la supervisione dovrebbe essere progettata come un compito reale. La persona deve sapere quando il sistema viene utilizzato, qual è la limitazione pertinente, quali prove sono disponibili, che tipo di disaccordo può registrare e cosa succede dopo averlo registrato. Deve avere un'autorità che corrisponda alla responsabilità. Chiedere a qualcuno di supervisionare un output che non può mettere in pausa, correggere o instradare è più decorazione umana che supervisione umana.

L'Atto attribuisce ai deployer un ruolo in questo contesto. L'articolo 26 richiede che i deployer di sistemi ad alto rischio adottino misure tecniche e organizzative appropriate per garantire che utilizzino i sistemi in conformità con le istruzioni allegate. Chiede ai deployer di assegnare la supervisione umana a persone fisiche con le competenze, la formazione e l'autorità necessarie, e di monitorare il funzionamento sulla base delle istruzioni. In alcuni casi richiede anche di mantenere sotto il loro controllo i log generati automaticamente. Non è una richiesta di tenere una persona competente nelle vicinanze nel caso in cui l'interfaccia diventi nervosa. È una richiesta di organizzare una pratica di lavoro.

La formazione è spesso discussa come la risposta completa. Non lo è. La formazione può aiutare una persona a riconoscere una limitazione, ma non può creare una registrazione di origine che l'interfaccia nasconde. Non può creare tempo che una progettazione di coda consuma. Non può creare autorità che un contratto riserva altrove. Non può riparare un'integrazione che converte una raccomandazione cauta in un'azione irreversibile. Un'organizzazione dovrebbe formare le persone, ovviamente. Dovrebbe anche rendere possibile il compito per cui vengono formate nel sistema che viene effettivamente fornito.

Esiste un test utile: descrivere l'azione dell'utente senza usare il verbo "rivedere". Cosa leggono? Quale confronto possono fare? Cosa possono rifiutare? Dove va la motivazione? Chi la vede? Cosa succede alla raccomandazione dopo il rifiuto? La persona interessata dal risultato può chiedere cosa è successo? Un collega successivo può ricostruire lo stato pertinente? Se le risposte rimangono generiche, probabilmente anche la progettazione della supervisione è generica.

Questo test si applica oltre i sistemi ad alto rischio. La legge ha ambito e date specifici; un buon giudizio operativo non aspetta un'etichetta di categoria prima di chiedersi se una persona sia stata collocata in un ruolo performativo. È perfettamente possibile costruire uno strumento a basso impatto che renda le persone meno capaci riguardo al proprio lavoro perché l'output è troppo fluido per essere contestato. È anche possibile costruire uno strumento vincolato che aumenti la capacità di una persona di porre buone domande perché preserva le prove, limita la propria autorità e rende visibile l'incertezza. Il modello può contribuire a entrambi gli esiti. Il sistema decide quale esito ha un luogo in cui realizzarsi.

Le persone interessate siedono fuori dalla console

Molte delle persone più importanti in un sistema di IA non lo toccano mai. Possono essere un candidato, uno studente, un lavoratore, un paziente, un passeggero, un residente, un cliente, un richiedente, un mutuatario, un testimone o un membro del pubblico. Potrebbero non sapere che un modello è stato coinvolto. Potrebbero solo sperimentare una risposta che arriva rapidamente, una richiesta che viene ritardata, un servizio che diventa non disponibile, una priorità che cambia o una decisione che sembra impossibile da comprendere. La loro assenza dall'interfaccia non li rende assenti dal sistema.

Questo è uno dei motivi per cui la struttura di rischio dell'Atto si riferisce a salute, sicurezza e diritti fondamentali. Dirige l'attenzione verso conseguenze che non possono essere ridotte al fatto che un collega connesso abbia apprezzato lo strumento. È anche il motivo per cui una dichiarazione di scopo dovrebbe nominare le persone e i gruppi su cui il sistema è destinato a essere utilizzato, come richiede l'allegato IV. Un sistema costruito attorno a una categoria chiamata "utente" può nascondere silenziosamente una differenza tra la persona che opera l'interfaccia e la persona che vive con il risultato.

Le persone coinvolte cambiano le domande che un team deve porsi. Esiste un modo per sapere che il sistema ha avuto un ruolo significativo? La decisione si basa su informazioni che possono essere corrette? Una lingua, una disabilità, un dispositivo, una località o uno stato amministrativo rendono più difficile partecipare? Il team operativo riceve segnali dalle persone coinvolte o solo dal cruscotto? Una correzione raggiunge i dati, la raccomandazione, la decisione e qualsiasi copia a valle che vi faceva affidamento? Queste domande non sono una richiesta di trasformare ogni sistema in una consultazione pubblica. Sono una richiesta di seguire la conseguenza abbastanza lontano da vedere la persona all'altro capo.

La legge sulla protezione dei dati è pertinente quando vengono trattati dati personali, insieme al quadro dell'AI Act. L'EDPB e l'EDPS hanno chiarito questo punto nel loro parere congiunto del 2021 sulla proposta: la normativa UE esistente sulla protezione dei dati si applica al trattamento di dati personali nell'ambito della proposta. L'analisi giuridica esatta dipenderà dal trattamento e dagli attori coinvolti. La lezione di governance è semplice. Un esercizio di classificazione non può assorbire ogni altro obbligo. La privacy, la non discriminazione, gli obblighi settoriali, i requisiti del diritto amministrativo, le norme sui consumatori e gli impegni contrattuali non scompaiono perché un team ha creato un registro dei rischi dall'aspetto curato.

C'è anche una questione fondamentale di leggibilità. Una persona non deve diventare un'esperta di machine learning per capire come chiedere una correzione. Ma un sistema non deve usare la complessità tecnica come motivo per rendere impossibile la correzione. Un buon percorso distingue ciò che il sistema ha registrato, ciò che un essere umano ha deciso, quali prove sono state considerate, cosa rimane incerto e cosa può ancora essere modificato. Non rivendica una precisione che i registri non possono sostenere. In questo ambito, l'onestà non è solo un tono di voce. È parte del servizio.

L'integrazione è il punto in cui le responsabilità cambiano di mano

I team a volte disegnano un'architettura di IA come una catena ordinata: modello, prompt, risposta, utente. Le implementazioni reali assomigliano più a una mappa comunale dopo che qualcuno si è ricordato dei tubi di servizio. Ci sono sistemi di identità, archivi di recupero, permessi degli strumenti, code, schemi, cache, piattaforme di osservabilità, estensioni del browser, processi batch, regole di approvazione, impostazioni di conservazione, fornitori e persone che ereditano un compito perché la persona precedente è andata in vacanza. Il modello è importante. Raramente è da solo.

Ogni integrazione può alterare ciò che il sistema è in grado di fare e come si muove un errore. Il recupero può far sembrare un output del modello fondato mentre la fonte è obsoleta, incompleta o con un ambito errato. Una chiamata a uno strumento può trasformare una bozza in un cambiamento di stato. Una coda può trasformare una raccomandazione tempestiva in una tardiva. Un livello di orchestrazione può selezionare un modello o una versione del prompt diversa. Un'interfaccia utente può nascondere l'incertezza che esiste in un livello inferiore. Un'integrazione di identità può dare a uno strumento utile l'accesso a materiale che un utente non potrebbe altrimenti aprire. Nessuna di queste osservazioni accusa un prodotto o un'organizzazione specifica. Descrivono proprietà ordinarie del sistema, ed è proprio per questo che dovrebbero essere documentate prima che diventino sorprendenti.

La guida GPAI della Commissione è utile qui perché colloca le informazioni nel punto di passaggio di consegne. La documentazione per i fornitori a valle è pensata per aiutarli a comprendere le capacità e i limiti del modello, i suoi compiti previsti, i requisiti tecnici di integrazione, le specifiche di input e output e le informazioni sui dati di addestramento. Queste informazioni sono necessarie. Non sono sufficienti. I team a valle devono comunque decidere come viene sollecitato il modello, se un output viene mostrato con le prove, quali permessi degli strumenti sono consentiti, come viene testata una modifica, quali log vengono conservati e se una raccomandazione può influenzare un flusso di lavoro specifico.

Ecco perché l'acquisto di un servizio di modello non è l'acquisto di una postura di rischio completa. La documentazione del fornitore può dire a un team che un modello ha una limitazione nota o che è stato valutato in determinate condizioni. Non può dimostrare che l'indice di recupero dell'acquirente sia aggiornato, che il personale dell'acquirente abbia l'autorità necessaria o che una persona interessata abbia accesso a un canale di contestazione. Al contrario, l'acquirente non può pretendere che il fornitore del modello conosca ogni policy locale o processo a valle. La cosa responsabile non è fingere che una parte possa conoscere l'intero sistema. È rendere esplicito il confine e mantenere le prove in movimento attraverso di esso.

L'articolo 25 fornisce un utile riferimento giuridico per questa realtà operativa. Individua le circostanze in cui un soggetto diverso dal fornitore originario è considerato fornitore di un sistema di IA ad alto rischio. Queste includono l'immissione sul mercato del sistema con il nome o il marchio di tale soggetto, l'apporto di una modifica sostanziale o la modifica della finalità prevista in modo da rendere il sistema ad alto rischio. La disposizione è tecnica e dipende dai fatti specifici; nessuno dovrebbe auto-classificarsi basandosi su un post di un blog. Ma la sua direzione è chiara. L'integrazione e il riutilizzo per scopi diversi possono cambiare chi assume gli obblighi del fornitore. Un accordo a valle non è per sempre a valle solo perché il modello originale è arrivato da altrove.

C'è una ragione istituzionale per prendere questo sul serio. Quando la responsabilità cambia in silenzio, sicurezza e risarcimento diventano un gioco di ping-pong organizzativo. Il fornitore del modello indica la distribuzione. Il distributore indica il modello. L'integratore indica il servizio cloud. Il proprietario del servizio indica una configurazione che non esiste più. Le persone interessate ricevono una spiegazione raffinata di quanto tutto sia complesso. Questo può essere accurato, ma non è una risposta. Il sistema ha bisogno di una registrazione di quale organizzazione possiede la domanda a ogni confine e di un percorso per la domanda quando la risposta si trova altrove.

La documentazione dovrebbe descrivere un sistema che può ancora cambiare

La documentazione tecnica ha la reputazione di arrivare alla fine di un progetto con un vago odore di panico. L'Atto descrive un ruolo diverso. Per i sistemi ad alto rischio, la documentazione tecnica deve essere redatta prima che il sistema sia immesso sul mercato o messo in servizio e mantenuta aggiornata. L'elenco dell'allegato IV va oltre il comportamento del modello e include finalità prevista, versioni, architettura del sistema, sviluppo, requisiti dei dati, validazione e test, supervisione umana, accuratezza e misure di cybersicurezza, gestione del rischio, modifiche e monitoraggio post-commercializzazione. Non è un'appendice decorativa. È un tentativo di preservare memoria sufficiente affinché qualcuno possa ispezionare il sistema dopo che la riunione di lancio è diventata folklore.

La documentazione funziona solo quando può mostrare le relazioni. Una versione del modello deve essere collegata alla versione del sistema che la utilizzava. Un test deve essere collegato alle sue condizioni di input e al suo scopo. Una policy deve essere collegata a un punto di applicazione. Un ruolo utente deve essere collegato all'autorità che ha nell'interfaccia. Una policy di registrazione deve essere collegata all'evento che può ricostruire. Una modifica deve essere collegata alla valutazione che ha innescato. Altrimenti un team ha una libreria di buoni documenti e nessun modo per rispondere a una domanda specifica.

I log sono un caso simile. L'articolo 12 richiede che i sistemi di IA ad alto rischio dispongano di capacità tecniche per la registrazione automatica degli eventi per l'intero ciclo di vita del sistema, in modo proporzionato alla finalità prevista. I log possono agevolare la tracciabilità, il monitoraggio post-commercializzazione e il monitoraggio operativo. Non spiegano una decisione per magia. Un log può dire a un successivo investigatore che è stato chiamato uno strumento, che era attiva una versione o che un revisore ha fatto clic su un controllo. Non può, da solo, stabilire se il revisore abbia compreso le prove, se la fonte di input fosse autorevole o se un processo fosse equo. Le registrazioni hanno valore perché danno a un'indagine un punto di partenza onesto, non perché eliminano la necessità di un giudizio.

Il monitoraggio post-commercializzazione completa il quadro. L'articolo 72 richiede che i fornitori di sistemi ad alto rischio istituiscano e documentino un sistema di monitoraggio post-commercializzazione in modo proporzionato alla natura delle tecnologie e ai rischi del sistema di IA ad alto rischio. Questo ha una semplice implicazione per i team di distribuzione: il rilascio non è il momento in cui il sistema diventa pienamente noto. L'organizzazione ha bisogno di un modo per ricevere informazioni pertinenti, distinguere un segnale da una conclusione, decidere se il confine della finalità prevista regge ancora e apportare una modifica o interrompere un uso quando le prove lo richiedono.

Questo lavoro non è affascinante. Si presenta come identificatori di versione, criteri di rilascio chiari, una registrazione delle dipendenze, un test per un percorso di inversione, un proprietario designato per una limitazione e una decisione che resta visibile dopo che la persona che l'ha presa cambia ruolo. Si presenta come chiedersi se un'integrazione sia cambiata prima di chiedersi se il modello sia cambiato. Si presenta come conservare prove sufficienti per correggere una conseguenza piuttosto che limitarsi a spiegarla a posteriori. Noioso non è l'opposto di ambizioso qui. È la parte che fa stare l'ambizione dentro un'istituzione.

Come ragionare sull'intero sistema senza fingere certezza

Un'analisi completa non è una ricerca di un punteggio di rischio universale. È una sequenza di domande che diventa più precisa man mano che il progetto diventa più preciso. La prima domanda è la finalità: cosa deve fare questo sistema e cosa specificamente non deve fare? La seconda è la conseguenza: chi può essere coinvolto, come e attraverso quale decisione o servizio? La terza è l'autorità: quale output può alterare uno stato, influenzare una decisione, fissare una priorità o cambiare ciò che una persona riceve? La quarta è l'evidenza: cosa supporta l'uso del sistema in questo contesto e quali condizioni fanno sì che tale evidenza sia valida?

Poi arrivano le domande scomode. Cosa succede quando il modello è incerto, sbagliato, non disponibile o usato al di fuori del suo confine dichiarato? Cosa cambia quando una fonte è obsoleta o uno strumento è negato? E se un utente ha fretta, è nuovo nel ruolo o non è in grado di esaminare il materiale sottostante? E se una persona coinvolta chiede una correzione? E se un aggiornamento modifica un prompt, il corpus di recupero, le impostazioni predefinite dell'interfaccia, la versione del modello o le autorizzazioni di ruolo? La risposta a volte è un controllo tecnico, a volte una procedura, a volte un uso più limitato, a volte un proprietario diverso e a volte una decisione di non distribuire. Una governance che non consente mai quest'ultima risposta è solo approvazione con una veste più elegante.

Aiuta tenere separate diverse affermazioni. Un fatto confermato dice ciò che il fornitore del modello ha documentato o ciò che l'organizzazione ha osservato in un test definito. Un'inferenza dice perché quel fatto può essere rilevante in un particolare flusso di lavoro. Un controllo proposto dice ciò che il team intende implementare. Un rischio residuo dice ciò che rimane dopo il controllo. Una conclusione giuridica dice ciò che si applica ai sensi della legge. Queste cose non sono intercambiabili. Un buon documento le etichetta perché il lettore potrebbe aver bisogno di contestarne una senza scartare le altre.

Ad esempio, è possibile dire: la documentazione del fornitore afferma che il modello presenta una certa limitazione; il team di implementazione deduce che la limitazione potrebbe incidere su un uso specifico; il team propone un controllo di verifica della fonte; il controllo non è ancora stato testato sotto il carico di lavoro previsto; e il consulente legale deve valutare l'uso risultante ai sensi della legge applicabile. Questa frase è meno appagante di una spunta verde. È più utile di una spunta verde perché non lascia alcun mistero su cosa sia stato e cosa non sia stato stabilito.

I team dovrebbero prestare particolare attenzione alla parola umano. Un ruolo umano può essere un controllo, ma solo quando ha un compito definito, informazioni adeguate, tempo, formazione, autorità e una via per agire. Un ruolo umano può anche diventare un modo per trasferire la colpa alla persona più vicina allo schermo. La distinzione non è filosofica. È visibile nel flusso di lavoro. Se un revisore può solo approvare, se il disaccordo svanisce in un campo di commenti non monitorato, o se nessuno può correggere la conseguenza a valle, il sistema non ha acquisito una supervisione significativa solo perché una persona ha cliccato qualcosa.

La stessa cautela vale per la trasparenza. Un documento lungo può rendere un sistema descrivibile senza renderlo contestabile. Una dashboard può renderlo visibile senza renderlo comprensibile. Una informativa può dire a un utente che l'IA è coinvolta senza dire loro cosa si può fare in caso di errore. La domanda utile è pratica: la persona interessata può trovare il confine, le prove, il ruolo responsabile e il percorso di correzione nel punto in cui queste cose contano? Se no, le informazioni esistono nel posto sbagliato perché possa avvenire la governance.

Una breve nota da parte nostra

Presso Dweve, il nostro Trust Centre pubblico tratta il record del modello e l'integrazione a valle come record correlati ma separati. La sua pagina a valle afferma che i team che integrano o implementano Loom necessitano di capacità, limiti, interfacce, contesto di valutazione e modifiche attuali, mentre il record pubblico dichiara che un modello è un filo in una più ampia trama di componenti e confini operativi. Questa è una postura documentale, non un'affermazione che una pagina pubblica classifichi ogni possibile implementazione o dimostri la conformità per un integratore. Lo scopo della separazione è più modesto: un record del modello dovrebbe viaggiare con l'integrazione senza fingere di sostituire l'analisi di sistema dell'integratore stesso.

Questo è lo standard che vale la pena mantenere. Un fornitore di modelli dovrebbe rendere disponibili informazioni utili. Un'organizzazione che implementa o integra il modello dovrebbe descrivere il sistema reale che ha creato: scopo, persone, dati, interfacce, autorità, monitoraggio e correzione. Nessuna delle due parti dovrebbe usare la documentazione come uno scambio cerimoniale in cui una parte riceve un PDF e l'altra riceve l'assoluzione.

La domanda più difficile è di solito quella migliore

Quando un team chiede se un modello è ad alto rischio, potrebbe cercare una risposta rapida a una preoccupazione sensata. Ma la domanda più utile è di solito più lunga: quale sistema stiamo creando da questo modello, per quale scopo, in quale contesto, con quali persone, e cosa succede quando sbaglia? Questa domanda non può sempre trovare risposta in una sola riunione. Potrebbe rivelare che l'uso proposto è più limitato del previsto, che le prove sono incomplete, che un ruolo utente manca di autorità, che un contratto lascia un confine importante senza un responsabile, o che un'integrazione a valle è diventata silenziosamente il centro del sistema.

Nessuno di questi risultati è un fallimento dell'innovazione. Sono le cose che un'istituzione impara prima di dare a un sistema il potere di plasmare le opzioni di un'altra persona. L'approccio europeo è spesso descritto come un insieme di obblighi. È anche una disciplina di denominazione: nominare lo scopo, l'attore, il contesto, la versione, la persona interessata, la limitazione, l'evidenza e la via per intervenire. Una volta nominati, questi elementi possono essere testati, modificati e contestati. Prima che vengano nominati, tendono a riapparire più tardi come sorpresa.

Un modello può essere capace, accuratamente documentato e prezioso. Può anche essere collocato in un sistema che pretende troppo da esso, nasconde troppo ai suoi utenti o lascia troppo poco spazio a una persona influenzata dal risultato. La differenza si gioca al di fuori dei pesi. È lì che vive il lavoro difficile, e anche dove si trova la vera opportunità: costruire sistemi la cui autorità corrisponde alle loro evidenze, i cui confini sopravvivono all'integrazione, e i cui operatori possono ancora dire di no.

Fonti