Passaggio all'operatore umano

Un agente di intelligenza artificiale ha un passaggio all'operatore umano verificabile solo se si può osservare quando deve fermarsi, a chi passa il caso, con quale contesto e che cosa succede se nessuno accetta. Un pulsante «parla con un operatore» o una funzione del fornitore non bastano: serve una prova ripetibile, sul canale reale.

Come si fa a verificare che l'escalation di un agente di intelligenza artificiale funzioni davvero? Si scrivono prima i casi in cui l'agente deve passare a una persona, quelli che deve chiudere da solo e quelli di confine. Si eseguono queste prove sul canale reale e si controllano quattro cose: il passaggio scatta al momento giusto, arriva alla coda giusta, la persona riceve il contesto sufficiente per continuare senza far ripetere all'utente ciò che ha già detto, e l'agente smette di agire una volta ceduta la responsabilità. Se nessuno è disponibile, deve restare un caso con un titolare e un messaggio onesto all'utente, non una chiusura silenziosa.

Che cosa si sta progettando, e che cosa no

Escalation e handoff (passaggio di responsabilità) indicano il trasferimento del caso a una persona. L'approvazione umana è un'altra cosa: l'agente si ferma, ottiene un sì o un no su un'azione delimitata e può riprendere. Usarle come sinonimi confonde il progetto e la verifica.

La «sorveglianza umana» di cui all'articolo 14 del regolamento (UE) 2024/1689 riguarda i sistemi di intelligenza artificiale ad alto rischio. Chiede che il sistema sia progettato perché persone fisiche possano sovrintendere in modo effettivo durante l'uso: comprendere capacità e limiti, monitorare il funzionamento, restare consapevoli del rischio di affidarsi troppo all'output, interpretarlo, ignorarlo o invertirlo, intervenire o interrompere il sistema in uno stato sicuro. L'articolo 26, paragrafo 2, chiede a chi impiega il sistema (deployer) di assegnare questa sorveglianza a persone con competenza, formazione, autorità e supporto necessari. Il testo autentico resta quello pubblicato in Gazzetta e su EUR-Lex; il regolamento è stato oggetto di aggiornamenti successivi, quindi va riletto sulla fonte ufficiale al momento della pubblicazione.

Non ogni agente per il servizio clienti è un sistema ad alto rischio. Questa pagina non valuta la qualificazione giuridica di un caso d'uso e non è un parere legale. Un pulsante di passaggio all'operatore non dimostra, da solo, una sorveglianza effettiva. Neppure un tasso basso di passaggi all'umano è, da solo, un successo: può nascondere i casi che dovevano uscire e sono rimasti chiusi dall'agente.

Tre fatti da tenere fermi

Il regolamento chiede una sorveglianza effettiva, quando si applica. Per i sistemi ad alto rischio, come si è detto, non basta esporre un controllo in interfaccia. Il limite è chiaro: questa non è una valutazione del tuo caso, e Conflux non attesta la conformità al regolamento. La conseguenza pratica è la stessa, anche fuori da quel regime: se nessuno può interpretare, fermare o prendere in carico il caso, o se il caso scompare quando la coda è piena, il passaggio non è verificabile. L'azione è provare, su casi reali o di collaudo, l'override, l'interruzione in stato sicuro e l'accettazione della titolarità da parte di una persona nominata.

