Chatbot aziendale: cosa definire prima di svilupparlo

Prima di sviluppare un chatbot aziendale devi definire 7 elementi: utente, compito, fonti, limiti, passaggio a una persona, integrazioni e criteri di qualità. Se mancano, il progetto parte dalla tecnologia e scopre troppo tardi cosa dovrebbe risolvere.

La checklist di questo articolo può diventare il primo capitolato. Non richiede di scegliere subito modello, piattaforma o canale. Serve a rendere confrontabili proposte tecniche e aspettative interne.

Chatbot o assistente AI?

Nel linguaggio comune i 2 termini si sovrappongono, ma in fase di progetto conviene specificare il comportamento atteso.

• Un chatbot informativo risponde a domande entro una knowledge base definita.
• Un assistente operativo aiuta una persona a trovare, sintetizzare o preparare informazioni.
• Un agente con tool può leggere o modificare sistemi tramite funzioni autorizzate.

Il rischio cresce quando aumenta la capacità di agire. Un chatbot che indica un articolo del centro assistenza ha un perimetro diverso da un agente che apre ticket, aggiorna un CRM o invia messaggi.

Se l'obiettivo include azioni su sistemi, confronta il perimetro anche con Automazioni con Agenti AI e con la guida sugli agenti AI per PMI.

1. Chi userà il chatbot e in quale momento?

Descrivi la situazione, non soltanto il pubblico.

Esempi:

• una persona visita la pagina prezzi e vuole capire quale servizio è adatto;
• un cliente cerca una procedura dopo l'acquisto;
• un commerciale interno deve recuperare una scheda prodotto aggiornata;
• un operatore vuole preparare una risposta, ma resta responsabile dell'invio.

Per ogni scenario indica:

Campo	Esempio
Utente	Cliente già autenticato
Momento	Dopo aver aperto una richiesta
Bisogno	Conoscere stato e prossima azione
Canale	Area riservata
Esito	Risposta con fonte o passaggio all'operatore

Lo stesso utente può avere bisogni diversi in momenti diversi. La progettazione deve quindi partire dalle conversazioni reali o da casi sintetici plausibili, non da una lista generica di funzionalità.

2. Qual è il compito preciso?

Scrivi 1 frase che contenga verbo, oggetto e limite.

Esempio debole: "aiutare il customer care".

Esempio verificabile: "rispondere alle domande sulle procedure pubblicate, citando il documento corrente, e passare a un operatore quando la fonte non è disponibile".

Poi separa 3 categorie:

1. Deve fare: compiti inclusi e testabili.
2. Può fare: funzioni utili ma non necessarie al primo rilascio.
3. Non deve fare: consigli, decisioni o azioni escluse.

Questo confine riduce il rischio di costruire un assistente che promette tutto e non può essere valutato su niente.

3. Quali fonti può usare?

La knowledge base è il prodotto editoriale del chatbot. Prima dello sviluppo, inventaria:

• documenti;
• URL;
• owner;
• data di aggiornamento;
• pubblico autorizzato;
• versione corrente;
• data di scadenza;
• contenuti in conflitto.

Un documento non diventa affidabile perché è stato caricato nel sistema. Se 2 procedure danno istruzioni diverse, l'assistente non deve scegliere in silenzio. Deve usare la fonte prioritaria o dichiarare il conflitto.

Definisci anche il formato della risposta:

• risposta breve;
• collegamento alla fonte;
• data o versione quando rilevante;
• livello di certezza operativo, per esempio "fonte trovata" o "verifica necessaria";
• prossima azione.

4. Quando deve fermarsi?

Il requisito più importante può essere un rifiuto corretto. Prepara una tassonomia dei casi da bloccare:

• fonte assente o scaduta;
• richiesta fuori perimetro;
• identità o permesso non verificati;
• dati sensibili non necessari;
• istruzioni che cercano di modificare il comportamento del sistema;
• azione irreversibile;
• situazione che richiede giudizio professionale.

OWASP descrive la prompt injection come un rischio in cui input costruiti ad arte alterano il comportamento previsto del modello. Per questo le istruzioni dell'utente e i contenuti recuperati vanno trattati come input non affidabili, soprattutto quando il sistema dispone di tool.

Il chatbot non dovrebbe custodire segreti nel prompt. Credenziali, ruoli e autorizzazioni devono essere gestiti dall'applicazione con controlli esterni al modello. Anche questa separazione è richiamata dalle indicazioni OWASP sul system prompt leakage.

5. Come avviene il passaggio a una persona?

"Contatta l'assistenza" non è ancora un flusso di escalation. Devi definire:

• quale condizione lo attiva;
• quale team riceve la richiesta;
• quali dati vengono passati;
• quale parte della conversazione viene inclusa;
• come l'utente viene informato;
• cosa succede se il canale non è disponibile;
• come si chiude il caso.

Un buon handoff evita di far ripetere tutto alla persona, ma trasferisce soltanto informazioni necessarie e autorizzate. Il riassunto generato deve restare distinguibile dalla conversazione originale.

