Architettura del dialogo: progettare chatbot utili nell’era dell’intelligenza artificiale
C’è una confusione che circola spesso nei testi dedicati ai chatbot e all’intelligenza artificiale conversazionale. Si mescolano due livelli molto diversi: quello di chi costruisce i modelli linguistici — i ricercatori, gli ingegneri, le grandi organizzazioni tecnologiche — e quello di chi progetta sistemi conversazionali per un’organizzazione, un servizio, un prodotto. Come se fossero la stessa cosa, o come se il secondo potesse risolvere i problemi del primo leggendo un articolo.
Non è così. E vale la pena dirlo chiaramente.
Chi progetta un chatbot oggi non costruisce un Large Language Model. Non addestra reti neurali su miliardi di testi. Non risolve problemi di allucinazione a livello architetturale, non progetta sistemi multi-agente con moduli specializzati in parallelo, non gestisce basi di conoscenza distribuite su infrastrutture cloud. Queste sono sfide reali e affascinanti, ma appartengono a un altro mestiere — e a un altro ordine di grandezza di risorse.
Il lavoro di un UX designer o di un information architect che progetta un chatbot è diverso, e non per questo meno complesso. È un lavoro di struttura, linguaggio, responsabilità e contesto. Riguarda le decisioni che si prendono prima che il sistema parli, e quelle che definiscono come parla quando lo fa.
Conviene quindi tenere separati questi due livelli, non per semplificare, ma per essere precisi su dove si può agire davvero.
Cosa fanno i ricercatori e gli ingegneri: il livello dei modelli
I grandi sistemi conversazionali basati su modelli linguistici — i cosiddetti LLM, Large Language Models — sono progettati da team di ricerca con competenze molto specifiche. Le sfide che affrontano sono di natura statistica, computazionale e ingegneristica.
Alcune di queste sfide meritano di essere nominate, perché appaiono spesso nei testi sul tema e rischiano di far credere che siano problemi che un designer può risolvere con le proprie scelte progettuali. Non è così.
Il problema delle allucinazioni — quando un modello produce contenuti plausibili ma non supportati da dati verificabili — è un problema strutturale del modo in cui i modelli linguistici funzionano. Non si risolve scrivendo prompt migliori o progettando flussi conversazionali più chiari. Si affronta a livello di architettura del modello, di tecniche di ancoraggio a fonti verificabili, di sistemi di retrieval. Esistono approcci come il RAG (Retrieval-Augmented Generation) che cercano di mitigarlo, ma sono scelte infrastrutturali, non progettuali nel senso in cui lo intendiamo noi.
Lo stesso vale per il ragionamento multimodale — la capacità di integrare testo, immagini, documenti, audio in un unico sistema coerente — o per le architetture multi-agente, in cui più moduli specializzati collaborano in parallelo. Sono ambiti di ricerca attivi, con risultati interessanti, ma non sono decisioni che un designer prende configurando un assistente per un’azienda.
Conoscere questi temi è utile, per capire cosa c’è sotto il cofano e quali sono i limiti reali di un sistema. Ma non è il nostro campo d’azione.
Cosa fa chi progetta un chatbot: il livello della conversazione
Il livello in cui lavoriamo come designer e information architect è quello della conversazione come sistema. Non il modello, ma il contesto in cui il modello opera. Non l’intelligenza del sistema, ma la sua utilità per una persona specifica, in un momento specifico, dentro un’organizzazione specifica.
Questo livello ha le sue complessità, e non sono affatto banali.
La prima distinzione utile riguarda il tipo di sistema che si sta progettando. Un chatbot basato su flussi e intenti — come quelli costruiti su piattaforme come Dialogflow, Rasa o sistemi simili — funziona su logiche esplicite: l’utente dice qualcosa, il sistema riconosce un intento, seleziona una risposta predefinita o attiva un’azione. Chi progetta questo tipo di sistema lavora sulla mappa degli intenti, sulla struttura dei flussi, sulla gestione dei fallback, sulla chiarezza dei testi. È un lavoro di architettura dichiarativa: tutto ciò che il sistema può fare deve essere stato previsto e scritto esplicitamente.
Un assistente basato su LLM — configurato con istruzioni, prompt di sistema, basi di conoscenza — funziona diversamente. Non segue un flusso dichiarato, ma genera risposte a partire da un contesto. Il designer non scrive le risposte: definisce il perimetro dentro cui le risposte possono essere generate. Questo sposta il lavoro su un piano diverso. Non si progetta più solo cosa il sistema dice, ma come è fatto il campo di possibilità dentro cui parla.
In entrambi i casi, però, ci sono decisioni progettuali che nessun modello può prendere al posto nostro.
Le decisioni che appartengono alla progettazione
La prima è la definizione del contesto informativo. Quali informazioni deve avere il sistema per essere utile? Dove vivono queste informazioni nell’organizzazione? Sono aggiornate, verificate, accessibili? Un assistente non è migliore del contesto che gli viene dato. Progettare un chatbot significa anche progettare la knowledge base su cui si appoggia — e questo è un lavoro di architettura dell’informazione nel senso più pieno del termine.
La seconda è la gestione dell’ambiguità. Le persone non parlano con chiarezza chirurgica. Fanno domande parziali, cambiano direzione a metà frase, cercano qualcosa che non sanno ancora come chiamare. Un sistema ben progettato non risponde alla prima interpretazione possibile: chiede, chiarisce, rimanda. Un agente che pone domande mirate quando l’intento non è chiaro è percepito come più competente di uno che risponde subito in modo generico. Questa non è una caratteristica del modello. È una scelta progettuale che si traduce in istruzioni, esempi, struttura del dialogo.
La terza è la definizione dei limiti. Cosa può dire il sistema, e cosa non deve mai dire? Quali argomenti sono fuori dal suo perimetro di competenza? Quando deve fermarsi e passare la conversazione a una persona? Questi confini non si disegnano da soli. Sono decisioni che riguardano l’identità dell’organizzazione, la responsabilità legale, la protezione dell’utente. In settori regolamentati — sanità, finanza, servizi pubblici — questa progettazione dei limiti non è un dettaglio. È la condizione minima per operare in modo responsabile.
La quarta è la trasparenza del processo. Quando un sistema spiega come è arrivato a una risposta — quali fonti ha usato, perché ha chiesto una precisazione, perché suggerisce un’opzione invece di un’altra — aumenta la fiducia dell’utente e rende visibile il ragionamento. Questo non è un problema tecnico. È una scelta di design conversazionale che si traduce in tono, struttura delle risposte, gestione delle incertezze.
Il chatbot come punto di contatto, non come prodotto tecnologico
C’è un modo di guardare ai chatbot che li riduce a oggetti tecnologici da configurare. Si sceglie una piattaforma, si caricano le FAQ, si scrive qualche istruzione, si mette online. Questo approccio ha prodotto la maggior parte dei chatbot che non funzionano — quelli che abbiamo imparato a odiare prima ancora che ChatGPT cambiasse l’orizzonte.
Un modo più utile di guardarli è come punti di contatto tra un’organizzazione e le persone che la cercano. Da questo punto di vista, ogni scelta progettuale ha conseguenze sulla percezione dell’organizzazione stessa. Un sistema che non sa rispondere e non lo ammette non è solo un sistema debole: è un’organizzazione che sembra superficiale. Un sistema che risponde sempre, anche quando non dovrebbe, non è solo un sistema mal configurato: è un’organizzazione che non sa quando tacere.
La progettazione conversazionale, in questo senso, non è una competenza tecnica aggiuntiva. È una competenza comunicativa e organizzativa. Riguarda il linguaggio, la responsabilità, la struttura della conoscenza, il rapporto tra automazione e presenza umana.
Queste sono le domande che appartengono al nostro mestiere. Non costruiamo i motori. Progettiamo come i motori vengono usati, in quale direzione, con quale cura, a beneficio di chi.
Ed è un lavoro che vale la pena fare bene.
L’Architettura del Dialogo: progettare chatbot utili nella nuova era dell’intelligenza artificiale
Dal mio punto di vista, progettare un chatbot oggi non significa più costruire una sequenza di risposte predefinite che si attivano a fronte di determinate parole chiave. Quel modello appartiene a una stagione in cui l’automazione era soprattutto un esercizio di classificazione e smistamento. Oggi ci troviamo in un’altra epoca. I sistemi di intelligenza artificiale contemporanei, basati su modelli linguistici di grandi dimensioni – i cosiddetti Large Language Models, ossia modelli statistici addestrati su enormi quantità di testi per generare e comprendere linguaggio naturale – operano in condizioni di incertezza, dove l’informazione è incompleta, ambigua e distribuita nel tempo.
Da architetto dell’informazione, non posso più pensare al chatbot come a un semplice contenitore di risposte. Devo pensarlo come un sistema che struttura conoscenza in movimento. Le ricerche più avanzate sui sistemi conversazionali, inclusi prototipi come AMIE, mostrano chiaramente che l’utilità di un agente non risiede soltanto nella correttezza della risposta finale, ma nel modo in cui acquisisce, interpreta e organizza le informazioni durante il dialogo. La conversazione non è un canale neutro: è un processo cognitivo condiviso.
Per questo motivo, credo sia necessario superare definitivamente il paradigma del “bot domanda-risposta” per adottare un modello che definisco “agente di orientamento”. In inglese si parla di wayfinding, un termine che indica la capacità di aiutare una persona a orientarsi in uno spazio complesso. Applicato all’intelligenza artificiale, significa progettare un sistema che non si limita a fornire informazioni, ma che accompagna l’utente nella navigazione della conoscenza, chiarendo progressivamente il problema e rendendo espliciti i passaggi che portano alla soluzione.
Un chatbot realmente utile deve essere consapevole dello stato della conversazione. Con questa espressione non intendo una vaga memoria del passato, ma la capacità di mantenere e aggiornare una rappresentazione interna dinamica di ciò che è stato detto, di ciò che è stato compreso e di ciò che ancora manca. In termini tecnici si parla di state-aware reasoning, cioè ragionamento sensibile allo stato. Ogni interazione non può essere trattata come un evento isolato, ma come una fase di un percorso più ampio che attraversa momenti diversi: la raccolta del contesto, la sintesi interpretativa e l’accompagnamento successivo.
La raccolta del contesto, che in ambito clinico viene chiamata history taking, consiste nell’individuare ciò che si sa e, soprattutto, ciò che non si sa. Un agente ben progettato deve essere capace di mappare le lacune informative e di porre domande mirate per colmarle. La fase successiva riguarda la sintesi, ossia la capacità di integrare i dati raccolti in una proposta coerente. Infine, il dialogo deve prevedere uno spazio di follow-up, vale a dire un momento in cui l’utente può chiarire dubbi residui e pianificare i passi successivi. Questa articolazione non è un orpello metodologico, ma la traduzione conversazionale del modo in cui ragiona un esperto umano: prima raccoglie informazioni, poi le interpreta, infine verifica e orienta.
Un altro elemento decisivo riguarda l’integrazione multimodale. Per multimodalità si intende la capacità di un sistema di elaborare non solo testo, ma anche immagini, documenti, tracciati, dati strutturati. In un mondo reale, molte informazioni rilevanti non sono scritte in forma discorsiva. Possono essere fotografie, referti in formato PDF, diagrammi, file audio. Un chatbot davvero utile deve poter integrare questi diversi tipi di input in un unico quadro coerente. Dal punto di vista dell’architettura dell’informazione, questo implica una gestione rigorosa dei metadati, cioè delle informazioni che descrivono i dati stessi, e delle relazioni tra i diversi oggetti informativi. Senza una struttura chiara che colleghi fonti eterogenee, la multimodalità rischia di trasformarsi in caos.
C’è poi un aspetto che considero cruciale e che definirei ricerca attiva del contesto. In ambito tecnico si parla di context-seeking. Le ricerche sugli utenti mostrano che le persone percepiscono come più competente un agente che pone domande chiarificatrici, piuttosto che uno che risponde immediatamente in modo generico. Questo atteggiamento implica proattività nel chiarimento, ossia la capacità di individuare ambiguità e chiedere precisazioni quando l’intento dell’utente non è chiaro. Significa anche fornire risposte “migliori possibili” in ogni momento del dialogo, spiegando però che tali risposte sono parziali e potranno essere affinate con ulteriori dettagli. La trasparenza diventa qui un elemento architetturale, non solo etico. Quando il sistema esplicita in che modo le informazioni ricevute hanno contribuito a raffinare il risultato, aumenta la fiducia e rende visibile il processo di ragionamento.
Un’ulteriore evoluzione riguarda le architetture multi-agente. Con questa espressione si intende un sistema composto da più moduli specializzati che collaborano tra loro. Un modulo può essere dedicato alla gestione fluida e empatica della conversazione, mentre un altro può occuparsi dell’analisi profonda dei dati e dell’elaborazione strutturata delle informazioni. In ambito cognitivo si potrebbe parlare di una distinzione tra un sistema rapido e intuitivo e un sistema più lento e deliberativo. Il primo interagisce con l’utente, il secondo lavora in background, consultando basi di conoscenza, linee guida e cronologie. Questa separazione aiuta a ridurre il rischio di cosiddette allucinazioni, termine con cui si indica la produzione di contenuti plausibili ma non supportati da dati verificabili. Ancorare il ragionamento a fonti autorevoli e aggiornate non è solo una questione tecnica, ma una responsabilità progettuale.
Infine, l’utilità non può essere disgiunta dalla sicurezza. In settori regolamentati, come quello sanitario o finanziario, è necessario prevedere barriere di protezione, spesso chiamate guardrail. Si tratta di vincoli progettuali che impediscono al sistema di fornire consigli individualizzati non verificati o di operare al di fuori delle proprie competenze. Una scelta architetturale fondamentale consiste nel separare la fase di raccolta e organizzazione dei dati dal momento decisionale finale. L’intelligenza artificiale può strutturare informazioni, evidenziare opzioni, suggerire percorsi, ma l’ultima parola, soprattutto quando ha conseguenze rilevanti, deve passare attraverso un’interfaccia di supervisione umana. In ambito clinico si parla di cockpit del medico, cioè di una dashboard che consente al professionista di rivedere e approvare l’output prima che venga comunicato al paziente. Questo disaccoppiamento tutela l’utente e rafforza la credibilità del sistema.
In definitiva, progettare chatbot nella nuova era dell’intelligenza artificiale significa passare dalla produzione di contenuti alla costruzione di sistemi di ragionamento. Non si tratta più di scrivere risposte, ma di progettare relazioni tra informazioni, stati conversazionali, fonti e responsabilità. L’utilità emerge dall’equilibrio tra empatia nel dialogo, rigore nella raccolta dei dati e trasparenza nel processo decisionale. Se assumiamo questa prospettiva, l’intelligenza artificiale non è più un semplice motore di ricerca travestito da conversazione, ma può diventare un partner capace di accompagnare le persone nell’orientarsi dentro la complessità della conoscenza.