I chatbot alimentati da modelli generativi: dalle FAQ scriptate agli agenti che agiscono

Nota rivista il 25 maggio 2026. Articolo inizialmente pubblicato nel marzo 2026 — riscrittura integrale.

Il termine chatbot è diventato un termine ombrello che ricopre sistemi strutturalmente diversi. Un sistema di alberi di decisione scriptati degli anni 2015, un sistema RAG ancorato a una base di conoscenza di mestiere, e un agente capace di eseguire azioni in sistemi esistenti non hanno praticamente nulla in comune sul piano operativo, mentre condividono un'interfaccia conversazionale apparente. Questa confusione produce arbitraggi costosi per le organizzazioni che si attengono a una lettura indifferenziata.

Questa nota espone la distinzione tra queste generazioni successive, qualifica ciò che ciascuna categoria permette realmente, e identifica i vincoli specifici al quadro svizzero che strutturano un dispiegamento duraturo.

Tre generazioni che non hanno nulla in comune

La conversazione pubblica sui chatbot mescola regolarmente tre famiglie di sistemi che meritano di essere distinte esplicitamente.

I chatbot scriptati anzitutto, che costituiscono la generazione precedente e restano largamente distribuiti. Il loro funzionamento poggia su alberi di decisione predefiniti: l'utente clicca su un pulsante o sceglie da un elenco, il sistema segue il percorso programmato, e propone risposte preformulate. Non appena la domanda esce dal perimetro previsto, la risposta è invariabilmente «Non ho capito, potete riformulare?». Questa generazione copre correttamente le domande frequenti e stabili — orari, tariffe pubbliche, monitoraggio di ordini — ma fallisce di fronte alle domande sfumate o contestuali. La sua principale qualità risiede nella propria prevedibilità operativa; il suo principale limite risiede nell'incapacità di trattare ciò che non era previsto.

I chatbot ancorati con RAG poi, che costituiscono la generazione attuale dominante per i progetti d'impresa seri. Questi sistemi combinano un modello di linguaggio con un meccanismo di ricerca semantica in una base di conoscenza specifica all'organizzazione. Comprendono l'intenzione dietro una domanda formulata in linguaggio naturale, mantengono il contesto della conversazione in corso, e producono risposte ancorate ai documenti propri dell'impresa. La differenza operativa con la generazione precedente è sostanziale: il sistema non segue uno script, ragiona sulla base di informazioni verificate.

Gli agenti capaci di agire completano l'elenco, e costituiscono la generazione più recente. Un agente non si limita a rispondere a una domanda; combina un modello di linguaggio con strumenti — accesso a un sistema di gestione esistente, pianificazione di un appuntamento, creazione di un ticket di supporto, attivazione di un workflow di approvazione — per eseguire un compito concreto che supera la semplice conversazione. Questa capacità d'azione trasforma la natura del sistema, che diventa un intermediario operativo e non soltanto un canale di informazione.

Comprendere in quale categoria si situa un dato progetto è la decisione più strutturante dell'inquadramento iniziale. Ciascuna categoria corrisponde a uno sforzo di messa in opera diverso, a un costo di esercizio diverso, e a un profilo di rischio diverso.

La meccanica del RAG: ciò che permette e ciò che non sopprime

Il pattern RAG merita di essere compreso nella sua meccanica, perché i suoi punti di forza e i suoi limiti sono strutturali piuttosto che aneddotici.

La sua meccanica poggia su quattro tappe successive. I documenti dell'impresa — manuali, schede prodotto, procedure, base di conoscenza — sono anzitutto suddivisi in segmenti e trasformati in rappresentazioni vettoriali che catturano il loro senso semantico. Quando un utente pone una domanda, il sistema la trasforma a sua volta in rappresentazione vettoriale e cerca i segmenti più vicini semanticamente. I segmenti pertinenti sono iniettati nel prompt inviato al modello di linguaggio, con la domanda iniziale. Il modello produce allora una risposta ancorata a questi segmenti, con la capacità di citare le proprie fonti.

Questa meccanica risponde alla sfida centrale dei modelli di linguaggio utilizzati da soli: le allucinazioni. Ancorando ciascuna risposta a documenti verificati, il sistema resta fattuale sulle domande coperte dalla base di conoscenza. E quando la base non contiene la risposta a una domanda, il sistema può dirlo esplicitamente piuttosto che inventare una risposta plausibile ma incorretta.

La meccanica non sopprime tuttavia completamente le allucinazioni. Il modello può ancora estrapolare oltre il contenuto fornito, in particolare quando i segmenti restituiti dalla ricerca sono parzialmente pertinenti ma incompleti. Questo limite residuo richiede un monitoring delle risposte e un sistema di ritorno utente che rilevi le derive.

