Handoff tra agente AI e operatore umano: come si progetta

Un agente AI che risponde bene al 90% delle richieste non vale nulla se sbaglia il 10% restante nel modo peggiore: insistendo. Il momento in cui la macchina riconosce il proprio limite e chiama una persona è la parte del sistema che i clienti ricordano, e quasi sempre è anche la parte progettata con meno cura. L’handoff agente AI umano non è una funzione da attivare con un interruttore: è un insieme di decisioni su soglie, segnali, contesto e responsabilità che vanno prese conoscendo i processi dell’azienda, uno per uno.

In questo articolo vediamo quali segnali devono far scattare il passaggio, quali numeri mettere nelle soglie di confidenza, cosa impone l’AI Act quando la conversazione tocca materie regolamentate, cosa deve arrivare all’operatore insieme alla conversazione e come si misura se il meccanismo funziona davvero.

In questo articolo scoprirai:

• Cos’è l’handoff tra agente AI e operatore umano
• Quando un agente AI deve passare la conversazione a una persona
• Soglie di confidenza per l’handoff: quale valore impostare
• Segnali emotivi: riconoscere la frustrazione prima che il cliente se ne vada
• Handoff e AI Act: cosa impone la legge sul passaggio all’umano

Cos’è l’handoff tra agente AI e operatore umano

L’handoff è il trasferimento della responsabilità di una richiesta dall’agente AI a una persona, insieme a tutte le informazioni necessarie per continuarla. La definizione è volutamente più larga di “passare la chat”: la guida di Salted CX insiste sul fatto che a spostarsi non è il thread, ma la titolarità del problema. Se l’operatore riceve la conversazione ma non sa quali azioni l’agente abbia già tentato, il trasferimento è avvenuto solo sulla carta.

La stessa distinzione vale nei framework tecnici. Nella documentazione di Microsoft Agent Framework, l’handoff si differenzia dal pattern “agente come strumento” proprio per la titolarità: «nel passaggio, l’agente che riceve il passaggio assume la piena titolarità dell’attività», mentre nel secondo caso l’agente primario resta responsabile e delega solo sottocompiti. È una differenza architetturale, ma si traduce in una differenza di esperienza per chi sta dall’altra parte.

Handoff a caldo e handoff a freddo: quale usare

Un handoff a caldo (warm) porta con sé il contesto completo e presenta l’operatore alla conversazione in corso; uno a freddo (cold) sposta la richiesta in coda, tipicamente su un ticket, e il cliente ricomincia. BoldDesk suggerisce una regola semplice: warm transfer per le questioni complesse o emotivamente cariche, cold transfer solo per richieste semplici a bassa carica emotiva. Salesforce, nel suo blog sul passaggio agente-umano, arriva allo stesso punto dal lato operativo: quando l’operatore accede alla stessa console usata dall’AI, «non c’è bisogno che i clienti si ripetano», mentre transizioni inefficienti producono «tassi di abbandono più elevati».

Quando un agente AI deve passare la conversazione a una persona

I trigger che ricorrono in tutte le fonti serie sono sei, e conviene trattarli come un elenco chiuso da configurare esplicitamente invece che come un’intuizione del modello. Il glossario di Decagon sull’escalation policy li definisce come «l’insieme di regole e condizioni che determinano quando un agente AI trasferisce una conversazione a un umano»: soglia di confidenza sotto il minimo, analisi del sentiment che rileva frustrazione, richiesta esplicita di un operatore, regole per argomento (questioni legali, frodi, decisioni finanziarie regolamentate), rilevamento di contatti ripetuti sullo stesso problema, rilevamento di loop conversazionali.

Salted CX aggiunge due casi che nella pratica italiana pesano molto: le azioni che richiedono un’autorizzazione, un rimborso, una modifica contrattuale, una deroga, che vanno messe in pausa e instradate verso chi ha il potere di firmarle, e i fallimenti degli strumenti, dove la regola è preservare lo stato reale prima di ritentare: un agente che riprova un’operazione già andata a metà crea un danno peggiore di quello che stava risolvendo.

Una nota metodologica che vale più di molte checklist, sempre da Salted CX: le condizioni di escalation vanno legate al workflow specifico, non al solo punteggio di confidenza. È il motivo per cui questa configurazione non si può copiare da un’azienda all’altra, dipende da quali azioni l’agente può compiere e da chi, in quell’organizzazione, ha l’autorità di compierle.

La richiesta esplicita di un operatore non si negozia

