L'AI che ha inventato un caso giudiziario — e l'architettura che abbiamo costruito per renderlo impossibile

Ricordo il momento esatto in cui ho smesso di fidarmi del modo in cui la maggior parte delle persone costruisce l'AI legale.

Era tardi, di martedì, e stavo leggendo la trascrizione del processo di Mata v. Avianca. Non un riassunto. Non un thread su un social. L'atto vero e proprio. Un avvocato aveva depositato una memoria che citava Varghese v. China Southern Airlines, Shaboon v. Egyptair e Petersen v. Iran Air — completi di numeri di ruolo, date e massime citate. Abbastanza convincenti da costringere la controparte a cercarli. I casi non esistevano. ChatGPT li aveva inventati. E quando l'avvocato è tornato da ChatGPT per una verifica, il modello ha allegramente confermato le proprie invenzioni: «Sì, quei casi esistono davvero e possono essere trovati in autorevoli banche dati giuridiche».

Ho posato la trascrizione e ho pensato: questo non è un problema di prompting. È un problema di architettura. E gran parte del settore dell'AI legale finge il contrario.

Quell'episodio — che si è concluso con una multa di 5.000 dollari, un rimprovero giudiziario e un cratere reputazionale — è diventato il caso di studio fondativo di ciò che il mio team di Veriprajna oggi costruisce: sistemi GraphRAG con citazioni vincolate per l'AI legale. Sistemi in cui l'AI fisicamente non può produrre una citazione di un caso che non corrisponda a una voce verificata in un Knowledge Graph. Non «probabilmente non lo farà». Non può.

Voglio spiegare perché questa distinzione conta, cosa è servito per costruirla e perché credo che l'era di appiccicare un'interfaccia chatbot su un modello di base e chiamarla «AI legale» sia finita.

Perché ChatGPT ha inventato un caso giudiziario?

Questa è la domanda che tutti pongono, e a cui quasi nessuno risponde correttamente.

La spiegazione più comune è «allucinazione» — una parola talmente abusata da aver perso il suo valore diagnostico. Ciò che è realmente accaduto in Mata v. Avianca è più specifico e più grave. Al modello è stato chiesto di trovare precedenti sulla responsabilità delle compagnie aeree per le lesioni ai passeggeri. Non ha cercato in una banca dati. Non ne possiede una. Ha predetto la successiva sequenza di parole statisticamente più probabile.

«Varghese» è un nome plausibile per un attore. «China Southern Airlines» è un convenuto plausibile. Un numero di ruolo come «2017 WL 3245891» segue lo schema sintattico delle citazioni reali. Il modello ha assemblato questi frammenti allo stesso modo in cui assembla una poesia o un'email di marketing — minimizzando qualcosa chiamato perplessità, che è essenzialmente una misura di quanto il modello sia «sorpreso» dal proprio output. Bassa sorpresa significa testo fluente. Il testo fluente non è la stessa cosa del testo vero.

Il modello è addestrato a minimizzare la perplessità — quanto è sorpreso dalla parola successiva. Non è addestrato a ottimizzare la provenienza — se quella parola risalga a qualcosa di reale.

Questa è la tensione di fondo. Gli LLM ottimizzano la coerenza. Il diritto richiede la provenienza. Sono obiettivi fondamentalmente diversi, e nessuna dose di prompt engineering colma il divario. Puoi dire a GPT-4 «Sei un avvocato scrupoloso, cita solo casi reali». Annuirà e obbedirà — fino al momento in cui i suoi dati di addestramento non contengono il caso di cui hai bisogno, momento in cui ne inventerà uno che suona giusto, perché suonare giusto è letteralmente ciò per cui è ottimizzato.

I ricercatori di Stanford lo hanno testato rigorosamente. I chatbot generalisti, anche quelli con accesso a internet o capacità di recupero di base, hanno allucinato tra il 58% e l'82% delle volte su query legali complesse. Non casi limite. Normali quesiti di ricerca giuridica.

La trappola del wrapper

Dopo Mata, ho iniziato a catalogare gli strumenti di AI legale sul mercato. La maggior parte di essi era ciò che il settore chiama educatamente «wrapper» — sottili interfacce utente sovrapposte all'API di OpenAI o Anthropic. Un prompt di sistema che dice «Sei un utile assistente legale». Forse una funzione di caricamento PDF. Forse un font più gradevole.

