Human-in-the-loop: la persona nel sistema

Terzo e ultimo post della serie sul testing dei sistemi AI. Nel primo abbiamo costruito il metro, nel secondo l'abbiamo dato in mano a un modello. Resta la persona.

Il pacco sfocato è già passato. Il controllo di qualità è progettato bene: c'è una persona, ha l'autorità di fermare la linea, sa cosa cercare. La domanda del post è cosa succede a quella persona al terzo mese, quando la linea non si è mai fermata.

C'è una frase che si sente spesso nelle riunioni in cui si decide se mandare in produzione una funzionalità basata su un LLM: "per adesso mettiamo un umano in mezzo". Detta così sembra una soluzione. In realtà è l'inizio di un problema di design, perché "mettere un umano in mezzo" può voler dire cinque cose diverse, con costi, garanzie e modalità di fallimento completamente diverse tra loro.

Questo post prova a fare ordine: cosa significa davvero human-in-the-loop, quali varianti esistono, quando ha senso, quando è teatro, e soprattutto come si fa a capire se il tuo sta funzionando.

La definizione, e perché non basta

Human-in-the-loop (HITL) indica qualunque architettura in cui una persona è un nodo obbligatorio del ciclo decisionale di un sistema automatico. Senza il suo intervento, il flusso non prosegue.

La parola chiave è "obbligatorio". Se il sistema può andare avanti da solo, non sei in-the-loop. Stai facendo qualcos'altro — che può andare benissimo, ma va chiamato con il suo nome.

Le tre varianti, più una

Human-in-the-loop. L'AI produce un output o propone un'azione. Una persona approva, modifica o rifiuta. Solo dopo l'azione ha effetto. È un gate bloccante: il costo è latenza e lavoro umano, la garanzia è che nessun output raggiunge il mondo senza essere passato sotto due occhi.

Human-on-the-loop. Il sistema agisce in autonomia, una persona supervisiona e può intervenire, correggere o fermare tutto. Non c'è autorizzazione preventiva, c'è monitoraggio. Il costo è molto più basso, ma la garanzia è probabilistica: alcuni errori arrivano a destinazione e vengono corretti dopo.

Human-out-of-the-loop. Piena autonomia. Il controllo esiste solo a posteriori: log, metriche, alert, audit periodici, e un canale per le segnalazioni. Non è l'assenza di controllo, è controllo spostato sul piano statistico invece che sul singolo caso.

Vale la pena aggiungerne una quarta, meno citata ma molto usata nella pratica:

Human-in-the-loop-by-exception. Il sistema è autonomo per default, ma alcune condizioni fanno scattare il gate: bassa confidenza, importo sopra soglia, cliente in una certa categoria, azione irreversibile, input fuori distribuzione. È il compromesso che regge meglio in produzione, ed è anche il più difficile da tarare bene.

Non sono quattro etichette equivalenti tra cui scegliere per gusto: sono quattro punti su una scala che va dal controllo totale al controllo statistico, e ognuno costa e garantisce cose diverse.

Un'altra distinzione che si confonde spesso: dove nel ciclo di vita

"Human-in-the-loop" viene usato per indicare tre cose diverse a seconda del punto del ciclo di vita:

Sono attività diverse, con persone diverse e obiettivi diversi. Quando in azienda qualcuno dice "abbiamo l'HITL", la prima domanda utile è: in quale delle tre fasi? Capita spesso che ci sia in training, non ci sia a runtime, e in evaluation ci sia solo a parole.

In una serie sul testing, la fase che ci interessa di più è la terza — ma la seconda è quella che determina quanto ti costa sbagliare, quindi le trattiamo insieme.

I pattern concreti

Nella pratica l'HITL si materializza in una manciata di pattern ricorrenti. Riconoscerli aiuta a non reinventare la ruota (male).

Approval gate

Ogni azione con effetti collaterali richiede conferma esplicita. È il pattern tipico degli agenti: invio email, esecuzione comandi, scrittura su database, pagamenti, deploy.

La variabile di design decisiva è la granularità. Confermare ogni singolo step di un agente che ne fa quaranta è la ricetta perfetta per il click automatico. Confermare il piano una volta sola e poi lasciar correre l'esecuzione è più sostenibile, ma ti espone se l'agente devia dal piano a metà strada. La via di mezzo che funziona: approvazione del piano + gate obbligatorio sulle sole azioni irreversibili.

