Human-in-the-Loop vs Human-on-the-Loop: guida alla supervisione dell’IA

In sintesi

  • Human-in-the-loop (HITL) sospende l’esecuzione dell’IA finché una persona non valida il passo successivo. Human-on-the-loop (HOTL) lascia che l’IA agisca e attribuisce a un supervisore il potere di osservare, intervenire e interrompere. Human-out-of-the-loop (HOOTL) rimuove ogni presenza umana dal percorso di esecuzione.
  • Le tre etichette non nascono nel machine learning. Discendono da un rapporto di Human Rights Watch del 2012 sui sistemi d’arma autonomi, poi codificato nella direttiva 3000.09 del Dipartimento della Difesa statunitense.
  • Il Regolamento europeo sull’IA non sceglie nessuno dei tre. L’articolo 14, paragrafo 3, prescrive che le misure di sorveglianza siano commisurate ai rischi, al livello di autonomia e al contesto d'uso del sistema. È una cornice, non un mandato.
  • La scelta solida si fonda su sette assi: budget di latenza, reversibilità della decisione, criticità, tetto di autonomia, percorso di ripiego, granularità di audit, livello di rischio regolamentare. Si sceglie la colonna più a destra (quella più autonoma) che soddisfi tutti e sette gli assi, non quella che minimizza lo sforzo ingegneristico.
  • Una persona accanto a uno schermo non costituisce supervisione. In assenza di potere di intervento, formazione e tasso di override misurato, si dispone di quello che i giuristi chiamano oggi un corpo caldo nella loop, una postura di conformità destinata a cadere al primo audit.

Da dove arrivano i termini (e perché la maggior parte degli articoli sbaglia)

La tricotomia in/on/out-of-the-loop non nasce nel machine learning. È stata cristallizzata da Bonnie Docherty in un rapporto di Human Rights Watch del 2012 sui sistemi d’arma autonomi, e ripresa poco dopo dalla direttiva DoD 3000.09 (pubblicata nel 2012 e aggiornata nel 2023). La direttiva definisce i tre modi operativi e impone ai comandanti di conservare un livello adeguato di giudizio umano sull'impiego della forza.

Il vocabolario è migrato verso il machine learning civile tra il 2018 e il 2020, quando le piattaforme MLOps hanno avuto bisogno di una formula breve per descrivere code di annotazione e code di eccezione. I blog dei vendor lo hanno raccolto. Quando l’IA agentica è diventata il tema dominante nel 2025, le etichette erano ovunque e raramente referenziate alla fonte.

La filiazione conta per due ragioni. Anzitutto la tassonomia originaria riguarda decisioni di kill-chain, dove ogni errore costa vite umane: trasferirla a una coda di moderazione contenuti senza dichiararne la provenienza svuota il vocabolario. In secondo luogo, il legislatore statunitense ha già fatto un passo avanti: il National Defense Authorization Act FY2025 sostituisce human in the loop con positive human actions per il comando nucleare, proprio perché l’appartenenza alla loop veniva rivendicata senza un’azione umana sostanziale a sostegno.

Conservate le etichette: sono utili. Trattatele però come scelte di progettazione, non come slogan.

Tre definizioni, fianco a fianco

Human-in-the-loop (HITL)

Un sistema HITL si arresta a uno o più punti decisionali e non procede senza un’autorizzazione umana esplicita. L’IA svolge il carico cognitivo più oneroso (ranking, estrazione, scoring) e l’essere umano svolge la funzione di portinaio.

Esempi canonici:

  • Il sistema di combattimento Aegis della Marina statunitense in modalità Auto SM: la catena d’ingaggio è predisposta dal sistema, ma il fuoco richiede una azione umana positiva.
  • L’iter di concessione del credito: il modello propone, il funzionario di banca autorizza. L’articolo 22 del GDPR impone di fatto questa configurazione per le decisioni interamente automatizzate con effetti giuridici.
  • Un radiologo che conferma una lesione segnalata dall’IA prima dell’iscrizione nella cartella clinica.

Forza: tracciabilità e responsabilità. Debolezza: la portata operativa crolla quando un essere umano deve approvare ogni chiamata. L’HITL perde significato quando la coda di approvazione supera la capacità di attenzione del revisore (si veda la sezione sul timbro automatico).

Human-on-the-loop (HOTL)

Un sistema HOTL si esegue in autonomia ed espone la propria traiettoria a un supervisore che può intervenire, sovrascrivere o interrompere. L’essere umano sta sul percorso di allarme, non su quello critico.

