HITL e agenti AI: quando serve l’approvazione umana

Inserire una persona prima che l’AI agisca ha senso quando un errore sarebbe costoso o difficile da rimediare. Nell’approccio human in the loop (HITL), il controllo umano può intervenire in 3 momenti: con un’approvazione prima dell’esecuzione, con verifiche a campione sul lavoro concluso o con la presa in carico dei casi inoltrati dall’agente. Per ogni azione va scelto il punto di controllo adatto. Le approvazioni di routine si possono poi ridurre, ma solo quando i riscontri giustificano quella specifica modifica.

Che cos’è l’approccio HITL nell’AI?

Decidere dove inserire il controllo umano significa stabilire quali poteri affidare al sistema: che cosa può fare senza il consenso preventivo di una persona? Nella stessa conversazione, un agente di assistenza può leggere un ordine, preparare una risposta, modificare un record ed emettere un rimborso. Sono azioni che richiedono permessi diversi.

Immaginiamo un giardino con un cancello presidiato. Il giardiniere non controlla ogni passo: regola l’accesso dove un danno sarebbe difficile da riparare, verifica a posteriori il lavoro ordinario e risponde al campanello quando succede qualcosa di insolito. La domanda utile è dove mettere il cancello.

Human-in-the-loop: significato e ruolo delle persone

Human-in-the-loop, di solito abbreviato in HITL, indica la partecipazione delle persone al funzionamento di un sistema di AI attraverso feedback, interventi o decisioni. È un concetto più ampio di un pulsante di approvazione. Nell’attività quotidiana di un’azienda, però, deve corrispondere a una responsabilità precisa: qualcuno approva un’azione proposta, verifica il lavoro svolto oppure risolve un’eccezione. La definizione di Stanford HAI.

Il termine comprende anche il lavoro di chi etichetta i dati di addestramento, corregge gli output dei modelli e ne orienta l’apprendimento. Sono usi legittimi, ma una persona che approva il rimborso di oggi non sta automaticamente riaddestrando il modello di domani. Il controllo operativo produce riscontri; migliorare un modello o un workflow richiede un processo distinto e intenzionale. La spiegazione di Google Cloud.

Come si applica agli agenti AI

Un agente AI è un software che usa un modello per scegliere i passaggi da compiere e chiamare strumenti, per esempio per recuperare un ordine o inviare un messaggio. Il controllo umano va collocato immediatamente prima della chiamata allo strumento che può produrre conseguenze rilevanti. Approvare il piano iniziale dell’agente non dice quale destinatario, importo o record selezionerà in seguito.

Anche il coordinamento di questi passaggi deve essere esplicito. La guida all’orchestrazione degli agenti AI spiega come integrare stato salvato, responsabilità e passaggi di consegne nel lavoro di un agente.

I tre punti in cui può intervenire una persona

L’approvazione serve a impedire una specifica azione; le verifiche a campione a individuare problemi ricorrenti nel lavoro concluso; l’escalation a risolvere i casi che superano i poteri dell’agente. Questi controlli possono convivere nello stesso workflow.

Prima dell’azione: l’approvazione

Il sistema prepara una proposta d’azione precisa e attende. Chi deve approvarla vede il destinatario o il record interessato, la modifica proposta, gli elementi a supporto e la regola che ha richiesto il controllo. L’approvazione sblocca quell’azione; il rifiuto la impedisce.

Questo meccanismo è adatto a un rimborso, a una risposta delicata a un cliente o a una cancellazione irreversibile. Una schermata che chiede soltanto «Consentire lo strumento di assistenza?» nasconde la decisione aziendale. «Rimborsare questo ordine sul metodo di pagamento originale per questo motivo» offre invece qualcosa di concreto da valutare.

Dopo l’azione: la verifica a campione

Il sistema opera entro limiti già autorizzati e una persona controlla in seguito una selezione dei risultati. È un approccio adatto ad azioni di impatto limitato, per le quali gli errori occasionali si possono rilevare e tollerare: per esempio la classificazione dei ticket o i riepiloghi interni.

