Il timbro e la mano

Quando l’umano nel ciclo è solo di facciata (o non c’è più)

---

1. Perché ne parliamo

Poco dopo la mezzanotte del 26 settembre 1983, in un bunker vicino a Mosca, il tenente colonnello Stanislav Petrov è l’ufficiale di turno al centro di comando di Oko, il sistema sovietico di allerta nucleare basato su satelliti. Il sistema segnala il lancio di un missile dagli Stati Uniti, poi di altri quattro. Petrov giudica che si tratti di un falso allarme e aspetta una conferma che non arriva. Le indagini stabiliranno che il sistema di allerta si era sbagliato.

È la storia che tutti citano quando si parla di human in the loop (HITL, “umano nel ciclo”): una persona che, nel momento decisivo, ferma la macchina. Ed è una storia rassicurante, forse troppo.

Perché l’idea, nella versione che incontriamo ogni giorno, è quasi sempre una frase: “c’è sempre una persona che controlla”. La troviamo nei comunicati aziendali, nei regolamenti, nelle risposte a chi solleva dubbi su un sistema di intelligenza artificiale. Ma quella frase nasconde tre domande che nessuno fa: controlla che cosa? Con quali informazioni? E, soprattutto, con quale potere di dire no?

La tesi di questo articolo è semplice: la presenza di un umano non è un controllo, è un’ipotesi da verificare. Un umano nel ciclo può essere una vera barriera, una mera formalità (il “timbro”) oppure un capro espiatorio pronto per quando qualcosa va storto. Da fuori, i tre casi sembrano identici. Ciò che li distingue è il modo in cui il sistema è progettato attorno a quella persona.

Nelle pagine che seguono: che cos’è HITL; perché il controllo umano tende a svuotarsi; un test in cinque domande per distinguere un ciclo reale da uno di facciata; due esempi, uno pubblico e uno che conosciamo dall’interno.

---

2. A chi ci rivolgiamo

A chi legge notizie sull’IA e si chiede cosa significhi davvero “sotto controllo umano”. E a chi, in un’azienda o in un’amministrazione, sta introducendo sistemi automatici e deve decidere dove mettere le persone.

Chi arriva in fondo dovrebbe portarsi via tre cose: che cosa si intende per HITL; perché “c’è un umano” non basta; e un test pratico, cinque domande da rivolgere a chiunque dica “c’è sempre una persona che controlla”.

---

3. Che cosa c’è da sapere

3.1 HITL in cinque minuti

“Umano nel ciclo” descrive un modo di progettare sistemi automatici: una persona resta dentro il processo decisionale e può approvare, correggere o bloccare. L’idea di fondo è che umani e macchine sbagliano in modi diversi, quindi mettere insieme i due dovrebbe essere più robusto di ciascuno da solo.

Nel linguaggio comune si distinguono tre configurazioni:

• in-the-loop: l’umano approva o decide ogni passo (il medico che firma la diagnosi suggerita);
• on-the-loop: la macchina agisce e l’umano supervisiona, con la possibilità di fermarla (il pilota con l’autopilota inserito);
• out-of-the-loop: nessun controllo umano in tempo reale.

Ma “automatico” non è una condizione unica. Un modello classico della letteratura sull’interazione uomo-automazione (Parasuraman, Sheridan e Wickens, 2000) osserva che l’automazione può intervenire su quattro tipi di funzione: acquisire informazioni, analizzarle, scegliere una decisione, eseguirla. E per ciascuna può essere spinta a livelli diversi, dal tutto manuale al tutto automatico. Un sistema reale mescola queste scelte. Dire “c’è un umano” senza dire in quale funzione e a quale livello è un’informazione quasi vuota.

3.2 Perché il controllo si svuota

Se l’umano nel ciclo funzionasse sempre, non staremmo qui. Le ragioni per cui spesso non funziona sono ormai ben documentate.

Il compito è più difficile di quanto sembri. Nel 1983 Lisanne Bainbridge pubblicò un breve articolo diventato un classico, Ironies of Automation. La sua osservazione: quando si automatizza quasi tutto, all’umano restano i compiti che i progettisti non sapevano come automatizzare, cioè gestire i casi rari e difficili. Ma proprio perché ha smesso di praticare, le sue competenze si erodono; e il lavoro diventa un monitoraggio noioso e faticoso. Da qui l’ironia: più il sistema è affidabile, più l’addestramento dell’umano diventa cruciale per il momento raro in cui deve intervenire.

