Human-in-the-loop non è sorveglianza. È una disciplina di progettazione.

L'approvazione che non c'era

Da Marrowfield Specialty Risk, l'audit sulla selezione dei sinistri di questa primavera ha prodotto uno scambio breve e imbarazzante. L'intermediario, circa 150 dipendenti in un mercato sottoposto a vigilanza, utilizzava da diciotto mesi un sistema di IA per la segnalazione. Mariela Okafor, responsabile delle operazioni sinistri, occupava quella posizione da dodici anni. Gli addetti trattavano oltre 200 pratiche al giorno; il modello ne segnalava circa l'8%. L'audit ha estratto due numeri: 96% di approvazione sulle pratiche segnalate dall'IA e 23 secondi di tempo medio di revisione. Il responsabile della conformità ha chiesto: «Su quali soglie avete tarato?». La risposta: «Nessuna. Approvo semplicemente ciò che l'IA mi invia».

Marrowfield Specialty Risk è un caso composito, costruito a partire da interviste con intermediari specializzati di fascia media del mercato e dalla letteratura sulla conformità della BoE/FCA e dell'EU AI Act. I nomi sono anonimizzati; le metriche illustrano schemi rilevati nelle indagini citate.

Per le autorità di tre continenti, quello scambio si legge ormai come prova di una sorveglianza mancante. La data di applicazione dell'EU AI Act, fissata all'agosto 2026, mette un calendario sotto questo difetto di progettazione, ma il difetto è più vecchio del calendario.

§1 — L'approvazione passiva è teatro d'audit, non sorveglianza

Il modello mentale predefinito (l'IA segnala, l'essere umano approva) è strutturalmente indistinguibile dall'assenza di sorveglianza. Un'interfaccia con un solo pulsante, priva di dati di input, di ragionamento del modello e di punteggio di confidenza, produce esattamente le metriche emerse da Marrowfield. La firma operativa coincide con quella di un flusso di lavoro pienamente automatizzato, con una persona di guardia.

I dati di vigilanza lo confermano su scala di popolazione. L'indagine AI in UK Financial Services 2024 della BoE/FCA ha rilevato che «il 55% di tutti i casi d'uso dell'IA presenta un certo grado di processo decisionale automatizzato, e il 24% di questi è semi-autonomo, ossia, pur potendo assumere autonomamente una gamma di decisioni, è progettato per coinvolgere la sorveglianza umana nelle decisioni critiche o ambigue» [9]. L'implicazione, in linea con l'inquadramento dei rischi della configurazione uomo-IA proposto dal NIST AI 600-1, è che la maggior parte della popolazione soggetta a processi decisionali automatizzati non dispone di un punto di intervento significativo.

Le autorità si sono mosse per colmare la lacuna. La posizione dell'ICO è netta: una decisione non esce dall'ambito dell'articolo 22 del UK GDPR «solo perché un essere umano si è limitato a ratificarla» [2]. Le stesse linee guida sono più taglienti sulla prova operativa: i revisori che «concordano sistematicamente con gli output del sistema di IA e non sono in grado di dimostrare di averli realmente valutati» possono essere classificati come soggetti a una decisione esclusivamente automatizzata ai sensi del UK GDPR [3]. L'EU AI Act fissa un test parallelo all'articolo 14, esigendo sistemi «progettati e sviluppati in modo tale ... da poter essere efficacemente supervisionati da persone fisiche» [1]. La parola efficacemente è portante in entrambe le tradizioni giuridiche. La domanda progettuale non è più «c'è un essere umano?», ma «la progettazione è tale che una persona possa rilevare, annullare e interrompere, e che lo faccia davvero?».

§2 — Il modello HITL è un sistema a soglie, non una fase di revisione

