Migrazione da chatbot ad agente AI: cosa si recupera e cosa va rifatto

C’è una data che vale più di qualunque discorso sull’intelligenza artificiale: il 10 dicembre 2026. È il giorno in cui Zendesk spegne definitivamente la vecchia generazione dei suoi bot, bot builder, answers e intents compresi, e i chatbot rimasti su quella tecnologia, per usare le parole dell’annuncio ufficiale, «non funzioneranno più». Non è un caso isolato: la console di Dialogflow CX è stata deprecata il 31 ottobre 2025 in favore di Conversational Agents, e watsonx Assistant di IBM è stato assorbito dentro watsonx Orchestrate. Per migliaia di aziende che tra il 2019 e il 2024 hanno investito in un assistente conversazionale, la migrazione da chatbot ad agente AI ha smesso di essere un tema da convegno ed è diventata una voce di roadmap con una scadenza sopra.

La buona notizia è che non si riparte da zero. La cattiva è che la parte che si recupera non è quella che di solito si pensa: gli intent e i flussi, cioè il lavoro su cui si sono spesi mesi, valgono molto meno dei log delle conversazioni, che invece quasi nessuno guarda. Questo articolo mette in fila che cosa sopravvive tecnicamente al passaggio, che cosa va riprogettato per forza, e come si fa la transizione tenendo il vecchio bot in produzione fino all’ultimo giorno utile.

In questo articolo scoprirai:

• Perché le piattaforme chatbot legacy stanno chiudendo tutte insieme
• Cosa si può recuperare dal chatbot legacy (e cosa vale davvero)
• Cosa va rifatto da zero: orchestrazione, memoria e tool use
• Il rischio del lift-and-shift: perché ricopiare i flussi manda a sbattere
• Migrazione parallela senza downtime: le quattro fasi che funzionano

Perché le piattaforme chatbot legacy stanno chiudendo tutte insieme

Il calendario delle dismissioni non è una coincidenza commerciale: è la conseguenza di un cambio di architettura. I chatbot costruiti fino a due o tre anni fa poggiano su un modello a intent, l’utente scrive, un classificatore assegna la frase a una delle categorie previste, un flusso predefinito risponde. Funziona bene quando le domande sono poche e prevedibili, e crolla quando l’utente chiede due cose insieme o cambia idea a metà.

Dal modello a intent all’architettura agentica

La differenza non sta nella qualità del riconoscimento linguistico: sta in chi decide. Nell’architettura agentica il modello ragiona sull’obiettivo, sceglie gli strumenti da usare e ricalcola il percorso a ogni turno, invece di seguire un albero disegnato a mano mesi prima (IBM Think). È il motivo per cui i vecchi bot non vengono aggiornati ma spenti: il pezzo che cambia è quello al centro, non un modulo laterale. Il quadro completo di cosa sappia fare davvero un agente è nella nostra guida 2026 su cosa sono e come funzionano gli agenti AI.

Zendesk ha fissato tre tappe esplicite: annuncio il 23 giugno 2026, fine dello sviluppo il 31 agosto 2026 con passaggio in sola manutenzione, rimozione totale il 10 dicembre 2026, e raccomanda di completare la migrazione entro agosto per evitare disservizi (Zendesk Help). Google, sul suo versante, dice una cosa ancora più netta nella documentazione di migrazione da Dialogflow ES a CX: le due tipologie di agente hanno differenze così profonde che «non esiste un modo lineare per eseguire la migrazione», e il percorso consigliato è ibrido, un tool automatico porta una parte dei dati, il resto lo ricostruisce una persona (Google Cloud Documentation).

Il debito tecnico dei bot custom senza scadenza