Esempi canonici:

  • La moderazione di contenuti su scala in una piattaforma social: i classificatori operano su milioni di pubblicazioni ogni ora, i moderatori trattano le escalation e auditano un campione.
  • La rilevazione di frodi sulle reti di carte: le transazioni sono decise in decine di millisecondi, gli analisti lavorano la coda di eccezione e regolano il modello.
  • Il telemonitoraggio: l’algoritmo segnala anomalie in tempo reale, l’équipe sanitaria conferma o declassa.

Forza: scala. Debolezza: intervento tardivo. Nel tempo che un essere umano impiega per accorgersi di una deriva, il sistema può aver chiuso migliaia di decisioni. L’HOTL vive di strumentazione: log, allarmi, target di latenza di override, dimensionamento della coda di revisione.

Human-out-of-the-loop (HOOTL) e Human-in-Command (HIC)

HOOTL significa che, in fase di esecuzione, nessun essere umano partecipa. Il progettista ha fissato i parametri, il sistema gira. È l’unico modo a piena autonomia ed è sostenibile solo per decisioni a basso impatto e altissima frequenza: ordinamento di raccomandazioni all’interno di una sessione, market-making sub-millisecondo una volta codificati i limiti di sicurezza.

HIC è l’inverso: la persona resta il decisore principale e l’IA estende il suo gesto. Il pilota in autopilota, il chirurgo sulla consolle robotica. La differenza rispetto all’HITL sta nella proprietà della decisione. In HITL l’IA propone e l’essere umano valida. In HIC l’essere umano decide e l’IA esegue con precisione.

La tassonomia non è esaustiva. La letteratura accademica propone livelli intermedi (Human-in-the-Process, Human-Augmented Model), ma per i fini della governance lo schema a quattro stadi qui sopra è sufficiente.

La matrice decisionale a sette assi

La maggior parte dei glossari si ferma alle definizioni. Chi mette in produzione un sistema ha bisogno di un selettore. La matrice qui sotto valuta un sistema lungo sette assi, ognuno legato a un vincolo di governance concreto. Si legge ogni riga, si annota il punteggio del proprio sistema, si sceglie la colonna più a destra (la più autonoma) che soddisfi l’intera riga.

AsseHITL appropriato se…HOTL appropriato se…HOOTL appropriato se…
Budget di latenzaLa decisione può attendere secondi o minuti (credito, diagnosi clinica).La decisione deve cadere in millisecondi ma un intervento tardivo conserva valore (frode, moderazione).La decisione avviene in microsecondi e l’override è praticamente impossibile (asta pubblicitaria, instradamento).
ReversibilitàDifficilmente o non reversibile (sentenza penale, gesto chirurgico, tiro).Reversibile con sforzo (storno di transazione, ripristino di un post).Banalmente reversibile o di scarso impatto (cache, ordinamento).
Criticità (tetto di danno)Lo scenario peggiore mette in gioco sicurezza, diritti fondamentali o un danno finanziario rilevante.Lo scenario peggiore è una perdita finanziaria limitata o una frizione utente rimediabile.Lo scenario peggiore è trascurabile (UX).
Tetto di autonomiaLo spazio d’azione è strettamente perimetrato e pre-approvato.Lo spazio d’azione è ampio, ma con interruttore e guardrail attivi a runtime.Lo spazio d’azione è completo nel dominio; solo la politica di progetto lo vincola.
Percorso di ripiegoUn essere umano formato è in turno e può trattare la decisione senza l’IA.Esiste una modalità degradata (risposta in cache, policy di default).Nessun ripiego umano è richiesto; il minimo deterministico è accettabile.
Granularità di auditOgni decisione deve essere ricondotta a un approvatore umano nominato.Ogni decisione deve essere ricondotta a una versione di modello; l’override costituisce la traccia di audit.Tracce di audit aggregate, statistica periodica.
Livello di rischio regolamentareAlto rischio ai sensi dell’allegato III del Regolamento IA, MDR classe IIa+, articolo 22 del GDPR per le decisioni interamente automatizzate.Rischio limitato ai sensi del Regolamento IA, codici settoriali, policy interne.Rischio minimo ai sensi del Regolamento IA, governance informale.

La regola che trasforma la tabella in uno strumento di progetto: si scelga la colonna più a destra che il sistema può onorare lungo l’intera riga, mai quella di minore sforzo ingegneristico. Un singolo asse che richiede HITL trascina l’intero percorso decisionale verso sinistra; il sistema può conservare HOTL altrove nel flusso.

Lettura dell’articolo 14 del Regolamento IA

