Un saggio di Massimiliano Nicolini

Una macchina può sembrarci fuori controllo anche quando sta continuando un lavoro che le abbiamo affidato. Accade quando ricordiamo l’ultima richiesta, ma abbiamo perso la ricostruzione delle istruzioni precedenti, delle eccezioni introdotte e delle attività rimaste programmate. Il sistema produce allora un risultato che ci sorprende: noi lo confrontiamo con ciò che crediamo di aver stabilito; il processo lo genera sulla base della configurazione che sta effettivamente utilizzando. La distanza tra questi due stati costituisce una possibile origine dell’autonomia percepita.

La tesi che propongo riguarda questa distanza. Nei processi che integrano intelligenza artificiale, la perdita della storia delle decisioni può trasformare una delega in un comportamento apparentemente inspiegabile. La domanda tecnica da porre è quale insieme di istruzioni, dati, strumenti e autorizzazioni abbia reso possibile l’azione osservata. Ricostruire tale insieme permette di distinguere un incarico ancora attivo, una modifica applicata soltanto in parte, un errore di interpretazione e un difetto del software. Ciascuna causa richiede un intervento diverso.

Questa interpretazione ha un perimetro preciso. Non dimostra che ogni comportamento inatteso derivi da una dimenticanza umana, né consente di escludere i rischi propri dei modelli e delle applicazioni che li impiegano. Sostiene invece che la tracciabilità della delega sia una condizione necessaria per governare seriamente l’automazione. L’oggetto dell’analisi comprende quindi le persone che configurano il processo, i servizi che lo eseguono e le procedure con cui vengono autorizzate le modifiche.

La distanza tra conversazione e configurazione

Il linguaggio naturale rende molto semplice modificare una richiesta. Possiamo chiedere di aggiungere un passaggio, escludere un destinatario, cambiare un orario, ripetere un’attività oppure correggere un risultato. Questa semplicità dell’interfaccia nasconde una questione ingegneristica: una frase pronunciata in una conversazione deve diventare, se destinata a valere nel tempo, una modifica riconoscibile dello stato del sistema. Occorre sapere dove sia stata registrata, quale regola sostituisca, a quali attività si applichi e da quando produca effetti.

L’espressione «da ora fai così» contiene un’intenzione comprensibile alla persona che la pronuncia, ma lascia spesso implicito il suo campo di applicazione. Può riferirsi alla risposta corrente, al progetto in corso, a tutti i processi futuri oppure anche alle attività già avviate. Se l’applicazione non traduce questa distinzione in configurazioni esplicite, la correzione resta esposta a interpretazioni. Una conferma verbale dell’assistente può dare all’operatore la sensazione che tutto sia stato aggiornato, senza costituire una prova dell’effettiva modifica di ogni componente interessato.

La difficoltà cresce quando le istruzioni sono distribuite. Un documento contiene la procedura generale, una conversazione conserva un’eccezione, una funzione programmata include una copia precedente del testo e un database registra lo stato delle singole pratiche. Ognuno di questi elementi può essere internamente coerente, mentre il loro insieme produce contraddizioni. L’operatore continua a pensare a un unico interlocutore; l’infrastruttura esegue una pluralità di configurazioni, talvolta aggiornate in momenti diversi.

Il problema ha un precedente nella letteratura sul debito tecnico dei sistemi di apprendimento automatico. Sculley e colleghi descrivono costi e fragilità che emergono dalle dipendenze, dalle configurazioni e dalle interazioni dell’intero sistema, oltre il singolo modello [1]. Applicare questa prospettiva alle istruzioni degli assistenti è un’estensione interpretativa: invita a considerare la manutenzione delle regole come parte dell’ingegneria del processo, con una responsabilità e un costo propri.

Dove si trova realmente la capacità di agire