La tendenza a fidarsi. La letteratura la chiama compiacenza e bias da automazione: la tendenza a fidarsi troppo del suggerimento della macchina e a controllarlo meno (Parasuraman e Manzey, 2010). Non è pigrizia morale: è un effetto prevedibile di come funziona l’attenzione quando un sistema ha quasi sempre ragione.

I numeri e il tempo. Qui non citiamo uno studio, ma un’osservazione di buon senso organizzativo: se una persona deve validare decine di decisioni all’ora, il controllo diventa un gesto. Il “sì” costa un clic; il “no” costa spiegazioni, tempo, a volte problemi.

Le prove empiriche. Ben Green (2022) ha esaminato 41 politiche pubbliche che prescrivono la supervisione umana degli algoritmi usati dai governi. La sua conclusione è netta: le evidenze indicano che le persone non riescono a svolgere le funzioni di controllo che ci si aspetta da loro; e queste politiche finiscono per legittimare l’uso di algoritmi difettosi, dando un falso senso di sicurezza e consentendo a fornitori e amministrazioni di sottrarsi alla responsabilità. Green propone di spostare il baricentro dalla supervisione della singola persona alla supervisione istituzionale.

La trappola. Nella stessa direzione, Crootof, Kaminski e Price (2023) descrivono quella che chiamano la trappola MABA-MABA: quando i legislatori, preoccupati dai limiti di un algoritmo, “inseriscono un umano” per compensarli, dimenticano che un sistema uomo-macchina è più della somma delle sue parti e richiede regole sue. La loro indicazione: regolare il sistema uomo-nel-ciclo, non limitarsi a collocare un umano nel ciclo.

3.3 Il test delle cinque condizioni

Mettiamo insieme queste osservazioni in una lista di controllo. Un umano nel ciclo può esercitare un controllo reale se il sistema gli dà:

1. Tempo. Ha il tempo di guardare davvero, per ogni decisione che gli passa davanti?
2. Informazione. Vede ciò che serve per giudicare (dati, motivazioni, livello di incertezza), o solo l’esito da approvare?
3. Competenza. Ne sa abbastanza del dominio e del sistema da accorgersi di un errore, e la tiene allenata?
4. Autorità. Può dire no, e il suo no ferma davvero la decisione?
5. Protezione. Se dice no, o se sbaglia, cosa rischia? Chi paga?

Le prime tre condizioni discendono soprattutto dal lavoro di Bainbridge, le ultime due dal ragionamento sulla responsabilità (Elish, 2019, ne è il riferimento più noto: parla di “zona di deformazione morale”, il punto in cui l’umano, come la zona di assorbimento di un’auto, subisce l’urto al posto del sistema) e dalle analisi di Green. Il test è una nostra sintesi, non una tassonomia consolidata. Serve a individuare le condizioni da esaminare, non a produrre un punteggio automatico: anche una sola carenza può compromettere il controllo, soprattutto quando riguarda un requisito decisivo per il contesto, come l’impossibilità tecnica di fermare il sistema.

---

4. Esempio 1, dal mondo reale

Robodebt: quando il controllo umano viene tolto e spostato

Dal 2015 il governo australiano avviò un sistema, poi noto come Robodebt, per recuperare presunti sussidi versati in eccesso dal servizio di assistenza sociale Centrelink. Il meccanismo confrontava i dati dei sussidi con le dichiarazioni dei redditi e calcolava automaticamente i “debiti” facendo una media del reddito annuo. Una persona con lavori discontinui, o che aveva lavorato solo una parte dell’anno, risultava così con redditi diversi da quelli reali. Il sistema riduceva l’indagine umana sulle discrepanze e sostanzialmente spostava sul cittadino l’onere di dimostrare che il debito non esisteva. A Natale 2016 le notifiche automatiche erano più di 20.000 a settimana.

Nel 2019 una beneficiaria, Deanna Amato, portò un caso di prova davanti alla Corte federale, e il governo ammise l’illegalità del sistema. Il rapporto finale della Commissione reale, pubblicato a inizio luglio 2023, lo definì, con le parole della commissaria Catherine Holmes, un meccanismo “crudo e crudele”, né equo né legale.

