Quando si parla dei rischi legati all’intelligenza artificiale, una delle rassicurazioni più frequenti è che la decisione finale rimarrà comunque nelle mani di una persona. Il sistema analizza i dati, produce una raccomandazione, assegna magari un punteggio o segnala un’anomalia, ma prima che quella valutazione produca conseguenze concrete interviene un essere umano.
Indice degli argomenti
Human-in-the-loop: la promessa rassicurante
È il principio dello human-in-the-loop: mantenere una persona all’interno del processo decisionale affinché possa verificare, correggere o respingere ciò che propone la macchina.
Sulla carta il meccanismo sembra semplice. Ma immaginiamo un operatore che ogni giorno riceve centinaia di pratiche già elaborate da un sistema automatico. Per ciascuna vede una raccomandazione, alcuni dati di supporto e due possibili azioni: approvare oppure rifiutare. La decisione formalmente rimane sua.
Il problema cambia se quello stesso operatore dispone di pochi minuti, o persino pochi secondi, per esaminare ogni caso. Cambia ancora se il sistema si è dimostrato corretto nella grande maggioranza delle occasioni precedenti. E cambia ulteriormente se discostarsi dalla raccomandazione richiede più tempo, una motivazione o l’apertura di una procedura aggiuntiva.
A quel punto la domanda non è più semplicemente se una persona sia presente nel processo. Bisogna chiedersi quanto controllo riesca realmente a esercitare.
È qui che lo human-in-the-loop smette di essere soltanto una scelta tecnica e diventa un problema di progettazione organizzativa.
Essere nel loop non significa avere il controllo
Dietro l’espressione human-in-the-loop possono nascondersi configurazioni molto diverse. Un sistema può limitarsi a fornire informazioni che una persona utilizzerà per formulare autonomamente una decisione. Può produrre direttamente una raccomandazione da approvare. Può prendere una decisione automatica salvo chiedere l’intervento umano nei casi incerti. Oppure può funzionare autonomamente e lasciare agli operatori il compito di controllare soltanto una parte degli output.
In tutti questi casi esiste una componente umana, ma il suo peso nel processo è completamente diverso.
Non è quindi sufficiente sapere che “un umano controlla”. Bisogna capire cosa vede, quanto tempo dispone, quali competenze possiede e soprattutto che cosa può fare quando non è d’accordo.
La stessa impostazione emerge dall’AI Act europeo. Per i sistemi di IA ad alto rischio, l’articolo 14 non si limita a richiedere genericamente la presenza di una persona: parla di una supervisione che deve poter essere esercitata effettivamente. Chi svolge questo ruolo deve essere in grado di comprenderne capacità e limiti, interpretare gli output e, quando necessario, ignorarli, modificarli o invertirli.
È una distinzione importante perché separa due concetti che rischiano spesso di essere confusi: presenza umana e potere umano.
Inserire una persona nella catena decisionale è relativamente semplice. Garantire che quella persona mantenga autonomia di giudizio lo è molto meno.
Il controllo può quindi essere formalmente presente ma sostanzialmente debole. Un operatore può essere indicato come responsabile della decisione e, allo stesso tempo, avere pochissimo spazio per costruire una valutazione indipendente dalla raccomandazione automatica.
Quando la supervisione diventa approvazione automatica
Il problema diventa particolarmente evidente quando l’interazione con il sistema è ripetitiva. Le prime volte che una persona utilizza uno strumento automatico tende probabilmente a verificarne con maggiore attenzione i risultati. Controlla i dati, confronta la raccomandazione con ciò che avrebbe deciso autonomamente, cerca eventuali incongruenze.
Poi il sistema continua a suggerire risposte plausibili. Dopo decine o centinaia di decisioni corrette, il rapporto può cambiare. L’output non viene più percepito come un’ipotesi da verificare, ma come il punto di partenza normalmente corretto dal quale discostarsi soltanto in presenza di qualcosa di chiaramente anomalo.
La differenza è sottile, ma sostanziale. Nel primo caso l’operatore pensa: “Devo capire se questa decisione è corretta.” Nel secondo: “Devo capire se esiste qualche ragione per cui questa decisione potrebbe essere sbagliata.” La raccomandazione automatica diventa così il valore di default.
Ed è proprio questo uno dei problemi associati all’automation bias: la tendenza ad affidarsi eccessivamente alle indicazioni prodotte dai sistemi automatici. Non è un rischio teorico confinato agli studi sull’interazione uomo-macchina. L’AI Act lo cita esplicitamente tra gli aspetti di cui chi esercita la supervisione sui sistemi ad alto rischio deve essere consapevole.
In questo scenario l’essere umano continua a premere materialmente il pulsante finale, ma il centro della decisione si è già spostato.
L’operatore non costruisce più necessariamente una valutazione propria: controlla che quella della macchina non presenti errori abbastanza evidenti da giustificare un intervento.
Il carico di lavoro come limite strutturale
C’è poi un problema molto più semplice e spesso meno discusso: gli esseri umani non scalano alla stessa velocità dei sistemi automatici.
Un software può analizzare migliaia di record in pochi secondi, produrre altrettante classificazioni e ripetere il processo senza stanchezza. L’operatore chiamato a controllarne i risultati dispone invece di una quantità limitata di tempo e attenzione.
Se l’automazione aumenta il numero di decisioni che un’organizzazione può produrre ma la capacità di controllo rimane invariata, prima o poi si crea un collo di bottiglia.
L’organizzazione ha quindi diverse possibilità: aumentare il numero di persone incaricate della supervisione, ridurre il numero di casi sottoposti a controllo oppure diminuire il tempo dedicato a ciascuna verifica.
Quest’ultima è probabilmente la soluzione più semplice, ma anche quella che rischia di svuotare progressivamente il concetto stesso di supervisione.
Cinque minuti per valutare una pratica e trenta secondi non rappresentano semplicemente due livelli diversi di efficienza. Possono rappresentare due attività completamente differenti.
Nel primo caso è possibile leggere i dati, individuare incongruenze, confrontare informazioni. Nel secondo il controllo rischia di ridursi alla ricerca di anomalie immediatamente visibili.
Per questo la capacità di supervisione umana dovrebbe essere considerata una risorsa finita dell’architettura, esattamente come lo sono la capacità computazionale, la memoria o la disponibilità dei dati.
Non è sufficiente progettare quanto velocemente un modello riesca a produrre decisioni. Bisogna progettare anche quanto velocemente quelle decisioni possano essere controllate senza trasformare la verifica in un gesto quasi automatico.
Quando anche l’interfaccia spinge verso il sì
La qualità della supervisione dipende inoltre da un elemento che può sembrare secondario: il modo in cui la decisione viene presentata.
Immaginiamo due interfacce.
Nella prima l’operatore vede inizialmente i dati del caso, formula una valutazione e soltanto successivamente può confrontarla con la raccomandazione prodotta dal modello.
Nella seconda compare immediatamente:
Raccomandazione: APPROVARE
Confidenza del modello: 96%
I dati sottostanti sono gli stessi. Il modello è lo stesso. Anche l’operatore è lo stesso. Eppure il processo cognitivo non lo è più.
Nel secondo caso esiste già un punto di riferimento attorno al quale costruire il giudizio.
Anche piccoli dettagli possono incidere: un pulsante di approvazione evidenziato più del rifiuto, la necessità di motivare soltanto gli override, un numero elevato di passaggi per contestare la raccomandazione, oppure dashboard progettate principalmente per “smaltire” velocemente una coda di decisioni.
Il design dell’interfaccia diventa quindi parte del sistema di controllo.
Un’organizzazione può dichiarare che l’operatore possiede piena libertà di accettare o respingere il suggerimento automatico. Ma se accettarlo richiede un clic e contestarlo significa aprire una schermata, compilare un campo e giustificare la scelta, le due alternative non hanno realmente lo stesso costo.
Questo non significa che ogni forma di attrito sia sbagliata. In alcuni contesti potrebbe essere utile proprio il contrario: introdurre intenzionalmente un po’ di frizione nelle decisioni più delicate, evitando che vengano approvate con la stessa facilità di quelle ordinarie.
La questione è comprendere quale comportamento stiamo rendendo più semplice attraverso il design.
Automation bias e perdita del giudizio indipendente
L’automation bias diventa ancora più problematico quando il sistema raggiunge livelli elevati di accuratezza.
Paradossalmente, un sistema quasi sempre corretto può diventare più difficile da supervisionare di uno palesemente imperfetto.
Se un algoritmo sbaglia spesso, chi lo utilizza impara rapidamente a non fidarsi. Se invece produce per settimane o mesi risultati coerenti e affidabili, ogni nuova raccomandazione beneficia indirettamente della credibilità accumulata dalle precedenti.
Ed è proprio nei pochi casi in cui il sistema sbaglia che la supervisione dovrebbe essere più utile.
Si crea quindi un paradosso: più un sistema dimostra di funzionare, più può diventare difficile mantenere un controllo umano realmente indipendente.
Il NIST, nel suo AI Risk Management Framework, dedica attenzione proprio all’interazione tra fattori umani e sistemi di IA. Tra gli aspetti da considerare indica quanto gli operatori siano realmente messi nelle condizioni e incentivati a contestare i suggerimenti dell’AI, oltre all’utilità di osservare con quale frequenza e per quali motivi le raccomandazioni vengano ribaltate.
Il punto non è pretendere che gli esseri umani contraddicano periodicamente l’algoritmo per dimostrare la propria utilità.
Un tasso molto basso di override può semplicemente indicare che il sistema funziona bene.
Ma se il 99,9% delle raccomandazioni viene approvato, quel numero da solo non permette di distinguere tra due scenari molto diversi: un modello estremamente affidabile e una supervisione diventata puramente rituale.
Per capirlo servono altre informazioni.
Chi è responsabile quando l’umano ha solo premuto “Approva”?
Il problema della supervisione diventa inevitabilmente anche un problema di responsabilità.
Immaginiamo che una raccomandazione automatica produca una conseguenza sbagliata e che l’operatore l’abbia approvata.
La ricostruzione formale è semplice: il sistema non prendeva la decisione finale, ma offriva soltanto un supporto. A decidere era una persona.
Ma fermarsi all’ultimo clic rischia di offrire una rappresentazione incompleta di ciò che è accaduto.
L’operatore aveva il tempo necessario per valutare il caso? Disponeva delle informazioni utili per individuare l’errore? Conosceva i limiti del modello? Poteva modificare facilmente la decisione? Era prevista un’escalation? Contestare frequentemente l’algoritmo aveva conseguenze sulle sue performance lavorative?
Sono domande che spostano la responsabilità dal singolo gesto verso l’intero processo.
Il NIST osserva, del resto, che ruoli e responsabilità all’interno delle configurazioni uomo-AI devono essere chiaramente definiti e che un esperto di dominio non possiede necessariamente, per il solo fatto di essere tale, le competenze necessarie per svolgere funzioni di supervisione o governance di un sistema di IA.
La presenza dell’essere umano non dovrebbe quindi diventare una sorta di assicurazione organizzativa.
“C’era una persona che poteva intervenire” non equivale automaticamente a “quella persona aveva realmente gli strumenti per farlo”.
Il rischio è che lo human-in-the-loop finisca per aggiungere un nome umano alla fine di una catena decisionale senza aggiungere una proporzionata capacità di controllo.
E quando qualcosa va storto, quello stesso nome diventa il candidato più semplice al quale attribuire la decisione.
Più controllo umano non significa necessariamente più sicurezza
A questo punto sarebbe facile arrivare alla conclusione opposta: se il problema è una supervisione insufficiente, allora ogni decisione dovrebbe essere controllata con maggiore attenzione da una persona.
Ma nemmeno questa soluzione è necessariamente sostenibile.
Obbligare gli operatori a verificare manualmente ogni singolo output prodotto da un sistema ad alta velocità può moltiplicare proprio i problemi appena descritti: sovraccarico, stanchezza, perdita di attenzione e approvazione meccanica.
In alcuni contesti potrebbe essere molto più efficace concentrare la supervisione sui casi nei quali può davvero fare la differenza.
Un sistema potrebbe gestire automaticamente operazioni a basso rischio e con elevata confidenza, mentre i casi anomali, quelli vicini alle soglie decisionali o quelli che possono produrre conseguenze più rilevanti vengono inviati a una revisione più approfondita.
A questo possono aggiungersi controlli a campione anche sulle decisioni considerate semplici, audit periodici e meccanismi capaci di rilevare variazioni nelle prestazioni del modello.
L’obiettivo non dovrebbe quindi essere massimizzare il numero di decisioni toccate da un essere umano.
Dovrebbe essere massimizzare l’utilità dell’intervento umano.
Controllare superficialmente il cento per cento delle decisioni non è necessariamente più sicuro che controllarne attentamente una parte ben selezionata.
La quantità della supervisione e la sua qualità non sono la stessa cosa.
Come progettare una supervisione realmente efficace
Se lo human-in-the-loop deve rappresentare una garanzia, il controllo umano deve quindi essere progettato insieme al sistema e non aggiunto alla fine come un passaggio obbligatorio.
La prima condizione è il tempo. Il numero di pratiche assegnate a un operatore dovrebbe essere compatibile con il tipo di verifica richiesta. Se una decisione necessita di ragionamento, il processo deve prevedere uno spazio reale per quel ragionamento.
La seconda riguarda le informazioni. Non basta mostrare l’output del modello: bisogna mettere chi controlla nelle condizioni di comprenderlo e confrontarlo con gli elementi rilevanti del caso.
Serve poi la competenza. Conoscere il dominio applicativo è fondamentale, ma può non essere sufficiente. Chi supervisiona deve conoscere almeno i principali limiti dello strumento che utilizza, sapere quando la sua affidabilità può diminuire e riconoscere le situazioni nelle quali è necessario chiedere un secondo livello di verifica.
C’è poi l’autorità. Un supervisore deve poter ignorare, modificare, bloccare o sottoporre ad escalation una decisione senza che tali possibilità esistano soltanto in teoria. È un principio presente anche nell’AI Act, che lega la supervisione alla possibilità concreta di non utilizzare l’output o di ribaltarlo.
Infine serve misurare la supervisione stessa.
Quante raccomandazioni vengono modificate? Quanto tempo viene impiegato mediamente per una revisione? Quali categorie di decisioni generano più override? Gli errori vengono individuati dagli operatori o soltanto a posteriori? Il comportamento cambia quando aumenta il carico di lavoro?
Sono dati che permettono di capire se il controllo sta funzionando oppure se, con il tempo, si è trasformato in una formalità.
Perfino un’anomalia apparentemente positiva può diventare utile. Un reparto nel quale nessuno contesta mai il sistema può avere trovato un modello eccezionalmente accurato. Oppure può avere costruito un ambiente nel quale contestarlo è diventato troppo difficile.
La differenza non emerge dal diagramma del workflow. Va cercata nel comportamento reale di chi lo utilizza.
Da human-in-the-loop a human-in-control
Lo human-in-the-loop rimane uno strumento importante per governare sistemi automatici che prendono o supportano decisioni rilevanti. Il problema nasce quando la presenza dell’essere umano viene trattata come una garanzia sufficiente in sé.
Una persona può essere formalmente al centro del processo e avere comunque un controllo molto limitato.
Può ricevere troppe decisioni, vedere informazioni già filtrate dal sistema, essere influenzata dalla raccomandazione iniziale, non avere abbastanza tempo per verificarla oppure poterla contestare soltanto affrontando un costo organizzativo maggiore.
In queste condizioni la firma finale rimane umana, ma non è detto che lo sia anche il processo che ha prodotto la decisione.
Per questo parlare di supervisione dovrebbe significare qualcosa di più preciso che inserire un passaggio manuale tra l’output dell’algoritmo e la sua applicazione.
Significa progettare carichi di lavoro sostenibili, interfacce che non trasformino la raccomandazione in una risposta predefinita, sistemi di escalation, competenze adeguate e soprattutto un’effettiva possibilità di dire no.
Il punto non è contrapporre essere umano e macchina, né immaginare che ogni processo automatizzato debba tornare a essere manuale.
È capire dove il giudizio umano produce realmente valore e costruire il sistema affinché quel giudizio possa essere esercitato.
Di fronte ad algoritmi capaci di elaborare decisioni a una velocità e su una scala che nessuna persona potrebbe seguire individualmente, la domanda utile non è più soltanto “c’è un essere umano nel loop?”.
È piuttosto: quando non è d’accordo con la macchina, ha davvero il tempo, le informazioni e il potere necessari per fermarla?
Partecipa alla community