Il paradosso della supervisione: perché controllare l'IA diventa più difficile quanto più funziona bene
Nel 2018, a Tempe, in Arizona, un veicolo a guida autonoma Uber ha investito e ucciso un pedone. Nell'abitacolo era presente un'operatrice di sicurezza il cui compito era monitorare il comportamento del veicolo e assicurarsi che la macchina a guida autonoma non commettesse errori. Le indagini sull'accaduto ritennero che l'incidente fosse dovuto alla fiducia ormai eccessiva che l'operatrice, dopo mesi di funzionamento senza problemi, aveva riposto nel sistema.
Un meccanismo noto da prima dell'IA generativa
Il fenomeno del caso di cronaca raccontato sopra ha un nome in letteratura scientifica, automation complacency (compiacenza da automazione) e precede di decenni ChatGPT. Già nel 1983 l'ergonomista Lisanne Bainbridge descriveva un paradosso che oggi suona quasi profetico. Quando un sistema si occupa dei compiti di routine, chi lo supervisiona smette di svolgerli in prima persona e quindi smette anche di esercitarsi su di essi. Il guaio è che quei compiti tornano tutti nelle sue mani proprio nei rari casi in cui il sistema si inceppa. Da qui la conclusione di Bainbridge, controintuitiva ma logica: un sistema affidabile toglie a chi lo supervisiona le occasioni naturali per restare allenato e va quindi accompagnato da più formazione mirata proprio ai casi rari.
Il primo esperimento a dare a questa intuizione una conferma empirica risale al 1993: bastavano circa venti minuti di funzionamento affidabile e costante di un sistema automatizzato perché la capacità dei soggetti di accorgersi di un suo guasto peggiorasse in modo netto. Da allora, decine di studi in aviazione, medicina e ingegneria hanno riprodotto lo stesso schema di fondo, confermando che tanto più un sistema è affidabile, tanto peggiore è la qualità della supervisione umana di quel sistema.
Quello che i dati sull'IA generativa aggiungono
Due studi recenti mostrano lo stesso meccanismo applicato agli strumenti di oggi.
Il primo ha seguito nel tempo gli stessi 400 revisori di codice generato da agenti IA, per un totale di oltre 11.000 revisioni in sette mesi. Il tasso di approvazione del codice è salito dal 30% al 37%, mentre le correzioni lasciate durante ogni revisione sono calate del 22%.
Il secondo studio, pubblicato nel 2025 sulla rivista The Lancet Gastroenterology & Hepatology, mostra il rovescio della stessa medaglia: endoscopisti esperti, dopo mesi di lavoro assistito da un sistema di IA per il rilevamento di polipi, hanno mostrato un calo del 20% nella propria capacità di individuarli quando l'IA non era presente.
Non stavano diventando meno bravi nel lavoro assistito. Stavano perdendo, senza accorgersene, l'abitudine a farlo da soli.
Perché un generico invito alla cautela non serve
L'istinto, di fronte a questi dati, è chiedere alle persone coinvolte nella supervisione più attenzione: un avviso, un promemoria, una raccomandazione a "usare l'IA con spirito critico". La ricerca, però, suggerisce che da sola questa strada non porta lontano e in certi casi è addirittura controproducente. Uno studio del 2021 ha confrontato diversi modi di incoraggiare le persone a controllare meglio i suggerimenti di un sistema IA: le spiegazioni testuali su come lo strumento arriva alle proprie conclusioni (la soluzione più diffusa nella pratica) non hanno ridotto l'affidamento eccessivo e in alcuni casi lo hanno addirittura aumentato.
Il problema, insomma, non è che le persone non sappiano di dover controllare. È che, quando un sistema ha dimostrato di essere affidabile abbastanza a lungo, smettono di avere un segnale interno che gli dica quando è il momento di farlo.
Che cosa funziona, quindi
Le ricerche che hanno testato interventi concreti convergono su un'idea di fondo: il controllo funziona quando resta un atto attivo, non quando si riduce a un passaggio burocratico.
Rendere le persone esplicitamente responsabili del risultato finale, e non solo del gesto formale di aver controllato, è la leva più solida: decenni di studi in aviazione mostrano che chi sa di rispondere personalmente dell'esito verifica con più attenzione e commette meno errori da eccessivo affidamento. Un secondo intervento, meno intuitivo ma ben supportato dai dati, consiste nel chiedere alle persone di formarsi un proprio giudizio prima ancora di vedere il suggerimento dell'IA: costa uno sforzo cognitivo in più e infatti tende a essere meno gradito, ma è l'unico tipo di intervento che, nella ricerca disponibile, ha ridotto l'affidamento eccessivo. Infine, utile, seppure ancora poco testato su larga scala, è inserire di tanto in tanto un errore deliberato in un output da revisionare, per verificare se chi supervisiona lo nota ancora.
Alla base di tutto, però, resta l'intuizione di Bainbridge: uno strumento affidabile non offre da solo le occasioni per imparare a riconoscerne i fallimenti, perché quei fallimenti sono rari per definizione. Quelle occasioni vanno quindi create apposta, con una formazione che mostri esattamente come e quando un sistema affidabile continua comunque a sbagliare.
Gli errori che nessuno raccoglie
Nel modo in cui si parla di adozione dell'IA in azienda, quasi tutto il discorso pubblico ruota intorno ai casi d'uso riusciti: quanto tempo si risparmia, quali processi si velocizzano, quali applicazioni hanno funzionato meglio. Quasi nessuno parla di come raccogliere, con la stessa cura, i casi in cui l'IA ha sbagliato.
È un'omissione che vale la pena correggere. Se il problema, come mostrano gli studi citati, è che gli errori di un sistema affidabile sono rari (e per questo non offrono occasioni naturali per imparare a riconoscerli), allora ogni errore realmente accaduto è un'occasione preziosa, non un incidente da archiviare in fretta una volta corretto. Osservare con attenzione come si è manifestato, quali segnali lo hanno preceduto, aiuta chi supervisiona a costruirsi nel tempo un repertorio di pattern a cui prestare attenzione la volta successiva.
Le organizzazioni che si limitano a collezionare casi di successo per giustificare l'investimento in IA si stanno perdendo la parte più utile dei dati che già possiedono: i propri errori.
Fonti
Bainbridge, "Ironies of Automation", Automatica (1983); Parasuraman, Molloy & Singh, International Journal of Aviation Psychology (1993); Parasuraman & Manzey, Human Factors (2010); Yu et al., preprint/KDD Workshop on Agentic Software Engineering (2026); Romańczyk et al., The Lancet Gastroenterology & Hepatology (2025); Buçinca, Malaya & Gajos, ACM CSCW (2021); Bo, Wan & Anderson, ACM CHI (2025); Mosier, Skitka et al. (1996, 2000); Noland v. Land of the Free, L.P., California Court of Appeal (2025); NTSB, Highway Accident Report HAR-19/03 sull'incidente Uber di Tempe, Arizona (2018).
Note di trasparenza sull'uso dell'IA
Per questo articolo l'intelligenza artificiale è stata usata in due fasi. Nella prima, per trovare le fonti, analizzarle ed estrarne i dati a sostegno della tesi. Nella seconda, per generare una prima bozza del testo, che l'autore ha poi rivisto e curato personalmente prima della pubblicazione.