Da Gemini a Claude API per un call center AI: costi e risultati reali in produzione

Non avevamo previsto di cambiare.

Quando abbiamo sviluppato il voice agent AI per il nostro cliente, un’azienda italiana di medie dimensioni che gestisce circa 3.000 chiamate in entrata al mese, Gemini era la scelta ovvia. Prezzi buoni, API veloce, buon supporto per l’italiano. Abbiamo costruito l’intera pipeline in circa sei settimane: Deepgram per l’ASR, ElevenLabs per la sintesi vocale, Vapi come livello di orchestrazione e Gemini 1.5 Flash come cervello.

Funzionava. Più o meno.

Dopo tre mesi di produzione abbiamo iniziato a notare uno schema nei ticket di assistenza. Chi chiamava riattaccava a metà conversazione in circa l’8% dei casi. In un call center è molto fatturato perso. Il cliente ha iniziato a fare domande a cui non sapevamo rispondere con dati puliti.

Questo articolo è il racconto onesto di cosa abbiamo scoperto, cosa abbiamo fatto e quanto ci è costata davvero la migrazione da Gemini a Claude API: in denaro, ore di sviluppo e rischio di interruzione del servizio.

Lo stack originale (e perché aveva senso)

Prima di parlare del cambio, vale la pena spiegare perché avevamo scelto Gemini. Non è una storia su "Gemini è scarso": è una storia di contesto.

Il caso d’uso principale del cliente: chiamate in entrata di qualificazione per lead B2B. L’AI doveva capire l’intenzione, fare domande di approfondimento, raccogliere dati strutturati e gestire chi chiamava arrabbiato o fuori copione senza interrompere la conversazione.

Gemini 1.5 Flash era veloce. La latenza dell’LLM si aggirava sui 400–600 ms che, sommati ai 200–300 ms di trascrizione di Deepgram, mantenevano la latenza vocale complessiva sotto il secondo. Oltre 1,2–1,5 secondi la conversazione inizia a sembrare spezzata.

Cosa ha iniziato a non funzionare

Il primo segnale non è stato clamoroso. Al secondo mese il cliente ci ha scritto su Slack: "Alcune persone si lamentano che il bot non le capisce quando escono dal tema."

Le trascrizioni erano pulite: Deepgram faceva il suo lavoro. Il problema era a valle. Gemini produceva risposte tecnicamente corrette ma piatte rispetto al contesto. Quando chi chiamava usciva dal flusso previsto (un commento arrabbiato, una battuta sarcastica, un’espressione colloquiale italiana) il modello ignorava il sottotesto o rispondeva nel modo più robotico possibile.

Chi chiama: "Senta, mi hanno già trasferito tre volte, sono sfinito."

Risposta di Gemini: "Capisco. Può dirmi il nome della sua azienda?" Non sbagliata. Solo... sbagliata.

Nelle settimane successive abbiamo documentato tre categorie di errore distinte:

1. Cecità al registro

Il modello trattava chi era frustrato come chi era neutro. Nessun riconoscimento, nessun cambio di tono, nessuna frase per recuperare. Chi era leggermente infastidito diventava molto più infastidito dopo interazioni come quella sopra.

2. Deriva idiomatica in italiano

L’italiano di Gemini era grammaticalmente corretto ma suonava estraneo. Le frasi avevano una struttura sintattica che i madrelingua associano a una traduzione, non al parlato naturale. Un effetto sottile ma cumulativo: al terzo minuto chi chiamava percepiva inconsciamente che qualcosa non andava.

3. Rigidità delle istruzioni in caso di ambiguità

Quando l’intenzione di chi chiamava non corrispondeva chiaramente a uno dei rami definiti, Gemini ripeteva la domanda precedente oppure faceva un’ipotesi poco sicura e andava avanti. I casi limite, circa il 15% delle chiamate, venivano gestiti male.

La decisione di cambiare

Prima di raccomandare la migrazione abbiamo fatto una valutazione interna di tre settimane. Ogni modello è stato testato su 200 trascrizioni di chiamate sintetiche: 60% flussi standard, 25% fuori copione, 15% avversariali (chi chiama è frustrato, confuso o volutamente evasivo).

Claude 3.5 Haiku ha vinto per la combinazione di latenza, naturalezza dell’italiano e quello che internamente abbiamo chiamato "degradazione elegante" : cosa fa il modello quando non ha una risposta chiara. Invece di procedere alla cieca o ripetersi, faceva emergere l’ambiguità in modo naturale:

"Scusa, vuoi dire che il problema è principalmente con i tempi di consegna, o riguarda qualcos'altro?" (Una domanda di chiarimento, esattamente come farebbe una persona.)

Quel singolo comportamento, fare una domanda di chiarimento come farebbe una persona, valeva più di qualsiasi punteggio nei benchmark. Abbiamo scelto Haiku per il flusso principale e tenuto Sonnet 4 come fallback per i flussi di escalation non risolti.

La migrazione: cosa è servito davvero