Un chiarimento per i lettori più scettici: Robodebt non era intelligenza artificiale nel senso in cui oggi la intendiamo. Era un calcolo elementare, una media. Ed è proprio questo il punto: perché un ciclo si svuoti non serve un modello sofisticato.

Il test delle cinque condizioni, va detto con chiarezza, era pensato per chi opera dentro un sistema, non per chi lo subisce dall’esterno: applicarlo a un cittadino che riceve una notifica è un livello diverso, quello della contestazione di una decisione già presa, non quello del controllo in tempo reale. Con questo distinguo, Robodebt mostra che eliminare o ridurre le verifiche umane, trasferendo ai cittadini l’onere di contestare decisioni fondate su assunzioni inadeguate, può produrre conseguenze gravi. Per comprendere perché il sistema sia rimasto operativo così a lungo occorre però ricostruire anche le responsabilità istituzionali e i meccanismi di controllo, cosa che questo articolo non fa.

Il controesempio: Petrov, riletto col test

Torniamo al 1983. Proviamo ad applicare le cinque domande, con la cautela che le ricostruzioni storiche impongono: le fonti disponibili non bastano a rispondere a tutte con sicurezza.

• Tempo: non determinabile dalle fonti consultate con la precisione che servirebbe.
• Competenza: verosimile ma da confermare con una fonte primaria. Il racconto più diffuso lo descrive impegnato nella messa a punto del sistema, entrato in servizio nonostante non fosse del tutto pronto.
• Informazione: parziale. Secondo il racconto più diffuso ragionò che un vero attacco avrebbe coinvolto molti più missili di cinque, ma quanto quell’indizio fosse davvero sufficiente andrebbe valutato nel contesto operativo, che non conosciamo nel dettaglio.
• Autorità: qui occorre distinguere due cose diverse: la facoltà di valutare un allarme e segnalarlo, che aveva, dalla facoltà di disattendere formalmente una procedura, che non aveva.
• Protezione: non determinabile con certezza dalle fonti consultate; le conseguenze istituzionali della sua scelta richiederebbero un riferimento documentato.

C’è anche una nota di prudenza più ampia: le ricostruzioni hanno talvolta fatto di Petrov un argine solitario, mentre fonti ufficiali russe affermano che una ritorsione richiedeva la conferma di più fonti. Ciò non toglie valore alla sua decisione, ma la sposta dal piano del mito a quello del sistema.

La decisione di Petrov mostra il valore del giudizio umano davanti a un allarme automatico. Non dimostra, da sola, che l’architettura di supervisione fosse adeguata: competenze, informazioni disponibili, tempi decisionali, autorità e protezioni andrebbero ricostruiti separatamente, con fonti migliori di quelle usate qui. Ciò che possiamo dire con più fondamento è più modesto: un sistema affidabile non dovrebbe dipendere esclusivamente dalle qualità eccezionali di un singolo operatore.

---

5. Esempio 2, dall’interno: aiNEXUS

aiNEXUS è un ambiente di co-creazione a configurazione variabile, dentro la metodologia FractalCEI. A seconda del compito, collaboriamo con una o più IA, distribuiamo attività differenti oppure organizziamo revisioni incrociate; non tutte le IA partecipano a ogni lavoro. Per questo articolo abbiamo scelto una configurazione specifica: una prima stesura affidata a Claude, una revisione critica di ChatGPT e un successivo consolidamento sotto responsabilità umana. Ne parliamo qui per una ragione precisa: un articolo sul controllo umano che non applicasse il test a se stesso sarebbe poco credibile.

Un flusso a impulsi

aiNEXUS non lavora a grandi consegne separate da lunghe attese, ma con un flusso di consegna quasi continuo, scandito da iterazioni brevi, tipicamente tra i venti minuti e un’ora, che chiamiamo pulse.

In ciascun pulse si compie per intero il ciclo dell’umano nel ciclo. Una IA produce un artefatto (una bozza, un’analisi, uno schema). Io lo passo a un’altra IA perché lo verifichi, lo critichi o lo continui, guardo che cosa ne esce e decido il passo successivo.

Cosa automatizziamo e cosa no

Spesso ci chiedono perché non automatizziamo tutto. La risposta è che non vogliamo: vogliamo restare a conoscenza di ciò che accade, cioè restare davvero nel ciclo. Per questo lavoro, il trasferimento degli artefatti passa per cartelle condivise su Google Drive che le IA possono leggere direttamente: una condivisione accessibile, più che un’automazione in senso stretto.

