Guardrail nei chatbot AI: come definire regole e limiti delle risposte

Un cliente scrive all'assistente virtuale del tuo e-commerce: «Ho ricevuto l'ordine il mese scorso, posso ancora restituirlo?». La Knowledge Base contiene la risposta, chiara e aggiornata: il reso è consentito entro 15 giorni dalla consegna. Il chatbot la riporta correttamente.

Poi arriva il messaggio successivo: «Ho avuto un problema personale e non sono riuscito a fare il reso in tempo. Potete fare un'eccezione?».

Qui la Knowledge Base non aiuta più. Contiene la regola, non la facoltà di derogarvi. Eppure il chatbot, se nessuno gli ha detto come comportarsi, una risposta la darà comunque: potrebbe rispondere di no con troppa durezza, oppure — molto peggio — rispondere che «in casi particolari l'azienda valuta delle eccezioni», creando un'aspettativa che nessuno in azienda ha autorizzato.

È esattamente in questo spazio che entrano in gioco i guardrail.

Cosa sono i guardrail di un chatbot AI

Il termine inglese guardrail indica il guard rail stradale: quella barriera che non decide dove vai, ma impedisce che tu esca di strada. Applicato a un assistente virtuale, il concetto è lo stesso. I guardrail sono l'insieme di regole e limiti che definiscono il comportamento dell'assistente: cosa può dire, cosa non deve dire, quali decisioni può prendere da solo e quando deve fermarsi.

La distinzione più utile da tenere a mente quando configuri un assistente per la tua azienda è questa:

• la Knowledge Base stabilisce ciò che l'assistente sa: listini, policy, schede prodotto, condizioni di vendita, procedure;
• i guardrail stabiliscono cosa può farne: come usa quelle informazioni, con che tono, entro quali confini, e cosa fa quando le informazioni non bastano.

Sono due livelli diversi e non si sostituiscono a vicenda. Puoi avere una Knowledge Base impeccabile e un assistente che si comporta male, così come puoi avere regole di comportamento perfette e un assistente che, non avendo contenuti affidabili, non è in grado di essere utile.

Vale anche la pena chiarire un equivoco frequente. Quando si parla di sicurezza dei chatbot si pensa quasi sempre alla protezione da usi malevoli: tentativi di far dire all'assistente cose inopportune, richieste di dati riservati, contenuti offensivi. Sono aspetti reali, ma in un contesto aziendale i guardrail sono soprattutto altro: sono regole commerciali, di tono, di ambito e di responsabilità.

Chi può concedere uno sconto. Fino a che punto si può interpretare una policy. Quando serve il giudizio di una persona. Sono decisioni di business prima che tecniche, e per questo non possono essere delegate a chi installa il chatbot: devono venire da chi conosce l'azienda.

Perché una buona Knowledge Base non basta

La tentazione, quando si configura un assistente, è pensare che il lavoro consista nel caricare più materiale possibile. Più documenti carichiamo, più domande coprirà. È vero solo in parte, perché la maggior parte dei problemi non nasce dalle domande che la Knowledge Base copre: nasce da quelle che la sfiorano.

Prendi una regola semplicissima: «spedizione gratuita per ordini superiori a 100 euro». Un cliente con un carrello da 95 euro scrive: «Mi mancano pochi euro, potete farmela gratuita lo stesso?».

L'assistente conosce perfettamente la regola. Ma la domanda non riguarda la regola, riguarda la sua deroga — e su quella nessuno lo ha autorizzato a pronunciarsi. Conoscere una policy e avere l'autorità per modificarla sono due cose diverse, e questa differenza è invisibile in un documento. In un documento c'è scritto solo «100 euro».

Lo stesso vale in decine di situazioni quotidiane: un cliente che chiede una consegna in una data particolare, un'azienda che chiede se il preventivo pubblicato vale anche per un ordine di grandi volumi, un paziente che chiede se un trattamento è adatto al suo caso specifico. La Knowledge Base descrive il caso normale. La realtà porta continuamente casi al confine.