Per comprendere ciò che accade bisogna distinguere il modello linguistico dall’applicazione che lo utilizza. Il modello elabora gli input che riceve e genera un output. L’applicazione costruisce quegli input, decide quali documenti recuperare, espone strumenti e può trasformare una proposta del modello in una chiamata a un servizio. Un ulteriore componente può avviare il processo a un’ora stabilita o quando arriva un evento. La continuità dell’attività può quindi dipendere da un normale meccanismo di pianificazione, senza richiedere che il modello rimanga continuamente in esecuzione.

Le architetture agentiche possono attribuire al modello anche la scelta di passaggi intermedi: cercare un dato, valutarne l’utilità, richiamare uno strumento e aggiornare un piano in funzione del risultato. Il lavoro ReAct di Yao e colleghi costituisce un riferimento per l’interazione tra generazione di passaggi di ragionamento e azioni verso un ambiente esterno [2]. Questa capacità configura un’autonomia operativa reale: entro il perimetro concesso, il sistema seleziona azioni senza una nuova istruzione umana per ciascun passaggio.

L’autonomia operativa va distinta dall’attribuzione di volontà o intenzioni proprie. Osservare una sequenza di azioni non basta a dimostrare l’esistenza di un desiderio del sistema. Al tempo stesso, sarebbe tecnicamente inesatto ridurre un agente a un registratore che ripete soltanto comandi letterali. Un obiettivo generale può ammettere molte strategie; il modello può selezionarne una che l’operatore non aveva immaginato e può anche scegliere male. Il controllo deve riguardare tanto l’origine dell’incarico quanto lo spazio delle azioni consentite durante la sua esecuzione.

Nel caso concreto, l’analisi deve dunque separare quattro elementi: ciò che la persona ha chiesto, ciò che il modello ha proposto, ciò che l’applicazione ha autorizzato e ciò che il servizio esterno ha effettivamente eseguito. Confondere queste fasi impedisce di individuare il guasto. Un testo che annuncia un invio non prova che l’invio sia avvenuto; una chiamata riuscita non prova che fosse conforme all’incarico; un incarico originariamente valido può avere cessato di esserlo prima dell’esecuzione.

Le istruzioni non diventano automaticamente una memoria perfetta

L’immagine delle istruzioni che si cristallizzano nella macchina descrive bene la persistenza di una regola salvata in un file, in una configurazione o in un’attività programmata. Diventa però fuorviante se applicata indistintamente alla memoria di un modello. Nelle normali interazioni con un modello già addestrato, scrivere una nuova istruzione non equivale a modificarne immediatamente i pesi. La sua eventuale conservazione dipende dai meccanismi dell’applicazione: cronologia, memoria esterna, archivi documentali, registri delle attività o altri sistemi di persistenza.

Anche quando una conversazione viene conservata, non segue che il suo contenuto integrale sia presente a ogni esecuzione. Il contesto può essere limitato, selezionato, riassunto o ricostruito. Una sintesi può omettere la scadenza di un’eccezione; un recupero documentale può richiamare una versione superata; due regole possono entrare in conflitto. La priorità attribuita alle istruzioni dipende inoltre dall’architettura adottata: l’ultima frase scritta non è, per principio generale, una revoca affidabile di tutto ciò che la precede.

La ricerca Lost in the Middle ha mostrato, nei modelli e nei compiti esaminati, che la posizione delle informazioni all’interno di contesti lunghi può influenzare sensibilmente il loro utilizzo [3]. Il risultato non va esteso automaticamente a ogni sistema successivo; evidenzia tuttavia una distinzione essenziale tra avere un’informazione nell’input e riuscire a utilizzarla correttamente. Aumentare la quantità di testo conservato non garantisce, da solo, una migliore osservanza delle regole.

Possiamo quindi incontrare due problemi differenti. Il primo riguarda una disposizione che continua a essere applicata mentre l’operatore l’ha dimenticata. Il secondo riguarda una disposizione che l’operatore considera acquisita, ma che il sistema non recupera o non interpreta correttamente. Un metodo di controllo adeguato deve rilevare entrambe le situazioni. Limitarsi a conservare una conversazione molto lunga lascia irrisolta la domanda su quale politica operativa sia effettivamente in vigore.