Il trasferimento è agevolato; il giudizio resta manuale. È una scelta di progetto, e risponde in modo diretto alle ironie di Bainbridge: un umano che pratica ogni giorno la verifica mantiene le competenze che gli serviranno nel momento raro in cui contano davvero. (Questa lettura è nostra, non un’affermazione dell’autrice.)

Le regole di questo lavoro

Per questo articolo, in particolare, valgono tre regole:

• L’umano decide. Le IA propongono, criticano, si correggono a vicenda; ma la scelta di cosa sopravvive, e se e quando pubblicare, resta a una persona. Nessuna IA può imporre nuovi round di revisione.
• La revisione è avversariale. Più IA hanno lavorato in sequenza su questo testo, e ciascuna ha criticato il lavoro della precedente.
• Le fonti hanno una regola. Ogni riferimento suggerito da un’IA finisce in una lista “da verificare” e passa in bibliografia solo dopo un controllo.

Sono le regole di questo lavoro, non un protocollo fisso applicato a ogni output di aiNEXUS: configurazioni diverse, per compiti diversi, possono seguire schemi diversi.

Come decidiamo se un pulse è concluso

Passare da un pulse al successivo non è una sensazione: è il risultato di un meccanismo di feedback strutturato. Alla fine di ogni pulse vengono identificati gli action item per il passo successivo, in un modo che è a sua volta un piccolo esempio di ciclo umano-macchina: prima li propone il sistema, in automatico; poi li convalido io. Non è la macchina che decide cosa fare dopo, ma nemmeno riparto ogni volta da zero: uso quello che il sistema ha già notato, e lo correggo dove non mi convince.

A questo si affianca una metrica di sintesi: un punteggio da 1 a 10, dichiaratamente convenzionale, calcolato su più dimensioni ortogonali (non è un voto assoluto di qualità, ma un indicatore). Il punto non è il numero in sé, ma il suo muoversi nel tempo: ci serve a vedere se c’è un Kaizen, un miglioramento continuo, pulse dopo pulse. Quando un artefatto supera il 9,4 su questa valutazione, il nostro processo interno lo considera maturo.

Il superamento della soglia segnala il livello di maturità previsto dal processo, non una certificazione di correttezza: un testo può superarla e contenere ancora un errore fattuale bloccante. Per questo non prevale mai su un problema bloccante ancora aperto, e la decisione di pubblicare resta separata. È qui che il paragone con lo Scrum resta utile, come analogia e non come equivalenza metodologica: un increment potentially shippable ha una qualità tecnica dichiarata sufficiente, ma resta una decisione a parte, del product owner o degli stakeholder, se e quando effettivamente rilasciarlo. Nel nostro caso il product owner sono io: il sistema può dire “è maturo”, non “pubblicalo”. Sono due affermazioni diverse, e tenerle separate è, di nuovo, il punto dell’intero articolo applicato a noi stessi.

Il caso concreto

Questo stesso articolo. Le fonti che lo sorreggono sono state proposte all’inizio dell’analisi e messe in quella lista. Prima di citarle, le abbiamo controllate una per una, e i dati bibliografici sono risultati corretti. Ma va detto che quel controllo l’ha fatto un’IA, con una ricerca sul web: non ha sostituito la lettura umana delle fonti. È un ciclo che funziona, e insieme un ciclo che potrebbe diventare di facciata se ci accontentassimo del “verificato dall’IA”.

Il test, applicato a noi

Condizione	Come stiamo messi
Tempo	I pulse brevi (20 minuti-1 ora) tengono il ciclo leggero e l’attenzione viva. Ma la velocità è anche un rischio: più pulse ci sono, più è facile che il controllo scivoli in un passaggio meccanico. Per questo articolo, in particolare, abbiamo scelto apertamente un vincolo editoriale che contiene il costo umano: una bozza, una revisione, poi ci si ferma.
Informazione	Gli artefatti stanno nelle stesse cartelle per tutti, umano compreso: la visibilità è condivisa. Resta meno visibile il percorso con cui un’IA ha scelto una frase o una fonte.
Competenza	Più orientata al dominio che alla tecnica: nei casi estremi, un rapporto vicino all’80/20. So riconoscere se un argomento regge o se una fonte è plausibile; sono meno attrezzato a valutare, per dire, il funzionamento interno di un modello. È un limite di cui tengo conto, non un punto cieco che ignoro.
Autorità	Alta, e tenuta distinta per progetto: il sistema può dichiarare un artefatto “maturo” (score oltre 9,4), ma solo io decido se pubblicarlo. È lo stesso confine, per analogia, tra potentially shippable e shipped dello Scrum.
Protezione	Nessuna penalità per un “no”. Il rischio è un altro: la comodità di dire sempre “va bene”.