L’articolo 14 è il punto d’ancoraggio giuridico dell’intero discorso. Il paragrafo 1 fissa la soglia: i sistemi di IA ad alto rischio sono progettati e sviluppati in modo da poter essere efficacemente supervisionati da persone fisiche durante il periodo di utilizzo. Il paragrafo 3 contestualizza la scelta: le misure di sorveglianza devono essere commisurate ai rischi, al livello di autonomia e al contesto d'uso del sistema di IA ad alto rischio.

Quel che l’articolo 14 non dice è altrettanto importante. Non impone che un essere umano approvi ogni decisione. Non nomina HITL né HOTL. Esige che il sistema sia progettato perché una persona possa comprendere, sorvegliare, intervenire e arrestare, e che queste capacità siano proporzionate. È un capitolato di progettazione, non un modo di esecuzione.

Traduzione operativa:

  • Sistemi ad alto rischio (allegato III): HITL o HOTL rafforzato con autorità di override nominata. L’articolo 14, paragrafo 4, lettera d), prevede esplicitamente la capacità di decidere ... di non utilizzare il sistema di IA ad alto rischio o di disapplicare, sovrascrivere o invertire l'output. Se l’architettura HOTL non dimostra che il supervisore può intervenire in tempo, l’articolo 14 non è rispettato.
  • Sistemi a rischio limitato: obblighi di trasparenza dell’articolo 50 e, come soglia minima, HOTL. Il supervisore non deve approvare ogni azione, ma deve poter osservare e fermare.
  • Modelli di IA per finalità generali (GPAI): la sorveglianza scivola verso il ciclo di vita del modello (articoli 51-55: documentazione tecnica, politica sul diritto d’autore, sintesi dei dati di addestramento e, per il rischio sistemico, valutazione avversariale e segnalazione di incidenti). HITL e HOTL tornano protagonisti al livello del deployer, quando il GPAI viene integrato in un prodotto a valle ad alto rischio.
  • Sistemi vietati (articolo 5): la questione del modo di sorveglianza non si pone.

Il Garante per la Protezione dei Dati Personali e l’AgID stanno articolando progressivamente la lettura settoriale di questi obblighi. Lo studio di Melanie Fink su SSRN merita attenzione: argomenta che l’articolo 14 lascia al deployer la gran parte dell’operazionalizzazione, e dunque le scelte di progetto diventano la postura di conformità di fatto.

Raccordo con ISO/IEC 42001 e con NIST AI RMF

Se il Regolamento IA offre l’ancora legale, ISO/IEC 42001 costituisce la spina dorsale del sistema di gestione e NIST AI RMF il vocabolario ingegneristico. Le tre cornici si incastrano:

  • ISO/IEC 42001 §6.1.4 (pianificazione operativa) e allegato A.6.2.6 (sorveglianza umana) chiedono all’organizzazione di definire, attuare e mantenere controlli di sorveglianza umana all’interno del sistema di gestione dell’IA. La norma non prescrive HITL né HOTL; esige la prova che la scelta sia stata deliberata e testata.
  • NIST AI RMF GOVERN-1.4 (Esistono processi che determinano il livello richiesto di attività di gestione del rischio in base alla tolleranza al rischio dell'organizzazione) e MANAGE-2.4 (meccanismi per sovrascrivere, disinserire o disattivare un sistema di IA con prestazioni o output non conformi all’uso previsto) sono le controparti architetturale e di runtime dell’articolo 14.
  • Il crosswalk ufficiale AIRC mappa le due norme riga per riga.

La postura pratica: si iscrive il modo di sorveglianza nella dichiarazione di applicabilità ISO 42001, si giustifica con la matrice a sette assi, si strumenta secondo quanto richiede MANAGE-2.4, e si ottiene una risposta coerente per un audit articolo 14, un audit di certificazione ISO 42001 e un questionario cliente allineato NIST.

La trappola del timbro automatico

Un HITL eccedente è peggiore di un HITL ben tarato. Quando un revisore tratta migliaia di richieste di approvazione per turno, l’attenzione cala e la validazione diventa riflesso. Verfassungsblog parla ormai di un corpo caldo nella loop: una sorveglianza nominale che spunta una casella e non costituisce un controllo reale sul modello. Le autorità di vigilanza se ne accorgono.

Quattro misure di progetto sono ormai considerate baseline:

  1. Escalation condizionata alla confidenza. Il revisore vede soltanto i casi che il modello stesso segnala come incerti, oppure il campione di QA. La via ad alta confidenza viene auditata a lotti.
  2. Tasso di override come indicatore chiave. Si misura la quota di decisioni IA rovesciate dai revisori nel tempo. Un valore fisso a zero indica timbratura. Un valore stabilmente sopra il venti per cento indica un modello da riprendere. La banda accettabile dipende dall’uso; il punto è che la misura esista.
  3. Formazione e rotazione dei revisori. L’articolo 14, paragrafo 4, lettera b), cita la formazione. I revisori devono essere formati sul dominio, ruotati per combattere la fatica e testati con errori seminati.
  4. Latenza di override. Si misura il tempo che intercorre tra l’anomalia e l’azione umana. Se la mediana supera il tempo necessario all’IA per consolidare un’uscita errata, l’HOTL è di facciata.

