Ogni AI agent fa un'ottima figura nelle demo. Gli sottoponi tre domande pulite, risponde con una voce calda, tutti in sala annuiscono. Poi lo metti davanti a 4.000 chiamate reali al giorno e scopri che la demo era il 5% facile. La produzione è l'altro 95%: il chiamante con un bambino che urla, il numero di conto a 11 cifre letto fuori ordine, il caso limite che il tuo prompt non aveva mai previsto e il momento in cui il modello inventa con sicurezza una politica di rimborso che non esiste.
Questo non è un articolo su "come costruire un chatbot". Questa è la checklist di deployment che usiamo davvero per portare gli agenti vocali in produzione e mantenerli lì. Se hai superato la demo e stai guardando la distanza che ti separa da un funzionamento affidabile e su larga scala, questo è il playbook: le cinque vere modalità di fallimento, la progettazione dell'escalation, i guardrail, l'osservabilità, gli SLO e un rollout graduale che non scommette la tua CSAT sul giorno del lancio.
Perché gli AI agent falliscono in produzione (le 5 vere modalità di fallimento)
Gli elenchi in rete ti diranno che esistono "11 sfide degli AI agent". Nella pratica, quasi ogni incidente in produzione si riduce a una di queste cinque:
- Picchi di latenza. Un agente vocale che risponde in 800ms sembra umano. Uno che risponde in 2,5s sembra rotto: i chiamanti gli parlano sopra, lo interrompono, riagganciano. Il problema letale non è la latenza media, è la coda p95 quando il tuo provider LLM è sotto carico o una chiamata a uno strumento si blocca.
- Allucinazioni / risposte sbagliate date con sicurezza. Il modello non dice "non lo so". Dice la cosa sbagliata in modo fluente. In una telefonata non c'è nessun link da cliccare per verificare: il chiamante ci crede e basta, agisce di conseguenza e richiama arrabbiato.
- Escalation rotta. L'agente avrebbe dovuto passare la mano tre turni fa ma ha continuato a provarci, oppure scarica la chiamata su un operatore umano senza alcun contesto, così il chiamante ripete tutto da capo. Entrambi i casi distruggono la fiducia.
- Perdita di stato / contesto. Le chiamate multi-turno perdono il filo: l'agente dimentica l'account che ha appena autenticato, richiede di nuovo il numero d'ordine, entra in loop.
- Nessuna osservabilità. Qualcosa sta andando storto e lo scopri da un picco nel tasso di richiamate una settimana dopo, perché nessuno ha registrato la trascrizione turno per turno, le chiamate agli strumenti o i segnali di confidenza.
Nota cosa non c'è in questo elenco: l'intelligenza del modello. I modelli di frontiera sono abbastanza intelligenti. I fallimenti di deployment sono quasi sempre fallimenti di infrastruttura e operations travestiti da problemi di modello.
Progettare l'escalation: quando e come l'agente passa la mano a un umano
L'escalation non è un ripiego. È una funzionalità di prima classe che progetti, strumenti e ottimizzi. Se la sbagli, ogni altro guardrail perde colpi.
Quando fare escalation: attiva su segnali, non a sensazione:
- Richiesta esplicita. Il chiamante dice "operatore", "rappresentante", "persona". Immediata, senza negoziare, senza "prima lascia che provi ad aiutarti".
- Fallimenti ripetuti. Due turni consecutivi in cui l'agente non riesce a risolvere o il chiamante si ripete → escalation.
- Confidenza bassa. Il passaggio di retrieval non restituisce nulla di fondato, oppure il classificatore di intent è sotto la soglia → non tirare a indovinare, passa la mano.
- Intent ad alto rischio. Contestazioni di pagamento, disdette, qualsiasi cosa legale o medica → instradare a un umano per policy, anche se l'agente potrebbe rispondere.
- Sentiment. Frustrazione rilevata o tono di voce alzato → escalation prima che diventi un reclamo.
Come fare escalation: porta con te il contesto. Un warm transfer significa che l'operatore umano riceve un payload strutturato: identità del chiamante (già autenticata), intent, riassunto della trascrizione, cosa l'agente ha già provato e qualsiasi azione in sospeso. Il chiamante non dovrebbe mai ripetere il numero di conto che ha appena fornito. Quel singolo dettaglio è la differenza tra "l'AI mi ha fatto perdere tempo" e "l'AI ha preparato tutto alla perfezione".
Guardrail e grounding: fermare le risposte sbagliate date con sicurezza
Non puoi uscire dalle allucinazioni a forza di prompt. Ci si lavora attorno con l'ingegneria, su tre livelli:
- Grounding / RAG con rifiuto. Le risposte arrivano dalla tua knowledge base recuperata, non dalla memoria del modello. E la regola ferrea: se il retrieval non restituisce nulla di rilevante, l'agente dice "le passo qualcuno che può confermarlo" — non una supposizione plausibile. Un rifiuto è un successo, non un fallimento.
- Chiamate a strumenti con ambito definito, non testo libero, per le azioni. L'agente non "decide" di emettere un rimborso in prosa. Chiama uno strumento
refund()con argomenti tipizzati, il tuo backend convalida l'idoneità e l'API — non il modello — è la fonte di verità. Le chiavi di idempotenza evitano il doppio rimborso quando una chiamata cade a metà azione. - Validazione dell'output. Prima che il TTS lo pronunci, controlla la risposta rispetto alle policy: nessun importo in dollari fuori dagli intervalli consentiti, nessuna promessa di date che non puoi rispettare, nessun dato personale letto ad alta voce in una chiamata non autenticata.
Il modello mentale: l'LLM è un ottimo router e conversatore e un pessimo sistema di registrazione. Tienilo fuori dai registri.
Osservabilità: cosa registrare, harness di valutazione, test di regressione
Se non riesci a vederlo, non puoi gestirlo su larga scala. Registra ogni turno: trascrizione, confidenza dell'ASR, chunk recuperati, chiamate agli strumenti e relativi risultati, latenza per fase (ASR → LLM → TTS) e il motivo dell'escalation quando ne scatta una. Collega tutto a un ID chiamata che puoi riprodurre.
Harness di valutazione. Mantieni un golden set di chiamate reali — parti da 50, arriva a 500 — etichettate con l'esito corretto. Ogni modifica al prompt, cambio di modello o aggiornamento della knowledge base viene eseguito sul set prima di andare in produzione. Stai misurando containment, tasso di risposte corrette, tasso di falsi rifiuti e tasso di escalation indesiderate.
Test di regressione. La modifica pericolosa è quella che risolve l'intento A e rompe silenziosamente l'intento B. La valutazione con LLM-as-judge sul golden set intercetta questo problema, ma prima calibra il judge su etichette umane, altrimenti stai solo automatizzando i tuoi punti ciechi. Definisci un gate di deploy per singolo intento: una modifica che peggiora "contestazione di fatturazione" non va in produzione, anche se migliora tutto il resto.
SLO per un voice agent (latenza, containment, CSAT)
Obiettivi vaghi ("fallo bene") non sopravvivono al contatto con un cercapersone. Definisci SLO numerici e imposta alert su di essi:
| SLO | Target | Perché è importante |
|---|---|---|
| Latenza di risposta (p95) | < 1.2s | Oltre questa soglia, i chiamanti interrompono e parlano sopra l'agente |
| Tasso di containment | 60–75% | Risolto senza un umano; un valore troppo alto spesso indica un'escalation mal gestita |
| Tasso di risposte corrette | > 95% | Misurato sul golden eval set, non a sensazione |
| Tasso di rifiuti errati | < 5% | Fare troppa escalation erode il ROI |
| CSAT (post-chiamata) | ≥ baseline umana | L'agente dovrebbe eguagliare o superare la tua coda umana |
| Uptime / risposta alle chiamate | 99.9% | Un voice agent che non risponde è peggio di nessun agente |
Nota la tensione: containment e tasso di risposte corrette si contrappongono. Inseguire un containment del 90% di solito significa che l'agente tira a indovinare su chiamate che dovrebbe portare in escalation. Ottimizza per la risoluzione corretta, non per la deflection pura.
Piano di rollout per fasi: shadow → assist → autonomo
Non premere l'interruttore. Costruisci la fiducia in tre fasi:
- Shadow (2-4 settimane). L'agente gira su chiamate reali ma non parla: ascolta, genera ciò che direbbe e tu lo valuti rispetto a ciò che l'operatore umano ha effettivamente fatto. Zero rischio per il chiamante, dati reali. Stai validando l'eval harness e individuando le modalità di errore prima che siano in produzione.
- Assist. L'agente gestisce una fetta ristretta e ben fondata — per esempio stato dell'ordine e orari del negozio — con escalation rapida su tutto il resto. Parti dal 10% del traffico, monitora gli SLO e sali al 100% di quell'intento prima di aggiungere il successivo.
- Autonomo. L'agente gestisce end-to-end l'intero set di intenti validati, con gli umani sulla coda di escalation e una dashboard SLO in tempo reale. "Autonomo" significa comunque monitorato: non rimuovi mai l'osservabilità, smetti solo di sorvegliare ogni singola chiamata.
Ogni fase ha un gate di uscita legato alla tabella SLO qui sopra. Non avanzi perché sono passate due settimane; avanzi perché i numeri hanno superato la soglia.
Quando NON usare Finn (la nota di onestà)
Se il tuo volume di chiamate è sotto le poche centinaia al mese e ogni chiamata è davvero inedita e ad alto tocco — vendite enterprise su misura, raccolta di pratiche legali sensibili — il ROI di un voice agent è sottile e il carico di escalation può superare i risparmi. La voice AI rende sui volumi ripetibili: gli stessi 20 intenti, migliaia di volte. Se le tue chiamate non si raggruppano, metti persone e torna sull'argomento quando lo faranno. Preferiamo dirtelo piuttosto che venderti un deployment che smonterai entro un trimestre.
FAQ
Quanto tempo serve per portare in produzione un AI voice agent? Preventivate 6-10 settimane per arrivare a un rollout autonomo su larga scala: 2-4 settimane in shadow mode, poi una rampa graduale in modalità assist per ogni intent. I team che saltano lo shadow mode rilasciano più in fretta e regrediscono in modo più rumoroso.
Qual è la principale causa di fallimento degli AI agent in produzione? Non la qualità del modello, ma l'infrastruttura e le operations. Code di latenza, grounding assente ed escalation non funzionanti causano la stragrande maggioranza degli incidenti. Il modello di solito è abbastanza intelligente; è il sistema attorno a esso che non è costruito per il 95%.
Come faccio a evitare che l'agent inventi le risposte? Ancora ogni risposta al retrieval, rendi il rifiuto un percorso di successo e instrada tutte le azioni attraverso tool call validate invece che testo libero. Se il retrieval non restituisce nulla, l'agent fa escalation: non tira mai a indovinare.
Quali SLO dovrei impostare per un voice agent? Parti da una latenza p95 < 1,2 s, un tasso di risposte corrette > 95% su un golden eval set, false-refusal < 5% e un CSAT pari o superiore al tuo livello di riferimento umano. Ottimizza per la risoluzione corretta, non per la containment grezza.
(Genera il FAQ JSON-LD dalle quattro coppie domanda-risposta qui sopra.)
Link interni
- Finn vs Retell
- Alternative a Vapi
- Voice Agent API: architettura di produzione
- Come scalare il customer support con la voice AI
- Warm transfer vs cold transfer nei call center AI
Superata la demo, sei alle prese con la produzione? Finn integra fin da subito i guardrail, l'escalation, l'eval harness e la dashboard SLO descritti in questo playbook, senza aggiunte posticce. Prenota una panoramica sul deployment di Finn →