Confidence routing

Sotto una certa soglia di confidenza il caso va in coda a un umano, sopra passa automatico. È il pattern più diffuso perché bilancia costo e rischio con un solo parametro.

Il trucco sta tutto nel fatto che la confidenza dichiarata da un LLM non è calibrata. Un modello che dice "sono sicuro al 90%" non ha ragione nove volte su dieci. Se usi una soglia, va costruita su un segnale calibrato: probabilità di un classificatore addestrato per lo scopo, varianza tra più campionamenti, disaccordo tra modelli diversi, presenza/assenza di citazioni nel contesto. Non sulla frase "confidence: high" che hai chiesto al modello di generare.

Review a campione (audit)

Tutto passa automatico, ma una percentuale degli output viene ispezionata a posteriori per stimare la qualità reale.

Il campionamento casuale puro è quasi sempre lo spreco peggiore: se il tasso di errore è del 2%, su cento casi ne trovate due. Meglio un campionamento stratificato: una quota casuale (per avere una stima non distorta), più una quota mirata sui casi che il sistema stesso segnala come dubbi, più una quota sui casi rari o ad alto impatto. Le tre quote rispondono a domande diverse e vanno tenute separate anche nei report.

Suggerimento invece di esecuzione

L'AI non decide: precompila. La persona resta l'autore formale dell'atto. È il pattern dominante in ambito medico, legale e HR, e non solo per prudenza: sposta la responsabilità in modo giuridicamente netto.

Attenzione però, perché è anche il pattern che genera più automation bias (ci arriviamo). Un campo precompilato è un'ancora cognitiva potentissima: la persona non sta più decidendo, sta cercando motivi per non cambiare quello che vede già scritto.

Escalation / arbitraggio

Il sistema gestisce il caso normale, l'umano gestisce l'eccezione. Funziona bene quando "eccezione" è definibile con regole esplicite, molto meno quando la definizione è "quando l'AI ha sbagliato" — perché quella è esattamente l'informazione che non hai.

Feedback loop

Ogni correzione umana viene registrata e riutilizzata: come esempio few-shot, come caso nel golden dataset, come dato di fine-tuning, come regola aggiuntiva nel prompt.

È la parte che quasi tutti dimenticano di implementare. Un HITL che corregge gli output ma non li raccoglie è un tampone; un HITL che li raccoglie è un motore di miglioramento. La differenza in valore, su 12 mesi, è enorme.

Quando serve davvero

Il criterio guida è il costo dell'errore, non la difficoltà del compito. È un errore frequente: si mette la review sui task complicati, quando andrebbe messa sui task le cui conseguenze sono costose da annullare.

Le condizioni in cui un gate umano si giustifica:

• Irreversibilità. Invio, cancellazione, pagamento, pubblicazione, deploy in produzione. Se annullare costa più che confermare, mettete il gate.
• Conseguenze su terzi. Un credito negato, una candidatura scartata, una diagnosi, una segnalazione. Chi subisce la decisione non è chi ha comprato il software.
• Vincoli normativi. L'AI Act (Reg. UE 2024/1689) richiede all'art. 14 che i sistemi ad alto rischio siano progettati per consentire una sorveglianza umana effettiva, con la capacità di interpretare, monitorare e annullare l'output. Il GDPR all'art. 22 limita le decisioni basate unicamente sul trattamento automatizzato che producano effetti giuridici o similmente significativi.
• Responsabilità identificabile. In caso di contestazione serve qualcuno che abbia firmato. Non è burocrazia: è la condizione per cui l'organizzazione può difendere la decisione.
• Sistema giovane. Nelle prime settimane di produzione non hai idea del tasso di errore reale. Il gate serve a comprare i dati per poterlo togliere.
• Casi fuori distribuzione. Input mai visti, lingue non previste, formati anomali, richieste ambigue.

E le condizioni in cui è controproducente:

• Volume alto, valore unitario basso. Categorizzare cinquantamila ticket. Il costo della review supera il danno degli errori.
• Latenza stringente. Antifrode in tempo reale, moderazione di chat live, trading. Il gate non ci sta dentro.
• L'umano fa oggettivamente peggio. Succede più spesso di quanto si ammetta, soprattutto su compiti noiosi e ripetitivi in cui l'attenzione crolla dopo venti minuti.
• Nessun potere reale di intervento. Se il revisore non può dire di no — perché non ha le informazioni, o perché il processo lo penalizza se rallenta — il gate è teatro. Ed è teatro costoso, perché produce la documentazione di un controllo che non è avvenuto.