L'approccio human-in-the-loop, preso sul serio, è un sistema: soglie di confidenza esplicite, tre vie decisionali, un livello di ponderazione del rischio e una politica di gestione della coda. Il modello restituisce un punteggio di confidenza nell'intervallo 0,0-1,0, e si applicano tre limiti: rifiuto automatico al di sotto del limite inferiore, revisione umana nella fascia centrale, approvazione automatica al di sopra del limite superiore. I punti di partenza prudenti per i flussi di lavoro regolamentati si collocano intorno a 0,3 / 0,95; le operazioni moderate intorno a 0,5 / 0,9; la classificazione a basso rischio a 0,7 / 0,95. I limiti sono deliberatamente asimmetrici: i falsi positivi e i falsi negativi comportano costi diversi, e il sistema a soglie codifica tale asimmetria invece di seppellirla in un unico numero. Il NIST AI RMF 1.0 giunge alla stessa conclusione: la sua funzione MANAGE «comporta l'assegnazione periodica di risorse di rischio ai rischi mappati e misurati» [5], e le soglie sono il meccanismo di assegnazione, dimensionato sul rischio anziché sulla comodità.

Al di sopra si colloca un livello ponderato per il rischio. La confidenza si moltiplica per un punteggio di gravità del rischio aziendale (entità del sinistro, irreversibilità della decisione, esposizione regolamentare) per produrre una matrice di instradamento 3×3. Un caso ad alto rischio e bassa confidenza viene escalato al supervisore; un caso ad alto rischio e alta confidenza viene comunque instradato alla revisione HITL ordinaria anziché all'approvazione automatica. La scelta tra due e tre livelli conta: un sistema a due livelli convoglia ogni caso incerto in un'unica coda, la coda trabocca, gli addetti ripiegano sull'approvazione in blocco, lo schema che ha prodotto il tasso del 96% di Marrowfield. Un sistema a tre livelli affida al rifiuto automatico un ruolo produttivo. L'instradamento dipende da una strategia di IA centralizzata^EN, con uno stack autorizzato che produce un punteggio di confidenza coerente; la proliferazione di strumenti improvvisati rende impossibile la disciplina delle soglie, perché i punteggi di modelli diversi non sono comparabili.

§3 — I percorsi di riserva si progettano, non si sottintendono

Il «ripiego» non è gestione degli errori. È la diramazione esplicita che il sistema imbocca quando l'IA è incerta, e ha bisogno di un percorso, di una persona, di uno SLA. Tre soluzioni coprono il campo.

Soluzione A — human-in-loop sincrona: l'IA si arresta e rimette il caso in coda con record di input, ragionamento e confidenza allegati, a fronte di uno SLA di 2-4 ore; adatta a decisioni quasi in tempo reale. Soluzione B — coda per elaborazione in lotti, asincrona: l'IA restituisce una risposta provvisoria, poi la espone in un lotto giornaliero o settimanale con una finestra di annullamento retroattivo; adatta al lavoro non critico sui tempi. Soluzione C — escalation a un esperto, gerarchica: instrada in base all'incertezza dell'IA e alla gravità del rischio verso un bacino di revisori a più livelli (ordinario → esperto → supervisore), con SLA di 4h / 24h / 72h; adatta alle decisioni regolamentate (rinvii in sede di sottoscrizione, triage medico, segnalazioni di conformità).

Ogni percorso di riserva ha bisogno di un titolare designato e di uno SLA documentato. L'AI Playbook del DSIT britannico lo enuncia in chiave operativa, richiedendo «processi di revisione ed escalation chiaramente documentati ... e un comitato di revisione dell'IA o un comitato a livello di programma» [4], e la funzione MANAGE del NIST AI RMF veicola la stessa indicazione da un'altra angolatura, esigendo un monitoraggio post-implementazione con canali di feedback designati. L'anti-schema d'audit è ricorrente: una coda generica di «revisione umana», senza SLA né titolare, in cui la coda cresce e la raccomandazione dell'IA diventa di fatto la decisione. Da Marrowfield la riprogettazione ha assegnato ciascun percorso di riserva: i sinistri di importo modesto, al di sotto di una soglia di materialità, si processano automaticamente; i casi della fascia intermedia seguono la Soluzione A con uno SLA di 4 ore; i casi della fascia alta e quelli sotto soglia seguono la Soluzione C con sottoscrittori designati. Le code hanno smesso di essere un unico canale di troppopieno e sono diventate tre linee di produzione, ciascuna con metriche e titolari propri.

§4 — La pista di controllo degli annullamenti è l'artefatto di conformità