Il debito istruzionale

Chiamo qui debito istruzionale il lavoro di ricostruzione, verifica e manutenzione che accumuliamo quando modifichiamo una procedura senza aggiornare in modo coerente la sua rappresentazione operativa. L’espressione serve a descrivere un problema organizzativo e tecnico; non indica una grandezza scientifica già standardizzata. Il debito cresce quando una correzione risolve l’urgenza del momento, lasciando incerti i rapporti con le regole precedenti.

Una procedura può autorizzare l’invio automatico di un documento, mentre una nota successiva prescrive una verifica preventiva soltanto per alcune categorie di destinatari. Una terza modifica introduce una scadenza, una quarta consente una deroga. Se le disposizioni rimangono sparse, ciascuna aggiunta aumenta lo sforzo necessario per capire quale comportamento sia ammesso in un caso concreto. La difficoltà dipende soprattutto dalle interazioni e dall’ampiezza delle regole; il semplice numero dei messaggi costituisce un indicatore insufficiente.

Le eccezioni senza termine sono particolarmente insidiose. Nascono spesso per gestire una circostanza contingente, ma possono sopravvivere alla ragione che le aveva motivate. Anche l’autorità di chi modifica una procedura conta: un collaboratore potrebbe correggere un dettaglio del proprio compito senza essere autorizzato a cambiare una regola generale. Se il sistema tratta ogni frase come equivalente, perde la distinzione tra suggerimento, istruzione locale e modifica della politica comune.

La manutenzione richiede perciò un atto esplicito di consolidamento. Dopo le correzioni si deve produrre una versione corrente leggibile, indicare quali regole cessano di valere e conservare separatamente la loro storia. Un riassunto generato automaticamente può aiutare a preparare questa versione, ma non costituisce da solo la prova della sua completezza. Il confronto con le modifiche originarie e la verifica dei casi di confine restano necessari quando l’aggiornamento cambia il comportamento di un processo.

Un processo che continua dopo una correzione

Consideriamo un caso ipotetico. Un ufficio incarica un assistente di raccogliere documenti dai fornitori e di inviare un sollecito ogni tre giorni finché una pratica non risulta completa. La procedura viene salvata come versione A e il sistema crea attività programmate. In seguito, l’operatore decide che qualsiasi risposta del fornitore debba sospendere i solleciti, anche se la documentazione è ancora incompleta. La nuova regola viene inserita nel documento principale come versione B.

Supponiamo che l’applicazione, per come è stata costruita, conservi nelle attività già programmate una copia della versione A e non la sostituisca automaticamente. Il fornitore risponde, ma la pratica rimane incompleta in attesa di verifica. Alla scadenza successiva parte un altro messaggio. Per l’operatore l’assistente ha ignorato un ordine recente; per il componente che esegue il lavoro, invece, la condizione prevista dalla configurazione caricata è ancora soddisfatta.

Passaggio	Stato effettivo	Conseguenza
Avvio	La versione A richiede solleciti fino al completamento.	Le attività programmate conservano questa regola.
Modifica	La versione B sospende i solleciti alla prima risposta.	Il documento principale cambia; le attività esistenti restano alla versione A.
Risposta	Il fornitore risponde; la pratica è ancora incompleta.	La nuova condizione di sospensione non viene applicata al lavoro già programmato.
Esecuzione	L’attività carica la versione A e trova la pratica incompleta.	Parte un sollecito incompatibile con l’intenzione aggiornata dell’operatore.

La spiegazione dipende dalla specifica architettura ipotizzata e va verificata nei registri. Se la ricostruzione la conferma, il difetto riguarda la propagazione della modifica e il controllo prima dell’invio. Il rimedio consiste nell’aggiornare o invalidare i lavori esistenti, rivalutare lo stato delle pratiche e verificare quale versione sia autorizzata al momento dell’azione. Aggiungere un’altra frase nella conversazione potrebbe lasciare intatta la causa.