Una regola pratica che uso per decidere: se il revisore non può, in nessuna circostanza realistica, bloccare il flusso, allora non è un revisore. È un passaggio burocratico e va tolto o ridisegnato.

I vantaggi (quelli veri)

Intercetta la categoria di errori peggiore. I sistemi generativi non falliscono in modo rumoroso: falliscono producendo output plausibili, ben scritti e sbagliati. Non c'è eccezione, non c'è stack trace, non c'è alert. Un lettore competente è, ad oggi, il rilevatore più affidabile per questa classe di difetti.

Produce accountability. C'è una persona che ha guardato e ha detto sì. Cambia completamente la conversazione quando qualcosa va storto.

Genera i dati migliori che avrai. Una correzione umana è un dato etichettato in contesto reale, sul tuo dominio, su un caso che il sistema ha effettivamente sbagliato. Vale dieci volte un'annotazione fatta a freddo su un dataset sintetico. È materia prima per il golden dataset — che è il tema del primo post di questa serie.

Permette di partire prima. Con un gate puoi andare in produzione con un sistema che non ti fideresti a lasciare libero, e usare i primi mesi per raccogliere le prove necessarie ad allentarlo.

Copre i requisiti di compliance in modo verificabile, purché documentato.

Gli svantaggi (quelli che nessuno mette nelle slide)

Non scala

Il costo cresce linearmente con il volume. Se il tuo business plan prevede 10x di traffico, l'HITL a gate totale prevede 10x di revisori. Non funziona, e prima o poi qualcuno "risolve" alzando la produttività richiesta per revisore — che è il modo elegante per dire che la review diventa finta.

Automation bias

È il problema numero uno, ed è psicologico prima che tecnico. Le persone tendono ad accettare ciò che il sistema propone, soprattutto se il sistema ha ragione la maggior parte delle volte. Il fenomeno è studiato da decenni nell'aviazione e nella medicina, con due modalità distinte: gli errori di omissione (non mi accorgo di quello che il sistema non ha segnalato) e quelli di commissione (adotto acriticamente un output sbagliato). La pressione temporale li amplifica entrambi.

Il risvolto amaro: più il modello è bravo, meno efficace diventa la review. Un sistema corretto al 99% addestra i revisori ad approvare senza guardare, ed è proprio nell'1% che serviva l'attenzione. L'AI Act ne è consapevole al punto da citare esplicitamente il rischio di eccessivo affidamento tra le cose di cui il supervisore dev'essere reso consapevole.

Un revisore che approva tutto è peggio di nessun revisore: costa, e produce l'illusione documentata del controllo.

Un esempio che probabilmente hai sotto gli occhi tutti i giorni. Gli assistenti di coding agentici come Claude Code sono, di fatto, un human-in-the-loop puro: prima di eseguire un comando, modificare un file o installare una dipendenza, chiedono conferma. Sulla carta è il design corretto. Nella pratica, chiunque li abbia usati per qualche giorno riconosce la sequenza: le prime venti richieste vengono lette con attenzione, le successive duecento diventano y, y, y, Invio, Invio. Non per superficialità — per tre ragioni strutturali che si sommano.

Primo, il volume: un task non banale genera decine di richieste, e nessuno mantiene vigilanza critica su decine di decisioni consecutive. Secondo, il rapporto segnale/rumore: la stragrande maggioranza delle richieste è innocua (leggi un file, esegui i test), quindi il cervello impara statisticamente che la risposta giusta è sempre sì. Terzo, e più interessante per chi progetta sistemi: l'asimmetria di competenza. Se il comando proposto è sed -i 's/.../.../' $(grep -rl ... src/), l'utente medio non ha gli strumenti per valutarlo in due secondi. Può leggerlo, non può giudicarlo. Ed è esattamente il caso in cui il gate dovrebbe servire.

Il risultato è un gate formalmente presente e sostanzialmente disattivato — che è la ragione per cui questi strumenti offrono anche permessi granulari e allowlist per categoria di comando: non per comodità, ma perché togliere le conferme innocue è l'unico modo per far tornare attenzione su quelle che contano. È lo stesso principio della regola 5 più avanti: meno gate, presi più sul serio.