Ciò che gli auditor ispezionano davvero è il registro degli annullamenti. Un registro assente, o privo di motivazioni strutturate, non supera il test prima ancora che qualsiasi difesa narrativa ottenga udienza. L'artefatto minimo per ciascuna decisione HITL è uno schema fisso: case_id, confidenza dell'IA, raccomandazione dell'IA, ID del revisore, durata della revisione in secondi, decisione umana, motivazione dell'annullamento, marca temporale, policy_version. Senza policy_version la pista risulta ininterpretabile a distanza di un anno, perché le soglie nel frattempo si saranno spostate. L'articolo 14, paragrafo 4, dell'EU AI Act esige che i revisori possano «intervenire sul funzionamento ... o interrompere il sistema» [1], e il corollario operativo è che la capacità deve lasciare traccia, altrimenti è come se non fosse avvenuta. Il NIST AI 600-1 lo declina a livello di azione: «Monitorare e documentare i casi in cui operatori umani o altri sistemi annullano le decisioni dell'IA generativa» [6]. Il registro è la prova centrale di una revisione significativa.

La responsabilità si colloca a monte del registro. L'AI Update dell'FCA fissa il principio: «linee di responsabilità chiare, definite lungo tutto il ciclo di vita dell'IA» [10]. Le imprese britanniche soggette al regime SM&CR collocano lo stack dell'IA e delle operazioni in capo alla funzione Chief Operations; quelle statunitensi istituiscono comitati per l'IA a livello di consiglio; quelle dell'UE seguono gli orientamenti dell'EBA e della BCE sulla responsabilità dell'alta dirigenza. Il principio è trasferibile alle tre tradizioni, il che rende costruire la governance dell'IA fin dal primo giorno più economico dell'adeguamento successivo. La norma ISO/IEC 42001:2023 inquadra l'insieme di controlli più ampio come «un approccio integrato alla gestione dei progetti di IA, dalla valutazione del rischio al trattamento efficace di tali rischi» [8].

Gli auditor cercano i segnali inversi. Una durata della revisione inferiore a 10 secondi si legge come approvazione di mera forma. Un tasso di approvazione superiore al 98% si legge come assenza di revisione. Un campo motivazione vuoto si legge come significatività non documentata. Più di 200 decisioni al giorno per revisore si leggono come affaticamento. Ciascuno è di per sé un rilievo.

§5 — Come mantiene onesto il modello HITL la taratura trimestrale?

Le soglie non si impostano una volta per tutte. I modelli si scostano, le regole di business cambiano, emergono casi limite. Un ciclo trimestrale è la disciplina più economica che impedisce a un sistema HITL progettato di regredire a puro teatro, e pesa in tutte le giurisdizioni: il test di sorveglianza «efficace» dell'articolo 14 è insoddisfabile senza di esso, e la funzione MANAGE del NIST AI RMF richiede che siano predisposti «piani per la prioritizzazione del rischio e un monitoraggio e miglioramento regolari» [5].

Mese uno — misurare il riferimento di base: volume HITL settimanale, tasso di annullamento per fascia di confidenza, distribuzione dei tempi di decisione, tasso di escalation per livello. Mese due — individuare i segnali di scostamento: le fasce in cui l'annullamento supera il 20% indicano un modello inaffidabile e impongono di ampliare la fascia HITL o di riaddestrare il modello; le fasce sotto il 2% si possono restringere in sicurezza; i casi della Soluzione B senza alcuna revisione entro la finestra segnalano un processo in lotti guasto. Mese tre — correggere e documentare: aggiornare le definizioni delle soglie, incrementare la policy_version indicando la ragione della modifica, informare le operazioni, azzerare il riferimento di base.

Il ciclo presuppone una cultura dei revisori che sostiene l'annullamento. L'ICO è esplicito: una revisione significativa richiede che «i revisori abbiano l'autorità di annullare l'output generato dal sistema di IA e siano certi che non saranno penalizzati per averlo fatto» [3]. La stessa aspettativa figura negli appalti statunitensi sotto il NIST AI RMF e nelle regole di responsabilità dell'UE secondo l'EBA e la BCE: giurisdizioni diverse, test operativo identico. Dove la cultura punisce lo scostamento, i tassi di annullamento crollano per ragioni culturali anziché tecniche, e i dati su cui il ciclo si fonda diventano ininterpretabili. L'AI Playbook del DSIT individua la titolarità: un comitato di revisione dell'IA o un comitato a livello di programma è titolare del ciclo [4]. La risposta tipica delle imprese di fascia media alla domanda «chi se ne occupa?» è una promozione interna; si veda l'argomentazione a favore del miglior profilo da nominare AI Lead^EN, che è già dentro l'azienda.