L’esempio mostra anche perché attribuire tutto alla disattenzione dell’utente sarebbe riduttivo. Una persona può ricordare perfettamente la correzione e trovarsi comunque davanti a un’applicazione che non l’ha distribuita. La perdita di controllo può derivare da un disallineamento tra interfaccia, configurazione e stato di esecuzione. Per ricostruirlo servono prove tecniche accessibili, insieme a un’interfaccia capace di segnalare quali processi continuino a utilizzare una versione precedente.

Una traccia utile deve collegare intenzioni e azioni

Tenere traccia di ciò che diciamo alla macchina è un buon punto di partenza. Per trasformarlo in un metodo ingegneristico servono tre registri collegati. Il primo conserva l’origine delle istruzioni: testo pertinente, autore, momento della richiesta e ragione della modifica. Il secondo descrive la politica corrente: regole attive, ambito, priorità, eccezioni, scadenze e versione approvata. Il terzo documenta l’esecuzione: evento di avvio, dati utilizzati, strumenti richiamati, verifiche effettuate e risultati osservati.

Il collegamento tra i registri è decisivo. Ogni esecuzione dovrebbe avere un identificativo e riferirsi alla versione delle regole che ha ricevuto. Un’azione esterna dovrebbe poter essere ricondotta all’esecuzione che l’ha prodotta e alla verifica che ne ha consentito il compimento. Quando rilevanti e tecnicamente disponibili, vanno registrati anche il modello impiegato, i suoi parametri di generazione e le versioni dei componenti software. Il livello di dettaglio deve essere proporzionato alle conseguenze dell’attività.

La registrazione dovrebbe permettere di distinguere una proposta da un effetto confermato. Per un aggiornamento di un archivio, per esempio, risultano utili l’identificativo del record, la modifica richiesta, l’esito restituito dal servizio e la verifica dello stato successivo. Per un’attività pianificata servono inoltre il criterio di attivazione, la prossima esecuzione, le condizioni di sospensione e la persona responsabile. Questi dati consentono di rispondere a una domanda concreta: quali lavori possono ancora produrre effetti senza un nuovo intervento umano?

I registri documentano la provenienza operativa e gli eventi osservabili; non forniscono necessariamente una spiegazione completa del funzionamento interno del modello. Anche una motivazione testuale generata dall’assistente può essere incompleta o inesatta. Deve essere trattata come una dichiarazione da confrontare con le evidenze, non come un accesso privilegiato alla causa di ogni scelta. Non occorre acquisire un presunto flusso mentale interno per verificare se un’azione fosse autorizzata e se sia stata realmente eseguita.

Registrare tutto non significa infine conservare indiscriminatamente ogni contenuto. Il sistema deve proteggere credenziali, dati personali e informazioni riservate, prevedendo accessi selettivi e tempi di conservazione adeguati. Quando serve, si possono mantenere riferimenti a documenti protetti, copie controllate o impronte crittografiche. Un’impronta può aiutare a verificare l’identità di un contenuto disponibile, ma non consente di ricostruire un testo che sia stato eliminato. La progettazione del registro deve rendere espliciti questi limiti.

La tracciabilità deve diventare capacità di intervento

Un archivio accurato permette di capire un incidente dopo che è avvenuto. Il governo del processo richiede anche controlli prima dell’effetto esterno. Per le operazioni rilevanti, conviene separare la proposta del modello dalla decisione dell’applicazione di eseguirla. Il sistema deve verificare in modo esplicito che lo strumento, l’oggetto dell’azione e il destinatario rientrino nell’incarico valido, che la delega non sia scaduta e che le eventuali condizioni di approvazione siano soddisfatte.