Da questo esempio si estraggono tre requisiti che valgono per qualunque HITL: il gate deve essere raro, deve essere comprensibile a chi lo riceve, e deve mostrare cosa cambia, non solo cosa verrà eseguito.

Review fatigue

Correlato ma distinto. Non è bias cognitivo, è stanchezza. La qualità della revisione crolla con la frequenza e con la ripetitività. Se un operatore fa quattrocento approvazioni al giorno, le ultime cento non sono revisioni.

Moral crumple zone

Espressione di Madeleine Elish, e vale la pena tenerla a mente: l'umano nel loop rischia di diventare la zona di deformazione che assorbe l'urto degli errori sistemici del modello. Formalmente responsabile, materialmente senza il tempo, le informazioni o l'autorità per decidere davvero. Quando qualcosa va storto, la colpa cade su di lui — e il difetto strutturale del sistema resta lì.

Se progetti un HITL, questa è la domanda etica da farsi: sto dando a questa persona gli strumenti per decidere, o le sto dando la responsabilità senza gli strumenti?

Incoerenza tra revisori

Due persone competenti, sullo stesso caso, decidono diversamente. Non è una patologia, è la norma: nella letteratura sull'annotazione si considera accettabile un accordo inter-annotatore (Cohen's kappa) intorno a 0.6-0.7, il che significa che una quota non piccola di disaccordo è fisiologica anche tra esperti. Se non misuri l'accordo tra i tuoi revisori, non sai quanto rumore stai iniettando nel sistema — e nel golden dataset che ne deriva.

Attrito e latenza

Il gate si vede nel prodotto. Un utente che aspetta un'approvazione umana ha un'esperienza diversa, e va progettata anche quella.

Falsa sicurezza

Il rischio meta: la presenza dell'HITL viene usata come argomento per non investire in test automatici, monitoraggio e valutazione sistematica. "Tanto c'è la review". È la giustificazione con cui i sistemi restano non misurati per anni.

Come si capisce se il tuo HITL funziona

Questa è la parte che manca in quasi tutte le implementazioni che ho visto. Un gate umano è un componente del sistema come gli altri: va misurato.

Override rate. La percentuale di casi in cui il revisore modifica o rifiuta la proposta. È la metrica più informativa e la più fraintesa.

• Override molto basso (< 2%): o il modello è ottimo, o i revisori stanno timbrando. Sono due situazioni indistinguibili dai soli log, e per separarle serve altro (vedi sotto).
• Override molto alto (> 30%): il modello non è pronto per quel task, o il prompt è sbagliato, o i revisori e il modello hanno criteri diversi — e in quest'ultimo caso il problema è la rubrica, non il modello.

Audit ciechi. Il modo per distinguere i due casi sopra: inietta periodicamente casi con errori noti nel flusso di revisione e misura quanti ne vengono intercettati. È un test del revisore, non del modello. Va detto in anticipo alle persone coinvolte, altrimenti diventa sorveglianza; ma va fatto, perché è l'unico dato onesto sulla vigilanza reale.

Accordo inter-revisore. Fai rivedere lo stesso set di casi a due persone e calcola il kappa. Se è basso, non hai un problema di modello: hai un problema di definizione. La rubrica è ambigua, e finché resta ambigua qualsiasi metrica costruita su quei giudizi è rumore.

Tempo mediano per review. Se scende nel tempo può voler dire che i revisori sono diventati esperti, oppure che hanno smesso di leggere. Incrocialo con l'override rate: tempo giù + override giù insieme è un segnale d'allarme, non di efficienza.

Tasso di errore post-gate. Quanti errori sono passati comunque, misurati da reclami, correzioni a valle, incidenti. È la misura del valore effettivo del gate. Se è uguale al tasso pre-gate, il gate non sta facendo niente.

Costo per revisione e costo per errore evitato. Il secondo è il numero che serve per decidere se allentare il gate. Se evitare un errore costa più del danno che quell'errore produce, il gate va tolto — o spostato solo sui casi dove il rapporto si inverte.

Progettare bene: sette regole pratiche