§6 — Quali cinque anti-schemi non superano un audit ai sensi dell'articolo 14?

In ogni audit ricorrono le stesse cinque modalità di fallimento.

Interfaccia di approvazione o rifiuto con un solo pulsante. Il revisore vede soltanto la decisione. Sintomo: tassi di approvazione oltre il 95%, revisioni sotto i 10 secondi. Correzione: esporre confidenza, record di input e fattori di incertezza dichiarati. L'articolo 14, paragrafo 4, lettera b), è esplicito sul bias di automazione: i revisori devono «restare consapevoli della possibile tendenza a fare automaticamente affidamento o a fare eccessivo affidamento sull'output prodotto da un sistema di IA ad alto rischio» [1].

Revisore unico, senza rotazione. Un solo direttore delle operazioni revisiona ogni caso HITL. Sintomo: colli di bottiglia nei fine settimana, errori da affaticamento a fine giornata, un singolo punto di vulnerabilità. Correzione: un bacino formato di 3-5 revisori su un calendario di rotazione documentato.

Soglia impostata una volta, mai tarata. I valori predefiniti del fornitore restano immutati. Sintomo: volume HITL lontano dalla fascia; tassi di annullamento sospettosamente bassi o cronicamente sopra il 20%. Correzione: il ciclo trimestrale del §5.

Nessuna raccolta delle motivazioni di annullamento. I revisori possono annullare, ma il campo motivazione è facoltativo o vuoto. Sintomo: la significatività non è dimostrabile. Correzione: raccolta strutturata, con un menù a tendina delle tre motivazioni principali più un campo di testo libero, entrambi obbligatori.

Coda di riserva senza SLA. I casi vengono instradati alla «revisione umana» senza alcuna responsabilità di smaltimento entro una finestra definita. Sintomo: lunghezza della coda in crescita di mese in mese, revisori che saltano le voci più vecchie. Correzione: uno SLA esplicito per ciascun percorso di riserva, più un cruscotto di monitoraggio della coda con un titolare designato. La titolarità diffusa è il rischio strutturale; l'indagine BoE/FCA osserva che la responsabilità «è spesso ripartita, e la maggior parte delle imprese dichiara tre o più persone o organi responsabili» [9], mentre l'articolo 14 dell'EU AI Act pone la sorveglianza in capo a una «persona fisica» designata [1].

§7 — L'articolo 14 e il calendario dell'agosto 2026

L'inquadramento di conformità non è teatro circoscritto a una singola giurisdizione. Più autorità convergono sullo stesso test operativo; l'EU AI Act vi associa la scadenza più nota. L'articolo 113 fissa la data di applicazione degli obblighi per l'alto rischio, articolo 14 incluso, al 2 agosto 2026 [1]. Da quella data, le imprese che implementano l'IA negli ambiti ad alto rischio dell'allegato III (occupazione, scoring creditizio, infrastrutture critiche, dati delle attività di contrasto) ne portano l'obbligo.

L'articolo 22 del UK GDPR è già vincolante, e il suo test è quello del «contributo umano significativo» [3]: autorità, competenza, considerazione dei dati di input e delle alternative, una cultura che sostiene e nessuna penalizzazione per chi si discosta dal modello. Dove si applica l'articolo 22, ovunque una decisione produca effetti giuridici o analogamente significativi, l'approvazione di mera forma non supera il test [2]. La posizione statunitense non è assente: leggi statali (Colorado AI Act, NYC AEDT, le regole ADMT proposte in California) ed enforcement settoriale (la FTC sul processo decisionale automatizzato, il NIST AI RMF come riferimento d'appalto per l'uso federale) spingono la stessa disciplina. La norma ISO/IEC 23894:2023 standardizza l'approccio sottostante alla gestione del rischio come «guida sul modo in cui le organizzazioni ... possono gestire il rischio specificamente connesso all'IA» [7], l'ancoraggio non regolamentare più pulito per i mercati le cui leggi specifiche sull'IA non sono ancora in vigore, e l'ossatura di qualsiasi politica operativa multigiurisdizionale.