Un assistente ben configurato non deve saper rispondere a tutte queste domande. Deve saper riconoscere che si trova sul confine, dirlo con chiarezza e sapere cosa fare da quel momento in poi.

Cosa deve fare il chatbot quando non conosce la risposta

Le risposte più pericolose non sono quelle sbagliate in modo evidente. Sono quelle vaghe che sembrano ragionevoli: «Generalmente i tempi di consegna sono di due o tre giorni», «Probabilmente il prodotto è disponibile anche nella variante blu», «Credo che il servizio sia incluso nell'abbonamento base».

Formule del genere hanno un problema preciso. Il cliente non legge un'ipotesi: legge una risposta dell'azienda. E quando quell'ipotesi si rivela sbagliata, il costo non è un fastidio conversazionale, è un reclamo, un reso, una recensione negativa o una discussione su un impegno che l'azienda non ha mai preso.

Sono le cosiddette allucinazioni dell'AI, e nel contesto aziendale si manifestano quasi sempre così: non come invenzioni clamorose, ma come plausibili approssimazioni su informazioni che l'assistente non ha davvero.

Il comportamento corretto in questi casi segue un principio semplice: non so → lo dichiaro → aiuto comunque a proseguire.

Dichiarare il limite significa essere espliciti su cosa l'assistente può confermare e cosa no. Aiutare a proseguire significa che la conversazione non finisce lì. «Non ho questa informazione» è un vicolo cieco. «Nelle informazioni che ho a disposizione non trovo i tempi di consegna per la Sardegna. Se mi indichi il CAP e il prodotto che ti interessa, giro la richiesta al nostro ufficio logistica che ti risponde entro la giornata» è un servizio.

La differenza tra le due frasi non sta nella cortesia. Sta nel fatto che la seconda raccoglie le informazioni che serviranno a un collega per chiudere davvero la questione.

Le domande ambigue: quando chiedere è meglio che rispondere

«Ho un problema con il pagamento.» Questa frase, che nel customer care arriva ogni giorno, può significare almeno cinque cose diverse: una carta rifiutata, un doppio addebito, un rimborso che non è arrivato, una fattura mancante, un bonifico che risulta non registrato. Le azioni da compiere sono completamente diverse, e in alcuni casi opposte.

Un assistente configurato male sceglierà l'interpretazione statisticamente più frequente e partirà con la sua spiegazione. Se ha indovinato, ha risparmiato un passaggio. Se ha sbagliato, ha fatto perdere tempo al cliente e ha reso la conversazione più difficile, perché ora il cliente deve anche correggere l'assistente prima di poter esporre il proprio problema.

Una domanda di chiarimento ben fatta vale più di una risposta immediata basata su un'ipotesi: «Per aiutarti nel modo giusto: il pagamento è stato rifiutato, hai visto un addebito doppio, oppure stai aspettando un rimborso?». Sono dieci secondi in più per il cliente e una conversazione che va nella direzione corretta.

La regola da trasmettere all'assistente è quindi che l'ambiguità non si risolve indovinando. Quando la richiesta può portare a percorsi diversi, e soprattutto quando uno di questi percorsi coinvolge denaro, dati o impegni, la scelta giusta è chiedere.

Definire ciò che il chatbot non deve fare

Nella configurazione di un assistente aziendale si dedica molta attenzione a cosa deve saper fare, e quasi nessuna all'elenco opposto. Eppure è quello che protegge l'azienda. Ecco alcuni limiti che vale la pena mettere per iscritto:

• rispondere su temi aziendali usando informazioni che non provengono dalle fonti autorizzate;
• inventare prezzi, condizioni contrattuali o disponibilità di magazzino;
• concedere sconti di propria iniziativa;
• promettere rimborsi, sostituzioni o proroghe;
• modificare o negoziare condizioni commerciali;
• interpretare liberamente una policy quando il caso non è previsto;
• fornire informazioni riservate o dati di altri clienti;
• affrontare argomenti estranei all'attività dell'azienda;
• prendere decisioni che internamente richiedono l'autorizzazione di una persona.

Non esiste una configurazione valida per tutti. Uno studio professionale ha bisogno di limiti molto più stretti sulla consulenza rispetto a un negozio di articoli sportivi. Una struttura sanitaria non può permettersi le stesse libertà di un'agenzia di viaggi. Un'azienda B2B che lavora su preventivi personalizzati avrà bisogno di regole precise su cosa l'assistente può anticipare in termini di prezzo, mentre un e-commerce con listini pubblici avrà problemi diversi.

Il modo pratico di costruire questo elenco è partire da una domanda concreta: quali risposte, se le desse un neoassunto al primo giorno senza chiedere a nessuno, ti farebbero preoccupare? Quelle sono le tue regole.

Quando il chatbot deve passare la conversazione a un operatore in carne ed ossa

C'è una convinzione diffusa secondo cui ogni passaggio a un operatore sia una sconfitta dell'automazione. È il contrario. Un buon assistente AI non è quello che risponde sempre: è quello che sa anche quando non dovrebbe rispondere.

Le situazioni in cui l'escalation è il comportamento corretto sono abbastanza ricorrenti da poter essere previste in fase di configurazione: reclami complessi, clienti visibilmente insoddisfatti, richieste di eccezione a una regola commerciale, informazioni che non sono nelle fonti disponibili, questioni delicate che toccano salute, denaro o aspetti legali, casi che richiedono una verifica interna, decisioni che necessitano di un'autorizzazione.

Il punto meno considerato, però, è che anche il passaggio va progettato. Chiudere la conversazione con «contatta l'assistenza» scarica sul cliente tutto il lavoro residuo: trovare il canale giusto, ripetere il problema da capo, allegare di nuovo i dati. Un handoff ben costruito fa il contrario. Riassume la situazione, raccoglie in anticipo ciò che servirà a chi prende in carico la richiesta — numero d'ordine, riferimento fattura, descrizione del problema, recapito preferito — e dice al cliente cosa succederà e in quanto tempo.

Quando il chatbot compie azioni, i guardrail contano ancora di più

Fino a questo punto abbiamo parlato di risposte. Ma un assistente collegato ai sistemi aziendali non si limita a parlare: fa. Può fissare un appuntamento in agenda, controllare lo stato di una spedizione, aprire un ticket di assistenza, recuperare un dato dal gestionale, registrare le informazioni di un contatto.

La differenza rispetto a prima è sostanziale. Una risposta sbagliata è un'informazione da correggere; un'azione sbagliata è un fatto avvenuto. Un appuntamento fissato nello slot di un altro cliente, un ticket duplicato, un dato scritto nel record sbagliato non si risolvono riformulando la frase.

Per ogni azione che affidi all'assistente vanno quindi definite alcune cose: in quali condizioni può eseguirla, quali informazioni deve avere raccolto prima di procedere, quando deve chiedere una conferma esplicita all'utente, come verifica che l'operazione sia andata a buon fine e cosa comunica se qualcosa non funziona.

Su quest'ultimo aspetto vale la pena essere categorici: l'assistente non deve mai comunicare che un'operazione è stata completata se il sistema esterno non ne ha confermato l'esito. Un cliente che si sente dire «appuntamento confermato per giovedì alle 15» e si presenta senza essere in agenda è un problema molto più serio di un cliente a cui viene detto «non riesco a completare la prenotazione in questo momento, ti metto in contatto con la segreteria».

Come testare i guardrail prima di pubblicare l'assistente