Chi ha in casa un bot custom, costruito con un framework proprietario o con una vecchia integrazione via webhook, non ha nemmeno la scadenza a ricordarglielo: il bot continua a girare e a rispondere male, e il costo si vede solo nel tasso di escalation verso gli operatori. È la forma più insidiosa di debito tecnico, perché non genera un ticket. Se non hai ancora chiaro dove finisce un chatbot e dove inizia un agente, vale la pena partire dalle differenze reali tra chatbot e chatbot AI prima di guardare i preventivi.

Cosa si può recuperare dal chatbot legacy (e cosa vale davvero)

La documentazione di Google è la fonte più precisa che esista su questo punto, perché elenca riga per riga cosa il tool di migrazione sposta e cosa no. Il quadro è utile anche se la tua piattaforma è un’altra, perché le categorie sono le stesse. Va detto però che quell’elenco descrive un passaggio fra due piattaforme conversazionali a intent e flussi, Dialogflow CX resta tale, e non il salto verso un’architettura agentica: in quella direzione la quota recuperabile si restringe ancora, perché flussi e fulfillment non hanno un corrispondente nel loop di un agente che decide da sé quali strumenti usare.

Entità, training phrase e knowledge base: il patrimonio riutilizzabile

Le entità personalizzate passano intatte: «il tool si limita a copiarle così come sono», con valori e sinonimi. Le training phrase degli intent migrano anch’esse, con una verifica automatica di compatibilità sulle entità di sistema. Anche i parametri degli intent si trasferiscono, ma vengono segnalati per la conversione. Tradotto: il lavoro linguistico si salva quasi tutto, anni di frasi raccolte dagli utenti reali, che sono la cosa più difficile da rifare a tavolino.

Si recupera anche, e integralmente, la knowledge base. Qui il passaggio è persino un guadagno: nell’architettura nuova i contenuti non vanno più incollati dentro i flussi, ma indicizzati e recuperati a runtime. È il meccanismo che sta dietro al RAG, e in pratica significa che manuali, PDF, pagine di help center e macro degli operatori diventano una fonte unica che si aggiorna senza toccare una riga di configurazione.

I log di conversazione valgono più degli intent

Lo schema proposto da Aidbase, un fornitore di soluzioni di supporto AI, mette l’audit dei log al primo posto e non alla fine: esportare da tre a sei mesi di conversazioni, inventariare i punti di ingresso e isolare i venti-trenta intent che concentrano il volume (Aidbase). Il motivo è che quei log contengono l’unica informazione che nessun fornitore può venderti: dove il bot attuale fallisce e cosa l’utente stava chiedendo quando è scappato verso l’operatore. Le integrazioni verso CRM, ticketing e gestionale, infine, si riusano nella sostanza, le credenziali e gli endpoint restano, ma cambiano di ruolo, e questo è il tema della sezione che segue.

Cosa va rifatto da zero: orchestrazione, memoria e tool use

Qui finisce la parte facile. Il tool di Google, insieme ai dati, produce un file CSV di cose da rifare a mano, e l’elenco è istruttivo: risposte dell’agente da convertire in fulfillment, logica di controllo della conversazione da riprogettare con flussi e pagine, codice dei webhook da riscrivere perché la struttura di richiesta e risposta è diversa, gestione degli eventi da rimappare, intent di benvenuto e di fallback da sostituire con event handler. Non è una rifinitura: è il cuore del sistema.

La memoria è una componente nuova, non un’opzione

Un chatbot a intent è stateless: richiesta, risposta, fine. Un agente ha bisogno di memoria a breve termine, lo stato della conversazione in corso, persistito con checkpoint, e di memoria a lungo termine, che attraversa le sessioni e va organizzata in namespace interrogabili. Serve infrastruttura vera: strategie di pruning dei messaggi obsoleti, aggiornamento dei profili, ricerca semantica sui ricordi. E serve gestire un vincolo che prima non esisteva: la cronologia cresce all’infinito mentre la finestra di contesto è finita, e oltre una certa lunghezza il modello «peggiora, per distrazione e per rallentamento» (documentazione LangGraph).