1. Rendi la revisione economica. Mostra il diff, non il testo intero. Evidenzia cosa cambia, quali fonti sono state usate, cosa succede se approvo. Ogni secondo di lettura risparmiato è attenzione che resta disponibile per il caso difficile.
2. Mostra l'incertezza dove c'è. Un output uniformemente sicuro invita all'approvazione uniforme. Se il sistema sa di essere su terreno scivoloso su un paragrafo specifico, deve dirlo lì, non in una nota generica a fondo pagina.
3. Il default non deve essere "approva". Nessun pulsante preselezionato, niente conferma con Invio. Fa risparmiare tempo e distrugge il valore del gate.
4. Chiedi un'azione, non un consenso. Far selezionare la motivazione del rifiuto, o far spuntare le due o tre cose verificate, produce un'attenzione qualitativamente diversa dal singolo click su "OK". Costa qualche secondo in più e cambia la natura del compito.
5. Riduci i gate, non aumentarli. Meglio tre gate presi sul serio che trenta timbrati. Ogni gate che aggiungi abbassa il valore di tutti gli altri.
6. Chiudi il loop. Ogni correzione va da qualche parte: dataset, prompt, regole, backlog. Se le correzioni muoiono nel database, hai un costo ricorrente senza rendimento.
7. Tratta l'autonomia come un parametro, non come una scelta binaria. Per categoria di azione, non per sistema. "Le bozze passano automatiche, gli invii richiedono conferma, le cancellazioni richiedono doppia conferma" è una politica sensata. "Il sistema è supervisionato" non lo è.

Su quest'ultimo punto, un frammento che rende l'idea. Il livello di autonomia è una proprietà dell'azione, non del sistema:

from enum import IntEnum


class AutonomyLevel(IntEnum):
    AUTONOMOUS = 0       # executes immediately, logged for sampling
    NOTIFY_AFTER = 1     # executes, then notifies a human (human-on-the-loop)
    REQUIRE_APPROVAL = 2 # blocks until a human approves (human-in-the-loop)
    DUAL_CONTROL = 3     # requires two distinct approvers


def resolve_level(action, context, approval_threshold=0.85):
    # Irreversible actions never run unattended, regardless of confidence
    if action.is_irreversible and action.impact >= Impact.HIGH:
        return AutonomyLevel.DUAL_CONTROL

    if action.is_irreversible:
        return AutonomyLevel.REQUIRE_APPROVAL

    # Calibrated confidence, not the model's self-reported one
    if context.calibrated_confidence < approval_threshold:
        return AutonomyLevel.REQUIRE_APPROVAL

    if context.is_out_of_distribution:
        return AutonomyLevel.REQUIRE_APPROVAL

    if action.impact >= Impact.MEDIUM:
        return AutonomyLevel.NOTIFY_AFTER

    return AutonomyLevel.AUTONOMOUS

Non è il codice il punto. Il punto è che questa funzione deve esistere, essere leggibile da chi non scrive codice, e cambiare quando cambiano i dati. Nella maggior parte dei progetti questa logica è sparsa in sei punti diversi e nessuno sa dire, a colpo d'occhio, cosa il sistema è autorizzato a fare da solo.

Tre storie dal campo

La review che approvava tutto. Un flusso di generazione di risposte a ticket di supporto, con approvazione obbligatoria prima dell'invio. Nelle prime due settimane l'override rate era intorno al 25%: gli operatori correggevano tono, aggiungevano dettagli, ogni tanto riscrivevano da capo. Dopo due mesi era sceso sotto il 3%. La lettura ottimistica era "il modello è migliorato grazie al feedback". La lettura corretta emerse iniettando venti risposte volutamente sbagliate nel flusso: ne furono intercettate sei. Il modello non era migliorato di molto; erano gli operatori ad aver imparato che di solito andava bene. Il fix non fu tecnico: si ridusse il gate ai soli ticket con impegni contrattuali o rimborsi, e su quelli l'attenzione tornò alta perché il volume era gestibile.

Il disaccordo che non era del modello. Un progetto di classificazione documentale in cui il modello sembrava impresentabile: circa il 40% di giudizi "sbagliati" secondo i revisori. Prima di toccare il prompt, abbiamo fatto rivedere lo stesso campione di duecento documenti a due revisori indipendenti. Erano d'accordo tra loro sul 68% dei casi. Il modello non aveva un problema di accuratezza: non esisteva una definizione condivisa di cosa fosse la risposta giusta. Due giorni spesi a scrivere una rubrica esplicita con esempi di confine hanno fatto più della settimana precedente di prompt engineering — e hanno reso finalmente sensato costruirci sopra un golden dataset.