Per un assistente interno, il passaggio può essere una richiesta di approvazione. Per un chatbot pubblico, può essere un ticket o un contatto umano. In entrambi i casi, prova anche l'errore: operatore non disponibile, integrazione in timeout, utente non riconosciuto.

6. Quali sistemi può leggere o modificare?

Elenca le integrazioni come permessi specifici.

Sistema	Lettura ammessa	Scrittura ammessa	Conferma	Log
Knowledge base	Articoli pubblicati	Nessuna	Non richiesta	Fonti usate
CRM	Scheda del contatto autenticato	Nota bozza	Operatore	Utente, azione, esito
Ticketing	Stato del ticket	Apertura ticket	Utente prima dell'invio	ID e timestamp
Calendario	Slot disponibili	Prenotazione	Utente	Evento creato

Applica il principio del minimo privilegio: ogni funzione deve poter accedere solo ai dati e alle azioni necessari. Il modello propone, l'applicazione controlla permesso e formato, la persona conferma quando l'azione ha conseguenze esterne.

Se il progetto richiede una base applicativa più ampia, valuta il servizio Software, Gestionali e CRM AI separatamente dal design conversazionale.

7. Come sapremo se funziona?

Definisci test e metriche prima del rilascio.

Dataset di test

Prepara almeno queste categorie:

• domande frequenti con fonte;
• domande formulate in modi diversi;
• fonte mancante;
• documenti in conflitto;
• richiesta fuori ambito;
• richiesta con dato sensibile;
• tentativo di prompt injection;
• errore dell'integrazione;
• richiesta di parlare con una persona;
• interazione tramite tastiera e tecnologie assistive.

Il NIST AI RMF tratta la gestione del rischio come un lavoro continuo lungo il ciclo di vita. Il dataset non si chiude al lancio: gli errori reali, una volta anonimizzati e classificati, devono diventare nuovi casi di test.

Metriche minime

Evita una sola metrica aggregata. Usa un set che distingua qualità, copertura e rischio:

• risposta corretta con fonte;
• risposta incompleta;
• rifiuto corretto;
• rifiuto errato;
• escalation corretta;
• escalation mancata;
• errore tecnico;
• azione esterna confermata;
• segnalazioni dell'utente;
• tempo fino alla risoluzione.

Il tasso di conversazioni "gestite" può sembrare alto anche quando il sistema risponde male. Campiona le conversazioni con criteri di privacy e revisiona la qualità per categoria.

Requisiti che non vanno lasciati alla fine

Trasparenza

La persona deve capire che sta interagendo con un sistema AI quando questo è il caso. Le linee guida della Commissione europea pubblicate per gli obblighi di trasparenza dell'AI Act trattano esplicitamente i sistemi che interagiscono direttamente con persone. Applicazione e responsabilità dipendono dal ruolo e dal caso concreto, quindi la configurazione va verificata con chi presidia compliance e legale.

Accessibilità

Il chatbot deve funzionare con tastiera, focus visibile, etichette comprensibili, aggiornamenti annunciabili e alternative al solo input vocale. Il W3C include requisiti specifici per le interfacce in linguaggio naturale all'interno del lavoro sull'accessibilità digitale.

Privacy e conservazione

Indica quali conversazioni vengono conservate, per quanto tempo, con quale finalità e chi può leggerle. Non raccogliere dati solo perché la chat rende facile chiederli.

Osservabilità

Registra versione del sistema, fonte usata, tool chiamato, esito e passaggio a una persona. Evita di registrare più contenuto personale del necessario.

Continuità operativa

Prevedi cosa accade quando modello, knowledge base o integrazione non sono disponibili. Una risposta chiara e un canale alternativo sono migliori di un'azione parziale nascosta.

Mini capitolato da copiare

Compila questo schema prima di chiedere una proposta:

Sezione	Decisione richiesta
Obiettivo	1 compito principale e risultato atteso
Utenti	pubblico, contesto, autenticazione e canale
In scope	richieste che il sistema deve gestire
Out of scope	richieste da rifiutare o escalare
Knowledge base	fonti, owner, aggiornamento e permessi
Risposta	formato, citazioni e tono
Handoff	condizioni, destinatario e dati trasferiti
Integrazioni	letture, scritture e conferme
Sicurezza	minimi privilegi, input ostili e segreti
Compliance	trasparenza, privacy, conservazione e accessibilità
Test	categorie, dataset e soglia di rilascio
Metriche	qualità, rischio, copertura e operatività
Owner	responsabile prodotto, tecnico e contenuti

Porta una checklist, non soltanto un'idea

Se hai compilato le 7 domande, puoi discutere obiettivo, rischi e criteri di successo prima della tecnologia. MAIKER HUB progetta chatbot e assistenti AI per aziende partendo da analisi, design conversazionale, knowledge base, sviluppo e ottimizzazione verificabile.