I guardrail si verificano provandoli, non leggendoli. Prima di mettere l'assistente davanti ai clienti, dedica mezz'ora a un test strutturato: apri una conversazione nuova per ogni scenario (il contesto delle domande precedenti può mascherare un problema) e definisci il comportamento atteso prima di leggere la risposta, altrimenti finirai per giudicare accettabile ciò che suona bene.

Otto scenari coprono la quasi totalità dei casi in cui i guardrail vengono davvero messi alla prova. Per ognuno, accanto alla domanda da porre, trovi il comportamento che dovresti aspettarti.

• Domanda con risposta chiaramente presente nella Knowledge Base. Deve rispondere in modo corretto e coerente con la fonte, senza aggiungere dettagli che nei contenuti caricati non ci sono.
• Domanda su un'informazione assente. Deve dichiarare di non avere quel dato, non improvvisare e indicare il passo successivo o il contatto giusto.
• Domanda ambigua, del tipo «ho un problema con l'ordine». Deve chiedere un chiarimento mirato invece di scegliere per conto suo un'interpretazione.
• Richiesta di eccezione a una regola: uno sconto, una proroga, una deroga. Deve spiegare la regola, dichiarare di non poter decidere l'eccezione, raccogliere i dati utili e passare la conversazione a una persona.
• Argomento fuori contesto. Deve declinare con cortesia e riportare la conversazione nell'ambito dell'azienda.
• Situazione che richiede un operatore, come un reclamo o un cliente visibilmente irritato. Deve riconoscerla, evitare di insistere con risposte automatiche e proporre il passaggio raccogliendo il contesto necessario.
• Tentativo di ottenere informazioni riservate o interne. Deve rifiutare senza rivelare nulla, anche quando la richiesta è formulata in modo indiretto o insistente.
• Errore durante un'azione eseguita tramite integrazione. Non deve dichiarare l'operazione completata: comunica il problema e offre un'alternativa concreta.

Vale la pena tenere traccia degli esiti in un semplice foglio condiviso, con una riga per scenario e la data della verifica. Serve meno per il singolo test che per i confronti successivi: quando qualcosa cambia, avere sotto mano il comportamento precedente rende immediato capire se è cambiato in meglio o in peggio.

Questi test non servono solo al lancio. Vanno rifatti ogni volta che cambia qualcosa di sostanziale: nuovi contenuti nella Knowledge Base, modifiche alle istruzioni dell'assistente, un cambio di modello AI, una procedura aziendale aggiornata, una nuova integrazione. Un intervento che migliora la qualità delle risposte può, senza che nessuno se ne accorga, rendere l'assistente più disponibile a rispondere anche dove non dovrebbe.

Le domande giuste da farsi in fase di configurazione

Quando si progetta un assistente virtuale, la domanda che viene naturale è: «A quali domande saprà rispondere?». È una domanda legittima, ma da sola porta a configurazioni fragili. Accanto a quella, vale la pena mettersene altre quattro:

• A quali domande non deve rispondere?
• In quali casi deve chiedere maggiori informazioni prima di procedere?
• Quali decisioni può prendere in autonomia?
• Quando deve lasciare spazio a una persona?

Le risposte a queste domande non sono un dettaglio tecnico da definire alla fine: sono la parte della configurazione che determina se l'assistente sarà una risorsa affidabile o una fonte di equivoci da gestire.

È anche il motivo per cui, in IKIbrain, la Knowledge Base è solo una parte del lavoro. L'assistente si configura definendo la sua identità, le istruzioni di comportamento, il tono di voce, l'ambito delle conversazioni che può affrontare, il modo in cui deve gestire le informazioni che non ha e le modalità con cui mettere l'utente in contatto con una persona, fino al passaggio della conversazione a un operatore. Sono elementi che agiscono insieme: ciascuno di essi contribuisce a determinare come l'assistente si comporta con i tuoi clienti, non solo cosa sa.

Un assistente virtuale ben configurato non è quello che non si ferma mai. È quello che, quando si ferma, lo fa nel punto giusto.