Quando una prova basta
Conoscenza, autorizzazione e possibilità di ricredersi nell'intelligenza artificiale
«Vai da un medico», «chiedi a un avvocato», «parlane con uno psicologo»: sono consigli ragionevoli e talvolta indispensabili. Per molte persone il problema comincia subito dopo. Servono denaro, tempo, un professionista disponibile, talvolta un mezzo per raggiungerlo. Nell'attesa, la domanda rimane, e la risposta più vicina può essere quella di un sistema di intelligenza artificiale.
Salvatore Sanfilippo ha posto con chiarezza questo problema nel video La gente chiede tutto alle AI: perché non ha scelta. [1] Per chi non trova assistenza professionale, il confronto reale è tra una risposta generata e nessuna risposta. L'argomento di Sanfilippo impone di guardare alle alternative davvero disponibili prima di giudicare chi usa questi strumenti. Non sostiene che un'IA sostituisca un medico, un avvocato o uno psicologo. Richiama le condizioni che spingono una persona a rivolgersi a lei.
Nel mio post Chi può permettersi di verificare una risposta? sono ripartito da quel ragionamento. [3] Ottenere una risposta è spesso economico e rapido. Verificarne l'accuratezza no: richiede competenze, relazioni, tempo, denaro, servizi che non sono alla portata di tutti. Due persone possono leggere la stessa clausola contrattuale. Una può rivolgersi a un professionista. L'altra deve decidere da sola quanto fidarsi. Lo strumento è accessibile a entrambe. La possibilità di controllarne l'uso no.
La lettura di Tradurre la realtà, di Leonardo Lastilla, ha offerto un contrappeso fondamentale a questa tesi. [2] Lastilla osserva che il significato di una risposta dipende da circostanze, esperienze, informazioni che la conversazione può non aver condiviso. Chi cerca aiuto dice ciò che riesce a esprimere e ciò che è disposto a rivelare. Un professionista competente coglie una lacuna, fa una domanda in più, collega una frase a una storia che il sistema non ha ricevuto. La verifica, quindi, non confronta soltanto una risposta con una fonte. Riconosce anche quali aspetti del caso restano inesplorati.
Questo saggio approfondisce un problema ulteriore. Quando un'organizzazione autorizza l'uso di un sistema e giustifica la decisione anche con controlli successivi, deve conservare la capacità di riconoscere gli errori e rivedere l'autorizzazione. Il passaggio dall'aiuto individuale al sistema organizzativo è diretto: in entrambi i casi, la possibilità di controllare una risposta è cruciale. Nell'organizzazione, però, questa possibilità dipende anche da procedure, ruoli, dati accessibili, e dal potere di interrompere un impiego già avviato.
Immaginiamo un gruppo di lavoro che sperimenta un sistema incaricato di dare priorità alle richieste di assistenza. Gli operatori leggono ogni richiesta, confrontano la priorità proposta con il proprio giudizio, registrano gli errori. Il verbale autorizza un uso limitato: il sistema propone la priorità, gli operatori controllano i casi e correggono le classificazioni sbagliate.
La prova raccolta è un elemento della decisione, non la decisione. Chi dà il via libera deve indicare l'uso autorizzato, gli errori tollerabili, le persone che ne subirebbero le conseguenze, i controlli che resteranno attivi. Un rapporto può attestare che il sistema ha raggiunto una certa precisione nel campione esaminato. Quel dato, da solo, non stabilisce quale impiego sia accettabile, né quali precauzioni l'organizzazione debba mantenere.
Roman Yampolskiy affronta il controllo dell'IA su una scala molto più ampia. In On Controllability of AI discute le difficoltà di prevedere, verificare e mantenere compatibile con gli scopi umani il comportamento di un'intelligenza artificiale generale o di una superintelligenza. [4] Il suo argomento non dimostra che ogni sistema oggi in uso sia inutilizzabile: un classificatore di richieste e un sistema capace di modificare i propri scopi pongono problemi diversi. Il preprint offre comunque una cautela utile. La frase «abbiamo controllato il sistema» richiede sempre di precisare quale azione si vuole impedire, con quale vincolo, per quanto tempo.
La differenza emerge osservando i permessi. Sapere se un modello produrrà sempre risposte appropriate richiede una prova diversa da sapere se può modificare un archivio. Nel secondo caso si possono esaminare accessi, integrazioni, registri, procedure di blocco. La verifica non garantisce che il sistema sia innocuo in ogni circostanza. Può accertare che un vincolo preciso funzioni nelle condizioni dichiarate, e anche questa certezza resta delimitata dall'azione, dall'ambiente, dal tempo.
Richard Rudner ha formulato, nel 1953, una domanda che aiuta a capire la natura della soglia. Chi accetta un'ipotesi scientifica deve stabilire quale grado di conferma sia sufficiente, e la soglia dipende anche dalla gravità dell'errore possibile. Un produttore di fibbie può tollerare un margine d'incertezza che sarebbe irresponsabile nel valutare una sostanza letale in un farmaco. [5] Heather Douglas ha analizzato il rischio induttivo: il modo in cui le conseguenze dell'errore entrano nella scelta dei metodi, nella descrizione dei dati, nell'interpretazione dei risultati. [6]
Le conseguenze non rendono vera un'ipotesi incerta, e il vantaggio atteso da un'innovazione non rafforza una prova debole: stabiliscono quanta evidenza serve, e quale decisione prendere quando l'evidenza resta incompleta. Marten H. L. Kaas e Ibrahim Habli distinguono il soddisfacimento descrittivo di requisiti già fissati dalla scelta normativa dei requisiti stessi. [7] Le prove possono mostrare che una soglia è stata raggiunta. Qualcuno deve comunque decidere quanto alta quella soglia debba essere, per l'uso previsto.
Nel caso ipotetico, la possibilità di trovare gli errori è parte delle ragioni che hanno consentito l'uso limitato. Supponiamo che, dopo alcuni mesi, l'organizzazione decida di ridurre il lavoro manuale. Gli operatori non leggeranno più tutte le richieste. Vedranno soltanto quelle che il sistema ha già segnalato come urgenti. La procedura fa risparmiare tempo, ma nasconde proprio l'errore più grave: una richiesta urgente classificata come ordinaria, sottratta così all'attenzione di chi avrebbe potuto riconoscerla.
Se gli errori registrati diminuiscono, il dato ammette almeno due spiegazioni. Il sistema può classificare meglio. Gli operatori possono anche rilevare meno errori perché esaminano meno richieste. Per distinguere le due ipotesi occorre un controllo indipendente, per esempio un campione estratto anche fra le richieste considerate ordinarie. Il numero degli errori noti non misura automaticamente il numero degli errori prodotti.
Qui sta il punto dell'argomento. Se l'autorizzazione poggiava sulla verifica successiva come condizione della propria accettabilità, l'organizzazione che riduce quella verifica deve riesaminare il permesso. Può sostituire il controllo con un metodo più efficace, restringere l'uso del sistema, sospenderlo. Non può invocare senza modifiche il verbale iniziale: ha cambiato una delle premesse che lo rendevano persuasivo. Questa è una mia interpretazione normativa dell'autorizzazione. Non la attribuisco a Sanfilippo, a Lastilla, né agli altri autori citati.
Il riesame non serve a punire chi ha preso la prima decisione. Serve a distinguere due fatti che possono divergere. Un sistema può continuare a produrre risultati buoni dopo che l'organizzazione ha indebolito il controllo. In assenza di un danno osservato non possiamo dimostrare che la prima autorizzazione fosse sbagliata. Possiamo però constatare che alcune ragioni invocate per mantenerla non valgono più allo stesso modo. La nuova decisione richiede prove e argomenti adeguati alle nuove condizioni.
Conservare ogni controllo precedente sarebbe un errore simmetrico. Una lettura completa e superficiale può offrire meno informazioni di un campionamento ben costruito; un controllo esterno può risultare più affidabile di un confronto interno. Chi propone una sostituzione deve indicare quali errori il nuovo metodo riesce ancora a rilevare, quali casi lascerà fuori, chi interverrà quando emergerà una deviazione. La questione riguarda l'efficacia della possibilità di ricredersi, non la fedeltà a una procedura passata.
I safety cases raccolgono argomenti e prove per sostenere che un sistema sia sufficientemente sicuro in un contesto definito. Clymer e altri discutono valutazioni delimitate nel tempo, monitoraggio e revoca quando nuove evidenze indeboliscono le condizioni iniziali. [8] Cârlan e altri propongono dynamic safety cases per aggiornare sistematicamente queste valutazioni quando cambiano le capacità del sistema, l'ambiente operativo o le conoscenze disponibili. [9] Questi lavori non garantiscono che un'organizzazione riesca sempre a intercettare un errore. Mostrano che ogni giustificazione della sicurezza ha un campo, delle condizioni, una durata, e che vanno resi espliciti.
Gjergji Kasneci ed Enkelejda Kasneci richiamano un problema vicino: la perdita della capacità di rendere visibili, contestare, contenere e correggere errori. [10] Il loro contributo impedisce di presentare come inedita l'idea che un sistema possa indebolire le condizioni del proprio controllo. La tesi di questo saggio è più circoscritta: quando quella capacità ha contribuito a giustificare un'autorizzazione, la sua riduzione modifica la giustificazione stessa e richiede un riesame.
Anche il riferimento alle previsioni performative ha un limite preciso. Juan Perdomo, Tijana Zrnic, Celestine Mendler-Dünner e Moritz Hardt studiano come l'uso di una previsione possa modificare la distribuzione dei dati che il modello osserverà in seguito. [11] Il loro problema matematico non coincide con quello discusso qui. Aiuta però a distinguere il cambiamento del sistema dal cambiamento della capacità dell'organizzazione di misurarlo. Dopo l'adozione, possono variare entrambi.
La presenza di una persona nel processo non basta a conservare il controllo. Una firma attesta che qualcuno ha approvato un'azione. Per valutarne il significato occorre sapere quali informazioni la persona ha esaminato, quanto tempo aveva, se poteva contestare o sospendere il sistema. Un operatore che riceve centinaia di proposte e viene valutato sulla rapidità dell'approvazione può confermarle senza verificarle. L'organizzazione conserva il gesto della supervisione, ma toglie alle persone il tempo e l'autorità necessari per esercitarla davvero.
Il problema riguarda soprattutto chi subisce le conseguenze senza aver partecipato alla decisione. Una persona che invia una richiesta di assistenza può ignorare che un sistema l'abbia classificata, e non possedere gli elementi per dimostrare subito un errore. Un procedimento corretto deve permetterle di segnalare un'informazione trascurata o una conseguenza che il sistema non ha considerato, e prevedere poi una risposta motivata. Chiederle di provare immediatamente l'errore può renderle impossibile ottenere la verifica che le manca. Torna qui il problema iniziale: l'accesso a una risposta non rende uguale l'accesso alle condizioni per contestarla.
Alcuni danni arrivano prima di qualsiasi riesame utile. Un errore può produrre conseguenze irreversibili prima che qualcuno riceva un segnale, lo interpreti, intervenga. Il monitoraggio può evitare una ripetizione, ma non protegge chi ha subito il primo effetto. Chi autorizza un sistema deve confrontare il tempo necessario per rilevare un difetto con il tempo nel quale quel difetto può produrre conseguenze. La promessa di intervenire dopo ha valore solo quando esiste davvero un dopo nel quale l'intervento possa ancora cambiare il risultato.
Secondo me, una decisione responsabile sull'IA deve indicare come l'organizzazione potrà ricredersi: quali risultati potrebbero modificare il giudizio, chi li osserverà, quali dati resteranno accessibili, chi potrà restringere o sospendere l'uso. Queste condizioni richiedono tempo, persone, risorse. Appartengono alle ragioni dell'autorizzazione, quando il controllo successivo è stato invocato per renderla accettabile.
Un verbale può essere breve. Deve però rendere consultabili l'uso consentito, i limiti delle prove, i dati da osservare, i ruoli che possono intervenire, le condizioni della sospensione. Una risposta automatica può essere il solo aiuto disponibile per una persona: per questo non basta esortarla genericamente a verificare. Un'organizzazione che la introduce in un servizio deve rendere praticabile quella verifica anche dopo avere dato il via libera. Quando elimina le persone, i dati o i passaggi che la rendevano possibile, deve conservare la capacità di rileggere la propria decisione e di cambiarla.
Riferimenti
- Salvatore Sanfilippo, La gente chiede tutto alle AI: perché non ha scelta, video. YouTube.
- Leonardo Lastilla, Tradurre la realtà, «Stultifera Navis». Testo.
- Calogero Bonasia, Chi può permettersi di verificare una risposta?, 5 settembre 2026. Testo.
- Roman V. Yampolskiy, On Controllability of AI, preprint, 2020. Testo e scheda.
- Richard Rudner, The Scientist Qua Scientist Makes Value Judgments, «Philosophy of Science», 20, 1, 1953, pp. 1–6. Scheda editoriale.
- Heather Douglas, Inductive Risk and Values in Science, «Philosophy of Science», 67, 4, 2000, pp. 559–579. DOI.
- Marten H. L. Kaas e Ibrahim Habli, Assuring AI safety: fallible knowledge and the Gricean maxims, pubblicato online nel 2024, «AI and Ethics», 5, 2025, pp. 1467–1480. Testo.
- Joshua Clymer, Nick Gabrieli, David Krueger e Thomas Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems, preprint, 2024, versione 2. Testo.
- Carmen Cârlan, Francesca Gomez, Yohan Mathew, Ketana Krishna, René King, Peter Gebauer e Ben R. Smith, Dynamic safety cases for frontier AI, preprint, 2024. Testo.
- Gjergji Kasneci ed Enkelejda Kasneci, The safety failures we are not instrumenting: a perspective on hidden safety-critical challenges in modern AI systems, «AI and Ethics», 6, articolo 295, 2026. Testo.
- Juan Perdomo, Tijana Zrnic, Celestine Mendler-Dünner e Moritz Hardt, Performative Prediction, «Proceedings of the 37th International Conference on Machine Learning», PMLR 119, 2020, pp. 7599–7609. Scheda e abstract.