Le autorità di settore rafforzano il punto: l'FCA è tecnologicamente neutrale [10], gli omologhi dell'UE sotto l'EBA e la BCE si allineano sulla responsabilità dell'alta dirigenza, e l'indagine BoE/FCA 2024 mostra che nella maggior parte delle imprese intervistate la responsabilità è tipicamente frammentata tra tre o più soggetti responsabili [9].

Le domande di progettazione dei §§2-5 sono le domande di conformità nelle tre tradizioni giuridiche. Costruire il modello HITL in questo modo si paga una volta sola; adeguarlo dopo un audit fallito si paga ogni trimestre.

§8 — Com'è fatto lo sprint di progettazione HITL di quattro settimane?

La riprogettazione è circoscritta: uno sprint guidato dal responsabile delle operazioni, non un programma.

Settimana 1 — Misurare lo stato attuale. Censire ogni fase di «revisione umana». Estrarre i tassi di approvazione, le distribuzioni della durata delle revisioni, lo stato della raccolta degli annullamenti, le lunghezze delle code. La firma dell'approvazione passiva: tasso di approvazione elevato, durata di revisione ridotta, nessuna motivazione di annullamento strutturata.

Settimana 2 — Progettare le vie decisionali. Impostare i limiti di confidenza per flusso di lavoro usando i punti di partenza del §2. Progettare i percorsi di riserva secondo il §3. Definire lo schema della pista di controllo degli annullamenti secondo il §4. Documentare la policy_version v1.0 con valori delle soglie, titolari e SLA.

Settimana 3 — Implementare, formare, raccogliere dati. Realizzare le modifiche dell'interfaccia, esponendo il ragionamento del modello e la confidenza sullo schermo del revisore. Formare il bacino di revisori su esempi pratici. Avviare l'operatività dal vivo con la registrazione completa per l'audit fin dal primo giorno.

Settimana 4 — Prima revisione di taratura e documentazione pronta per l'audit. Eseguire il ciclo del §5 sui dati della settimana 3; i segnali di scostamento evidenti emergono anche su una finestra breve. Comporre il pacchetto di artefatti: definizioni delle soglie, cruscotto del tasso di annullamento, censimento dei percorsi di escalation, mappa delle titolarità. Il risultato è la posizione da mettere alla prova rispetto alle 50 domande che i decisori si pongono prima di implementare l'IA^EN, che copre i punti Q3.10, Q5.4, Q5.5 e Q5.7.

Fascia di costo: 20-40 ore di tempo del responsabile delle operazioni. Risultato: un protocollo di sorveglianza pronto per l'articolo 14, una posizione di «revisione significativa» difendibile sull'articolo 22 e una funzione MANAGE allineata al NIST RMF.

Dall'approvazione alla disciplina

Quattro settimane dopo la riprogettazione, il quadro operativo è cambiato. Il volume HITL sul flusso di lavoro dei sinistri è sceso del 70%, perché il rifiuto automatico fa un lavoro reale sulla fascia sotto soglia. Il tempo medio di revisione sui casi che arrivano effettivamente al modello HITL è salito a circa quattro minuti, il tempo che la revisione strutturata richiede davvero. Il tasso di annullamento si è stabilizzato al 14%, entro la fascia sana del 5-20%, e ogni caso annullato porta con sé una motivazione strutturata. La domanda del responsabile della conformità ha ora una risposta, con numeri di versione allegati.

La differenza tra il teatro d'audit e una sorveglianza difendibile in sede di audit non sta nella serietà con cui un'impresa parla di revisione umana. Sta nel fatto che la revisione sia un sistema a soglie progettato oppure un'approvazione con un solo clic. Il primo supera l'articolo 14. La seconda no.

Per una lettura di come la progettazione HITL si colloca nei flussi di lavoro regolamentati di un'organizzazione, easy-audit.ai la mappa in due ore di domande strutturate.

In sintesi

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document