Quanto Velocemente Deve Rispondere un AI Voice Agent?

Un AI voice agent in produzione dovrebbe iniziare a parlare entro 800ms-1,2 secondi dal momento in cui il chiamante finisce una frase. Oltre i 2 secondi, i chiamanti presumono che la linea sia caduta, iniziano a ripetersi o riattaccano. Che si stia valutando un vendor o costruendo la soluzione internamente, la latenza non è una metrica accessoria: è la differenza tra un agente di cui le persone si fidano e uno che aggirano.

Perché la latenza determina la fiducia nell'agente

La conversazione umana ha un ritmo. Le ricerche sul turn-taking nelle diverse lingue hanno rilevato che il gap medio tra la fine di un intervento e l'inizio del successivo è di circa 200 millisecondi, spesso ancora prima che il primo interlocutore abbia finito (Stivers et al., PNAS). Nessuno si aspetta che un AI raggiunga i 200ms oggi, ma il riferimento con cui compete è quello, non i 3-5 secondi che un cliente potrebbe tollerare da una pagina web lenta.

Sul fronte dell'interfaccia, le soglie di tempo di risposta del Nielsen Norman Group sono il riferimento classico: sotto 0,1s la risposta sembra istantanea, fino a 1s il flusso di pensiero dell'utente rimane ininterrotto, oltre i 10s l'attenzione è già altrove. La voce comprime ulteriormente questa scala, perché non c'è nessuno spinner né barra di avanzamento — solo silenzio — e quindi un gap di 2 secondi in una telefonata sembra molto più lungo dello stesso gap su una pagina web.

Questo aspetto è particolarmente critico per tutto ciò che è transazionale: modifiche alle prenotazioni, stato degli ordini, triage del supporto, vendite outbound. Se si sta confrontando questo canale con uno testuale, la soglia di latenza per un agente AI su WhatsApp per le vendite è molto più permissiva — qualche secondo viene letto come normale tempo di digitazione. La voce non offre questa copertura.

Dove vanno a finire i millisecondi

Una pipeline tipica di un voice agent ha tre stadi, e la maggior parte delle implementazioni li esegue in sequenza:

1. Speech-to-text (STT), trascrivere l'audio del chiamante. 150-500ms a seconda che sia in streaming o batch.
2. Generazione LLM, decidere cosa rispondere e generare la risposta completa. 500ms-2s+ a seconda delle dimensioni del modello, della lunghezza del prompt e dell'eventuale utilizzo di strumenti (consultare un ordine, controllare un calendario) prima di poter rispondere.
3. Text-to-speech (TTS), convertire la risposta testuale completa in audio. 200ms-1s.

Sommati in sequenza, si arriva facilmente a 1,5-3,5 secondi prima che il chiamante senta qualcosa, ancora prima dei round trip di rete. È questo il gap che fa sembrare un agente malfunzionante.

La soluzione non è un modello più veloce: è non aspettare la risposta completa prima di iniziare a parlare. Trasmettere in streaming l'output dell'LLM token per token al TTS e parlare non appena la prima frase è pronta — invece dell'intera risposta — è ciò che riduce davvero il ritardo percepito. È una scelta architetturale di pipeline, non un aggiornamento del modello, ed è generalmente la soluzione con il più alto impatto disponibile.

Le tool call rendono tutto più complesso. Se l'agente deve consultare un database prima di rispondere ("un attimo, controllo il suo ordine"), quella ricerca deve avvenire all'interno del gap e necessita di una propria strategia di riempimento — un'affermazione naturale ("un secondo, sto recuperando i dati") invece del silenzio. Questo è uno dei motivi per cui i sistemi voice agentici richiedono un'orchestrazione più attenta rispetto a una semplice sostituzione di un IVR scriptato: l'agente sta svolgendo un lavoro reale a metà conversazione, non si limita a leggere un testo.

Come valutare un vendor sulla latenza

Non fidarsi di un video dimostrativo. Richiedere:

• Una chiamata dal vivo non scritta sulla propria rete, non una demo preregistrata su infrastruttura inattiva.
• Il time-to-first-audio-byte, misurato — non il "response time", che i vendor a volte indicano come time-to-first-token dell'LLM, ignorando il TTS.
• La latenza sotto carico simultaneo. Una singola chiamata di test non dice nulla su cosa succede con 50 chiamate simultanee, quando entrano in gioco le code GPU e i rate limit.
• Cosa succede con le tool call. Chiedere di attivare una ricerca reale (CRM, calendario, sistema ordini) durante la chiamata e misurare il gap.
• Il routing regionale. Se i chiamanti si trovano nel Golfo o altrove fuori dalla regione predefinita del vendor, chiedere dove viene eseguita effettivamente l'inferenza: un modello ospitato a tre continenti di distanza aggiunge un round-trip reale, limitato dalle leggi della fisica, che nessuna ingegneria può eliminare.

Quest'ultimo punto si amplifica se si gestisce anche un parlato con accento o una lingua non inglese: l'ASR in arabo in particolare presenta veri compromessi tra accuratezza e latenza, poiché i modelli più accurati per i dialetti del Golfo sono spesso più lenti e costosi rispetto agli STT generici per l'inglese.

Se si intende inserire questi requisiti in un contratto, la latenza va trattata come un dato di accuratezza: va definita e il vendor va vincolato a rispettarla. La stessa disciplina usata per le evals nei contratti con vendor AI si applica direttamente: senza un SLA misurabile, "veloce" significa qualunque cosa il vendor abbia deciso il giorno della demo.

Segnali d'allarme

• Il vendor non sa indicare immediatamente il proprio time-to-first-audio-byte a p50/p95.
• La demo funziona bene solo su domande scriptate: basta fare una domanda fuori copione per vedere il gap allargarsi.
• "Abbastanza veloce" è l'unica risposta che si ottiene quando si chiede un numero.
• Nessuna menzione dello streaming nell'architettura: se attendono una risposta LLM completa prima di avviare il TTS, si è bloccati sul percorso lento indipendentemente dal modello che utilizzeranno.

La conclusione

La latenza è una decisione architetturale, non una decisione di selezione del modello. Una pipeline ben progettata su un modello di livello intermedio batterà sistematicamente una pipeline con streaming mal gestito sul miglior modello disponibile. Prima di firmare con un vendor o approvare un progetto interno, occorre ottenere un numero reale — non un'impressione — e se si sta integrando l'AI in un prodotto esistente, è necessario pianificare il tempo di sviluppo per l'infrastruttura di streaming fin dall'inizio, perché aggiungerla in seguito è una riscrittura, non una patch.

Se si sta definendo un voice agent e si desidera un'opinione indipendente sulla solidità delle dichiarazioni di latenza di un vendor, parliamone.