Sono le nove di sera. Un potenziale ospite sta guardando le camere sul sito di un hotel, apre la chat e scrive una domanda di sei parole: «Posso portare il cane in camera?».
Qualche secondo dopo riceve una risposta corretta, con le taglie ammesse e l'eventuale supplemento previsto. Visto da fuori il processo sembra banale: l'utente scrive, l'intelligenza artificiale risponde. Due passaggi, nessun mistero.
Tra quella domanda e quella risposta, però, in un assistente AI aziendale ben progettato succedono parecchie cose. E la parte in cui interviene il modello linguistico — quello che quasi tutti chiamano semplicemente "l'AI" — è soltanto una di queste.
Questo articolo ricostruisce quel percorso passo per passo, senza dare per scontate conoscenze tecniche. Useremo la domanda sul cane come filo conduttore, affiancandola quando serve a esempi presi da e-commerce, servizi professionali e customer care.
Un chatbot AI non è semplicemente "domanda → ChatGPT → risposta"
La rappresentazione più diffusa di un assistente AI è una linea retta: arriva una domanda, il modello genera una risposta. È una semplificazione comprensibile, perché è esattamente quello che vediamo quando usiamo un assistente generalista come ChatGPT: scriviamo qualcosa e otteniamo un testo.
Un assistente installato sul sito di un'azienda lavora però in condizioni molto diverse. Non deve produrre un testo plausibile in generale: deve rispondere su quella specifica azienda, con le sue policy, i suoi prezzi, i suoi orari, le sue eccezioni. E deve farlo davanti a un cliente che poi si presenterà in hotel con il cane al guinzaglio.
Per riuscirci, un assistente aziendale deve tipicamente capire che cosa sta chiedendo l'utente, tenere conto di ciò che è stato detto prima nella conversazione, trovare le informazioni aziendali pertinenti, distinguere ciò che sa da ciò che non sa, costruire una risposta coerente, rispettare le regole che l'azienda gli ha dato, in alcuni casi dialogare con sistemi esterni e riconoscere quando è il momento di coinvolgere una persona.
Sono molte cose. Nelle prossime sezioni le percorriamo una alla volta, nell'ordine in cui tipicamente si presentano.
Primo passaggio: capire che cosa sta chiedendo l'utente
Le persone non scrivono in chat come si scrive in un motore di ricerca, e ancora meno come sono scritte le pagine di un sito. La stessa richiesta può assumere forme molto diverse:
- «Quanto costa la spedizione?»
- «Mi fate pagare la consegna?»
- «Le spese di spedizione sono comprese?»
Tre formulazioni, un solo argomento. Un sistema che cercasse semplicemente le parole della domanda dentro un archivio di testi sarebbe in difficoltà già qui: nella seconda frase la parola "spedizione" non compare, nella terza cambia completamente la costruzione. Eppure l'utente vuole sapere la stessa cosa.
Comprendere la richiesta significa quindi risalire all'intento, cioè all'obiettivo reale della persona, al di là delle parole usate. È il primo punto in cui un assistente moderno si distingue nettamente dai vecchi chatbot a regole, quelli che riconoscevano una parola chiave e restituivano una risposta preconfezionata.
Lo stesso vale per la nostra domanda di partenza. «Posso portare il cane in camera?», «Siete pet friendly?» e «Accettate animali di piccola taglia?» sono formulazioni diverse dello stesso bisogno informativo, anche se la terza contiene già un dettaglio che potrebbe cambiare la risposta.
Il contesto: una domanda non vive sempre da sola
Nella maggior parte dei casi la domanda non arriva isolata, ma dentro una conversazione. Immaginiamo questo scambio:
Utente: «Accettate animali?»
Assistente: «Sì, sono ammessi cani di piccola e media taglia.»
Utente: «E quanto costa?»
Presa da sola, l'ultima domanda non significa quasi nulla. Quanto costa che cosa? La camera, la colazione, il parcheggio? Dentro la conversazione, invece, è perfettamente chiara: l'utente sta chiedendo se c'è un supplemento per l'animale.
Un assistente capace di sostenere una conversazione mantiene questo filo. Un sistema che tratta ogni messaggio come se fosse il primo costringe l'utente a ripetere ogni volta il contesto per intero, e l'esperienza si sfalda in poche battute.
Il contesto, però, non va usato in modo indiscriminato. Se dopo dieci messaggi sugli animali l'utente chiede «e per la colazione a che ora?», l'argomento è cambiato: continuare a trascinarsi dietro il tema precedente porterebbe a risposte fuori bersaglio. In un sistema ben progettato la gestione del contesto consiste anche nel capire quando un'informazione non è più pertinente, e nel non lasciare che una conversazione lunga inquini le risposte successive.
La Knowledge Base: le informazioni che l'azienda mette a disposizione
A questo punto l'assistente ha capito che cosa gli viene chiesto. Deve trovare la risposta. E qui entra in gioco il componente che più di ogni altro determina l'affidabilità del sistema: la Knowledge Base.
Con Knowledge Base si intende l'insieme delle fonti aziendali autorizzate dalle quali l'assistente può recuperare informazioni. A seconda dell'attività può comprendere pagine del sito, FAQ, documenti e PDF, listini, procedure interne, schede prodotto, condizioni di vendita, oppure informazioni inserite direttamente dall'azienda in forma di domanda e risposta.
Nel caso del nostro hotel, la Knowledge Base potrebbe contenere una riga come questa:
«Sono ammessi cani di piccola e media taglia con un supplemento di 15 euro per notte.»
Questa frase è la base fattuale della risposta. Non è una preferenza stilistica: è il dato che l'azienda si assume la responsabilità di comunicare, e che può aggiornare quando il supplemento cambia.
C'è un principio che vale la pena isolare, perché è quello che più spesso viene frainteso: il modello AI non conosce le informazioni reali della vostra azienda. Un modello linguistico è stato addestrato su enormi quantità di testo generico e ha imparato come funziona la lingua e come sono fatte, in media, le informazioni del mondo. Non conosce il vostro listino, i vostri orari, la vostra policy sugli animali. Se gli viene chiesto di rispondere senza fonti, tenderà a produrre qualcosa di plausibile — e plausibile non vuol dire corretto.
Le informazioni specifiche sull'azienda devono quindi arrivare da fonti controllate e aggiornabili dall'azienda stessa. È anche il motivo per cui la qualità della Knowledge Base pesa così tanto sul risultato finale: un assistente non può essere più preciso delle informazioni che gli sono state date.
Retrieval: trovare l'informazione giusta tra tutte quelle disponibili
Avere l'informazione da qualche parte non basta. Bisogna riuscire a tirarla fuori nel momento in cui serve.
Una Knowledge Base aziendale può contenere centinaia o migliaia di informazioni: un catalogo prodotti, anni di FAQ, decine di documenti. Non avrebbe senso — né sarebbe tecnicamente possibile — passare tutto questo materiale al modello a ogni domanda. Il sistema deve selezionare le poche informazioni realmente pertinenti rispetto alla richiesta in corso.
Questa operazione si chiama retrieval, cioè recupero. Funziona un po' come un bravo collega dell'ufficio amministrativo: quando gli chiedete se si può portare il cane non vi consegna l'intero raccoglitore delle procedure, va direttamente alla pagina giusta. La differenza è che il sistema non cerca solo le parole esatte, ma informazioni che riguardano lo stesso significato — motivo per cui «siete pet friendly?» può portare comunque alla riga sulla policy animali.
La combinazione tra questa fase di recupero e la successiva generazione della risposta viene comunemente indicata con la sigla RAG, Retrieval-Augmented Generation: generazione potenziata dal recupero delle informazioni. Detto in modo meno tecnico: prima si cerca nelle fonti aziendali, poi si scrive la risposta basandosi su ciò che si è trovato.
Il punto pratico è questo: un'informazione presente nella Knowledge Base ma che il sistema non riesce a recuperare, per l'utente è come se non esistesse. Molti dei casi in cui un assistente "non sa rispondere" non dipendono dal modello, ma da un problema di recupero o da fonti scritte in modo confuso.
Solo a questo punto entra in gioco il modello linguistico
Siamo arrivati alla parte che tutti immaginano all'inizio del processo, e che invece arriva verso la fine.
Il modello linguistico — l'LLM, Large Language Model — riceve tipicamente un insieme di elementi: la domanda dell'utente, la parte utile della conversazione precedente, le informazioni pertinenti recuperate dalla Knowledge Base e le istruzioni che definiscono il comportamento dell'assistente (chi rappresenta, con quale tono parla, che cosa può e non può fare).
Con questo materiale il modello costruisce una risposta in linguaggio naturale: riformula la policy sugli animali in una frase adatta al contesto, la collega alla domanda specifica, la scrive nella lingua dell'utente, aggiunge se serve una precisazione.
È utile mettere a fuoco la differenza. Il compito del modello non è "sapere la risposta", ma interpretare la richiesta e formularne una utilizzando le informazioni e le regole che gli vengono fornite. La conoscenza sull'azienda arriva dal sistema di retrieval; il modello ci mette la comprensione della lingua e la capacità di costruire un testo coerente. Tenere distinti questi due ruoli aiuta molto a capire dove nascono i problemi quando qualcosa non funziona.
Una precisazione doverosa: non tutte le implementazioni organizzano i passaggi nello stesso ordine, e alcune architetture prevedono più giri tra il modello e gli altri componenti prima di arrivare alla risposta finale. La sequenza descritta qui è una rappresentazione logica e funzionale, non l'unica possibile.
Regole e guardrail: sapere qualcosa non significa poter dire o fare qualsiasi cosa
Torniamo all'hotel, con una variante. La Knowledge Base dice che sono ammessi cani di piccola e media taglia. L'utente scrive:
«Ho un San Bernardo di 70 kg. Posso portarlo comunque?»
Le informazioni disponibili non coprono questo caso. Non dicono che i cani grandi sono vietati in modo assoluto, e non dicono che la struttura concede eccezioni. Dicono soltanto che cosa è previsto normalmente.
Un assistente che qui inventasse una policy — in un senso o nell'altro — creerebbe un danno concreto: un ospite che arriva con un cane troppo grande contando su un via libera che nessuno ha dato, oppure una prenotazione persa perché è stato negato qualcosa che l'hotel avrebbe magari accettato.
Per questo un sistema aziendale non si limita a generare testo: applica regole che stabiliscono, per esempio, quando rispondere e quando dichiarare che l'informazione non è disponibile, quando chiedere un chiarimento invece di procedere, quali argomenti evitare, quali decisioni non prendere in autonomia e in quali situazioni proporre il contatto con una persona.
Questo insieme di limiti e comportamenti previsti è quello che viene chiamato guardrail: letteralmente "guard rail", le barriere che tengono il veicolo in carreggiata. Non servono a rendere l'assistente più timido, ma a fare in modo che si comporti in modo prevedibile anche nei casi che nessuno aveva previsto. È un tema abbastanza ampio da meritare una trattazione a parte.
Il risultato non deve essere necessariamente una risposta
C'è un'idea implicita in molte valutazioni sui chatbot: che il loro obiettivo sia rispondere al maggior numero possibile di domande. È un criterio fuorviante. L'obiettivo è gestire correttamente la richiesta, e a volte gestirla correttamente significa non dare una risposta.
Un assistente ben progettato ha tipicamente diverse conclusioni possibili.
Rispondere, quando le informazioni disponibili sono sufficienti. È il caso della domanda sul cane di taglia media: la policy c'è, la risposta si può dare con precisione, supplemento incluso.
Fare una domanda, quando la richiesta è ambigua. A un «vorrei disdire» su un sito di servizi manca l'informazione essenziale: quale contratto, da quando, con quale preavviso. Chiedere un chiarimento è più utile che indovinare.
Raccogliere informazioni, quando servono per proseguire. Un utente che chiede un preventivo su un sito B2B sta aprendo un processo commerciale: l'assistente può raccogliere settore, esigenza e contatto, e passare il tutto a chi di dovere. È il caso classico della qualifica di un lead.
Compiere un'azione, quando è collegato a strumenti esterni: verificare lo stato di un ordine, controllare uno slot in agenda, aprire una richiesta di assistenza.
Passare la mano a una persona, quando la situazione lo richiede. Una contestazione su un addebito, un reclamo, una richiesta delicata o semplicemente un utente che si sta innervosendo sono casi in cui insistere con l'automazione peggiora le cose. Un buon handoff porta con sé la conversazione già avvenuta, così l'utente non deve ricominciare da capo.
Quando l'assistente AI può anche compiere azioni
Fino a qui abbiamo parlato di informazioni statiche: testi che l'azienda ha preparato in anticipo. Alcune domande, però, riguardano dati che cambiano di continuo e che vivono dentro altri sistemi.
«La camera doppia è libera dal 12 al 14?» non è una domanda a cui si possa rispondere con una pagina del sito. La risposta esiste, ma sta nel gestionale delle prenotazioni. Lo stesso vale per lo stato di una spedizione, la disponibilità di uno slot in agenda o la giacenza di un prodotto.
Quando un assistente è collegato a strumenti e servizi esterni può interrogare questi sistemi e usarne il risultato: recuperare lo stato di un ordine, verificare la disponibilità di un appuntamento, aprire un ticket, registrare un lead nel CRM, avviare una procedura prevista dall'azienda. Vale la pena sottolineare che si tratta di configurazioni esplicite: senza un collegamento con il sistema di prenotazione, nessun assistente può conoscere la disponibilità reale delle camere, per quanto ben scritta sia la Knowledge Base.
La differenza tra generare un testo e compiere un'azione è sostanziale. Una risposta imprecisa si corregge; un appuntamento fissato per errore, un ticket duplicato o un dato scritto nel gestionale sbagliato producono conseguenze reali. Per questo le azioni richiedono controlli più stretti delle risposte, e una regola che dovrebbe valere sempre: l'assistente non dovrebbe comunicare all'utente che qualcosa è stato completato se non ha ricevuto conferma dal sistema coinvolto. Se la richiesta non va a buon fine, l'utente deve saperlo, e deve avere una via d'uscita.
Perché due chatbot che usano lo stesso modello AI possono essere molto diversi
Mettiamo due assistenti fianco a fianco, sui siti di due aziende dello stesso settore. Usano lo stesso identico modello linguistico. Uno funziona bene: risponde con precisione, ammette i propri limiti, passa la conversazione a una persona quando serve. L'altro dà risposte generiche, sbaglia i prezzi, ogni tanto inventa.
La differenza non sta nell'AI. Sta in tutto quello che le è stato costruito intorno: la qualità e l'organizzazione della Knowledge Base, la capacità di recuperare l'informazione giusta al momento giusto, la gestione del contesto conversazionale, le istruzioni che definiscono il comportamento, le regole e i guardrail, il modo in cui vengono trattate le informazioni mancanti, le integrazioni con i sistemi aziendali, le procedure di fallback quando qualcosa non funziona e, più in generale, la progettazione dell'esperienza.
«Quale modello AI utilizza questo chatbot?» resta una domanda legittima. I modelli non sono tutti uguali e le loro capacità contano: un modello più solido interpreta meglio richieste complesse, segue meglio le istruzioni, gestisce meglio le sfumature. Ma è una domanda parziale. Accanto ad essa vale la pena chiedere da dove arrivano le informazioni, come vengono aggiornate, che cosa succede quando la risposta non c'è, e come si passa a una persona.
Un esempio completo: seguiamo una domanda dall'inizio alla fine
Ricomponiamo il percorso sulla domanda da cui siamo partiti: «Posso portare il cane in camera?»
- L'assistente interpreta la richiesta e riconosce l'argomento: policy sugli animali domestici.
- Considera il contesto della conversazione, per capire se l'utente stava già parlando di una camera o di date specifiche.
- Il sistema di retrieval cerca nella Knowledge Base le informazioni pertinenti.
- Recupera la policy: cani di piccola e media taglia ammessi, supplemento di 15 euro per notte.
- Passa al modello la domanda, il contesto utile, l'informazione recuperata e le istruzioni sul comportamento dell'assistente.
- Il modello formula una risposta chiara e coerente con la fonte.
- Le regole verificano che la risposta resti dentro i limiti previsti.
- Se utile, l'assistente propone un passo successivo: verificare la disponibilità, contattare la struttura, ricevere le condizioni complete.
Ora cambiamo la domanda: «Ho un San Bernardo di 70 kg. Posso portarlo comunque?»
I primi passaggi sono identici. L'assistente riconosce lo stesso argomento e recupera la stessa policy. Il percorso però arriva a una conclusione diversa, perché l'informazione disponibile non copre il caso: non autorizza l'eccezione e non la esclude.
La gestione corretta, a questo punto, è dichiarare con precisione ciò che risulta — che la policy standard prevede cani di piccola e media taglia — spiegare che per una taglia superiore serve una valutazione della struttura, e offrire un contatto diretto. L'utente non ottiene un sì, ma ottiene qualcosa di più utile: un quadro chiaro e un modo per risolvere davvero la questione. E l'hotel non si ritrova un San Bernardo in reception senza saperlo.
Dalla semplificazione a una rappresentazione più realistica
Torniamo allo schema da cui siamo partiti. La versione semplificata (e assolutamente sbagliata) di come funziona un chatbot AI per siti web:
Domanda → AI → Risposta
Una rappresentazione più vicina a come funziona un assistente aziendale:
Domanda → Intento → Contesto → Knowledge Base → Retrieval → Modello AI → Regole → Risposta / Domanda / Azione / Contatto umano
Non tutti i sistemi seguono esattamente questa architettura o questo preciso ordine: esistono implementazioni diverse e alcune organizzano i passaggi in modo differente. Ma lo schema rende evidente una cosa che la versione semplicistica nasconde completamente: un assistente AI aziendale è molto più del semplice accesso a un modello linguistico.
È anche il motivo per cui IKIbrain non si limita a mettere un modello AI dentro un widget di chat. L'assistente viene costruito intorno alla Knowledge Base dell'azienda, alla gestione delle conversazioni, alle istruzioni che ne definiscono il comportamento, alle regole che stabiliscono limiti e casi di fallback, e alle eventuali integrazioni con i sistemi già in uso. L'obiettivo non è avere un chatbot che risponde a tutto, ma un assistente che gestisce correttamente le richieste dei visitatori di quella specifica azienda — compresi i casi in cui la risposta giusta è passare la parola a un operatore.