Il rischio che conosciamo

Il pericolo più serio per un ciclo come il nostro non è l’assenza dell’umano, ma la sua trasformazione in corriere: qualcuno che sposta gli artefatti da una IA all’altra senza leggerli davvero. È la versione da laboratorio del “timbro”. La difesa sta nel progetto (a mano resta ciò che richiede giudizio, non ciò che richiede solo trasporto) e nell’abitudine, che nessun sistema può garantire al posto nostro. Il racconto in prima persona di come si vive dall’interno tutto questo è materia del satellite S5.

---

6. Conclusioni

Tre idee da portarsi via.

Un umano nel ciclo è una proprietà del sistema, non della persona. Se non ha tempo, informazione, competenza, autorità e protezione, quella persona non è un controllo: è una firma.

Mettere un umano non è una soluzione, è una domanda di progetto. Le domande giuste sono dove, quando e con quale potere, non se. Come dicono Crootof e colleghi, si regola il sistema, non il posto a sedere.

Quando il ciclo è finto, il costo si sposta. Sul cittadino che deve dimostrare di non dovere nulla, sull’operatore che resta a pagare per un errore che non poteva vedere. Sono conseguenze che poi ricadono su qualcuno di preciso, e non sono mai neutrali.

Restiamo con un’osservazione che vale anche per noi. Petrov non fu un sistema: fu un uomo con la competenza giusta, nella notte giusta. Non possiamo costruire il futuro sperando che ogni volta ci sia un Petrov.

---

7. Prossimi passi

Per il lettore. La prossima volta che sentite “c’è sempre una persona che controlla”, provate a chiedere:

1. Quanto tempo ha per ogni decisione?
2. Che cosa vede, oltre al risultato?
3. Sa abbastanza per accorgersi dell’errore?
4. Il suo “no” ferma davvero la decisione?
5. Cosa succede a chi dice no, e cosa a chi sbaglia?

Per questo cluster. Questo è il primo di cinque articoli, più un testo di sintesi. Seguiranno: chi occupa oggi il ciclo (lavoro invisibile di chi annota e modera dati), i valori che il feedback umano incorpora nei modelli, responsabilità e perdita di competenze, e infine il passaggio dal ciclo di controllo a una co-creazione bidirezionale.

---

8. Riferimenti

Stato di verifica: [V] = dati bibliografici confermati su fonti indipendenti (abstract o scheda dell’editore) ma articolo non letto integralmente da chi scrive; [D] = da verificare o reperire la fonte primaria.

• [V] Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779.
• [V] Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), 286–297.
• [V] Parasuraman, R., & Manzey, D. H. (2010). Complacency and bias in human use of automation: An attentional integration. Human Factors, 52(3), 381–410. (Verificata solo come voce bibliografica citata in altre opere.)
• [V] Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society, 5, 40–60.
• [V] Green, B. (2022). The flaws of policies requiring human oversight of government algorithms. Computer Law & Security Review, 45, 105681.
• [V] Crootof, R., Kaminski, M. E., & Price, W. N. II (2023). Humans in the Loop. Vanderbilt Law Review, 76(2), 429.
• [D] Royal Commission into the Robodebt Scheme, Final Report (luglio 2023): il rapporto primario non è stato letto; le informazioni qui riportate provengono da resoconti secondari. Reperire il testo ufficiale, incluse le citazioni della commissaria Holmes.
• [D] Cifre e dettagli su Robodebt (avvio del sistema, 20.000 notifiche a settimana, caso Amato del 2019): confermare sul rapporto primario.
• [D] Petrov, 26 settembre 1983: la ricostruzione si basa su fonti secondarie. Reperire una fonte primaria o una ricostruzione storica (ad esempio David Hoffman, The Dead Hand, 2009: da verificare come fonte pertinente), e chiarire la questione della conferma da più fonti.