Prima di delegare a una macchina
Chiediamo a un agente di intelligenza artificiale di modificare un documento. Scriviamo le istruzioni e aspettiamo il file aggiornato. Sembra un’operazione semplice, almeno dalla nostra parte dello schermo. Per arrivare al risultato, però, il modello deve chiedere di usare uno strumento e un programma deve ricevere quella richiesta, controllare i permessi, aprire il file e scrivere le modifiche. Insomma, fra la nostra richiesta e il documento aggiornato ci sono diversi passaggi, ciascuno con le proprie regole.
Già da questo esempio si vede che qualcuno, prima ancora di avviare il lavoro, ha dovuto prendere alcune decisioni. Quali documenti può aprire il programma? Quali può modificare? E chi controlla che le modifiche siano corrette? Quando scriviamo una richiesta nella finestra di conversazione, tutte queste scelte rimangono sullo sfondo. Noi vediamo il documento che arriva, mentre i passaggi che hanno permesso di produrlo sono molto meno visibili.
L’insieme dei meccanismi che coordina il modello, gli strumenti, le informazioni disponibili e l’avanzamento del lavoro viene chiamato, nel lessico tecnico, agent harness. Attraverso questi meccanismi si stabilisce come il sistema deve procedere, che cosa conservare dopo un’operazione e quando fermarsi. Si tratta, quindi, anche di governare il lavoro: assegnare compiti, concedere accessi, fissare limiti e verificare risultati.
Proviamo allora a seguire un incarico dall’inizio. Un agente deve aggiornare una procedura aziendale. Apre una cartella, trova un documento recente, integra alcune osservazioni e restituisce una nuova versione. A prima vista sembra tutto a posto: il testo è chiaro, i paragrafi sono ordinati e il riepilogo descrive le modifiche. Poi scopriamo che il documento di partenza era una bozza e che alcune osservazioni erano ancora in discussione. Il file è stato aggiornato, certo. Per usarlo, però, dovremo ricontrollare da capo quali modifiche erano autorizzate.
Il problema era già presente nella cartella. Qualcuno avrebbe dovuto distinguere la procedura in vigore dalle copie di lavoro e indicare quali osservazioni erano già state approvate. Se questa distinzione manca, l’agente può leggere tutti i documenti e trovarsi comunque senza l’informazione necessaria per scegliere. La data più recente, da sola, dice quando un file è stato modificato. Per sapere se il contenuto è valido serve anche conoscere chi lo ha approvato e per quale uso.
A questo punto viene spontaneo pensare che basti formulare meglio la richiesta. In effetti, istruzioni più precise aiutano. Scrivere «usa la versione approvata», però, serve a poco quando l’approvazione non è registrata da nessuna parte. Lo stesso accade con «verifica il risultato»: dobbiamo stabilire che cosa controllare e quale esito considerare accettabile. Altrimenti affidiamo al sistema anche una scelta che avremmo dovuto chiarire prima.
Nel saggio Leverage Points: Places to Intervene in a System, Donella Meadows distingue dodici punti sui quali intervenire per modificare il comportamento di un sistema. Cambiare un parametro, far circolare un’informazione, modificare una regola o rivedere un obiettivo hanno, nella sua analisi, un diverso potere di cambiamento. Meadows accompagna questa gerarchia con una cautela importante: riconoscere un punto influente richiede anche di capire in quale direzione intervenire.
Questa distinzione mi sembra utile anche quando decidiamo come deve lavorare un agente. Aumentare il numero dei tentativi può risolvere un errore occasionale. Dare accesso a un’altra cartella può fornire un documento mancante. Stabilire che il lavoro si conclude soltanto dopo una determinata verifica cambia invece il percorso necessario per portarlo a termine. Sono interventi diversi, anche se nel programma compaiono uno accanto all’altro fra le opzioni da configurare.
Torniamo alla nostra procedura. Se basta produrre un nuovo file, l’agente può fermarsi appena lo ha scritto. Se deve anche controllare la fonte, conservare le modifiche e attendere la convalida del responsabile, lo stesso file rappresenta un risultato intermedio. La differenza dipende da ciò che abbiamo deciso di chiamare «completato». Secondo me, conviene soffermarsi proprio su questa parola, perché da lì discende una parte considerevole del lavoro che il sistema svolgerà, o lascerà da fare agli altri.
Anche il controllo, del resto, può essere eseguito bene e riguardare la cosa sbagliata. Verificare che un documento si apra dimostra che il file è leggibile. Confrontarlo con la procedura in vigore permette di controllare quali parti sono cambiate. Accertare che quelle modifiche corrispondano alle decisioni approvate richiede un ulteriore confronto. Se ci fermiamo al primo controllo, potremo avere un file tecnicamente integro che contiene indicazioni mai autorizzate.
Il risultato di una verifica può poi tornare al modello e orientare l’operazione successiva. È un meccanismo di retroazione: il sistema riceve informazioni sugli effetti di ciò che ha fatto e le usa per correggere il proprio comportamento. Ma se la verifica osserva soltanto che il file si apre, nella correzione continuerà a mancare il punto decisivo. Ripetere quel controllo dieci volte ci darà dieci conferme della leggibilità del documento, lasciando intatto il dubbio sulla validità del contenuto.
C’è poi un problema più pratico: che cosa succede quando il lavoro si interrompe? Immaginiamo che un agente aggiorni un archivio e che la comunicazione cada prima dell’arrivo della conferma. L’aggiornamento potrebbe essere già avvenuto. Ripetere subito l’operazione rischia quindi di creare una seconda registrazione. Prima di ripartire occorre guardare che cosa è stato effettivamente scritto.
Per questo serve conservare una traccia che distingua la richiesta, l’esecuzione e la verifica. «Ho chiesto di aggiornare l’archivio», «l’archivio è stato aggiornato» e «ho controllato il nuovo contenuto» descrivono tre passaggi diversi. Se il riepilogo li raccoglie tutti sotto «operazione completata», chi riprende il lavoro dovrà ricostruirli. Avere una cronologia molto lunga aiuta poco quando manca proprio la distinzione che ci consentirebbe di capire dove ci siamo fermati.
Qualcosa di simile accade con la memoria. Possiamo conservare migliaia di documenti e lasciare fuori dalla singola operazione quello necessario. Possiamo anche preparare un buon riepilogo e perdere, nel riassumere, l’eccezione che limitava un’autorizzazione. Oppure recuperare una nota corretta quando fu scritta, ma ormai superata. Insomma, bisogna poter ritrovare l’informazione e controllare che sia ancora valida per la decisione da prendere.
Una volta recuperato un documento, inoltre, occorre capire quale uso farne. Potrebbe contenere una proposta, un ordine rivolto a un’altra persona o un’istruzione ormai scaduta. Leggere quelle parole non autorizza il sistema a eseguirle. Se un documento propone di cancellare un archivio, l’agente deve poter esaminare la proposta senza ricevere per questo il permesso di cancellarlo. La distinzione va mantenuta anche nei programmi che rendono possibile l’operazione.
Si potrebbe allora chiedere una conferma umana per qualsiasi passaggio. Il rischio, però, è riempire la giornata di richieste tutte uguali, fino a rendere abituale l’approvazione distratta. Vale la pena distinguere: preparare una copia da esaminare e sostituire una procedura in uso producono conseguenze diverse. Il controllo dovrebbe tenerne conto, riservando la decisione della persona ai passaggi nei quali occorre davvero valutarne gli effetti.
E bisogna anche prevedere quando fermarsi. Se manca una fonte, se due versioni si contraddicono o se l’esito di un’operazione rimane incerto, continuare a tentare può aggiungere errori a quelli già presenti. In questi casi, chi riprenderà il lavoro deve sapere che cosa è stato fatto, che cosa resta da verificare e quale informazione manca. Un messaggio rassicurante che dichiari tutto concluso gli toglierebbe proprio la possibilità di intervenire.
Alla fine, la prova sarà nell’uso che qualcuno farà del risultato. La procedura aggiornata dovrà dare indicazioni valide a chi la consulta. Se per riuscirci occorre ricostruire le autorizzazioni, confrontare di nuovo le versioni e correggere le prescrizioni introdotte per errore, una parte del lavoro è stata soltanto trasferita a chi viene dopo.
Torniamo allora al documento che avevamo chiesto di modificare. Quando il nuovo file sarà pronto, dovremo poter controllare da quale versione è partito l’agente, quali indicazioni ha seguito e chi aveva autorizzato le modifiche. Altrimenti avremo un documento scritto più in fretta e qualcuno ancora incaricato di capire se possiamo usarlo.