Una verifica a campione non può prevenire l’errore che rileva. Nel caso di un messaggio a un cliente, una rettifica può rimediare alla conversazione, ma non può far dimenticare al destinatario il testo originale. Questo danno residuo va considerato quando si decide di automatizzare.

Usare un campione casuale per valutare la qualità del lavoro ordinario e un campione mirato distinto per i casi insoliti. Controllare solo i reclami permette di conoscere gli errori segnalati, non la qualità di tutto il lavoro svolto.

In caso di escalation: il passaggio di consegne

L’escalation trasferisce un caso a una persona perché all’agente mancano elementi, permessi o una regola applicabile. Può accadere quando ci sono informazioni discordanti sulla titolarità di un account, dati mancanti sull’ordine, un’eccezione alle regole aziendali o una richiesta esplicita del cliente di parlare con una persona.

Chi riceve il caso deve avere gli elementi raccolti, le azioni tentate, il punto da chiarire e lo stato attuale. L’azione che richiede una valutazione resta sospesa. Se la policy lo consente, possono proseguire altre attività esplicitamente considerate sicure, come preparare un riepilogo interno.

Human over the loop: chi governa il sistema

Quando si incontra questa espressione, è utile ricondurla al livello di governo del sistema: la persona che stabilisce le regole, modifica i permessi e può fermarlo. La terminologia varia, quindi è meglio descrivere la responsabilità anziché affidarsi all’etichetta. Un responsabile che segue le prestazioni non sta necessariamente controllando le singole transazioni.

Per lo stesso motivo, occorre distinguere l’approvazione in the loop dal monitoraggio on the loop. Una dashboard può far emergere rapidamente un problema; non introduce però una pausa prima dell’azione successiva, a meno che quella pausa non sia stata implementata.

Decidere in base al costo dell’errore e alla possibilità di rimediare

Richiedere un’approvazione quando il danno plausibile supera ciò che si è disposti ad assorbire prima di rilevare l’errore e porvi rimedio. Il solo grado di confidenza del modello non risponde a questa domanda.

Valutare ogni azione da questi punti di vista:

• Conseguenze: potrebbe esporre informazioni private, trasferire denaro, assumere un impegno o incidere sull’accesso a un account?
• Ripristino: è possibile tornare completamente e rapidamente allo stato precedente, senza chiedere al cliente di rimediare all’errore?
• Portata: l’azione riguarda una bozza interna, un cliente o un intero gruppo di record?
• Elementi disponibili: identità, dati di origine e regole sono abbastanza chiari da consentire una decisione?
• Rilevamento: ci si accorgerà del problema prima che si accumulino altre azioni simili?

La modifica reversibile di un campo nel database può comunque innescare un evento irreversibile a valle. Cambiare un indirizzo di spedizione può essere facile da annullare finché non inizia l’evasione dell’ordine. Va valutata l’intera conseguenza, non soltanto la presenza di una funzione di annullamento nel database.

Le verifiche a campione sono adatte quando l’azione ha confini precisi, gli elementi disponibili sono affidabili e il danno residuo è accettabile. L’approvazione preventiva serve quando le conseguenze sono rilevanti o le possibilità di ripristino sono limitate. L’escalation serve quando manca un fatto necessario o una regola. Se un’azione è vietata, va bloccata: la coda delle approvazioni non deve diventare un modo per aggirare la policy.

I guardrail per l’AI, controlli automatici su input, output e chiamate agli strumenti, sostengono questo impianto. Possono respingere una richiesta malformata o una destinazione non autorizzata prima che una persona perda tempo a esaminarla. Il giudizio umano dovrebbe occuparsi delle ambiguità legittime che restano.

Human-in-the-loop: l’esempio di un agente di assistenza

I poteri dell’agente di assistenza vanno distinti per tipo di azione. La tabella propone una policy iniziale ipotetica per un’azienda che introduce un agente nell’assistenza sugli ordini. È un esempio progettuale: non descrive le impostazioni predefinite di un fornitore né risultati misurati.

Supponiamo che un cliente dichiari di non aver mai ricevuto un ordine e chieda un rimborso. L’agente può recuperare l’ordine e lo stato della spedizione presso il corriere, quindi preparare una raccomandazione. Se le informazioni sulla consegna contraddicono il racconto del cliente, inoltra la decisione a una persona invece di inventare una soluzione.

