Strato di Escalation Human-in-the-Loop: Come…

Introduzione al problema dell'escalation umana

Ogni sistema di intelligenza artificiale soggetto a regolamentazione incontra, prima o poi, una decisione che non dovrebbe prendere da solo. La disciplina ingegneristica non riguarda la semplice scelta di se escalare, ma la progettazione di uno strato di escalation che un regolatore riconoscerà come supervisione umana anche tre anni dopo, quando l'auditor chiederà chi ha realmente deciso.

Questo è l'articolo 9 di una serie sull'economia ingegneristica dell'AI regolamentata. I precedenti hanno trattato grafi di provenienza, validazione multimodale per il rischio climatico, enforcement in tempo reale al posto dell'approvazione pre‑deployment, la crisi di riproducibilità per gli LLM aziendali, la stabilità dell'attribuzione, l'orchestrazione deterministica tramite macchine a stati e il modello di costo per l'AI auditabile. Il prossimo pezzo affronterà l'audit replay, ovvero il meccanismo con cui lo stato persistito diventa prova retrospettiva di decisioni passate.

Un caso reale: il pipeline di validazione ESG

Sei mesi dopo il lancio di una pipeline di validazione ESG, è emerso un problema non previsto nei documenti di design. Il sistema funzionava esattamente come previsto: ingestiva le dichiarazioni dei fornitori, le confrontava con baseline geospaziali e strutturate, segnalava incongruenze e instradava le anomalie ad alta fiducia verso l'auto‑remediation e quelle a bassa fiducia verso la revisione umana. Le metriche sembravano sane: la precisione era nel target, il recall entro la banda di tolleranza e la coda di revisori si svuotava nei tempi previsti.

Il problema è emerso da un campione di audit interno di routine. Un revisore senior aveva approvato un lotto di ventitré record di fornitori in quattordici minuti. Sulla carta sembrava accettabile: l'interfaccia della coda era efficiente, i revisori esperti e i record per lo più semplici. Tuttavia, ricostruendo il comportamento reale del revisore dal tracciato di audit — tempi di click, sequenza di record aperti, momenti in cui il pannello di evidenza era espanso o solo osservato — è comparso un modello che nessuna metrica aveva catturato. Il revisore non stava realmente esaminando, ma confermando. La raccomandazione del sistema era trattata come decisione, e l'umano svolgeva solo un rituale di supervisione senza esercitarne il contenuto.

Perché il modello di “human‑in‑the‑loop” tradizionale sta fallendo

Questa è la modalità di guasto che i regolatori hanno ora l'obiettivo di individuare, e che la maggior parte delle architetture AI aziendali produce per sua natura. L'articolo 14 del EU AI Act, lo SS1/23 del PRA britannico sulla gestione del rischio di modello, e i requisiti di integrità della divulgazione di ESRS e TCFD convergono tutti sulla stessa domanda fondamentale: quando un'AI è inserita in una decisione regolamentata, come appare realmente la supervisione umana al momento dell'audit?

Non si tratta di spuntare la casella “c'era un umano nel loop”, un controllo che qualsiasi sistema competente può soddisfare. La questione è: il giudizio umano è stato realmente operativo, e può essere provato retrospettivamente confrontandolo con lo stato che ha prodotto la decisione che è stata approvata?

Tre fallimenti strutturali del modello di conferma