Questi quattro punti separano c'è un umano nella loop da c'è una sorveglianza umana effettiva ai sensi dell'articolo 14. I valutatori chiedono sempre più spesso la seconda formulazione.

Sorveglianza per settore

Il modo di sorveglianza che sopravvive a un audit è settoriale, perché i livelli di rischio lo sono.

  • Sanità: HITL come default per ogni output diagnostico che entra in cartella. L’articolo 14 si combina con il regolamento sui dispositivi medici e, negli Stati Uniti, con la dottrina FDA Software-as-a-Medical-Device. L’HOTL è accettabile per triage e monitoraggio una volta che il tasso di falsi negativi è stato delimitato da studio clinico.
  • Servizi finanziari: HITL per le decisioni creditizie e di sottoscrizione su persone fisiche (articolo 22 GDPR), HOTL per la sorveglianza delle transazioni e la rilevazione frodi. Banca d’Italia e Consob stanno precisando le rispettive attese.
  • Settore pubblico e giustizia: caso speciale. Lo studio Oxford IJLIT 2026 sui giudici nella loop sostiene che, per i sistemi di supporto decisionale ad alto rischio in ambito giurisdizionale, la sorveglianza deve essere esercitata dal decisore stesso, non da un terzo, altrimenti non si configura un controllo umano significativo.
  • Mobilità autonoma: HOTL nelle operazioni ordinarie, con escalation HITL gestita da un centro operazioni remoto. L’HOOTL è riservato ai loop di controllo sub-secondo, dove la latenza umana non è fisicamente compatibile.
  • Contenuti e ricerca: HOTL con campionamento condizionato alla confidenza, ormai standard. L’HITL torna obbligatorio quando la rimozione tocca la libertà d’espressione politica o altre categorie cariche di diritti fondamentali.

Lettura trasversale: più alto il tetto di danno, più la matrice spinge a sinistra; più stretto il budget di latenza, più spinge a destra. I sistemi reali vivono all’intersezione.

Come implementare la sorveglianza

Una routine in cinque passi allinea la matrice con la documentazione ISO 42001 e con la prova di audit attesa ai sensi dell’articolo 14:

  1. Classificare il sistema rispetto ai livelli di rischio del Regolamento IA, all’articolo 22 GDPR, ai regimi settoriali e agli obblighi contrattuali. Determina la riga Livello di rischio regolamentare.
  2. Valutare il sistema sugli altri sei assi. Si annotano i punteggi. Il modo discende dai punteggi.
  3. Documentare la scelta nella dichiarazione di applicabilità ISO 42001 (allegato A.6.2.6) con rimando alla matrice e razionale firmato.
  4. Strumentare l’esecuzione. Percorso di override, target di latenza di override, traccia di audit per decisione (o per versione di modello, secondo la riga), registri di formazione, dashboard del tasso di override.
  5. Rivedere trimestralmente. Tasso di override, tasso di falso timbro (campione di approvati), segnali di fatica dei revisori, evoluzioni regolamentari o tecniche che spostino una riga.

Il ciclo si chiude quando la dashboard conferma la scelta iniziale o segnala una riga spostata; in tal caso si ri-valuta e si aggiorna la SoA. Le squadre che governano l’IA a livello di portafoglio adottano in fretta uno strumento dedicato. AI Sigil è costruita attorno a questo flusso preciso.

Domande frequenti

C’è davvero una differenza tra human-in-the-loop e human-on-the-loop? Sì. L’HITL ferma l’IA e attende una validazione umana. L’HOTL lascia che l’IA agisca e attribuisce a una persona il potere di osservare e sovrascrivere. La differenza non è estetica: cambia il budget di latenza, la traccia di audit, il modello organizzativo e l’esposizione regolamentare. Considerarli intercambiabili è un debito di conformità a scoppio ritardato.