Se gli elementi raccolti giustificano un rimborso secondo la policy, l’agente prepara per l’approvazione l’ordine esatto, l’importo, la destinazione e il motivo. Il componente che esegue l’azione verifica l’approvazione e lo stato attuale del rimborso prima di chiamare il sistema di pagamento. Registra poi la ricevuta della transazione restituita dal sistema. Solo a quel punto l’agente può dichiarare che il rimborso è riuscito.

Approvare il rimborso e approvare la risposta sono due autorizzazioni distinte. Il via libera all’operazione finanziaria non autorizza una promessa di consegna inventata nell’email che la accompagna. Allo stesso modo, approvare un messaggio rassicurante non autorizza un rimborso nascosto nella chiamata successiva a uno strumento.

La stessa distinzione vale per le email commerciali in uscita: la stesura del testo può essere automatica, mentre l’invio a una nuova lista di destinatari richiede un controllo. Per le modifiche ai dati, va esaminata la differenza effettiva tra i valori precedenti e quelli proposti, non un riepilogo che si limita a dire «record ripuliti».

Una coda di approvazione che si possa gestire davvero

Chi esamina una richiesta ha bisogno di tutti gli elementi per decidere, di una scadenza e del potere di dire no. Inserire un pulsante di approvazione in un canale di chat risolve soltanto il problema della notifica.

La richiesta deve mostrare l’azione esatta, il cliente o il record interessato, gli argomenti proposti, le fonti a supporto, la corrispondenza con la policy e i fatti ancora da chiarire. Accanto a una modifica proposta va mostrato il valore precedente. I collegamenti alle fonti permettono di verificare la spiegazione dell’agente senza dover ricostruire l’intera conversazione.

Assegnare un revisore principale e un responsabile di riserva. Separare le escalation urgenti dalle approvazioni di routine. Alla scadenza del termine per la revisione, mantenere sospesa o annullare l’azione in attesa e avvisare il responsabile di riserva. Il silenzio non deve diventare consenso.

La capacità di lavoro è un limite concreto. In una coda ipotetica, 24 richieste all’ora × 3 minuti di revisione = 72 minuti di lavoro del revisore all’ora. Una persona ha a disposizione solo 60 minuti, ancora prima di considerare gli altri compiti. La coda cresce anche se ogni decisione è corretta. Prima di promettere un tempo di risposta, occorre eliminare le approvazioni superflue, restringere l’ambito dell’agente o aumentare il personale disponibile.

L’approvazione va vincolata esattamente al contenuto e agli argomenti esaminati. Se cambiano il destinatario, l’importo del rimborso, la versione del record o il messaggio, la decisione va invalidata e occorre una nuova revisione. Prima dell’esecuzione, ricontrollare i fatti che potrebbero essere cambiati durante l’attesa: per esempio, se un altro operatore abbia già rimborsato l’ordine.

Anche ricevere due volte la stessa decisione deve essere sicuro. Usare un identificativo stabile per l’azione, applicare la decisione una sola volta e proteggere dalle duplicazioni la scrittura nel sistema esterno. Un’azione è idempotente quando ripeterla produce lo stesso effetto di una singola esecuzione. Se una richiesta di rimborso va in timeout, accertarne l’esito prima di tentare un altro pagamento.

Come si sospende un agente AI negli strumenti attuali

Gli strumenti offrono meccanismi di pausa diversi; le regole decisionali restano a carico dell’azienda. Le descrizioni seguenti sono state verificate sulla documentazione online dei produttori il 21 ottobre 2026. Riportano il comportamento documentato, non prove pratiche dei prodotti.

OpenAI Agents SDK: approvare la chiamata in attesa

OpenAI Agents SDK, una libreria per sviluppare agenti nel codice applicativo, supporta l’approvazione degli strumenti tramite needs_approval=True in Python o needsApproval: true in JavaScript. Una chiamata soggetta ad approvazione restituisce un’interruzione e uno stato da cui riprendere. L’applicazione approva o rifiuta l’elemento in attesa, poi riprende la stessa esecuzione; lo stato può essere serializzato per una decisione differita. La documentazione di OpenAI sulle approvazioni.