Ho avuto una chiamata con un potenziale cliente — il general counsel di uno studio di medie dimensioni — che mi ha raccontato di aver valutato uno di questi strumenti. «È veloce», ha detto. «Ma la settimana scorsa ha citato un'opinione dissenziente come se fosse la massima di maggioranza. Il mio collaboratore l'ha quasi depositata». Ha fatto una pausa. «La parte spaventosa è che il caso era reale. Era solo la massima a essere... sbagliata».

Ecco la cosa delle allucinazioni legali che mi tiene sveglio la notte. Mata è stato eclatante perché i casi erano interamente inventati. Ma gli errori più sottili — caso reale, massima sbagliata; norma valida, ma successivamente abrogata; precedente vincolante ma della giurisdizione sbagliata — sono più difficili da cogliere e probabilmente più pericolosi. Un caso falso viene segnalato al primo passaggio di verifica. Un caso reale citato a sostegno di una tesi che non regge? Quello può sopravvivere a più cicli di revisione.

L'approccio wrapper non può risolvere questo problema perché non possiede lo strato dei dati. Non sa quali casi esistano. Non sa quali siano stati ribaltati. Non capisce che una decisione del Second Circuit non vincola una corte del Ninth Circuit. È una raffinata casella di testo collegata a un motore probabilistico.

E l'economia è spietata. L'analisi del mercato dei wrapper mostra che, mentre alcuni raggiungono rapidamente il fatturato, la stragrande maggioranza fallisce perché priva di qualsiasi tecnologia difendibile. Man mano che i modelli di base migliorano, ogni funzione che rendeva utile il wrapper — riassunto, redazione, domande e risposte — viene assorbita nel modello di base. Stai costruendo su terreno in affitto, e il padrone di casa è OpenAI.

Cosa succede quando dai a un'AI una mappa del diritto?

Ecco dove inizia l'ossessione del mio team.

La correzione standard per l'allucinazione è la Retrieval-Augmented Generation — RAG. Invece di affidarti alla memoria del modello, recuperi documenti rilevanti da una banca dati e li fornisci come contesto. È un vero miglioramento. Ma per il diritto non basta, e voglio spiegare perché con un esempio specifico che ci ha fatto impazzire per settimane.

Stavamo testando una pipeline standard di vector RAG su una domanda relativa al fatto se una specifica normativa ambientale del 1990 fosse ancora applicabile dopo una decisione della Corte Suprema del 2023. Il vector RAG ha fatto ciò che sa fare: ha trovato frammenti di testo semanticamente simili alla query. Ha restituito la normativa. Ha restituito l'opinione della Corte Suprema. Ha restituito un articolo di dottrina che discuteva entrambi.

L'LLM li ha ricuciti insieme in una risposta sicura e ben scritta che era completamente sbagliata. Ha trattato l'articolo di dottrina — un commento accademico persuasivo ma non vincolante — come se avesse lo stesso peso della massima della Corte Suprema. Peggio ancora, non ha colto che la normativa era stata di fatto invalidata, perché la catena di autorità che collegava la normativa alla decisione invalidante passava attraverso un caso d'appello intermedio che la ricerca vettoriale non aveva recuperato. Il collegamento non era semantico. Era strutturale.

Ricordo il mio ingegnere capo, a metà del debug di questo problema, che si è girato verso di me e ha detto: «Il problema non è il recupero. Il problema è che i vettori non capiscono le relazioni».

Aveva ragione. Ed è questa l'intuizione dietro GraphRAG — Graph-based Retrieval-Augmented Generation.

Invece di memorizzare i documenti giuridici come punti isolati nello spazio vettoriale, li mappiamo in un Knowledge Graph: una rete in cui ogni norma, caso, regolamento e dottrina giuridica è un nodo, e le relazioni tra di essi — cita, ribalta, distingue, interpreta, conferma — sono archi espliciti ed etichettati. Ho scritto dell'architettura completa nella versione interattiva della nostra ricerca.

Il vector RAG chiede: «Trova testo che assomigli a questa query». Il GraphRAG chiede: «Trova la norma, attraversa l'arco 'interpreta' per trovare la giurisprudenza, poi attraversa l'arco 'ribalta' per assicurarti che sia ancora valida».