Come si spiega l’human-on-the-loop in parole semplici? L’IA fa il lavoro, una persona lo sorveglia, può fermarlo e rivede un campione delle uscite. È la giusta taratura quando non si può approvare ogni decisione, né lasciar correre il sistema senza sguardo umano.

Chi ha coniato il termine human-in-the-loop? L’espressione esisteva già nella letteratura di modellistica e simulazione, ma la tricotomia moderna è stata popolarizzata da Bonnie Docherty nel rapporto Losing Humanity di Human Rights Watch nel 2012. Il Dipartimento della Difesa statunitense l’ha adottata poco dopo nella direttiva 3000.09.

Dove il Regolamento IA cita l’human-in-the-loop? Non lo cita per nome. L’articolo 14 impone una sorveglianza efficace da parte di persone fisiche, elenca quattro capacità (comprendere, sorvegliare, intervenire, arrestare) ed esige la proporzionalità rispetto a rischi, autonomia e contesto. Le etichette HITL e HOTL sono gli strumenti con cui il deployer adempie al capitolato.

L’human-in-the-loop basta per un sistema ad alto rischio? Solo se è autentico. L’articolo 14, paragrafo 4, richiede che il supervisore possa comprendere, sorvegliare, intervenire, arrestare e sovrascrivere. Un approvatore nominale che timbra non supera la soglia. Tasso di override, latenza di override e formazione sono le prove attese dal valutatore.

Cos’è l’human-in-command e in cosa differisce? In HIC, la persona resta il decisore principale e l’IA estende il gesto: pilota in autopilota, chirurgo su consolle robotica. La differenza rispetto all’HITL sta nella proprietà della decisione: in HITL l’IA propone e l’essere umano valida; in HIC l’essere umano decide e l’IA esegue.

Si possono combinare i modi nello stesso sistema? Sì, anzi è la norma in produzione. Si esegue HOTL sulla pipeline di massa, si instrada i casi a bassa confidenza in coda HITL, si tiene HOOTL per i loop di retroazione che non tollerano latenza. La matrice si applica per percorso decisionale, non per sistema.

Conclusione

Le etichette sulla loop non sono un argomento di marketing. Condensano un decennio di dibattito sull’autonomia tollerabile di una macchina a fronte di decisioni di vita o di morte. La governance civile ha ereditato il vocabolario insieme all’obbligo di impiegarlo con precisione.

La postura solida è strutturale. Si valuta ogni percorso decisionale lungo i sette assi. Si sceglie il modo più autonomo compatibile. Si scrive il modo e il razionale nella SoA ISO 42001. Si strumenta il percorso di override con il rigore richiesto dall’articolo 14, paragrafo 4, lettera d) e da MANAGE-2.4. Si seguono il tasso di override e il tasso di falso timbro. Si ri-valuta quando sistema, dati o regolamentazione cambiano.

L’alternativa, scegliere un’etichetta perché un blog di vendor l’ha usata, è la via breve alla casella spuntata e poi al rilievo d’audit. La matrice è il modo di accertarsi che il cartello scelto corrisponda a ciò che il sistema effettivamente fa.

Per un approfondimento sull’articolo 14 stesso, l’analisi dedicata di AI Sigil è il complemento di questo testo. Per la mappatura ISO 42001 dei controlli, il pilastro dedicato alla norma costituisce il passo successivo.

Le leggi sull’intelligenza artificiale nel 2026: una mappa di conformità globale

Fornitore, deployer o modello GPAI? Ecco come AI Act europeo, leggi USA, NIST AI RMF e ISO 42001 si intrecciano nel 2026, con una checklist.

Framework di governance dell’IA: la guida completa

Confronta NIST AI RMF, ISO 42001, il Regolamento IA e i principi OCSE. Scopri quale framework si adatta alla tua organizzazione e come implementarli insieme.

Human-in-the-Loop vs Human-on-the-Loop: guida alla supervisione dell’IA

Human-in-the-loop o human-on-the-loop: 7 assi decisionali, lettura dell'articolo 14 del Regolamento IA e raccordo con ISO/IEC 42001.

Framework di governance dell’IA: NIST AI RMF, ISO 42001, AI Act e principi OCSE a confronto (2026)

NIST AI RMF, ISO/IEC 42001, AI Act e principi OCSE a confronto: mappa dei controlli e albero decisionale per scegliere il framework giusto.

ISO 42001 non copre l’AI Act: lo stack di norme che vi serve davvero

Una certificazione ISO 42001 non vi mette in regola con l'AI Act. Ecco le norme armonizzate che contano davvero, e come integrarle nelle operazioni.