In un’applicazione di assistenza, il blocco di approvazione va posto sullo strumento che rimborsa o invia messaggi. L’interfaccia di revisione va costruita attorno all’azione in attesa. Il breve esempio nella documentazione approva le interruzioni restituite direttamente nel codice: copiarne il ciclo di approvazione incondizionata non introdurrebbe alcun controllo umano. L’applicazione deve prima ottenere la decisione della persona.

LangGraph: interrompere e riprendere il lavoro salvato

LangGraph, una libreria per workflow di agenti che mantengono lo stato, usa interrupt() per fermarsi in attesa di un input esterno. Occorre configurare un checkpointer persistente, il componente che salva lo stato di esecuzione, e un thread_id stabile. La ripresa avviene con Command(resume=...), usando lo stesso thread. La documentazione di LangGraph sulle interruzioni.

Il punto critico per l’uso in produzione è esplicito nella documentazione: quando l’esecuzione riprende, il nodo interrotto ricomincia dall’inizio. Il codice che precede l’interruzione può essere eseguito di nuovo. Le operazioni con effetti sul sistema vanno collocate dopo il punto di revisione e rese sicure da ripetere; la documentazione consiglia anche di isolarle in nodi dedicati. Un’interruzione può restare in attesa a tempo indeterminato: occorre quindi affiancarle le scadenze di revisione e la gestione delle escalation previste dall’azienda.

n8n: aggiungere il controllo umano agli strumenti selezionati

n8n, una piattaforma visuale di automazione dei workflow, permette di associare il controllo umano a strumenti selezionati collegati a un nodo AI Agent. Il flusso documentato si ferma, mostra lo strumento proposto e i parametri, quindi esegue l’input specificato dall’AI se arriva l’approvazione oppure annulla l’azione in caso di rifiuto. La guida di n8n al controllo umano.

Aprire il connettore Tools dell’agente, scegliere un canale sotto Human review e collegare a quel passaggio gli strumenti che richiedono una revisione. La guida documenta, tra i canali disponibili, n8n Chat e Slack, oltre a $tool.name e $tool.parameters per comporre il messaggio di revisione.

Quel messaggio deve rendere visibile ciò che la persona sta approvando. La guida descrive l’approvazione e il rifiuto: non bisogna presumere che fornisca anche un modulo di rimborso modificabile. Se il revisore richiede cambiamenti, la proposta va rimandata in lavorazione e sottoposta a una nuova approvazione.

Anthropic Claude Code: i permessi regolano l’accesso agli strumenti

Claude Code di Anthropic, un agente di programmazione, documenta diverse modalità di autorizzazione per i propri strumenti. default, indicata come Manual, usa richieste di autorizzazione con eccezioni per le operazioni e le regole consentite. acceptEdits autorizza automaticamente le modifiche ai file e alcuni comandi del filesystem nelle directory di lavoro consentite. plan esplora senza modificare i file sorgente. La documentazione di Claude Code sui permessi.

La modalità auto usa un classificatore in background per azioni come i comandi di shell e le richieste di rete. È una decisione di controllo automatizzata. bypassPermissions salta le richieste di autorizzazione, tranne per le azioni documentate che nessuna modalità approva automaticamente. Nessuna delle due dimostra che una persona abbia esaminato ogni azione.

Queste impostazioni governano i permessi di Claude Code durante l’esecuzione. Un servizio di assistenza clienti ha comunque bisogno di regole proprie su rimborsi, destinatari e accesso ai dati. La guida all’opzione dangerously skip permissions di Claude approfondisce i limiti operativi di quella modalità.

Che cosa registrare nei log

Conservare abbastanza elementi strutturati da ricostruire chi ha autorizzato quale azione e che cosa è successo dopo. La sola trascrizione della conversazione rende difficile questa ricostruzione, soprattutto quando un caso resta sospeso o passa di mano.

Registrare questi campi come eventi distinti, collegati dagli identificativi del caso e dell’azione:

• Proposta: tipo di azione, destinazione, argomenti esatti, versione o digest del contenuto, valori precedenti e riferimenti alle fonti di supporto. Un digest è un’impronta del contenuto esaminato.
• Percorso decisionale: versione della policy, regola applicata, obbligo di approvazione o di verifica a campione, motivo dell’escalation e risultati delle verifiche pertinenti.
• Decisione umana: identità autenticata del revisore, autorità per quella specifica azione, approvazione o rifiuto, modifiche richieste, motivo, data e ora e scadenza.
• Esecuzione: identificativo dell’azione approvata, versioni del workflow e della configurazione del modello, identificativo del tentativo, risultato dello strumento, ricevuta esterna e stato finale. Distinguere tra fallimento, successo ed esito sconosciuto.
• Controllo qualità: criterio con cui il caso è entrato nel campione, tipo di errore osservato, gravità, intervento correttivo ed eventuale modifica della regola di autorizzazione.
• Stato della coda: orario di arrivo, responsabile assegnato, tempo di attesa, tempo effettivo di revisione, eventuale superamento della scadenza ed esito del passaggio di consegne.

Limitare l’accesso agli elementi sensibili, oscurare i segreti e stabilire regole di conservazione. Dove possibile, collegare un record sorgente protetto invece di copiare i dati di ogni cliente in ogni log. Registrare motivazioni concise ed elementi a supporto delle decisioni: per verificare un’approvazione non serve il ragionamento nascosto del modello.

Responsabilità, azioni vietate e compiti di escalation vanno definiti nella policy per l’uso accettabile dell’AI. Il log documenta se quella policy è stata rispettata; non può sostituire una policy che nessuno ha scritto.

Ridurre la revisione un tipo di azione alla volta

Passare all’esecuzione automatica per una capacità circoscritta e dimostrata; mantenere il controllo sulle azioni nuove o con conseguenze rilevanti. Un punteggio complessivo di «accuratezza dell’agente» mescola rischi diversi e offre una base debole per modificare i permessi.

1. 1

   Cominciare dalle proposte

   Lasciare che l’agente prepari le azioni e che siano le persone a decidere. Classificare gli errori: destinatario sbagliato, affermazione non supportata, importo errato, elementi mancanti o escalation superflua. Da questi casi ricavare un insieme rappresentativo per la valutazione, con controlli di accesso adeguati.

2. 2

   Approvare entro un ambito circoscritto

   Abilitare l’esecuzione solo dopo l’approvazione. Verificare che il rifiuto impedisca l’azione, che una modifica agli argomenti invalidi l’approvazione e che decisioni duplicate non possano ripetere la scrittura. Prima di ampliare l’accesso, mettere alla prova la gestione dei timeout e degli esiti incerti nei sistemi esterni.

3. 3

   Passare alle verifiche a campione per le azioni adatte

   Scegliere una categoria specifica, per esempio le normali risposte sullo stato degli ordini basate su dati verificati. Prima di esaminare i risultati, stabilire una soglia di accettazione, il metodo di selezione del campione, il responsabile della revisione e una condizione di arresto. Mantenere attivi i criteri che impongono l’escalation.

4. 4

   Ripristinare il controllo quando cambiano le condizioni

   Una modifica a modello, prompt, policy, strumento o fonte di dati deve portare a rivalutare il permesso interessato. Un incidente grave o il peggioramento dei risultati a campione dovrebbe far ripristinare il relativo obbligo di approvazione durante l’indagine.

Monitorare per categoria di azione gli errori dannosi, le correzioni dei revisori, le escalation mancate e il lavoro necessario per rimediare. Distinguere le modifiche estetiche da quelle che hanno evitato un danno. Registrare sia il numero di azioni esaminate sia l’intera popolazione idonea al campionamento. Calcolare il tasso di errore del campione sulle azioni effettivamente esaminate e tenere separati campioni casuali e mirati: pochi casi controllati con esito positivo non dimostrano l’affidabilità dell’intero sistema.

Il tasso di approvazione non basta: una persona può approvare perché il lavoro è buono, perché la richiesta contiene poche informazioni o perché la coda è ingestibile. Occorre esaminare periodicamente anche le decisioni dei revisori. La presenza di una persona offre un’occasione per intercettare gli errori, non una garanzia.

