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

13/09/20267 min read
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.

AILegal TechComplianceBehind the scenes

Scritto da Giulio Garofalo