Su questo punto le fonti sono unanimi e vale la pena isolarlo: quando il cliente chiede di parlare con una persona, l’escalation avviene subito. Decagon lo scrive senza margini: «qualsiasi richiesta diretta di parlare con una persona viene onorata immediatamente, indipendentemente dal fatto che l’AI ritenga di poter risolvere il problema». Salted CX aggiunge il corollario che smaschera le implementazioni fatte male: «non costringere il cliente a ripetere un ciclo di troubleshooting per guadagnarsi l’accesso». Il deflection rate ottenuto trattenendo chi ha già chiesto un umano non è un risparmio: è un costo differito, che si presenta come churn.

Soglie di confidenza per l’handoff: quale valore impostare

La soglia di confidenza è il parametro che tutti cercano e che quasi nessuno tara bene. La guida di My AskAI sulle soglie di confidenza descrive lo schema a tre fasce su cui converge il settore: sopra circa 0,8 l’agente risponde direttamente; tra 0,5 e 0,8 risponde ma segnala l’incertezza e offre il passaggio a una persona; sotto 0,5 escala senza rispondere. È uno schema ragionevole come punto di partenza, ma il numero da solo non basta, e qui sta l’errore più diffuso.

L’avvertenza più importante che abbiamo trovato in tutta la ricerca è di Salted CX: «non trattare la confidenza auto-riportata da un modello come calibrata senza averla validata sul workflow rilevante». La confidenza di un LLM non è una probabilità di correttezza: è un numero che va messo alla prova sui casi reali dell’azienda prima di potersene fidare. Il modo corretto di procedere è quello indicato da Decagon: «la progettazione della policy deve partire dai dati, non dall’intuizione», rivedendo un campione di conversazioni storiche per individuare dove l’AI ha fallito. Solo allora si sa dove mettere il taglio.

Per questo la soglia va sempre accompagnata da altri segnali: tentativi ripetuti falliti, tono del cliente, rischio dell’argomento, richiesta esplicita. Un agente che escala solo sulla confidenza sbaglia in entrambe le direzioni, trattiene conversazioni che doveva passare e passa conversazioni che sapeva gestire.

Soglie di confidenza nei settori regolamentati: sanità, finanza, assicurazioni

Dove l’errore ha conseguenze legali o sanitarie, la soglia si alza. My AskAI indica un minimo del 90-95% di confidenza per la risposta automatica in sanità e servizi finanziari, contro l’80-85% che basta nel retail o nell’e-commerce. Salesforce porta un esempio che rende l’idea di cosa significhi “soglia di complessità”: alla domanda sulle implicazioni fiscali di un prelievo pensionistico, il sistema deve riconoscere che serve competenza normativa specializzata e consegnare il caso a un consulente umano, non perché non sappia rispondere, ma perché non è autorizzato a farlo.

Segnali emotivi: riconoscere la frustrazione prima che il cliente se ne vada

I numeri sulla preferenza per l’operatore umano sono più alti di quanto la retorica dell’automazione lasci intendere. Freshworks riporta che il 68% dei consumatori preferisce parlare con operatori umani e il 63% porterebbe i propri affari altrove in assenza di supporto umano; BoldDesk cita una rilevazione Qualtrics secondo cui il 62% preferisce canali assistiti da persone.

Handoff e fiducia: la domanda giusta non è se l’AI sa rispondere

Il contributo più utile di Freshworks però non è un numero, è una riformulazione della domanda. Secondo Viktoria Lozova la domanda giusta non è «l’AI può risolvere questo problema?» ma «l’utente si fiderà dell’AI per risolverlo?», perché anche quando il sistema è tecnicamente capace, sulle questioni sensibili le persone vogliono un interlocutore umano. Greg Boone indica i segnali concreti da intercettare: «nel momento in cui il sistema rileva esitazione, riformulazioni ripetute, linguaggio emotivo… deve escalare».

C’è un motivo statistico per cui questa soglia va tenuta bassa: sempre secondo Freshworks, meno di un terzo dei clienti insoddisfatti segnala il problema. Gli altri smettono e basta. Un handoff che aspetta il reclamo esplicito arriva, per due terzi dei casi, quando non serve più. La stessa dinamica vale sui canali vocali, dove i tempi di reazione sono ancora più stretti: se state valutando l’automazione del call center, la gestione dell’escalation vocale è il punto in cui si decide la riuscita del progetto, ne abbiamo parlato negli agenti vocali AI.

Handoff e AI Act: cosa impone la legge sul passaggio all’umano