Dalle integrazioni ai tool: il salto che rende l’agente un agente

Nel vecchio mondo l’integrazione era un webhook chiamato da un punto preciso del flusso: il codice decideva quando. In un agente le stesse API diventano tool, cioè capacità che il modello sceglie di usare in base alla situazione. È un rovesciamento di responsabilità, e il lavoro di ingegneria si sposta sulla descrizione degli strumenti. Anthropic è esplicita: gli sviluppatori finiscono per spendere «più tempo a ottimizzare i tool che il prompt», e l’interfaccia tra agente e sistemi va progettata con lo stesso rigore di una UI umana (Anthropic Engineering). Lo standard che oggi riduce questa fatica è il Model Context Protocol, definito dai suoi autori come «una porta USB-C per le applicazioni AI»: si espone il sistema una volta e lo si collega a client diversi (modelcontextprotocol.io). Sul terzo pilastro, l’orchestrazione, la stessa guida di Anthropic distingue i workflow, LLM e tool orchestrati da percorsi di codice predefiniti, dagli agenti, che dirigono da sé il proprio processo, e raccomanda di partire dalla soluzione più semplice che regge, perché ogni grado di autonomia si paga in latenza e in costo.

Il rischio del lift-and-shift: perché ricopiare i flussi manda a sbattere

L’errore più comune non è tecnico, è di impostazione: prendere i flussi esistenti e reimplementarli con un modello generativo sotto. Voiceflow lo chiama per nome, «trattare il sistema nuovo come un lift-and-shift», e propone il ribaltamento: partire dagli esiti che il cliente vuole ottenere, non dagli intent che il bot ha oggi, leggendo i dati di escalation per capire dove il vecchio sistema si rompe e mappando solo le integrazioni che servono a chiudere davvero la richiesta (Voiceflow).

L’agent washing dietro il 40% di progetti cancellati

La ragione per cui questo errore è così diffuso ha un nome anche lei. Gartner prevede che oltre il 40% dei progetti di AI agentica sarà cancellato entro la fine del 2027, su un campione di più di 3.400 organizzazioni, e indica come causa principale non la tecnologia ma progetti nati come esperimenti «guidati dall’hype e spesso mal applicati», senza strategia chiara, governance e qualità del dato. Alla voce cause aggiunge l’agent washing: fornitori che ribattezzano «agenti» chatbot e strumenti di automazione già esistenti. La stima è brutale, su migliaia di soluzioni che si dichiarano agentiche, «solo circa 130 offrono funzionalità agentiche reali» (MarTech, su dati Gartner).

Il lift-and-shift è la versione interna dell’agent washing: si cambia il motore, si tiene la stessa esperienza, e poi si scopre che il costo per conversazione è salito senza che il tasso di risoluzione si muovesse. È esattamente il punto in cui i progetti si fermano, come abbiamo raccontato analizzando le quattro cause per cui i POC non arrivano in produzione.

Migrazione da chatbot ad agente AI e obblighi normativi

Un agente che agisce sui sistemi aziendali ricade in obblighi diversi da un bot che risponde a FAQ: cambia il perimetro del rischio, e cambiano gli adempimenti. Per questo la migrazione è il momento giusto per rileggere cosa chiede l’AI Act e per decidere, riga per riga, quali azioni l’agente può eseguire da sé e quali restano sotto approvazione umana. Deciderlo dopo il go-live significa rimettere mano all’orchestrazione quando è già in produzione.

Migrazione parallela senza downtime: le quattro fasi che funzionano

La domanda che ogni responsabile IT fa per prima è come si fa lo switch senza restare scoperti. La risposta su cui convergono le guide dei fornitori è che non esiste uno switch: esiste una convivenza, e il vecchio bot resta in produzione fino a quando i numeri del nuovo non lo superano. Con un’avvertenza di calendario che conviene dire come sta: la finestra raccomandata da Zendesk, completare entro agosto, è a questo punto chiusa, e chi parte adesso lavora contro la data hard del 10 dicembre 2026. Il tempo che si perde non si toglie alla build, si toglie all’esercizio parallelo, cioè proprio alla fase che serve a scoprire i problemi prima degli utenti.