Più strutturalmente, la qualità di un sistema RAG dipende direttamente dalla qualità dei dati indicizzati. Documenti obsoleti producono risposte obsolete; documenti contraddittori producono risposte incoerenti; documenti mal strutturati producono ricerche imprecise. L'alimentazione e la manutenzione della base documentale costituiscono uno sforzo continuo che non si riassume nell'indicizzazione iniziale.

Gli agenti: quando l'IA passa all'azione

Gli agenti alimentati da modelli rappresentano l'evoluzione più recente, e probabilmente la più strutturante, della categoria. Il loro interesse operativo risiede nella capacità di eseguire una sequenza di azioni per compiere un compito complesso, piuttosto che semplicemente rispondere a una domanda.

Alcuni casi d'uso illustrano ciò che questa capacità apre. Un agente può verificare lo stato di un ordine nel sistema di gestione di un'impresa e fornire una risposta contestualizzata al cliente. Può pianificare un appuntamento nell'agenda di un commerciale dopo aver qualificato il bisogno del prospect. Può creare un ticket di supporto in un sistema di mestiere dopo aver raccolto le informazioni necessarie. Può generare un preventivo personalizzato sulla base dei parametri estratti dalla conversazione. Può attivare un workflow di approvazione interno con la documentazione appropriata.

Questo livello di capacità richiede un quadro tecnico più sofisticato delle generazioni precedenti. Gli strumenti accessibili all'agente devono essere definiti esplicitamente, i loro permessi devono essere inquadrati, le regole di sicurezza devono essere poste. L'agente decide quale strumento utilizzare in funzione della richiesta, ma questa decisione resta in un perimetro controllato dalla concezione del sistema.

Il costo di esercizio di un agente è sostanzialmente più elevato di un chatbot RAG semplice. Un agente può effettuare diverse decine di chiamate al modello per trattare un compito complesso, contro una chiamata o due per una risposta RAG classica. Questa caratteristica riserva l'uso degli agenti ai casi d'uso a forte valore aggiunto in cui la complessità del compito giustifica il costo.

Quattro casi d'uso che strutturano il mercato svizzero

L'osservazione dei dispiegamenti operativi nel mercato svizzero fa emergere quattro casi d'uso che costituiscono la maggioranza dei progetti seri.

Il supporto cliente multilingue continuo anzitutto. Il carattere multilingue strutturale del mercato svizzero — francese, tedesco, italiano, inglese — rende particolarmente pertinente un sistema che padroneggi nativamente più lingue senza configurazione supplementare. Per un'impresa di servizi o un attore del commercio elettronico, questa capacità libera un canale di supporto di primo livello disponibile in continuo, con una qualità linguistica che l'esternalizzazione classica fatica a raggiungere in quattro lingue simultaneamente.

Il supporto tecnico documentato poi. Un'impresa industriale può alimentare il proprio sistema con i propri manuali tecnici, schede prodotto e guide di risoluzione dei guasti. Il sistema diventa allora capace di guidare un cliente nella risoluzione di un problema complesso appoggiandosi alla documentazione precisa del prodotto interessato, piuttosto che proporre risposte generiche che obbligano il cliente a cercare l'informazione da sé.

La qualifica di prospect completa l'elenco degli usi esterni. Un sistema conversazionale sul sito web di un'impresa può porre le domande giuste per qualificare l'intenzione di un visitatore, identificare precisamente il suo bisogno, e orientare verso il giusto interlocutore interno. L'interazione è immediata e adattata alla situazione, ciò che i formulari di contatto classici non permettono per costruzione.

L'assistente interno per i collaboratori chiude l'elenco, e costituisce spesso il caso d'uso più semplice da dispiegare con il miglior rendimento. Un sistema alimentato dalle procedure interne, dalle politiche dell'impresa e dalla documentazione tecnica permette ai collaboratori di trovare rapidamente l'informazione senza sollecitare le équipe di supporto interne. Questa applicazione riduce il carico su équipe sature, e migliora la qualità delle decisioni operative facilitando l'accesso all'informazione di riferimento.

L'escalation umana: concezione importante quanto la tecnologia

Un chatbot alimentato da modello, qualunque sia la sua generazione, deve saper riconoscere i propri limiti. Le richieste emotive, i reclami complessi, i casi atipici che escono dal perimetro dei dati indicizzati, devono essere trasferiti a un umano. La concezione del percorso di escalation è tanto importante quanto la tecnologia che sottende il sistema.

Tre caratteristiche distinguono un'escalation ben concepita da un'escalation mal pensata.

Il rilevamento dei segnali di escalation anzitutto. Il sistema deve identificare — esplicitamente per regole, o implicitamente per le caratteristiche della conversazione — le situazioni che superano le proprie capacità. Un cliente visibilmente scontento, una domanda che esce dal perimetro della base di conoscenza, una richiesta che tocca un argomento sensibile, devono innescare un trasferimento piuttosto che una risposta forzata.

