Come progettare l'escalation umana di un workflow AI

Martedì, 09:14. Un workflow legge una richiesta, non trova il codice ordine e manda un messaggio a un canale con scritto serve verifica.

Alle 11:38 nessuno ha ancora capito chi deve verificare, quale record aprire e se il workflow continuerà a scrivere sul gestionale.

Scenario fittizio. Il difetto è reale: una notifica non è un'escalation.

Per progettare l'escalation umana di un workflow AI devi definire cinque cose prima che il caso si presenti: il trigger osservabile, lo stato sicuro in cui fermare l'esecuzione, la persona o il ruolo che prende il controllo, il contesto minimo da consegnare e la prova che chiude il caso. Si chiama handoff eseguibile.

L'escalation governa una singola esecuzione

Tre oggetti vengono spesso messi nello stesso contenitore.

La matrice di approvazione di un workflow AI decide chi può approvare un cambiamento, una nuova versione o un'azione sensibile. Il registro degli incidenti AI conserva un evento avverso, la sua gestione e le prove. L'escalation, invece, decide cosa succede adesso a questo caso.

Un ordine incompleto. Una bozza con fonti discordanti. Un import che supera la soglia ammessa. L'esecuzione non deve indovinare il seguito.

Il NIST AI RMF separa ruoli e responsabilità nelle configurazioni human-AI, chiede di documentare i processi di supervisione e include appeal e override nel monitoraggio post-deployment. È un riferimento volontario di gestione del rischio. Non stabilisce quale ruolo debba usare la tua azienda né in quanti minuti debba rispondere.

Parti dalle decisioni che l'AI non può prendere

Apri il diagramma del workflow. Evidenzia ogni punto in cui il sistema può:

• creare o modificare un record con effetto operativo
• inviare qualcosa fuori dall'organizzazione
• usare un dato mancante, vecchio o ambiguo
• scegliere tra due regole in conflitto
• proseguire oltre un limite di qualità o rischio

Non tutti i punti richiedono una persona. L'appendice C del NIST AI RMF osserva proprio questo: il bisogno di supervisione cambia con il contesto. Una compressione video automatica e una decisione che blocca una richiesta non hanno lo stesso effetto.

Per ogni punto scrivi due righe: può proseguire se e deve passare a una persona se. Il secondo campo deve usare un segnale che il workflow può osservare.

La risposta sembra strana non regge. Manca order_id, due fonti approvate riportano valori diversi, il totale supera il limite definito nella policy sono trigger controllabili.

Disegna il trigger con quattro campi

Un trigger utile ha evento, condizione, evidenza e gravità.

Campo	Domanda	Esempio fittizio
evento	cosa è appena successo?	import ricevuto
condizione	quale regola non passa?	customer_id assente
evidenza	quale fatto lo dimostra?	validatore schema V-03
gravità	cosa può succedere se prosegue?	record non attribuito

La gravità non si deduce dal tono del testo generato. Viene dalla mappa del processo e dalla tolleranza decisa dall'organizzazione.

Sul workflow di esempio, un campo facoltativo mancante può produrre una nota. Un identificatore necessario per scrivere sul gestionale produce stop e handoff. Stesso errore tecnico, conseguenza diversa.

Ferma il workflow in uno stato sicuro

L'escalation parte prima della notifica. Parte dal punto in cui togli al workflow la possibilità di peggiorare il caso.

Le opzioni comuni sono quattro:

1. hold: il caso resta fermo e nessuna azione esterna parte
2. draft_only: il sistema può preparare una bozza, ma non inviarla
3. fallback: il caso segue un percorso alternativo già provato
4. reject: l'input viene rifiutato con una ragione leggibile

Lo stato deve essere idempotente. Se il controllo gira due volte, non deve creare due ticket, due messaggi o due record. Registra un case_id unico e riusa quello.

Nel monitoraggio di un workflow AI in produzione puoi osservare quanti casi entrano in hold e quanto restano aperti. Il monitoraggio mostra il segnale. L'escalation assegna il lavoro.

Prepara il pacchetto di handoff

La persona non deve ricostruire il caso da cinque sistemi. Ma non deve neanche ricevere un dump pieno di dati inutili.

Un pacchetto minimo può avere questa forma:

case_id: ESC-2026-0818-0042
workflow_id: WF-ORDERS-07
workflow_version: 12
trigger_code: MISSING_CUSTOMER_ID
detected_at: 2026-08-18T09:14:07+02:00
safe_state: hold
owner_role: order_operations
response_due_at: 2026-08-18T10:00:00+02:00
source_refs:
  - request:REQ-8821
allowed_actions:
  - attach_customer_id
  - reject_request
  - request_missing_data
forbidden_actions:
  - publish
  - change_workflow_rule
closure_evidence:
  - action_code
  - actor_id
  - timestamp

ID e orari sono fittizi. Il pacchetto non contiene credenziali, testo personale non necessario o una copia completa del prompt. Contiene riferimenti che la persona autorizzata può aprire nel sistema giusto.

Il dettaglio più importante è allowed_actions. Una escalation senza confine consegna il problema, ma non il potere necessario per chiuderlo.

Instrada per ruolo, non per nome

Mandalo a Giulia funziona fino a quando Giulia è in ferie.