Dal 2 agosto 2026 sono operativi gli obblighi di trasparenza dell’articolo 50 dell’AI Act, e riguardano direttamente chi usa agenti conversazionali. Il testo dell’articolo 50 stabilisce che i fornitori devono garantire che i sistemi progettati per interagire direttamente con persone fisiche siano costruiti in modo che queste «siano informate che stanno interagendo con un sistema di AI», con l’unica eccezione dei casi in cui ciò sia «ovvio dal punto di vista di una persona ragionevolmente ben informata, attenta e consapevole». L’informazione va data «in modo chiaro e distinguibile, al più tardi al primo contatto».

La conseguenza pratica sull’handoff è che il passaggio deve essere dichiarato in entrambe le direzioni: l’utente deve sapere quando sta parlando con la macchina e deve capire quando è arrivata la persona. Una delle tentazioni peggiori, far proseguire l’operatore umano sotto l’identità dell’agente per non spezzare l’illusione di continuità, è esattamente ciò che questa norma rende problematico. Il quadro completo degli adempimenti lo abbiamo ricostruito nella guida sull’AI Act.

Sorveglianza umana (articolo 14): chi può fermare l’agente

Per i sistemi ad alto rischio l’articolo 14 è ancora più esigente, e definisce di fatto i requisiti di un handoff serio. Le persone incaricate della sorveglianza devono poter comprendere «capacità e limiti rilevanti» del sistema, restare consapevoli dell’automation bias, la tendenza a fare affidamento eccessivo sugli output automatici, e soprattutto poter decidere «di non usare il sistema o di ignorare, scavalcare o ribaltare» il suo output, oltre a disporre di un pulsante di arresto che porti il sistema «a fermarsi in uno stato sicuro». Un agente che non prevede chi ha l’autorità di fermarlo non è conforme, prima ancora che mal progettato. Sul rapporto tra guardrail tecnici e obblighi normativi abbiamo dedicato un approfondimento alla supervisione umana degli agenti AI.

Cosa passare all’operatore: il pacchetto di contesto di un handoff fatto bene

Qui la differenza tra un progetto riuscito e uno fallito è quasi tutta nei dettagli. Salted CX elenca sei aree che devono arrivare all’operatore: obiettivo del cliente, passo irrisolto, azioni già tentate e motivo dell’escalation; stato della verifica d’identità con i riferimenti di account o ordine; evidenza delle azioni compiute, distinguendo i risultati confermati dai fallimenti e dagli esiti ignoti; le policy applicate con la loro data di revisione; gli impegni già presi con il cliente, comprese promesse e scadenze; infine la titolarità, a quale team va, con quale priorità, e quale decisione va presa adesso.

Un criterio va sottolineato perché riguarda la protezione dei dati: «invia solo ciò di cui il destinatario ha bisogno e a cui è autorizzato ad accedere». Un handoff che riversa l’intera cronologia su chiunque prenda in carico il ticket è una violazione di minimizzazione travestita da attenzione al cliente.

Handoff tecnico: come si sospende l’agente AI a metà conversazione

Sul piano tecnico il meccanismo è meno esotico di quanto sembri. La documentazione di Parlant mostra il pattern essenziale: una guideline con condizione («il cliente chiede assistenza umana») e azione, un tool che porta la sessione in mode="manual" per fermare le risposte automatiche, e la sessione che resta «l’unica fonte di verità sullo stato della conversazione». Microsoft aggiunge un ulteriore livello per le operazioni sensibili: le funzioni possono essere marcate con approval_mode="always_require", e in quel caso il workflow si sospende e richiede l’approvazione di una persona prima di eseguire un rimborso o un’azione irreversibile, con checkpoint durevoli quando l’approvazione può arrivare ore o giorni dopo.

Come si misura un handoff: le metriche oltre al tasso di escalation

Il tasso di escalation preso da solo è una metrica ingannevole: si può abbassare a piacere peggiorando il servizio. Salted CX propone sei indicatori da leggere insieme: frequenza di escalation, tasso di accettazione da parte degli umani (mantenendo fallimenti e abbandoni al denominatore), completezza del contesto, quota di escalation non necessarie, tasso di escalation mancate, le sessioni in cui il passaggio era dovuto e non è avvenuto, e risoluzione verificata dopo l’handoff.

Escalation mancate e completezza del contesto: le due metriche dimenticate

Le due che quasi nessuno misura sono le escalation mancate e la completezza del contesto, ed è un peccato perché sono quelle che spiegano gli insuccessi. Salted CX avverte che non esiste un target universale: My AskAI indica una forbice sana intorno al 15-30%, con la regola empirica che oltre il 30% stabile il perimetro affidato all’agente è più largo di ciò che sa davvero risolvere. Ma è un’indicazione di orientamento, non un obiettivo da inseguire, e la nostra esperienza è che i progetti si fermano proprio quando si ottimizza un numero al posto del processo, come abbiamo raccontato analizzando gli agenti AI dopo il POC.