Le quattro fasi della migrazione parallela da chatbot ad agente AI

Lo schema in quattro fasi è questo. Uno, test interni: l’agente risponde a query storiche prese dai log, a rischio zero. Due, shadow mode: il nuovo sistema risponde in silenzio sul traffico reale mentre il bot legacy resta quello visibile all’utente, e si confrontano le risposte una per una. Tre, routing graduale: si instrada tra il 10% e il 30% del traffico sull’agente, la forbice indicata da CustomGPT.ai, un fornitore del settore. Quattro, cutover completo. Il principio che tiene insieme il tutto sta in tre parole: «parallel first, replace later» (CustomGPT.ai).

Soglie di promozione e metriche che autorizzano il cutover

Perché il parallelo non sia teatro, servono due cose decise prima di iniziare. La prima è una soglia numerica di promozione: si fissa il livello minimo per spostare un intent da shadow a live, il benchmark indicato da Aidbase, un fornitore del settore, è il 95% di risposte giudicate corrette e sicure in revisione, e non si aumenta il traffico finché non è raggiunto, verificando anche le citazioni delle fonti e il comportamento sui rifiuti, cioè che l’agente sappia dire «questo non lo so» (Aidbase). La seconda è la scelta della superficie di partenza: si comincia da intent semplici, alto volume e basso rischio, utenti autenticati, orario di ufficio, governando l’esposizione con feature flag e tenendo sempre attivo il percorso di fallback. In parallelo si classificano gli intent per livello di rischio: quelli automatizzabili, quelli assistiti dall’AI e quelli che restano umani, con una scorecard per intent e criteri espliciti di promozione o retrocessione.

Le metriche da confrontare non sono quelle del bot vecchio: oltre al containment rate servono first-contact resolution, tasso di handoff, CSAT e sforzo percepito dal cliente. Un dato di contesto aiuta a calibrare le attese: sulle piattaforme di customer service la forbice di automazione osservata sui clienti reali sta tra il 30% e il 70% delle richieste, mentre il punto di partenza senza AI è molto più basso, secondo Gartner solo il 10-15% delle persone risolve il proprio problema in self-service senza passare da un operatore (Aidbase, su dati Ada e Gartner). Se il tuo punto di partenza è un bot a intent, quella distanza è la misura del margine disponibile.

Quanto dura una migrazione da chatbot ad agente AI e cosa chiedere al partner

Sui tempi il riferimento più dettagliato in circolazione è un percorso tipo pubblicato da Redefine Innovations, un fornitore di servizi di migrazione: circa dodici settimane, articolate così, settimane 1-2 di audit di scoperta con mappatura di intent, percorsi di escalation e sistemi integrati; settimane 3-4 di progettazione e approvazione dell’agente; settimane 5-10 di build, integrazione e test con revisioni ogni due settimane; settimane 11-12 di esercizio parallelo su traffico reale; dalla tredicesima il go-live con un periodo di presidio (Redefine Innovations). È lo schema di un singolo fornitore, non una media di settore, e va preso per quello che è: se si tiene il ritmo di quel percorso tipo, chi parte oggi arriva alla scadenza Zendesk del 10 dicembre 2026 senza margini per ripensamenti, e con le due settimane di esercizio parallelo già ridotte all’osso, dato che la finestra raccomandata di agosto è passata.

Le tre clausole che distinguono un partner da un fornitore