Definisci un ruolo primario, un sostituto e un criterio di passaggio. Il routing può dipendere da processo, gravità, orario o competenza. Non dal nome trovato dentro il testo del caso.

Livello	Caso	Destinatario	Se non risponde
L1	dato operativo mancante	operations queue	passa al turno successivo
L2	regola in conflitto	process owner	resta in hold
L3	possibile impatto serio	funzione competente	blocco dell'azione collegata

La tabella è un esempio di struttura, non una tassonomia universale. Ogni organizzazione deve scegliere livelli e tempi in base al proprio processo.

Un indirizzo di gruppo o una coda sono più robusti di una chat privata. Il proprietario del ruolo decide chi è di turno. Il workflow legge solo la destinazione attiva.

Consegna una decisione, non un riassunto

Un LLM può comprimere il contesto, ma il riepilogo non deve nascondere le fonti.

Metti in cima la decisione richiesta:

Seleziona una delle tre azioni consentite per ESC-2026-0818-0042. Il caso è in hold. Nessun record è stato scritto.

Sotto arrivano trigger, evidenza, riferimenti e limite temporale. Per ultimo, un riassunto generato e marcato come tale.

Se il riassunto dice cliente non trovato ma il validatore dice solo customer_id assente, vince il validatore. L'AI non può trasformare un campo mancante in una causa.

Progetta override e ritorno al flusso

La persona può correggere il caso. Non deve cambiare di nascosto la regola per tutti i casi futuri.

Separa tre azioni:

• resolve_case: chiude questa esecuzione
• override_once: autorizza una sola eccezione tracciata
• propose_rule_change: apre il processo di modifica del workflow

La terza azione torna alla matrice di approvazione. Non passa dentro la scorciatoia dell'escalation.

Il ritorno al flusso usa un token di ripresa legato a case_id, versione e azione approvata. Se nel frattempo la versione del workflow è cambiata, il caso non riparte alla cieca. Torna in verifica.

Chiudi con una prova

Fatto non basta.

La chiusura registra chi ha agito, quale azione ha scelto, su quale versione, quando e con quale risultato. Se il caso riparte, conserva anche l'ID della nuova esecuzione. Se viene rifiutato, salva il codice motivo.

Poi controlla il seguito:

• il workflow ha eseguito soltanto l'azione autorizzata?
• il caso è uscito dalla coda?
• le notifiche duplicate sono rimaste a zero?
• il record finale punta alla decisione umana?

Qui si vede la differenza tra notifica e handoff. La notifica termina quando il messaggio parte. L'handoff termina quando il controllo è passato, la decisione è stata eseguita e la prova è rimasta.

Un esempio completo

Un workflow prepara risposte a richieste commerciali. Non invia nulla senza un contatto verificato.

Arriva una richiesta con email valida ma senza azienda. La policy del processo ammette bozze informative, non proposte personalizzate. Il validatore genera MISSING_COMPANY_FOR_PERSONALIZATION.

Il workflow salva la bozza in draft_only, crea il caso e lo assegna alla coda commerciale. La scheda mostra la richiesta, il riferimento alla fonte, la regola non passata e due azioni: inviare una risposta informativa oppure chiedere il dato mancante. Nessuna opzione consente di inventare l'azienda.

La persona sceglie request_missing_data. Il workflow invia il testo approvato, registra l'ID del messaggio e chiude il caso. Se qualcuno propone di rendere facoltativa l'azienda per le proposte, apre una modifica separata.

Pochi passaggi. Tutti visibili.

Misura il punto di controllo

Non usare il numero di escalation come voto al workflow. Un aumento può indicare un difetto, un nuovo tipo di input oppure un gate che finalmente intercetta casi prima invisibili.

Misura almeno:

• casi entrati per trigger_code
• tempo in stato sicuro
• casi riassegnati
• override singoli
• riaperture dopo la chiusura
• esecuzioni partite senza una prova valida, che devono restare a zero

Affianca sempre il volume delle esecuzioni. Dieci escalation su cento e dieci su diecimila raccontano processi diversi.

Il KPI di conversione di questa pagina resta l'invio form aggregato con source_page e source_form. L'impatto organico richiede una finestra comparabile di almeno 28 giorni dopo un eventuale rilascio.

Gli errori che rompono l'escalation

Il primo è mandare tutto a una persona. Dopo pochi giorni il controllo umano diventa una casella piena.

Il secondo è notificare senza mettere il caso in uno stato sicuro. La persona legge mentre il workflow continua a scrivere.

Il terzo è allegare troppo. Copiare intere conversazioni e record personali dentro una chat crea un nuovo problema.

Il quarto è consentire una modifica globale dalla schermata del singolo caso. Una eccezione operativa non è change control.

Il quinto è chiudere senza prova. Risolto non dice cosa è successo né permette di controllare la ripresa.

Think, Build, Enable applicato all'handoff

Think: scegli i punti in cui una decisione umana cambia davvero l'esito. Scrivi trigger e stato sicuro.

Build: crea routing, scheda di handoff, azioni consentite, timer e prova di chiusura. Testa anche il destinatario assente.

Enable: consegna il runbook a chi prende il controllo. Fagli chiudere casi normali, ambigui e non ammessi senza il team che ha costruito il workflow.

L'autonomia non significa togliere le persone. Significa farle intervenire con un compito preciso.