Human-in-the-loop come feature di prodotto AI B2B
Human-in-the-loop non è una checkbox di interrupt LangGraph. Nei prodotti B2B è un'esperienza di approvazione: evidence chiara, edit-and-resume, timeout, escalation e un audit trail che i buyer possono mostrare a security. Se gli operatori non vedono cosa farà l'agent e perché, o rubber-stampano o abbandonano la feature. Questa guida è per founder, PO e eng lead che rilasciano agent dentro SaaS o tool interni. Copre UX di approvazione, evidence card, policy di timeout, escalation, edit parziali e audit come feature di prodotto. Si collega a workflow agentici per il design del grafo, RAG in produzione quando le citazioni supportano la bozza, e audit logging quando l'HITL diventa superficie di compliance.
HITL come prodotto, non plumbing del framework
Gli interrupt del framework mettono in pausa l'esecuzione. L'HITL di prodotto decide chi vede la pausa, cosa può cambiare, quanto tempo ha e cosa succede se ignora. Quelle regole appartengono a requisiti e UX, non solo alla config dei nodi. I buyer enterprise chiedono: possiamo richiedere dual control sopra una soglia? Possiamo vedere l'evidence dopo? Il support può rifare il replay del perché una bozza è stata approvata? Rispondi in UI e data model. Tratta le code di approvazione come qualsiasi altro workflow B2B: SLA, ruoli, review mobile-friendly e ownership chiara—non un blob JSON in una console admin.
- Interrupt = pausa tecnica; HITL = job dell'operatore da completare
- Progetta per la persona approvatore, non per l'ingegnere che ha costruito il grafo
- Spedisci audit e comportamento timeout con il primo pilot
- Misura override e abandon rate come metriche di prodotto
Quando gli umani devono fare da gate
Gate sempre le azioni irreversibili o ad alto blast: post ERP, cambi prezzo, messaggi massivi, grant di accesso, wording legale/compliance, rimborsi sopra soglia. Gate opzionale per bozze a basso rischio: risposte ticket, summary interni, next step suggeriti. Codifica le regole nel grafo: importo, tier cliente, plant, tipo azione. Non affidarti al modello per 'decidere se chiedere a un umano'. Allinea i gate a AI product fit: se l'azione non supervisionata non è mai accettabile per lo use case, non vendere autonomia che non spedirai.
UX di approvazione che gli operatori finiscono
Uno schermo, una decisione. Mostra: azione proposta in linguaggio chiaro, campi chiave che verranno scritti, livello di rischio, richiedente/contesto e azioni primarie—approva, rifiuta, modifica, scala. Evita di scaricare trace grezze del modello. Gli operatori servono il payload di business. Deep link ai record sorgente (ordine, ticket, policy) battono screenshot di prompt. Supporta review da tastiera e mobile per ruoli plant e field. Uno step HITL che funziona solo su un pannello stile IDE desktop verrà saltato sotto carico.
- Default su labeling dell'azione più sicura (es. 'Posta bozza su ERP')
- Richiedi un motivo sul reject per training e audit
- Disabilita il double-submit; le approvazioni devono essere idempotenti
- Mostra chi altro può approvare se il primario è assente
Evidence card: citazioni, risultati tool, diff
Allega evidence che l'approvatore può verificare: citazioni RAG con titolo e sezione documento, risultati tool con ID e timestamp, e un diff dei campi prima vs dopo. Per bozze basate su RAG, segui le pratiche di citazione. Per azioni basate su tool, mostra l'exact payload che colpirà l'API—non una parafrasi. Segnala sulla card bassa confidence di retrieval o fonti in conflitto. Il silenzio qui è come inizia il rubber-stamping.
Timeout, parking ed escalation
Ogni interrupt ha bisogno di un orologio esplicito: notifica a T1, scala a T2, cancella o parcheggia a T3. Gli hang silenziosi distruggono fiducia e lasciano processi di business a metà. I path di escalation devono rispecchiare gli organigrammi reali: shift lead, plant manager, approvatore finance. Integra con ticket o chat ops esistenti dove le persone già lavorano. I run parcheggiati devono restare resumable dal checkpoint senza reinventare il piano. Documenta il comportamento nei modelli SLA e support così customer success sa cosa significa 'in attesa di approvazione'.
- Non lasciare side effect irreversibili pending senza scadenza
- Alert su età coda e approvazioni abbandonate
- Definisci cancel vs compensate se scatta un timeout a metà saga
- Testa copertura festivi e off-shift prima del go-live
Edit-and-resume senza perdere il filo
Gli approvatori spesso devono sistemare un campo—importo, plant code, destinatario email—poi continuare. Persisti lo state editato nel checkpoint del workflow; non ripartire tutto l'agent da zero a meno che non sia cambiato l'obiettivo. Valida le edit con gli stessi schema dei tool. Rifiuta valori fuori policy prima del resume. L'approve parziale ('approva con modifiche') deve essere un'azione first-class. Dopo il resume, salta il planning LLM ridondante quando l'umano ha già deciso il payload. Il re-planning invita drift rispetto all'intent approvato.
Audit come feature di prodotto
Conserva chi ha visto cosa, quale evidence è stata mostrata, cosa è cambiato, chi ha approvato o rifiutato e i timestamp. Esponi un replay friendly per il support nelle dispute—non solo log grezzi per gli ingegneri. Retention e controllo accessi allineati agli altri journey sensibili per audit e compliance. Redigi i secret; tieni i campi rilevanti per il business. I buyer lo chiederanno nei questionari di security. Spedirlo dopo è una riscrittura del path di approvazione.
- Eventi di approvazione immutabili con correlation ID
- Collega le righe di audit a tenant e ID oggetto di business
- Trail esportabile per review enterprise
- Separa eventi 'evidence vista' da 'azione approvata'
Ruoli: chi può approvare cosa
Lega i diritti di approvazione allo stesso modello di identity del resto del prodotto via SSO e identity. Separation of duties: il richiedente non può approvare la propria azione high-risk quando la policy richiede dual control. L'impersonation di support per debug deve essere auditata e time-boxed. Non usare un account di servizio 'approver' condiviso nella UI di produzione. SaaS multi-tenant: le code di approvazione non devono mai mischiare tenant; filtra come qualsiasi altra lista sensibile.
Scope MVP e metriche di successo
Scope un journey con un tipo di approvazione end-to-end. Non-goal: comitati multi-stage, ranking ML fancy degli approvatori, modalità non supervisionata 'dopo'. Misura: time-in-queue, rate approve/reject/edit, rate di incident post-approvazione e successo task vs baseline manuale. Accoppia a prioritizzazione MVP e unit economics così il costo HITL (minuti umani) è visibile. L'acceptance contractor dovrebbe includere test di timeout, edit-and-resume ed export audit—non solo una demo interrupt happy-path. Vedi acceptance contractor AI.
Prossimi passi
Elenca ogni step con side effect nel tuo agent. Per ciascuno, scrivi copy di approvazione, evidence, timeout e owner di escalation. I gap su quella lista sono lavoro di prodotto, non di prompt. Vedi AI agentica e LangGraph, tool layer MCP, altre risorse, case study, prenota una call, o contatti per revieware il design HITL prima che le write non supervisionate vadano live.
Domande frequenti
Un bottone 'approva' su Slack basta per l'HITL?
Può funzionare per bozze a basso rischio se evidence, identity, audit e timeout sono reali. Cambi ERP o access ad alto blast servono una card più ricca, check di ruolo e state durevole—non solo una reazione emoji.
Il modello dovrebbe decidere quando chiedere a un umano?
No per i gate di policy. Codifica soglie e tipi di azione nel workflow. Hint LLM opzionali per casi ambigui vanno bene; non devono bypassare i controlli obbligatori.
E se gli approvatori non rispondono mai?
Definisci notify, escalate, park o cancel con default business-safe. Misura l'età della coda. Una feature che si blocca per sempre è peggio di nessuna automation.
Come si collega l'HITL all'audit di compliance?
Gli eventi HITL sono eventi di audit: chi ha approvato cosa, su quale evidence, sotto quale versione di policy. Progetta retention e accessi con security subito, non come add-on post-pilot.