Bias cognitivo di automazione: quando la raccomandazione è presentata accanto all'opzione di accettare o rifiutare, i revisori tendono col tempo ad accettare. Non per pigrizia, ma perché l'interfaccia li inquadra come editori del giudizio della macchina anziché come decisori primari. Decenni di ricerca su sistemi CAD in radiologia, automazione delle richieste di risarcimento e supporto decisionale clinico mostrano costantemente questo drift: ambienti ad alta fiducia e carico producono tassi di endorsement superiori a quelli di un revisore indipendente.
Asimmetria delle evidenze: il revisore vede la raccomandazione e una porzione curata del contesto di supporto, ma raramente accede allo stato esatto che il modello ha visto al momento del punteggio — il vettore di feature, il contesto di recupero, la versione esatta del rule‑set. Questo è cruciale per l'audit, perché la domanda dell'auditor non è “l'umano ha concordato con il modello?”, ma “cosa aveva a disposizione l'umano per dissentire, ed era sufficiente a costituire una supervisione genuina?”.
Crescita dell'irreversibilità: nella modalità di conferma, l'azione umana è trattata come evento terminale (approvato, rifiutato, modificato). Dopo di che la decisione fluisce verso sistemi di fatturazione, filing di disclosure, ritorni regolamentari o comunicazioni al cliente. Se in seguito il modello deriva, il rule‑set è stato configurato erroneamente, o la dichiarazione del fornitore si rivela fabbricata, i sistemi a valle non possono essere ripristinati pulitamente. L'approvazione umana diventa un cancello unidirezionale che “lavanda” l'output del modello in un impegno istituzionale, violando i requisiti dell'Articolo 14 dell'AI Act di poter “intervenire nell'operazione” e “rimanere al comando”.

Questi tre fallimenti si amplificano a vicenda. Il bias cognitivo rende l'endorsement umano meno indipendente di quanto la documentazione di processo suggerisca; l'asimmetria delle evidenze impedisce al revisore di correggere quel bias; l'irreversibilità fa sì che la decisione propagata sia più veloce di quanto i meccanismi di controllo possano intervenire. Quando arriva l'auditor, tre anni di decisioni portano la firma di supervisione umana che, in realtà, non poteva operare.

Cosa richiedono concretamente i quadri normativi

Il linguaggio normativo si è spostato nettamente da forma a sostanza negli ultimi tre anni, ed è fondamentale leggere i testi specifici anziché affidarsi a riassunti.

EU AI Act, Articolo 14

L'articolo 14, provvedimento operativo per i sistemi AI ad alto rischio, impone che le misure di supervisione consentano alle persone naturali di:

interpretare correttamente l'output del sistema AI ad alto rischio;
decidere, in una situazione specifica, di non utilizzare il sistema AI o di ignorare, sovrascrivere o invertire l'output;
intervenire nell'operazione del sistema AI o interromperlo tramite un “pulsante di stop” o procedura analoga che porti il sistema a uno stato sicuro.

Letteralmente, la norma richiede un revisore capace di rifiutare o invertire genuinamente la raccomandazione, non di limitarsi a “rubber‑stamp”. Inoltre, il revisore deve poter intervenire anche dopo che l'output è stato prodotto, non solo prima. Lo strato di escalation deve quindi incorporare la reversibilità come proprietà di prima classe, non come pensiero post‑operativo.

UK PRA SS1/23 sulla gestione del rischio di modello

Il regolamento britannico richiede che le istituzioni finanziarie mantengano un “human‑in‑the‑loop” che sia effettivamente operativo, con capacità di:

monitorare le prestazioni del modello in tempo reale;
attivare meccanismi di intervento manuale quando le soglie di rischio sono superate;
documentare in modo verificabile ogni intervento, includendo lo stato del modello al momento dell'intervento.

Queste disposizioni rafforzano la necessità di uno stato immutabile e auditabile associato a ciascuna decisione.

ESRS e TCFD – integrità della divulgazione

Le linee guida ESRS (European Sustainability Reporting Standards) e TCFD (Task Force on Climate‑related Financial Disclosures) richiedono che le informazioni divulgate siano supportate da evidenze verificabili. Quando un'AI genera dati di sostenibilità, la supervisione umana deve poter dimostrare, retrospettivamente, di aver avuto accesso a:

i dati grezzi utilizzati;
i parametri di modello al momento della generazione;
le logiche di trasformazione applicate.

Solo così la disclosure è considerata “integrità provata”.

Progettare uno strato di escalation come superficie architetturale

Per passare dal modello di conferma a una supervisione realmente operativa, è necessario trattare lo strato di escalation come un’entità a sé stante, con:

una macchina a stati definita, che descriva i possibili passaggi (es. raccomandazione generata → revisore richiesto → revisore interviene → decisione finale → commit o rollback);
un contratto di evidenza che specifichi quali dati devono essere catturati per ogni transizione di stato (click, visualizzazioni, versioni di modello, feature vector, log di contesto);
proprietà di reversibilità integrate, ossia la capacità di annullare o modificare una decisione approvata e di propagare il rollback a tutti i sistemi downstream.

Questa architettura deve essere implementata fin dalla fase di progettazione, non aggiunta come “after‑thought”.

Componenti chiave da includere

Persistenza immutabile dello stato: ogni raccomandazione deve essere associata a un ID univoco e a un record immutabile (es. blockchain o log append‑only) contenente tutti gli input, le versioni di modello e le regole applicate.
Interfaccia di revisione contestuale: il revisore deve poter visualizzare l’intero contesto di generazione, non solo un estratto. Ciò include la visualizzazione del feature vector, la cronologia di retrieval e la configurazione esatta del modello.
Meccanismo di “stop” o “override”: un pulsante di emergenza che, una volta attivato, interrompe l'esecuzione del modello in corso e segnala il blocco a tutti i sistemi downstream.
Log di azione dettagliato: ogni click, scroll, apertura di pannello, tempo di permanenza e decisione finale devono essere registrati con timestamp e associati all'ID della raccomandazione.
Workflow di rollback: definire in anticipo come propagare un rollback (es. annullare una fatturazione, ri‑emettere un filing, notificare il cliente) e assicurare che tutti i sistemi consumatori siano progettati per accettare eventi di annullamento.

Implementando questi elementi, l'azienda può dimostrare in audit che la supervisione umana era effettivamente operativa e verificabile.

Esempio di implementazione pratica

Ritorniamo al caso della pipeline ESG. Per trasformare il processo di revisione:

Ogni record di fornitore viene associato a un record di evidenza immutabile contenente: (a) i dati grezzi del fornitore, (b) il feature vector usato dal modello, (c) la versione del modello e del rule‑set, (d) il contesto di retrieval geospaziale.
L'interfaccia di revisione mostra, oltre alla raccomandazione, un pannello “stato completo” con tutti i punti sopra elencati, espandibile su richiesta.
Il revisore ha a disposizione due pulsanti distinti: “Accetta e conferma” (che crea una transizione di stato “approvato”) e “Rifiuta/Modifica” (che apre un workflow di revisione con possibilità di inserire commenti e di rigenerare la raccomandazione).
Se il revisore attiva “Stop”, il modello corrente viene interrotto, il record passa a stato “interrotto” e tutti i sistemi downstream ricevono un evento di annullamento.
Tutte le azioni (click, tempo di visualizzazione, decisione) sono scritte in un log append‑only con firma digitale, garantendo integrità e non‑repudiation.

Con questa configurazione, un audit futuro può ricostruire esattamente cosa il revisore ha visto, quali alternative aveva e se ha effettivamente esercitato il proprio giudizio.

Conclusioni e raccomandazioni per gli ingegneri

Il passaggio da una supervisione di facciata a una reale human‑in‑the‑loop richiede un cambiamento di paradigma: la supervisione deve essere progettata come componente architetturale con stato, evidenza e reversibilità. Gli ingegneri dovrebbero:

Adottare macchine a stati esplicite per lo strato di escalation;
Garantire la persistenza immutabile di tutti gli input e delle configurazioni di modello;
Progettare interfacce che espongano l’intero contesto di generazione al revisore;
Implementare meccanismi di interruzione e rollback fin dalla fase di design;
Documentare e testare regolarmente il flusso di escalation per verificare la conformità alle normative (EU AI Act, UK PRA SS1/23, ESRS, TCFD).

Solo così le organizzazioni potranno dimostrare, a distanza di anni, che le decisioni regolamentate sono state effettivamente supervisionate da esseri umani capaci di intervenire, invertire e fornire prove concrete dell'intervento. Questo non è solo un requisito di compliance, ma una difesa fondamentale contro il rischio di delegare decisioni critiche a sistemi che, senza una supervisione reale, possono perpetuare errori, bias e vulnerabilità di cui l'auditor non potrà più fare a meno di chiedere la responsabilità.