È la parte che la maggior parte degli articoli salta.

Fase 1 — Riscrittura dei prompt (settimane 1–2)

I prompt scritti per Gemini non si trasferiscono a Claude così come sono. Gemini, con un system prompt di media lunghezza, tende a essere letterale e concentrato sul compito. Claude, con lo stesso prompt, cerca di dedurre l’intenzione in modo più deciso: di solito è un bene, ma a volte in un contesto vocale si dilunga, aggiungendo 40 parole invece di 20 e mandando all’aria il budget di latenza del TTS.

Abbiamo riscritto il system prompt da zero. Le modifiche principali:

• Istruzione esplicita di limitare le risposte a 1–2 frasi al massimo nei flussi standard
• Un ramo dedicato al "rilevamento della frustrazione" con script di recupero espliciti
• Indicazioni sul registro linguistico: informale ma professionale, evitare l’italiano burocratico
• Output strutturato (JSON) per la raccolta dei dati, rimosso prima del TTS

Riscrittura dei prompt: ~28 ore di sviluppo.

Fase 2 — Integrazione API e configurazione Vapi (settimana 2)

Sostituire l’LLM in Vapi è, in teoria, una modifica di configurazione. In pratica: ricontrollare ogni webhook, ritestare la latenza sotto carico, ricalibrare le soglie di rilevamento delle interruzioni (il ritmo dei token di Claude è diverso da quello di Gemini, e questo influisce su come Vapi decide che il modello "ha finito di parlare").

Lavoro di integrazione: ~14 ore di sviluppo.

Fase 3 — Test in shadow mode (settimana 3)

Prima di spostare il traffico, abbiamo fatto girare Claude in shadow mode: riceveva gli stessi input di Gemini ma senza produrre output vocale. Abbiamo confrontato manualmente le risposte su 300 chiamate reali in sette giorni. Abbiamo trovato tre casi limite nei prompt che non avevamo previsto, ne abbiamo corretti due e documentato uno come comportamento accettabile.

Shadow testing: ~8 ore di sviluppo + 12 ore di QA.

Fase 4 — Rilascio graduale (settimana 4)

10% → 30% → 70% → 100% in quattro giorni. Abbiamo monitorato in tempo reale tasso di completamento, durata media e tasso di uscita via tastiera (DTMF). Nessun rollback necessario. Al terzo giorno, con il 70% del traffico, le metriche andavano già nella direzione giusta.

I costi reali

Costo di sviluppo

Totale: circa 62 ore tra due ingegneri senior e uno specialista QA. Fatturazione al cliente: €5,800 a prezzo fisso, concordati in anticipo.

Differenza nei costi LLM ricorrenti

* Una volta calibrato il prompt, le risposte di Claude sono più concise, il che compensa in parte il costo per token più alto.

Interruzioni del servizio

Zero. Shadow mode e rilascio graduale hanno fatto sì che il cliente non vivesse mai un servizio degradato. Era l’aspetto a cui il CTO teneva di più.

Risultati dopo 60 giorni con Claude

Cosa abbiamo imparato (e che non compare nei benchmark)

1. La naturalezza dell’LLM conta più nella voce che nella chat

Nel testo, una risposta un po’ robotica è tollerabile. Nella voce, dove il cervello umano percepisce la mancanza di autenticità in pochi millisecondi, è fatale per la conversazione. È la dimensione di valutazione più sottovalutata nella scelta di un modello per la voice AI.

2. La lunghezza del prompt è una variabile di latenza

Un system prompt da 1.200 token con Claude produce un profilo di latenza misurabilmente diverso da uno da 400 token. Per la voce, tenete il prompt snello e gli esempi few-shot essenziali. I budget di latenza non perdonano un contesto gonfio.

3. Lo shadow mode non è negoziabile

Avremmo potuto fare il passaggio alla seconda settimana. Non l’abbiamo fatto. Lo shadow testing ha trovato tre bug che in produzione sarebbero stati brutti. Se state migrando un sistema vocale in produzione, mettete a budget lo shadow mode.

4. L’italiano (e le altre lingue diverse dall’inglese) fa davvero la differenza

Ogni grande LLM dichiara di supportare l’italiano. La distanza tra "supporta" e "suona naturale" è grande ed emerge solo in produzione. Se sviluppate per un mercato non anglofono, valutate i modelli proprio sulla lingua di destinazione con veri ascoltatori madrelingua, non con metriche automatiche.

5. Il costo totale di una migrazione non è quasi mai il costo dell’LLM

I nostri +$15 al mese di LLM erano irrilevanti per il business case. Le 62 ore di sviluppo e i 60 giorni di misurazione sono stati i costi reali. Pianificateli.

Conviene cambiare anche a voi?

La migrazione non è stata tecnicamente complessa. Ha richiesto onestà su ciò che il sistema originale non faceva bene, un processo di valutazione rigoroso e un rilascio attento. Queste tre cose sono sempre la parte difficile, non la chiamata API.