Dove le promesse superano la realtà

«C’è una persona nel processo» è un’affermazione incompleta finché non si sa che cosa vede e che cosa può fermare. Chi riceve una notifica dopo che un rimborso è già stato emesso sta svolgendo un’attività di supervisione, non di approvazione preventiva.

Anche «approviamo tutto finché cresce la fiducia» è un criterio incompleto. Senza condizioni chiare, il processo favorisce l’affaticamento e fa dipendere l’ampliamento dei permessi dall’impazienza. La fiducia dovrebbe derivare da riscontri specifici per ciascuna azione e da possibilità affidabili di ripristino.

Infine, il feedback umano non migliora il sistema da solo. Qualcuno deve trasformare le correzioni in dati sorgente migliori, regole più chiare, prompt rivisti o modifiche al modello sottoposte a valutazione. Quando si assegna la responsabilità del processo di controllo, va considerato anche questo lavoro.

Da dove cominciare lunedì

Chi gestisce le operazioni dovrebbe censire le azioni che l’agente può compiere e assegnare a ciascuna un punto di controllo. La tabella dell’assistenza è un punto di partenza: occorre identificare chi approva davvero e verificare che qualcuno sia responsabile della coda negli orari di servizio promessi.

Chi sviluppa dovrebbe far rispettare la regola al momento dell’esecuzione. Salvare l’azione proposta, vincolare l’approvazione alla sua versione e verificare che rifiuto, scadenza, decisioni duplicate e argomenti modificati siano gestiti correttamente. Il modello deve restare impossibilitato ad approvarsi da solo.

Fondatori e acquirenti dovrebbero chiedere una dimostrazione di un’azione rifiutata e di una richiesta di revisione scaduta senza risposta. Sono casi che rivelano se il sistema dispone di controlli operativi o soltanto di una notifica di approvazione.

Se un agente può già inviare messaggi, trasferire denaro o modificare dati dei clienti senza limiti definiti, è il momento di intervenire. Prima di concedergli più autonomia, vanno risolti i problemi di policy e di capacità dei revisori. A un assistente interno che prepara bozze e non può agire all’esterno potrebbe bastare la normale revisione editoriale, senza un nuovo sistema di approvazione.

Domande frequenti sul controllo umano

Che cosa significa human in the loop nell’AI?

Significa che una persona partecipa al funzionamento di un sistema di AI attraverso controlli, feedback o decisioni. Per gli agenti che svolgono attività aziendali, bisogna specificare se la persona approva prima dell’azione, verifica a campione il lavoro concluso oppure gestisce le eccezioni.

Che cosa comporta avere una persona nel ciclo decisionale?

Significa che il giudizio umano è una parte esplicita del processo. Un’implementazione utile identifica chi controlla, quale decisione gli compete, quali elementi può vedere e che cosa fa il sistema durante l’attesa.

Human-in-the-loop e AI agentica sono la stessa cosa?

L’approccio può essere applicato all’AI agentica, ma i termini indicano concetti diversi. Un agente sceglie i passaggi da compiere e usa strumenti; human-in-the-loop descrive i punti in cui le persone influenzano o autorizzano quel lavoro.

Come mantenere il controllo umano sull’AI?

Richiedere l’approvazione prima delle chiamate agli strumenti con conseguenze rilevanti, assegnare personale alla gestione delle escalation e verificare un campione definito del lavoro concluso idoneo a questo tipo di controllo. Registrare la decisione e l’esito, poi adeguare i permessi in base ai riscontri di ciascuna categoria di azione.

Perché l’AI può bloccarsi in un ciclo?

Nel workflow di un agente, tentativi ripetuti, scelte ripetute degli stessi strumenti o passaggi di consegne irrisolti possono impedire di avanzare. Servono condizioni di arresto e un responsabile delle escalation. Questo ciclo dovuto a un malfunzionamento è diverso dal ciclo di controllo umano introdotto deliberatamente di cui si parla qui.

Per guide pratiche su come integrare l’AI nei processi aziendali, iscriviti alla newsletter.