Non è una differenza sottile. È la differenza tra cercare in una biblioteca a intuito e cercarvi contemporaneamente attraverso lo schedario, l'indice delle citazioni e il rapporto Shepard's.

Come si impedisce a un'AI di inventare una citazione?

Questa è la parte che ci ha richiesto più tempo per essere messa a punto, ed è quella di cui sono più orgoglioso.

Avere un Knowledge Graph è necessario ma non sufficiente. Il grafo ti dà la struttura. Ma l'LLM continua a generare testo token per token, e in qualsiasi momento potrebbe deviare dal grafo e iniziare a inventare. Avevamo bisogno di un meccanismo che non si limitasse a incoraggiare il modello a citare casi reali — che gli impedisca fisicamente di citarne di falsi.

Lo chiamiamo Graph-Constrained Decoding, e il meccanismo centrale è qualcosa chiamato KG-Trie.

Ecco come funziona, in parole semplici. Prendiamo ogni entità valida nel nostro Knowledge Graph — ogni nome di caso, ogni citazione di repertorio, ogni numero di ruolo — e costruiamo un albero dei prefissi (un Trie) a partire da quegli identificatori. Quando l'LLM sta generando testo e raggiunge un punto in cui sta per produrre una citazione, il meccanismo di vincolo si attiva. Verifica: quali sono i token successivi validi secondo il Trie?

Se il modello ha generato «Mata v. A» — il Trie consente i token che completano nomi di casi validi che iniziano con quella stringa. «Avianca» è valido. A tutto il resto viene assegnata una probabilità pari a meno infinito. Bloccato.

Se il modello prova a generare «Varghese v. Chi» — il Trie non trova alcuna continuazione valida. La generazione viene interrotta. Il modello è costretto a tornare indietro e a trovare una citazione reale oppure a produrre qualcosa come «Nessun precedente trovato».

L'AI non può inventarsi un caso perché fisicamente non può produrre la sequenza di token per un caso che non è nella banca dati verificata.

Questa è una garanzia strutturale, non probabilistica. Non stiamo dicendo «il modello ha il 95% di probabilità in meno di allucinare». Stiamo dicendo che il percorso della falsificazione è chiuso. La sequenza di token per una citazione falsa letteralmente non può essere prodotta.

Ora, voglio essere preciso su ciò che questo fa e non fa. Impedisce la falsificazione — inventare un caso che non esiste. Non impedisce l'errata interpretazione — citare un caso reale traendone la conclusione sbagliata. Quello è un errore di ragionamento, e richiede comunque la revisione umana. Ma eliminare la falsificazione è enorme. Toglie completamente dal tavolo la modalità di fallimento più catastrofica — lo scenario Mata.

C'è stata una notte, all'inizio dello sviluppo, in cui abbiamo eseguito il nostro primo test end-to-end. Abbiamo sottoposto al sistema la query esatta che aveva prodotto le citazioni false in Mata. Il sistema vincolato ha provato a generare «Varghese», ha sbattuto contro il muro del Trie, è tornato indietro e ha restituito un caso reale con una catena di citazioni valida. Il mio ingegnere ha inviato uno screenshot nella nostra chat di gruppo all'1:47 del mattino. Nessuno ha risposto con parole. Solo una fila di emoji di fuoco.

Perché i wrapper non possono farlo?

Me lo chiedono continuamente, e la risposta è architetturale, non commerciale.

Il Graph-Constrained Decoding richiede di manipolare le probabilità dei token del modello — i suoi logit — in tempo reale durante la generazione. Serve accesso al motore di inferenza a livello di decodifica. Le API commerciali standard come GPT-4 non lo espongono. Puoi inviare un prompt e ottenere una risposta. Non puoi intercettare il processo di generazione a metà token e iniettare vincoli.

Ecco perché costruiamo su modelli open-weights — Llama, Mistral — o eseguiamo il deploy tramite endpoint enterprise che consentono cicli di decodifica personalizzati. Ospitiamo il modello. Controlliamo la pipeline di inferenza. Iniettiamo i vincoli KG-Trie direttamente nella distribuzione di probabilità di ogni token man mano che viene generato.