Un quadro di gestione dei rischi non sostituisce la prova sul caso. Il NIST AI Risk Management Framework 1.0 (National Institute of Standards and Technology, quadro volontario di gennaio 2023, oggi in revisione) e la norma ISO/IEC 42001:2023 (International Organization for Standardization / International Electrotechnical Commission: sistema di gestione dell'intelligenza artificiale, dicembre 2023) descrivono come un'organizzazione può governare i rischi dell'intelligenza artificiale. Il primo è un quadro volontario, di origine statunitense. La seconda è una norma a pagamento; la certificazione è volontaria e non viene rilasciata da ISO. Né l'uno né l'altra, e nessun certificato, provano che l'escalation di un agente funzioni. Conflux non si presenta come certificata rispetto a queste riferimenti, né come organismo di certificazione. Una policy o un badge non sostituiscono una prova osservabile. L'azione è collegare la checklist di questa pagina a un piano di misura e a un responsabile di processo, con evidenze conservate.

La funzione del fornitore è un trasferimento progettato, non una prova. La documentazione ufficiale di Microsoft Copilot Studio descrive il passaggio a un operatore con cronologia, variabili di contesto e un nodo di trasferimento, o in assenza un topic di escalation. Google Dialogflow CX documenta il live agent handoff come risposta di fulfillment (`LiveAgentHandoff`): l'integrazione esegue il trasferimento. Amazon Connect documenta l'intento `SpeakToAgent` e il blocco di trasferimento a una coda. Sono capacità di prodotto, non la prova che la tua organizzazione le abbia configurate, testate sul canale reale e presiedute. «Il nostro fornitore ha l'handoff» non risponde alla domanda di verifica. Un test solo nel costruttore può nascondere fallimenti su voce, chat o email. L'azione è ripetere le prove sul canale usato dalle persone e controllare coda, contesto, accettazione e fallback, indipendentemente dal fornitore.

Come si progetta il passaggio

Si dichiarano prima i trigger: richiesta esplicita di una persona; ripetuti fallimenti; richiesta fuori dal perimetro; azione irreversibile o ad alto impatto; identità o regola mancante; conflitto di evidenze. Alcuni trigger vanno provati anche più avanti nella conversazione, non solo al primo turno.

Si definisce il pacchetto di contesto minimo che deve arrivare all'operatore: la richiesta; lo stato della verifica di identità; i fatti raccolti e le fonti; ciò che manca ancora; le azioni tentate e il loro esito reale, distinto dalle inferenze dell'agente; il motivo del passaggio; la coda e il titolare; il messaggio già dato all'utente. I dati sensibili nel riassunto rispettano la policy: niente credenziali, segreti o informazioni non necessarie.

Si decide la coda e il ruolo a cui il caso deve arrivare, e si richiede un'accettazione da parte di una persona, non solo un «ticket aperto». Dopo il passaggio l'agente non compie altre azioni sul caso. Se la coda è piena, il trasferimento fallisce o l'utente si disconnette, il caso resta visibile, con un titolare e un prossimo passo; non viene marcato come risolto in silenzio.

Queste soglie si possono fissare prima di scrivere il dialogo, per esempio con l'Agent Design Canvas. L'articolo sul design agentico pone già la domanda sul protocollo di handover. Questa pagina non riformula quelle pagine: dice come si verifica che il protocollo tenga.

Come si verifica che il passaggio funzioni

Si costruiscono tre famiglie di casi: deve passare, non deve passare, confine. Si eseguono sul canale reale — voce, chat, email, applicazione — non solo nel flusso del fornitore. Dopo il passaggio si guarda se la persona ha letto il contesto, se ha corretto eventuali errori dell'agente, se il caso è arrivato a un esito accettato.

Si esaminano anche le conversazioni che l'agente ha chiuso da solo e che invece dovevano uscire. Chi guarda solo i passaggi avvenuti non vede i casi intrappolati.

Per ogni prova si registrano: trigger, momento del passaggio, coda, completezza del pacchetto, accettazione, azioni dell'agente dopo il passaggio, fallback, evidenza (trascrizione o registrazione). L'esito è passa, non passa, o non provato. Non esistono qui soglie o confronti di settore: un indicatore va letto con il suo denominatore, e un indicatore da solo è ambiguo.

La stessa checklist si può far girare in una sessione di prova con prodotto, sistemi informativi e assistenza. Non sostituisce la prova sul canale usato dalle persone.

Checklist di verifica

Ogni punto è autonomo e si valuta passa / non passa / non provato. Due persone che applicano la stessa voce dovrebbero arrivare alla stessa risposta.

1. Esiste una policy scritta di escalation, con versione e titolare.
2. La richiesta esplicita di una persona viene onorata, senza un nuovo giro di persuasione da parte dell'agente.
3. I temi o le azioni riservate a una persona non vengono tentati dall'agente.
4. Dopo fallimenti ripetuti l'agente cambia approccio o passa il caso: non ripete la stessa risposta in loop.
5. Il passaggio va alla coda e al ruolo giusti.
6. Il pacchetto di contesto è completo e distingue fatti, inferenze e azioni solo proposte.
7. Una persona accetta la titolarità; il tempo fino all'accettazione è registrato.
8. L'utente riceve un messaggio sul passo successivo, senza promesse non autorizzate.
9. L'agente non compie altre azioni sul caso dopo il passaggio.
10. Se nessuno è disponibile o il trasferimento fallisce, il caso resta aperto, con titolare e prossimo passo; non viene marcato come risolto.
11. I dati sensibili nel riassunto rispettano la policy.
12. Esiste un campione periodico sia dei passaggi avvenuti sia delle chiusure sospette.

Esempio di fallimento sulla voce 2: l'utente scrive «voglio parlare con una persona» e l'agente offre un altro tentativo automatico prima di trasferire. Esempio sulla voce 10: la coda è piena e la conversazione risulta «chiusa» senza un titolare.

Limiti di questa pagina

Da questa pagina non si può dedurre se un sistema è ad alto rischio, se un'organizzazione è conforme a un regolamento o a una norma, né se un fornitore «risolve» l'escalation. Non è un parere legale, non certifica un sistema e non sostituisce la valutazione delle funzioni competenti. Non contiene tassi, confronti o risultati di progetto.

Domande frequenti

Quando un agente di intelligenza artificiale deve passare il caso a una persona?

Quando la richiesta è fuori dal perimetro dichiarato, quando l'utente chiede una persona, quando un'azione è irreversibile o ad alto impatto, quando mancano identità o regole, o quando l'agente ha già fallito più volte. I trigger si scrivono prima e si provano sul canale reale. I casi di confine restano espliciti, non impliciti nel modello.

Che differenza c'è tra chiedere un'approvazione e cedere la responsabilità del caso?

Nell'approvazione l'agente si ferma, ottiene un sì o un no su un'azione delimitata e può riprendere. Nel passaggio, la responsabilità del caso passa a una persona: l'agente deve smettere di agire e l'operatore deve ricevere il contesto sufficiente per continuare. Non vanno usate come sinonimi.

Che cosa deve arrivare all'operatore, perché l'utente non debba ripetere tutto?

Al minimo: la richiesta; lo stato della verifica di identità; i fatti raccolti e le fonti; ciò che manca ancora; le azioni tentate e il loro esito reale, distinto dalle inferenze dell'agente; il motivo del passaggio; la coda e il titolare; il messaggio già dato all'utente.

Basta un pulsante «parla con un operatore» per dire che l'escalation è progettata?

No. Il pulsante è un canale, non una prova. Serve poter osservare se il passaggio scatta quando deve, se arriva alla coda giusta, se il contesto è sufficiente e se l'agente si ferma. Va anche definito il comportamento se la coda è piena o il trasferimento fallisce.

La sorveglianza umana del regolamento sull'intelligenza artificiale è la stessa cosa del passaggio all'operatore?

No. L'articolo 14 del regolamento (UE) 2024/1689 riguarda i sistemi ad alto rischio e chiede una sorveglianza efficace da parte di persone, commisurata al rischio. Non tutti gli agenti per il servizio clienti rientrano in quel regime, e un controllo in interfaccia non dimostra da solo quella sorveglianza. La valutazione giuridica resta alle funzioni competenti.

Fonti

• Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, articoli 14 e 26. Testo ufficiale: https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=it. Sintesi di navigazione della Commissione, Articolo 14, basata sulla versione consolidata EUR-Lex al 27 luglio 2026: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14. Il testo autentico resta quello pubblicato in Gazzetta / EUR-Lex.
• National Institute of Standards and Technology, AI Risk Management Framework 1.0, gennaio 2023 (in revisione): https://www.nist.gov/itl/ai-risk-management-framework. PDF: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.PDF. Non usare il DOI, risultato instabile.
• International Organization for Standardization, scheda ufficiale ISO/IEC 42001:2023: https://www.iso.org/standard/42001. Citare solo ciò che la scheda pubblica.
• Microsoft Learn, Hand off to a live agent (Copilot Studio), versione italiana: https://learn.microsoft.com/it-it/microsoft-copilot-studio/advanced-hand-off.
• Google Cloud, Dialogflow CX, Live agent handoff: https://docs.cloud.google.com/dialogflow/cx/docs/concept/fulfillment.
• Amazon Web Services, Amazon Connect, intent e trasferimento a una coda: https://docs.aws.amazon.com/connect/latest/adminguide/amazon-lex.html, https://docs.aws.amazon.com/connect/latest/adminguide/transfer-to-queue.html.

Le fonti su regolamento, quadri e documentazione di prodotto sono state verificate l'11 e il 12 novembre 2026. Vanno ricontrollate al momento della pubblicazione. La documentazione dei fornitori descrive capacità di prodotto, non una valutazione di Conflux.

Per approfondire

Conflux progetta servizi e esperienze per agenti di intelligenza artificiale, inclusa la supervisione umana, con metodo Evidence-Based Design. Lavora da Roma e da Milano. Questa pagina è un metodo di verifica, non una certificazione e non un parere legale.

Se stai progettando o mettendo alla prova un passaggio all'operatore, scopri il servizio di Agentic Service Design e il Manifesto del design agentico. Per le prove con le persone, scopri i test con utenti.

Su quale caso, questa settimana, potete dire con una prova — e non con una slide — che l'agente sa fermarsi? Scrivici del processo che volete verificare, senza inserire credenziali o dati non necessari nel primo messaggio.