Una regola che vieta un’azione dovrebbe trovare riscontro nei permessi e nei controlli del software quando ciò è possibile. Scrivere nel prompt che un assistente non deve modificare un archivio è meno robusto che concedergli soltanto accesso in lettura. Analogamente, un processo autorizzato a preparare una comunicazione può essere configurato in modo da non disporre direttamente della capacità di inviarla. I limiti tecnici rendono concreta la distinzione tra ciò che il modello sa proporre e ciò che l’applicazione può compiere.

Le modifiche alle procedure richiedono un meccanismo di distribuzione controllato. La versione nuova deve indicare se si applica soltanto ai lavori futuri oppure anche a quelli pendenti. Prima di eseguire un’azione con conseguenze esterne, il sistema dovrebbe verificare che la versione caricata sia ancora valida per quel lavoro. La verifica va collocata il più vicino possibile all’effetto e, quando l’architettura lo consente, resa atomica rispetto all’autorizzazione, per ridurre il rischio che una revoca intervenuta nel frattempo venga ignorata.

Anche l’arresto deve essere una funzione dell’infrastruttura. Un comando di sospensione deve raggiungere la pianificazione, i lavori in coda e le autorizzazioni necessarie a produrre nuovi effetti. Scrivere «fermati» in una conversazione è insufficiente se le attività indipendenti non ricevono quel segnale. Occorre inoltre chiarire che cosa si possa fermare immediatamente, quale operazione sia già in corso e quali effetti siano ormai avvenuti. La sospensione impedisce la prosecuzione entro i limiti tecnici del sistema; non cancella automaticamente un messaggio già consegnato.

Il ripristino di una versione precedente delle istruzioni presenta lo stesso limite. Può riportare la configurazione a uno stato noto, mentre i dati o il mondo esterno sono già cambiati. Correggere gli effetti richiede eventuali operazioni compensative, che devono a loro volta essere autorizzate e verificabili. Un controllo maturo distingue quindi la revoca dell’incarico, l’interruzione dell’esecuzione e la gestione delle conseguenze già prodotte.

Ciò che la storia delle istruzioni non spiega da sola

Anche con registri completi restano possibili errori. Un modello può interpretare male una condizione, generare informazioni inesatte, scegliere una strategia inadatta oppure classificare erroneamente un risultato ricevuto da uno strumento. Un servizio può restituire dati superati; un difetto di integrazione può duplicare un’operazione. La storia delle istruzioni aiuta a circoscrivere questi problemi, ma non garantisce che il comportamento risultante coincida con l’intenzione della persona.

Esiste inoltre il rischio che contenuti esterni vengano trattati impropriamente come istruzioni. Greshake e colleghi hanno studiato attacchi di prompt injection indiretta, nei quali indicazioni inserite in dati recuperati dall’applicazione possono interferire con il suo comportamento [4]. In questi casi la provenienza è essenziale: il testo di un documento da analizzare non deve acquisire, solo perché viene letto, l’autorità di modificare l’incarico. La separazione tra contenuti informativi e comandi autorizzati deve essere sostenuta da controlli applicativi.

La stessa riproduzione di un evento ha limiti. Ripetere la richiesta può produrre un risultato differente per effetto del campionamento, di un aggiornamento del modello o di un cambiamento nei dati esterni. Anche quando la generazione è configurata per ridurre la variabilità, non si deve presumere una riproducibilità assoluta dell’intero processo. Per analizzare un incidente può essere necessario conservare le risposte degli strumenti e ricostruire l’ambiente in cui l’azione si è svolta.

Questi limiti rendono la tesi più precisa. La mancata ricostruzione delle istruzioni è una possibile causa della sorpresa, da verificare insieme alle altre. Non è una spiegazione universale e non assolve i produttori da errori di progettazione. Un comportamento dannoso resta tale anche quando se ne individua l’origine. La spiegabilità operativa consente di intervenire con maggiore precisione; la sicurezza richiede anche prevenzione, prove e vincoli adeguati.

Come sottoporre la tesi a verifica