La prima è la proprietà di codice e dati: al termine devi ricevere codebase, file di configurazione, schemi di prompt e definizioni dei tool. Se questi artefatti restano dentro la piattaforma di qualcun altro, la migrazione non ti ha liberato dal lock-in: te l’ha rinnovato. La seconda è l’osservabilità, cioè una dashboard che mostri cosa l’agente ha fatto e perché, ed è la richiesta più sentita del mercato, con il 93% delle organizzazioni che considera la trasparenza dell’AI «molto importante» o «critica» e il 43% che non mette in produzione soluzioni che non la garantiscono. La terza è il controllo del deployment: il 66% richiede on-premise o cloud proprio, e il 60% indica governance e compliance come sfida numero uno (Rasa, 2026 State of Conversational AI Report).

Lo stesso report smonta anche un’aspettativa diffusa: solo il 13% delle organizzazioni preferisce sistemi completamente agentici, mentre il 63% sceglie un approccio ibrido, con l’umano nel percorso. Un partner che ti propone piena autonomia dal primo giorno sta vendendo, non progettando. Prima di firmare vale la pena chiarire una cosa sola: se ti serve un agente AI chiavi in mano o self-service, perché da quella scelta dipende quanto lavoro resta in casa.

È il senso di quello che scriviamo da tempo: nell’AI agent enterprise il servizio conta più del modello. I criteri per valutare chi hai davanti sono raccolti nella guida su come scegliere un partner AI in Italia.

Dove MIMIR entra nella migrazione

Il punto in cui una migrazione si decide non è la settimana della build: è il passaggio di consegne. Con MIMIR l’agente non viene consegnato e lasciato lì, l’onboarding è un servizio dedicato, non un allegato al contratto: si affianca il team che dovrà usarlo e presidiare, si legge insieme la dashboard nelle prime settimane di traffico reale, si tarano le soglie di escalation sui dati che arrivano invece che su quelli stimati in fase di progetto. È la differenza tra vendere un prodotto e assumersi la responsabilità che funzioni in produzione, ed è il motivo per cui trattiamo l’onboarding degli agenti AI in azienda come una fase progettuale a sé; come è fatto il sistema che consegniamo è descritto nella pagina del nostro AI agent per aziende.

Se il tuo punto di partenza è un abbonamento generalista anziché un bot su piattaforma, il percorso è diverso: l’abbiamo descritto nella guida su come si passa da ChatGPT Business a un agente AI custom e nel confronto tra ChatGPT Work e un agente AI custom.

Se in azienda hai un chatbot che ha smesso di essere un vantaggio ed è diventato una scadenza sul calendario, il momento per guardarci dentro è adesso: mappare i log, capire cosa si recupera e cosa va riprogettato è un lavoro di settimane, non di giorni. Noi di MIMIR facciamo esattamente questo, progettiamo l’agente, lo mettiamo in parallelo al sistema esistente e restiamo accanto al team durante l’onboarding, perché la migrazione riesce nel momento in cui le persone sanno usarla. Se vuoi capire da dove partire nel tuo caso, scrivici per una consulenza: si comincia sempre leggendo i tuoi dati, non presentando la nostra soluzione.

Fonti:

• Zendesk Help — Rimozione degli AI agents Essential e delle funzionalità legacy
• Google Cloud Documentation — Migrazione da Dialogflow ES a CX
• IBM Docs — Migrazione da watsonx Assistant a watsonx Orchestrate
• IBM Think — Che cosa sono gli AI agent
• Aidbase — Migrare da chatbot legacy al supporto AI moderno
• Documentazione LangGraph — Memoria degli agenti
• Anthropic Engineering — Building effective agents
• modelcontextprotocol.io — Introduzione al Model Context Protocol
• Voiceflow — Sostituire un chatbot legacy con un AI agent
• Gartner — Press release del 25 giugno 2025 sui progetti di AI agentica
• MarTech — Il 40% dei progetti di AI agentica fallirà (su dati Gartner)
• CustomGPT.ai — Migrare un chatbot legacy a un assistente AI moderno
• Redefine Innovations — Migrazione da chatbot legacy ad AI agent
• Rasa — 2026 State of Conversational AI Report