Il gate al posto sbagliato. Un agente che eseguiva una sequenza di operazioni su dati aziendali chiedeva conferma a ogni passo. Dodici, quindici conferme per un singolo task. Dopo una settimana gli utenti cliccavano "approva" a raffica senza leggere — il comportamento era così meccanico che qualcuno teneva premuto Invio. Il gate era ovunque e quindi non era da nessuna parte. Ridisegnato: approvazione unica sul piano proposto all'inizio, esecuzione libera per le operazioni di sola lettura, gate obbligatorio e non bypassabile solo su scritture e cancellazioni. Da quindici conferme a due, e le due venivano effettivamente lette.

Il filo comune delle tre: il problema non era mai il modello. Era la progettazione del punto in cui la persona veniva chiamata a decidere.

Il quadro normativo, in breve

Due riferimenti che vale la pena conoscere anche se non fate compliance.

AI Act (Reg. UE 2024/1689), art. 14. Impone che i sistemi ad alto rischio siano progettati per essere effettivamente sorvegliabili da persone fisiche, che devono poter comprendere il funzionamento, interpretare l'output e annullarlo o interrompere il sistema. Le misure devono essere proporzionate al rischio e all'autonomia del sistema. Rilevante per noi: la norma richiede esplicitamente che chi supervisiona sia messo in condizione di restare consapevole del rischio di eccessivo affidamento sugli output — cioè l'automation bias è un requisito di progettazione, non un dettaglio di UX. Per l'identificazione biometrica remota è previsto un principio di doppia verifica sulle decisioni critiche, con eccezioni delimitate.

GDPR (Reg. UE 2016/679), art. 22. Limita le decisioni basate unicamente su trattamento automatizzato che producano effetti giuridici o comunque significativi sulla persona, con diritto a ottenere l'intervento umano. Attenzione a "unicamente": una supervisione puramente nominale, in cui l'operatore ratifica senza margine reale, non fa uscire il trattamento dall'ambito della norma.

Il messaggio comune delle due norme è lo stesso che vale dal punto di vista ingegneristico: la supervisione di facciata non conta. Il che è comodo, perché significa che progettare bene l'HITL e progettarlo in modo conforme sono in larga parte lo stesso lavoro.

Il modo di sopravvivere mentre la costruisci

• HITL non è una cosa sola: distingui in-the-loop, on-the-loop, out-of-the-loop e by-exception, e specifica sempre in quale fase (training, runtime, valutazione).
• La domanda non è "quanto è difficile il task" ma "quanto costa l'errore e quanto è reversibile".
• Il fallimento tipico non è il revisore che sbaglia: è il revisore che approva senza guardare. Progetta contro questo.
• Misura il gate: override rate, audit ciechi, accordo inter-revisore, errori passati comunque, costo per errore evitato.
• Meno gate, presi più sul serio.
• Ogni correzione umana è materia prima. Se non la raccogliete, state pagando due volte.
• L'autonomia si alza gradualmente e per categoria di azione, sulla base di dati che il gate stesso ha prodotto.

E soprattutto: l'HITL non è un sostituto della valutazione sistematica. È il modo di sopravvivere mentre la costruisci.

Dove si chiude la serie

Se un umano che rivede tutto non scala, la tentazione ovvia è sostituirlo con un altro modello: è quello che abbiamo visto nel secondo articolo, con i bias documentati e la calibrazione contro giudizi umani che serve prima di poterlo usare come metrica. Ma un giudice, automatico o umano, ha comunque bisogno di qualcosa contro cui essere misurato — ed è il golden dataset del primo articolo.

Le tre cose non sono alternative fra loro. Sono i tre pezzi dello stesso apparato di misura, e chi ne salta uno se ne accorge tardi.

Fonti

• Regolamento (UE) 2024/1689 (AI Act), art. 14 — Sorveglianza umana: https://eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=OJ%3AL_202401689
• AI Act Service Desk, sintesi art. 14: https://ai-act-service-desk.ec.europa.eu/it/ai-act/article-14
• M. C. Elish, Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction (2019)
• Landis & Koch (1977) e McHugh (2012) sull'interpretazione del kappa di Cohen
• Rosbach et al., Automation Bias in AI-Assisted Medical Decision-Making under Time Pressure: https://arxiv.org/abs/2411.00998
• Wu et al., Style Over Substance: Evaluation Biases for Large Language Models: https://arxiv.org/abs/2307.03025