Molte aziende arrivano da noi dopo aver provato un chatbot generico: un widget configurato in un pomeriggio, collegato a un modello linguistico, con un prompt del tipo «sei l'assistente dell'azienda X, rispondi con cortesia». Funziona benissimo nella demo. Poi un cliente chiede se un prodotto è compatibile con un altro modello, e il chatbot risponde di sì con grande sicurezza. Non lo è.
La differenza tra un chatbot generico e un assistente costruito sui documenti aziendali non sta nel modello che c'è sotto, che spesso è lo stesso. Sta in tutto quello che gli si costruisce intorno. Vediamo i punti che contano davvero.
Allucinazioni: perché il generico inventa
Un modello linguistico è addestrato a produrre testo plausibile. Se gli chiedete la garanzia di un vostro prodotto e non ha accesso ai vostri documenti, produrrà la garanzia più plausibile per un prodotto di quel tipo. Non mente: completa. Il risultato però, per il cliente, è un'informazione sbagliata data con il vostro marchio sopra.
Un assistente basato su documenti (con un'architettura RAG, Retrieval-Augmented Generation) riduce il problema in tre modi:
- recupera i passaggi pertinenti dai vostri documenti prima di rispondere;
- è istruito a rispondere solo su quei passaggi;
- quando non trova nulla di pertinente, lo dice e propone un'alternativa, come un contatto con l'ufficio giusto.
Ridurre non significa eliminare. Anche un buon sistema RAG può interpretare male un passaggio ambiguo o combinare due fonti in modo improprio. Per questo servono le due cose che seguono: le fonti citate e il monitoraggio.
Fonti citate: la risposta che si può controllare
Un chatbot generico risponde e basta. Un assistente aziendale ben fatto risponde e dice da dove ha preso l'informazione: il nome del documento, la sezione, il link alla pagina. Questo cambia tre cose.
- L'utente può verificare. Su una domanda importante, un cliente o un collega apre la fonte e controlla.
- L'azienda può correggere. Se la risposta è sbagliata, la citazione dice subito se il problema è nel documento (vecchio, ambiguo, errato) o nel recupero.
- La fiducia si costruisce. Una risposta con fonte è percepita in modo diverso da un testo anonimo.
Su Caddy, il chatbot di questo sito, abbiamo seguito lo stesso principio: quando parla di un progetto lo cita per nome e collega la scheda, così il visitatore torna dentro il sito invece di fidarsi di una frase. La scheda di Caddy racconta come l'abbiamo impostato.
Permessi: non tutti devono vedere tutto
Questo è il punto in cui i chatbot generici, o quelli costruiti in fretta caricando una cartella di documenti, mostrano i limiti più seri. Se nell'indice finiscono insieme il catalogo pubblico, i listini riservati ai rivenditori e le note interne sul contenzioso con un fornitore, prima o poi qualcuno riceverà la risposta sbagliata.
Un assistente aziendale gestisce i permessi a livello di recupero, non solo di interfaccia:
- ogni documento ha metadati di visibilità (pubblico, clienti, rivenditori, interno, reparto);
- l'utente è autenticato o, se anonimo, ha il livello minimo;
- la ricerca filtra i documenti prima che arrivino al modello, così il modello non «vede» mai quello che l'utente non dovrebbe leggere.
Affidarsi a un'istruzione nel prompt («non rivelare informazioni riservate») non basta: un modello si può convincere a ignorarla. Il controllo va fatto nel codice.
Privacy: dove finiscono le conversazioni
Le domande degli utenti contengono spesso dati personali: nomi, numeri d'ordine, indirizzi, a volte informazioni sanitarie o economiche. Con un servizio generico è facile non sapere dove vengano conservate le conversazioni, per quanto tempo, e se vengano usate per addestrare modelli.
In un progetto su misura queste scelte si fanno in modo esplicito:
- quale fornitore di LLM usare e con quali condizioni contrattuali sul trattamento dei dati, comprese le opzioni con elaborazione in Europa;
- quali dati salvare nei log e per quanto tempo, ed eventualmente come mascherare i dati personali;
- come informare l'utente che sta parlando con un sistema di intelligenza artificiale, cosa che con l'AI Act è diventata un obbligo esplicito dal 2 agosto 2026;
- chi in azienda può leggere le conversazioni e per quale scopo.
Settori come quello legale o sanitario hanno vincoli ancora più stretti: per uno studio legale, per esempio, il perimetro di cosa il chatbot può trattare va definito prima di tutto il resto.
Integrazione con il CRM e con i sistemi esistenti
Un chatbot generico vive isolato: risponde, la conversazione finisce, nessuno sa che è avvenuta. Un assistente costruito per l'azienda si collega ai sistemi che già esistono:
- CRM: una richiesta di preventivo raccolta in chat diventa un lead con nome, azienda, esigenza e trascrizione della conversazione, invece di una mail da ricopiare;
- gestionale o e-commerce: lo stato di un ordine o la disponibilità di un articolo si leggono dai dati veri, non dai documenti. Per un e-commerce è spesso la differenza tra un assistente utile e uno decorativo;
- sistema di ticketing: le richieste che il chatbot non può risolvere aprono un ticket già classificato.
Queste integrazioni sono lavoro di software engineering classico, non di AI: API, autenticazione, gestione degli errori, test. È qui che un progetto si rivela solido o fragile.
Passaggio a un operatore umano
Ogni assistente deve sapere quando fermarsi. I casi tipici in cui la conversazione va passata a una persona:
- l'utente lo chiede esplicitamente;
- la domanda riguarda un reclamo, un problema di pagamento, una situazione delicata;
- il sistema non trova fonti pertinenti per due o tre tentativi;
- la richiesta richiede una valutazione che spetta a un professionista.
Il passaggio deve essere pulito: l'operatore riceve la conversazione già fatta, così il cliente non deve ripetere tutto. Se fuori orario non c'è nessuno, il chatbot lo dice chiaramente e raccoglie i dati per un ricontatto. Un chatbot generico, di solito, non ha nessuna di queste vie d'uscita e continua a rispondere anche quando non dovrebbe.
Le metriche da guardare
«Quante conversazioni ha fatto» è il numero meno interessante. Le metriche che dicono davvero se l'assistente funziona sono altre:
- Domande senza risposta: quante volte il sistema non ha trovato fonti. È la lista dei documenti che mancano.
- Feedback negativo sulle singole risposte, da leggere una per una almeno nelle prime settimane.
- Tasso di passaggio all'operatore e motivi del passaggio: se è troppo alto l'assistente serve a poco, se è quasi zero forse non sta riconoscendo i casi che dovrebbe passare.
- Argomenti più richiesti: spesso rivelano informazioni che mancano sul sito o nei manuali.
- Esiti concreti: lead generati nel CRM, ticket evitati o arrivati già classificati, tempo risparmiato dagli operatori.
Queste metriche richiedono una dashboard e qualcuno che la guardi. Senza, l'assistente peggiora silenziosamente man mano che i documenti invecchiano.
Allora il chatbot generico non serve mai?
Serve per alcune cose: scrivere bozze, riassumere testi, fare brainstorming interno. Lì il rischio di una risposta imprecisa è basso e chi lo usa sa che deve verificare. Diventa un problema quando parla a nome dell'azienda con clienti, cittadini o colleghi che si fidano della risposta. In quel caso servono documenti, permessi, fonti, integrazioni e una persona pronta a subentrare.
È il tipo di sistema che costruiamo nell'area AI Engineering. Se state valutando se il vostro caso richieda un assistente su misura o se basti qualcosa di più semplice, provate a fare qualche domanda a Caddy, poi raccontateci il vostro scenario: vi diciamo cosa ha senso costruire e cosa no.