L’ipotesi può essere studiata attraverso un esperimento su processi simulati. A gruppi di operatori si affida lo stesso insieme di attività e si introducono modifiche successive, eccezioni, revoche e variazioni dello stato esterno. Un gruppo dispone soltanto della cronologia delle conversazioni; un altro utilizza anche una versione consolidata delle regole e un registro delle esecuzioni. Modello, strumenti, condizioni iniziali e difficoltà dei compiti devono essere mantenuti comparabili.

Per separare il valore della documentazione da quello dei blocchi tecnici, un ulteriore gruppo può ricevere gli stessi registri insieme a controlli di autorizzazione e sospensione. Questa distinzione evita di attribuire alla sola tracciabilità benefici che dipendono, invece, dall’impedimento materiale di un’azione. Occorre includere casi con istruzioni obsolete e casi con errori del modello o dei servizi: una spiegazione valida deve saper riconoscere anche quando la propria ipotesi non si applica.

Indicatore	Misura proposta
Ricostruzione dell’incarico	Quota di casi in cui l’operatore identifica correttamente regola applicata, versione e ambito.
Tempo di diagnosi	Tempo necessario a individuare la causa verificata del comportamento inatteso.
Conformità dell’esecuzione	Quota di azioni esterne compatibili con l’incarico effettivamente vigente.
Efficacia della sospensione	Tempo tra revoca e blocco dei nuovi effetti, con conteggio delle azioni compiute nell’intervallo.

Andrebbe misurata separatamente anche la percezione di controllo degli operatori. Una maggiore fiducia, se accompagnata da errori invariati, potrebbe indicare soltanto un’interfaccia rassicurante. Il risultato utile sarebbe un miglioramento osservabile nella diagnosi e nella conformità delle azioni. Questo disegno di verifica è una proposta metodologica: non presenta risultati sperimentali e non attribuisce al fenomeno una frequenza che non sia stata misurata.

La responsabilità di una delega che continua nel tempo

L’attenzione individuale rimane importante, ma una procedura affidabile non può dipendere dalla capacità di una persona di ricordare ogni correzione impartita nell’arco di mesi. Quando più operatori intervengono sugli stessi processi, il problema diventa una responsabilità organizzativa. Deve essere riconoscibile chi può modificare le regole, chi ne verifica l’applicazione, chi gestisce gli incidenti e chi dispone dell’autorità effettiva per sospendere il lavoro.

Anche il passaggio di consegne cambia natura. Trasferire una lunga cronologia non equivale a consegnare il controllo di un sistema. Chi subentra deve poter leggere la politica corrente, identificare le deleghe ancora aperte e conoscere le condizioni che ne determineranno la chiusura. Un incarico privo di scadenza richiede almeno una revisione periodica esplicita, perché la validità di un’autorizzazione può dipendere da circostanze che nel frattempo sono cambiate.

La raccomandazione di tenere traccia di ciò che chiediamo all’intelligenza artificiale acquista così un significato operativo preciso: ogni delega deve avere un’origine ricostruibile, un perimetro verificabile e un modo effettivo di essere revocata. L’obiettivo è rendere valutabile la fiducia che accordiamo al processo. Quando sappiamo quali attività sono aperte, in base a quali regole procedono e dove possiamo intervenire, una parte dell’apparente imprevedibilità diventa un problema tecnico identificabile. La responsabilità umana continua per tutta la durata dell’incarico, fino alla verifica dei suoi effetti.

Riferimenti bibliografici

[1] Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28, pp. 2503–2511. Testo integrale.

[2] Yao, S., et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. International Conference on Learning Representations. Preprint arXiv:2210.03629. Testo integrale.

[3] Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. Preprint arXiv:2307.03172, versione consultata del 20 novembre 2023. Testo integrale.

[4] Greshake, K., et al. (2023). Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Preprint arXiv:2302.12173. Testo integrale.

Elaborazione visiva con intelligenza artificiale a partire dalla fotografia fornita dall’autore.