Un wrapper, per definizione, non può farlo. Sta chiamando l'API di qualcun altro. È un passeggero, non il pilota.

La parte più difficile di cui nessuno parla

Costruire il meccanismo di vincolo è stato intellettualmente appagante. Costruire il Knowledge Graph al di sotto è stata una faticaccia.

Il testo giuridico è disordinato in modi che farebbero piangere un data engineer. Un singolo caso potrebbe essere richiamato come «Mata v. Avianca», «Mata», «678 F. Supp. 3d 443», «il caso Avianca», o semplicemente «Id.» — un'abbreviazione di due lettere che significa «il caso che ho appena menzionato». Tutti questi devono risolversi in un unico nodo canonico nel grafo. Sbagliane uno e ti ritrovi con una lacuna nella rete delle citazioni.

Abbiamo passato mesi a costruire pipeline di Entity Resolution che gestiscono la deduplicazione («Smith v. Jones, 123 F.3d 456» e «Smith, 123 F.3d at 456» sono lo stesso caso), la disambiguazione («Smith v. Jones (1995)» rispetto a «Smith v. Jones (2002)» — casi diversi, stesso nome), e il particolare inferno di risolvere i riferimenti «Id.» usando il parsing del contesto a finestra scorrevole.

E poi c'è il trattamento negativo — il sistema delle «bandiere rosse». Un Knowledge Graph giuridico che tratta i casi ribaltati come autorità valida è peggio che inutile. Ingeriamo i segnali dei citator — espressioni come «ribaltato», «abrogato», «superato» — e li codifichiamo come archi bloccanti nel grafo. Quando il sistema attraversa un percorso e incontra un arco OVERRULES, quel percorso viene invalidato come autorità vincolante. Se qualcuno chiede di Roe v. Wade sui diritti riproduttivi, il grafo fa emergere immediatamente l'arco OVERRULES da Dobbs v. Jackson. Una ricerca vettoriale potrebbe comunque citare con entusiasmo Roe perché la mole di testo storico a suo sostegno domina i punteggi di somiglianza.

Per l'analisi tecnica completa dello schema del grafo, della pipeline di entity resolution e dell'architettura dei vincoli, vedi il nostro paper di ricerca.

Cosa significa davvero tutto questo per uno studio legale?

Ho avuto una conversazione con un managing partner che l'ha detto senza mezzi termini: «Non m'importa dei Knowledge Graph. M'importa se i miei collaboratori mi metteranno in imbarazzo davanti a un giudice».

Giusto. Allora lasciate che traduca.

Il costo di Mata v. Avianca non è stato di 5.000 dollari. È stato l'umiliazione pubblica, l'obbligo di notifica al cliente, l'esposizione alla responsabilità professionale e il segnale, a ogni potenziale cliente, che questo studio non verifica il proprio lavoro. Per un grande studio, un solo atto allucinato è un evento reputazionale esistenziale.

Il GraphRAG con citazioni vincolate funziona come una polizza assicurativa contro la falsificazione. L'approccio wrapper offre un basso costo iniziale e una responsabilità illimitata. Il nostro approccio richiede un investimento reale nello strato dei dati e nell'architettura dei vincoli, ma riduce a zero il rischio di falsificazione delle citazioni.

C'è anche un argomento di efficienza meno ovvio. In questo momento, se uno studio usa l'AI per la ricerca, un collaboratore deve verificare ogni singola citazione. Quel passaggio di verifica spesso richiede più tempo della ricerca stessa, il che vanifica lo scopo. I benchmark del GraphRAG mostrano un miglioramento del 30-35% rispetto al RAG standard nei compiti di ragionamento multi-hop — quel tipo di ricerca complessa, del collegare i puntini, che conta davvero nel contenzioso. Ancora più importante, poiché le citazioni sono strutturalmente garantite come valide, il ruolo umano passa da «verificatore di fatti» a «revisore della strategia». Non stai passando tre ore a confermare che i casi esistano. Stai spendendo quel tempo per capire se l'argomentazione sia persuasiva.

Quando ogni citazione è verificata strutturalmente, il lavoro dell'avvocato passa dal fact-checking dell'AI al pensare alla strategia. È lì che sta la vera leva.

