Quando un'AI può dare un verdetto netto (e a quali condizioni)

Risposta diretta: un sistema AI può permettersi un verdetto netto solo quando quel verdetto è ancorato a una citazione puntuale e verificabile — il testo esatto che lo sostiene, indicato all'utente. In tutti gli altri casi deve dichiarare esplicitamente che sta facendo un'inferenza, e separarla dal fatto documentato. Non è una scelta di tono: è una regola strutturale che decide cosa il modello ha il permesso di dire, e va scritta prima di scrivere il codice.
TL;DR
- La domanda difficile in un prodotto AI su temi sensibili non è tecnica: è «quanto può essere assertivo».
- Due risposte sbagliate e simmetriche: il modello che afferma senza ancoraggio, e il modello che non conclude mai niente («potrebbe essere, dipende, consulti un esperto»).
- La regola che funziona: verdetto netto ammesso solo con citazione puntuale; tutto il resto viene etichettato come inferenza.
- Serve una separazione esplicita e visibile fra fatto documentato e inferenza del sistema — nella risposta, non nella documentazione.
- Questo pattern non è nuovo: è lo stesso che si usa nei knowledge graph per distinguere archi autoritativi da archi generati, ed è riusabile pari pari.
Il problema, in astratto
Immagina un sistema che risponde su norme e dati pubblici. Un utente gli chiede se un certo soggetto rientri o meno in una fattispecie prevista da una norma costituzionale. La risposta corretta esiste, è argomentabile, e ha conseguenze: se il sistema dice «sì», sta affermando qualcosa di pesante su un soggetto reale; se dice «non posso saperlo», sta rendendo inutile l'intero prodotto proprio nel momento in cui serviva.
Questa è la situazione. Ed è una situazione di design, non di prompt engineering.
Le due risposte sbagliate
Il modello che afferma senza ancoraggio. È il più pericoloso, perché è anche il più convincente. Produce una conclusione netta, in buon italiano, con un tono di autorevolezza che l'utente non ha strumenti per verificare. Quando ha ragione è utile; quando ha torto è indistinguibile da quando ha ragione. È esattamente il fallimento che i knowledge graph dovrebbero prevenire, e che invece si ripresenta quando si confonde la vista con l'asset.
Il modello che non conclude mai. È il fallimento per eccesso di prudenza, e viene quasi sempre scambiato per responsabilità. «Si tratta di una questione complessa che dipende da molti fattori; si consiglia di consultare un professionista.» Tecnicamente ineccepibile, praticamente inutile. Un prodotto che non conclude mai niente non ha un problema di sicurezza: ha un problema di esistenza.
Il punto è che questi due fallimenti non si risolvono a vicenda. Stringere le maglie contro il primo produce il secondo. Serve una terza cosa.
La regola: verdetto solo con citazione
La regola che ho adottato, e che ha retto:
Il sistema può dare un verdetto netto se e solo se indica il testo esatto che lo sostiene. Senza citazione puntuale, nessun verdetto.
Il trucco è che questa regola non limita il modello per argomento — non c'è una lista di temi vietati, che sarebbe fragile e arbitraria — ma per forma della prova. Il modello può essere durissimo su un tema esplosivo, purché stia leggendo ad alta voce un testo che l'utente può andare a verificare. E non può essere assertivo nemmeno su un tema innocuo, se sta ragionando per conto suo.
Questo sposta il rischio dove è gestibile: dall'opinione del modello alla verificabilità della fonte.
La seconda regola: fatto e inferenza, separati e visibili
La citazione da sola non basta, perché la maggior parte delle risposte utili è composta: un pezzo documentato più un passaggio logico. Quindi la risposta va strutturata in due blocchi dichiarati:
| Blocco | Cosa contiene | Come si presenta |
|---|---|---|
| Fatto documentato | Ciò che risulta da fonti verificabili: testi, atti, statuti, precedenti, dati pubblici | Con la citazione puntuale accanto |
| Inferenza del sistema | Il collegamento logico fra i fatti, la conclusione, la valutazione | Etichettata come tale, con il grado di confidenza |
La separazione deve essere nella risposta che l'utente legge, non in una nota metodologica che nessuno apre. Se l'utente deve fare fatica per capire dove finisce il documento e comincia il modello, la separazione non esiste.
Il pattern era già lì (e questa è la parte interessante)
La cosa che mi ha colpito è che non ho inventato niente. Lo stesso sistema usava già questa distinzione altrove, per un problema che non c'entra niente: nel knowledge graph, gli archi fra norme sono di due tipi — archi autoritativi, derivati da riferimenti espliciti nei testi, e archi generati, proposti dal modello e marcati come tali con un grado di confidenza.
È la stessa identica idea: distinguere ciò che è documentato da ciò che è dedotto, e renderlo visibile a chi consuma. Era stata progettata per un problema di qualità del dato. Si è rivelata la risposta esatta a un problema di responsabilità editoriale e legale.
Vale la pena tenerselo a mente come euristica generale: quando ti trovi davanti a una scelta di design difficile su un prodotto AI, guarda se il sistema ha già risolto la stessa forma di problema altrove. Molto spesso il pattern buono è già dentro, applicato a un dominio diverso, e riusarlo costa una frazione di quello che costa inventarne uno nuovo — oltre a rendere il sistema più coerente con se stesso.
Perché questo è un problema di prodotto, non di prompt
La tentazione è risolverlo nel prompt di sistema: «sii prudente», «non fare affermazioni su persone». Non funziona, per due motivi.
Primo: le istruzioni di tono sono negoziabili dal contesto. Un input abbastanza insistente o abbastanza ambiguo le erode. Una regola che dice «senza citazione niente verdetto» è verificabile a valle: puoi controllare programmaticamente se la citazione c'è.
Secondo: il prompt non è ispezionabile dall'utente. La separazione fatto/inferenza deve essere una proprietà osservabile dell'output, perché è quella che permette a chi legge di fare il proprio controllo. Un prodotto che chiede fiducia invece di darne i mezzi ha spostato il problema, non risolto.
E c'è un punto di conformità che vale la pena esplicitare: rendere visibile quando una conclusione è generata dal modello non è solo buona pratica editoriale. È la direzione in cui vanno gli obblighi di trasparenza sui sistemi AI — la stessa logica per cui un chatbot deve dichiarare di essere un chatbot. Un sistema che etichetta le proprie inferenze è già allineato di suo.
FAQ
Non è più sicuro impedire al modello di concludere su temi sensibili?
No: è la forma più comune di fallimento mascherata da prudenza. Un sistema che non conclude mai non è sicuro, è inutile — e gli utenti che avevano una domanda legittima andranno a cercare la risposta da una fonte meno rigorosa. La sicurezza sta nell'ancoraggio, non nel silenzio.
Come si verifica che una risposta sia davvero ancorata?
Rendendolo un controllo programmatico e non una speranza: se la risposta contiene un verdetto ma non contiene un riferimento puntuale a un testo recuperato, la risposta non esce così com'è. È un vincolo che si può testare come qualsiasi altra regola di business.
Che differenza c'è fra questa regola e una semplice richiesta di citare le fonti?
«Cita le fonti» è un'istruzione di stile e viene applicata in modo irregolare. «Nessun verdetto senza citazione puntuale» è un vincolo strutturale sulla forma della risposta: lega il grado di assertività alla presenza di una prova verificabile, e rende osservabile la differenza fra ciò che il sistema ha letto e ciò che ha dedotto.
Questo approccio vale solo in ambito legale?
No. Vale ovunque una conclusione errata abbia conseguenze su qualcuno: sanità, finanza, compliance, valutazioni su persone o aziende. La forma del problema è sempre la stessa — un modello che collega fatti e produce un giudizio — e la separazione fra documentato e dedotto è sempre la leva giusta.
Se stai costruendo un prodotto AI che tocca temi dove sbagliare ha conseguenze, e devi decidere quanto può spingersi il modello, parliamone. È una decisione di architettura, e conviene prenderla prima di scrivere il codice — non dopo la prima risposta imbarazzante.
Articoli correlati
- Appalti PNRR: cinque sistemi pubblici che non si parlanoPer sapere chi ha vinto un appalto PNRR servono almeno cinque banche dati pubbliche diverse, nessuna delle quali è pensata per essere interrogata insieme alle altre. Il registro tecnico, fonte per fonte, di chi ha provato a farlo davvero.
- Il bug peggiore non rompe la funzione: rompe la vista26 strumenti collegati e funzionanti in produzione, la dashboard ne mostrava zero. Il bug era lì da mesi anche per un altro prodotto, e nessuno l'aveva visto perché chi poteva notarlo aveva i permessi di amministratore.
- Sapeva 22.000 sentenze, ma non un numero di attoUn sistema con la giurisprudenza costituzionale dal 1956 non riusciva a trovare un disegno di legge cercato per numero. Nessuno l'aveva mai testato: sembrava troppo ovvio per essere rotto.