Quando un assistente AI non deve rispondere

Un assistente AI non dovrebbe rispondere quando l'evidenza disponibile non copre la domanda, le fonti sono scadute o in conflitto, manca l'autorità per formulare quella conclusione oppure il rischio richiede una decisione umana. In questi casi una risposta fluida non è un servizio: nasconde l'incertezza e può far sembrare approvata un'informazione che non lo è.

La soluzione non è aggiungere al prompt se non sai, dì che non sai. Serve una policy che distingua quattro esiti: risposta completa, risposta parziale, astensione ed escalation. Ogni esito deve avere condizioni osservabili, un messaggio utile per l'utente e una ricevuta per chi gestisce il servizio.

Parti dai limiti del servizio

Prima di parlare di confidenza, definisci il perimetro:

• quali domande il servizio è autorizzato a trattare

• quali fonti sono ammesse e chi ne è responsabile

• per quanto tempo un contenuto resta utilizzabile

• quali decisioni richiedono approvazione o identità verificata

• quali categorie di dati non devono entrare nella conversazione

• quale canale umano esiste e in quali orari

La raccolta dei requisiti per un chatbot aziendale deve quindi includere i casi che il sistema rifiuterà. Un catalogo di risposte desiderate senza confini produce un assistente che tenta di completare qualsiasi domanda.

NIST AI RMF invita a documentare limiti di conoscenza e supervisione e a verificare il comportamento oltre quei limiti. Il fallimento sicuro non coincide con il silenzio: significa evitare un'azione o un'affermazione non sostenibile e offrire un percorso proporzionato.

Distingui i motivi di astensione

Non ho informazioni è troppo generico. Classifica almeno:

Questa distinzione migliora anche l'analisi. Se tutte le astensioni hanno la stessa etichetta, non saprai se correggere le fonti, il routing o l'esperienza utente.

Trasforma la sufficienza in un contratto verificabile

Per ogni domanda valuta cinque dimensioni separate:

1. Copertura: le fonti sostengono tutti gli elementi necessari alla risposta?

2. Freschezza: sono valide per la data, il mercato e la versione applicabili?

3. Conflitti: fonti autorevoli divergono su un punto materiale?

4. Autorità: la fonte e il servizio possono formulare quel tipo di conclusione?

5. Conseguenza: quale danno può derivare da una risposta errata o prematura?

Non comprimere tutto in un solo score. Un valore medio alto può nascondere una fonte scaduta o un conflitto bloccante. Usa regole come:

se autorita = assente -> non rispondere o escalare
se conflitto = materiale -> risposta parziale + escalation
se copertura = insufficiente e rischio = basso -> chiedere un dato o astenersi
se freschezza = non verificabile -> non dichiarare il dato come aggiornato
se tutte le dimensioni richieste sono verdi -> rispondere con fonti pertinenti

Microsoft distingue groundedness, completezza, rilevanza e correttezza nella valutazione RAG. È importante perché una risposta può citare fedelmente un documento e arrivare comunque alla conclusione sbagliata. Il controllo deve esaminare sia il legame con le fonti sia l'adeguatezza della risposta alla domanda.

Definisci quattro esiti, non due

Risposta completa

Copertura, freschezza, autorità e rischio rispettano il contratto. La risposta resta entro le fonti e mostra data o versione quando servono.

Risposta parziale

Una parte è supportata e utile, un'altra no. L'assistente separa chiaramente le due porzioni: Posso confermare X dalla procedura aggiornata al...; non posso determinare Y perché manca....

Astensione

Non esiste una risposta sostenibile o autorizzata. Il messaggio indica il motivo senza esporre log, prompt o policy interne e suggerisce un passo concreto: aggiungere un dato, consultare la fonte ufficiale o cambiare canale.

Escalation

Serve una persona o funzione competente. L'assistente raccoglie soltanto le informazioni necessarie, mostra cosa verrà trasferito e non promette un esito. La progettazione dell'escalation umana deve specificare owner, priorità, orari e fallback.

Scrivi messaggi che aiutano l'utente

Una buona astensione contiene tre elementi:

1. limite: cosa non può essere confermato

2. ragione leggibile: quale informazione o autorità manca

3. percorso: cosa può fare l'utente adesso

Esempio debole: Non posso aiutarti con questa richiesta.

Esempio utile: Non posso confermare il prezzo applicabile perché la fonte disponibile è scaduta. Posso mostrarti le condizioni generali oppure inoltrare la richiesta al team commerciale con il riferimento del prodotto.

Non simulare certezza con formule vaghe come in genere se la domanda richiede una regola aggiornata. Non scaricare sull'utente dettagli tecnici del retrieval. La spiegazione deve riguardare il limite del servizio, non la sua implementazione.

Conserva una ricevuta minima

Registra senza duplicare dati sensibili:

case_id
policy_version
question_class
evidence_ids
freshness_result
conflict_result
authority_result
outcome
reason_code
escalation_reference
review_label

Il motivo leggibile all'utente e il reason_code operativo non devono coincidere. Il primo spiega con linguaggio naturale; il secondo permette di misurare e correggere il servizio.

Usa la checklist per verificare gli output AI sui casi in cui una risposta è stata prodotta. Per le astensioni serve invece una valutazione dedicata: il sistema avrebbe dovuto parlare o fermarsi?

Prova l'astensione con casi difficili

Costruisci un set che contenga coppie vicine:

• domanda coperta e variante con un dettaglio non presente

• procedura valida e copia scaduta

• due fonti coerenti e due fonti in conflitto

• richiesta informativa e richiesta di approvazione

• utente autenticato e identità non verificata

• caso a basso rischio e caso con conseguenza elevata

Per ogni caso stabilisci prima l'esito atteso e il motivo. Misura:

• falsi permessi: l'assistente risponde quando dovrebbe fermarsi

• falsi rifiuti: si astiene quando l'evidenza è sufficiente

• risposte parziali ben delimitate

• escalation instradate al ruolo corretto

• ragioni comprensibili all'utente

• stabilità tra formulazioni equivalenti

Il profilo NIST per la GenAI tratta la confabulazione come rischio da gestire. Un test utile non cerca soltanto affermazioni inventate: cerca anche conclusioni non autorizzate, omissioni che cambiano il significato e risposte corrette ma riferite alla versione sbagliata.

Esempio fittizio

Un assistente interno risponde su trasferte. Un dipendente chiede il massimale per una città. Il retrieval trova una policy scaduta e una comunicazione più recente che annuncia un aggiornamento senza indicare il nuovo importo.

La copertura è insufficiente, la freschezza della cifra è rossa e l'autorità dell'assistente non include eccezioni. L'esito corretto non è scegliere il documento più recente né ripetere l'importo vecchio. L'assistente spiega che il massimale non è verificabile, collega la policy generale ancora valida e apre un'escalation al travel owner con città e data. La risposta diventa utile senza trasformare un vuoto informativo in una regola.

Think, Build, Enable applicato all'astensione

Think: definisci perimetro, fonti autorizzate, dimensioni di sufficienza, rischi ed esiti.

Build: implementa controlli, reason code, risposte parziali, escalation e ricevute.

Enable: assegna knowledge owner, crea casi difficili, rivedi falsi permessi e falsi rifiuti e aggiorna la policy per versione.

Porta casi, fonti e policy di escalation a MAIKER HUB per progettare chatbot e assistenti AI. Un buon assistente non risponde sempre: rende affidabile anche il momento in cui deve fermarsi.