Aggiungiamo un punto di progettazione spesso trascurato. L’UX Design Institute osserva che il modo in cui il passaggio viene annunciato cambia la percezione del sistema: invece di un messaggio d’errore generico, l’agente dovrebbe spiegare cosa ha già fatto e perché si ferma. Un handoff mal progettato «presenta semplicemente entrambe le opzioni senza spiegazione», lasciando l’utente confuso su cosa sia stato completato.

Livelli di supervisione: gli agenti AI non sostituiscono le persone, le richiamano al momento giusto

La domanda sul se gli agenti sostituiranno gli operatori è mal posta, e la letteratura lo mostra meglio del marketing. Uno studio sulla co-creazione uomo-AI propone una tassonomia a sei modalità lungo lo spettro dell’autonomia: HOOTL (piena automazione), HAM (assistenza AI passiva), HIC (approvazione umana obbligatoria delle proposte), HITP (flussi con compiti umani deterministici), HITL (escalation avviata dall’AI in caso di incertezza) e HOTL (supervisione discrezionale). L’handoff di cui parliamo in questo articolo è la modalità HITL, ed è solo una delle sei.

Il valore pratico della tassonomia sta nei fattori di contingenza che la governano: complessità del compito, rischio operativo, affidabilità del sistema. Non esiste un livello di supervisione giusto in assoluto: esiste quello giusto per un determinato processo. Lo stesso agente può operare in autonomia sul tracking di una spedizione e richiedere approvazione obbligatoria su una nota di credito. Chi progetta il sistema deve decidere processo per processo, e questa decisione non è tecnica: è organizzativa.

Chi configura l’handoff in azienda: un servizio, non un flag di prodotto

Tutte le piattaforme in circolazione offrono l’handoff come funzionalità. Nessuna può dirvi a quale soglia tagliare, quali argomenti sono regolamentati nel vostro settore, chi in azienda ha l’autorità di approvare una deroga, cosa può vedere il team di secondo livello e cosa no. Sono decisioni che richiedono di conoscere i processi, non il prodotto, ed è la ragione per cui in Tinke l’handoff si configura durante l’onboarding, insieme al cliente, mappando i casi reali prima di scrivere una regola. La stessa logica che applichiamo a tutto il resto: un agente autonomo è un servizio, e il livello di supervisione si sceglie insieme a chi quel processo lo governa ogni giorno.

Come si configura l’handoff agente AI umano, passo per passo

In pratica significa partire dalle conversazioni storiche per capire dove un agente avrebbe fallito, scrivere l’escalation policy come documento condiviso tra chi costruisce il sistema e chi risponde ai clienti, definire il pacchetto di contesto in base a ciò che l’operatore deve davvero sapere, e poi rivederlo con i dati dopo le prime settimane. Gli operatori che ricevono gli handoff vanno preparati a riceverli, altrimenti il passaggio si rompe sull’ultimo metro.

Quando poi il sistema passa in gestione al cliente, l’handoff è una delle cose che il partner deve consegnare documentate, come spieghiamo nell’articolo sulla consegna al team IT.

Se state valutando un agente conversazionale per la vostra azienda, il consiglio è di invertire l’ordine consueto delle domande: prima di chiedere quanto saprà rispondere, chiedete come si comporterà quando non saprà. La risposta a questa seconda domanda dice più sulla qualità del progetto di qualsiasi demo, e vale la pena approfondire anche come si costruiscono agenti AI su misura prima di decidere.

Chi deve portare l’AI in azienda e cerca qualcuno che lo accompagni nell’adozione, dalla mappatura dei processi alla configurazione dell’escalation, fino alla formazione di chi riceverà le conversazioni, può rivolgersi a Tinke per una consulenza. Il punto non è comprare un agente: è decidere insieme dove deve fermarsi.

Fonti:

• Salted CX, AI to human handoff guide
• Microsoft Agent Framework, orchestrazione handoff
• BoldDesk, AI to human handoff
• Salesforce, Agent to human handoff
• Decagon, What is an AI escalation policy
• My AskAI, AI confidence thresholds e handoff
• Freshworks, AI-human handoff
• AI Act, Articolo 50 (obblighi di trasparenza)
• AI Act, Articolo 14 (sorveglianza umana)
• Parlant, Human handoff in produzione
• UX Design Institute, Designing human-agent collaboration
• arXiv 2507.14034, Architettura della co-creazione uomo-AI nei servizi tecnici