E c'è una dimensione di trasparenza che conta per la conformità. Un wrapper non può spiegare perché ha scelto un caso. Un sistema GraphRAG può mostrare l'esatto percorso di attraversamento: «Ho selezionato il Caso A perché interpreta la Norma B ed è stato confermato dalla Corte C, che è vincolante nella tua giurisdizione». Quella pista di controllo non è solo un vezzo — sta diventando un'aspettativa normativa.

Dove porta tutto questo?

Il settore sta passando dai chatbot agli agenti — sistemi di AI che non si limitano a rispondere a domande, ma pianificano ed eseguono compiti a più fasi. A un agente legale a cui viene chiesto di redigere un'istanza di rigetto serve ricercare lo standard applicabile, trovare la giurisprudenza a sostegno, verificare che i casi siano diritto valido, controllare i requisiti procedurali e assemblare l'argomentazione.

Un agente che gira su una ricerca vettoriale non ha mappa. Ha un mucchio di documenti e una buona ipotesi. Un agente che gira su un Knowledge Graph ha una struttura esplicita che può attraversare: norma → casi interpretativi → regole procedurali → requisiti specifici della giurisdizione. Il grafo è lo strato di pianificazione dell'agente.

Ecco perché credo che l'investimento nell'infrastruttura a grafo oggi paghi rendimenti composti in seguito. I wrapper lasciano dietro di sé log di chat. I Knowledge Graph lasciano dietro di sé una mappa strutturata, in crescita e sempre più preziosa dell'autorità giuridica, che diventa più utile a ogni caso aggiunto, a ogni relazione codificata, a ogni segnale di trattamento negativo ingerito.

L'obiezione onesta

Le persone ribattono su due fronti, e voglio affrontarli entrambi direttamente.

Primo: «Non è solo Westlaw con passaggi in più?». No. Westlaw è un motore di ricerca per esseri umani. Restituisce documenti che un avvocato legge e interpreta. Ciò che costruiamo noi è un'architettura di vincoli per l'AI — un sistema che governa ciò che l'AI può e non può dire. Westlaw aiuta gli avvocati a trovare il diritto. Il GraphRAG impedisce all'AI di inventarlo. Sono complementari, non concorrenti.

Secondo: «Non puoi semplicemente fare il fine-tuning del modello per farlo smettere di allucinare?». Ci abbiamo provato. All'inizio del nostro lavoro, abbiamo sperimentato il fine-tuning su dataset giuridici verificati. Ha ridotto i tassi di allucinazione. Non li ha eliminati. Un modello sottoposto a fine-tuning è pur sempre un motore probabilistico. È un motore probabilistico migliore, ma «migliore» nella citazione legale significa «sbaglia meno spesso», e «sbaglia meno spesso» non è uno standard che alcun tribunale accetterà. L'unico modo per garantire zero falsificazioni è rendere la falsificazione strutturalmente impossibile, il che significa vincolare lo spazio dell'output, non solo migliorare i dati in ingresso.

La fine del «abbastanza buono»

Ecco ciò a cui continuo a tornare. La professione legale è costruita su una premessa semplice: quando citi un'autorità, quell'autorità deve essere reale. Non probabilmente reale. Non di solito reale. Reale.

Per due anni dopo Mata, i tribunali hanno inasprito le sanzioni, emesso ordinanze permanenti sulla divulgazione dell'uso dell'AI e chiarito che «l'ha fatto l'AI» non è una difesa. La professione sta tracciando una linea: se usi l'AI, il suo output deve essere verificato. E se verificare l'output richiede più tempo che svolgere il lavoro manualmente, l'AI non è uno strumento — è una responsabilità.

L'era dei wrapper ha risolto il problema sbagliato. Ha reso la ricerca giuridica più veloce. Doveva rendere la ricerca giuridica affidabile. Velocità senza fiducia è solo malpractice efficiente.

Ciò che costruiamo in Veriprajna non è un chatbot che per caso conosce un po' di diritto. È un sistema di ragionamento vincolato in cui ogni citazione è un attraversamento verificato attraverso un Knowledge Graph, ogni relazione è esplicita e verificabile, e il modello generativo è fisicamente impedito dallo sconfinare nella finzione.

La professione che ha inventato il concetto di precedente vincolante merita un'AI che lo rispetti davvero.