La continuità del contesto trasmesso poi. Quando l'escalation si attiva, il collaboratore che prende il testimone deve ricevere lo storico della conversazione e il contesto qualificato della richiesta, piuttosto che dover ridomandare tutto al cliente. Questa continuità è costitutiva di un'esperienza cliente rispettosa; la sua assenza trasforma l'escalation in frustrazione supplementare.

La gestione chiara dell'attesa completa l'elenco. Se il trasferimento verso un umano non può essere immediato, il sistema deve dirlo onestamente, indicare un tempo realistico, proporre un richiamo o un altro canale. Questa trasparenza preserva la fiducia che le promesse irrealistiche erodono.

Questa dimensione è particolarmente strutturante nel contesto svizzero, in cui la Legge federale sulla protezione dei dati^[1] impone una trasparenza sui processi automatizzati che colpiscono gli utenti. Allorché il sistema produce o prepara una decisione automatizzata che colpisce significativamente l'utente, la possibilità di una revisione umana deve essere trattata esplicitamente fin dalla concezione.

Il quadro svizzero della protezione dei dati

Tre dimensioni della conformità alla Legge federale sulla protezione dei dati meritano di essere poste esplicitamente all'inquadramento di un progetto di chatbot d'impresa.

La trasparenza sulla natura del sistema anzitutto. L'utente deve sapere che interagisce con un sistema automatizzato, e non con un collaboratore umano. Questa trasparenza non è una formalità; condiziona la fiducia e la qualità dell'interazione. Si tratta generalmente con una menzione esplicita in apertura di conversazione.

Il trattamento dei dati personali condivisi poi. Se un cliente condivide informazioni personali nel corso di una conversazione — coordinate, identificatori, dati sanitari, dati finanziari — queste informazioni entrano nel perimetro della Legge federale sulla protezione dei dati. Il loro trattamento deve essere conforme ai principi di liceità, proporzionalità e trasparenza. Questa dimensione richiede un'analisi esplicita all'inquadramento del progetto, piuttosto che un trattamento per difetto.

La localizzazione dei trattamenti completa l'elenco. Se il sistema è ospitato su infrastrutture sotto giurisdizione straniera, il trasferimento di dati personali verso queste infrastrutture può sollevare questioni di diritto applicabile e di accesso extraterritoriale ai dati. Per i settori sensibili — finanza, sanità, amministrazione pubblica — questa questione deve essere trattata esplicitamente. Alternative esistono: hosting su infrastruttura europea o svizzera, dispiegamento di modelli aperti su infrastruttura controllata. Ciascuna opzione presenta un profilo di costo e di complessità diverso che merita di essere qualificato all'inquadramento.

La disciplina che distingue il dispiegamento duraturo

Il dispiegamento di un chatbot d'impresa alimentato da modello non si riduce a una scelta tecnologica. Richiede una disciplina operativa di cui alcuni orientamenti distinguono i progetti che producono un valore duraturo.

L'avvio su un perimetro limitato anzitutto. Piuttosto che mirare a un sistema capace di trattare tutto fin dal lancio, identificare un caso d'uso preciso e misurabile — FAQ supporto, qualifica di prospect, assistente interno su un argomento documentato — produce risultati più rapidi e apprendimenti più utili per le estensioni successive.

L'investimento nella base di conoscenza poi. La qualità di un sistema RAG dipende direttamente dalla qualità dei dati indicizzati. Strutturare, pulire e aggiornare i documenti prima di indicizzarli rappresenta, nella pratica osservata in studio sui progetti MCVA, una parte sostanziale dello sforzo totale — tipicamente tra la metà e i due terzi. Questa osservazione merita di essere assunta piuttosto che minimizzata all'inquadramento.

La concezione esplicita dell'escalation umana completa l'elenco. I criteri di trasferimento, i percorsi di ripresa da parte di un collaboratore, la gestione del contesto trasmesso, meritano di essere pensati all'avvio del progetto, non scoperti in esercizio.

La misura continua e l'iterazione chiude la sequenza. Seguire il tasso di risoluzione, la soddisfazione utente, le domande che non ottengono una risposta soddisfacente, alimenta un miglioramento continuo che distingue i sistemi che consolidano la propria qualità nel tempo da quelli che derivano.

Un chatbot alimentato da modello ben concepito assorbe una parte sostanziale delle richieste ripetitive, libera tempo per le interazioni a più forte valore aggiunto, e migliora l'esperienza cliente attraverso la propria disponibilità immediata e la qualità di risposta. Un chatbot mal concepito produce frustrazione cliente e accumula un debito tecnico. La differenza non si gioca nel modello utilizzato. Si gioca nel rigore dell'inquadramento iniziale e nella disciplina del dispiegamento.

Sources

[1] Legge federale sulla protezione dei dati (LPD), revisione del 25 settembre 2020, entrata in vigore il 1° settembre 2023. www.fedlex.admin.ch/eli/cc/2022/491/it [↩]

Jérôme Deshaie è CEO di MCVA Consulting SA, studio svizzero di consulenza strategica in intelligenza artificiale, con sede in Vallese.