Ho cercato di far intercettare a un LLM i propri errori fiscali. Non può, e si è rivelato essere l'intero business.

La posizione era grammaticalmente perfetta. Quello era il problema.

Ricordo ancora la prima posizione che mi ha fatto fermare e posare il caffè. Un'IA aveva redatto una riga sulla nuova deduzione degli interessi sui prestiti auto OBBBA, e diceva: «la nuova deduzione degli interessi sui prestiti auto OBBBA è una deduzione sopra la linea che riduce l'AGI del cliente.» La frase era limpida. Era sicura di sé. Era formattata come ogni posizione difendibile che avessi mai letto. Ed era sbagliata nel modo esatto che costa a una persona reale soldi reali.

La deduzione degli interessi sul prestito per veicoli passeggeri qualificati (QPVLI) è una deduzione sotto la linea ai sensi del §63(b)(7). Non riduce il reddito lordo rettificato. Collocarla sopra la linea non è un errore di ortografia che si corregge rileggendo. Sposta silenziosamente l'AGI, e l'AGI è il numero su cui si basano metà delle voci della dichiarazione. Ciò che mi ha sorpreso non è stato che un modello sbagliasse leggermente una norma. È stato quanto bene sembrava la risposta sbagliata.

Una citazione allucinata è facile da individuare. Una classificazione errata espressa con sicurezza, scritta in un inglese fiscale perfetto, è quella che finisce depositata.

È stato il momento in cui il vero problema mi è apparso chiaro. Il settore ha trascorso tre anni ad automatizzare la redazione del lavoro fiscale, e ha fatto un lavoro davvero buono. Thomson Reuters prepara automaticamente i 1040. CCH Axcess redige insight consulenziali in migliaia di studi. Blue J risponde a domande di ricerca in linguaggio naturale. La preparazione sta venendo risolta. Ma il passo dopo la preparazione, quello in cui qualcuno deve decidere se la posizione è davvero difendibile ai sensi della norma, è stato affidato allo stesso modello probabilistico che l'aveva redatta. E ai sensi dell'IRC §6662, la sanzione del 20% per inesattezza ricade sulla persona che ha firmato la dichiarazione, non sull'algoritmo che l'ha scritta.

Ho passato una settimana a cercare di far valutare al modello i propri compiti.

Il mio primo istinto è stato quello ovvio, e voglio essere sincero: l'ho inseguito più a lungo di quanto avrei dovuto. Se il modello può redigere la posizione, di certo un prompt abbastanza buono può fargliela controllare. Così ci ho provato. Gli ho dato la norma. Gli ho dato la regola QPVLI spiegata per intero. Gli ho chiesto di verificare il proprio output e di segnalare qualsiasi cosa che collocasse una deduzione sulla riga sbagliata.

Ne ha intercettate alcune. Altre le ha mancate. E gli errori erano quelli spaventosi, perché quando sbagliava nella verifica sbagliava con la stessa fluida sicurezza con cui aveva redatto. L'autocontrollo passava dagli stessi pesi che avevano prodotto l'errore in primo luogo. Chiedere a un modello di controllare se stesso è chiedere alla cosa che ha fatto l'errore di essere anche la cosa che se ne accorge, usando lo stesso ragionamento che l'ha generato.

Ricordo di averlo spiegato a un collega e di avermi sentito dirlo ad alta voce: «non possiamo fidarci di un LLM che sorvegli un LLM.» Quella frase è il momento in cui il disegno mi si è ribaltato. Avevo cercato di rendere il modello più accurato. La vera risposta era smettere del tutto di fidarmi del modello come giudice.

Non potete rendere deterministico un sistema probabilistico chiedendoglielo gentilmente. Spostate il verdetto fuori da esso.

La distinzione che ho messo troppo tempo a interiorizzare è che redazione e verifica non sono lo stesso compito reso più facile o più difficile. Sono problemi diversi. La redazione premia fluenza, copertura e plausibilità, che è esattamente ciò per cui è costruito un modello linguistico. La verifica premia l'essere dimostrabilmente nel giusto su una regola specifica, e poter mostrare il proprio lavoro a un esaminatore che non era nella stanza. Sono temperamenti opposti. Ho smesso di cercare di far fare entrambe le cose a un solo sistema.

Cosa significa davvero «l'agente consiglia, il codice decide»?

Voglio essere preciso sull'architettura a cui sono arrivato, perché la frase può sembrare marketing finché non vedi dove viene tracciata la linea. In StatuteGuard, la demo che ho costruito, il modello linguistico fa esattamente un solo lavoro: legge linguaggio fiscale disordinato in linguaggio naturale e propone un'asserzione strutturata e tipizzata. Quello è l'unico passo neurale. È genuinamente bravo in questo, e quando non è sicuro si astiene e la posizione viene escalata a un umano invece di ricevere un verdetto indovinato.

Tutto ciò che viene dopo è codice. Il verdetto è deciso da un motore di policy deterministico, OPA/Rego reale con un gemello pure-Python identico, che esegue regole che ho scritto rispetto alla legge primaria. Estrazione neurale, verifica simbolica. Il modello consiglia. Il codice decide. E la differenza non è accademica, perché il codice non può essere convinto a cambiare risposta da un paragrafo ben scritto.

La parte a cui non mi aspettavo di tenere quanto ci tengo è la leggibilità. Le policy non sono una black box di cui vi chiedo di fidarvi. Sono tabelle decisionali e codice sorgente Rego che potete aprire e confrontare voi stessi con la norma.

Quello screenshot è l'intera tesi in un solo pannello. Un Head of Tax dovrebbe poter sedersi con il partner di compliance, aprire la regola e confermarla rispetto al §30D prima di fidarsi di un singolo verdetto. Quando la logica è un paragrafo di ragionamento del modello, non potete farlo. Quando è una regola che potete leggere, potete.

Quindi cosa succede quando il codice dice no?

La prima volta che ho fatto passare quella posizione sul prestito auto OBBBA attraverso il gate finito, ho davvero sorriso. Il modello aveva redatto l'asserzione «sopra la linea, riduce l'AGI» esattamente come prima. Ma questa volta il motore deterministico ha guardato l'asserzione estratta, l'ha confrontata con la regola §63(b)(7) codificata e ha restituito un verdetto netto: BLOCK. Non depositare.

Ciò che trovo persuasivo in questa vista, e che spero un lettore fiscale trovi persuasivo, è la cascata. Il motore non si limita a dire «riga sbagliata.» Vi mostra i cinque punti a valle che una falsa riduzione dell'AGI corromperebbe: il reddito lordo rettificato stesso, l'imposta sul reddito statale agganciata all'AGI, il sovrappremio Medicare IRMAA, la soglia del 7,5% per la deduzione delle spese mediche e il rimborso dei prestiti studenteschi basato sul reddito. Una deduzione classificata male non è un solo errore. È un piccolo raggio d'esplosione, e il pannello rende quel raggio visibile.

Poi anima la ragione, che è il pezzo a cui sono più legato. Percorre la catena di citazioni attraverso il grafo di rinvii dell'IRC, nodo per nodo, così che il «no» non sia mai una nuda asserzione.

Ecco il dettaglio a cui continuo a tornare, perché è quello che dimostra che non è un problema giocattolo. Secondo il README della demo stessa, l'etichetta errata «sopra la linea» non è qualcosa che ho inventato per fabbricarmi un villain. È un errore di consenso documentato che le guide mainstream di preparazione fiscale, incluso il sito di H&R Block, hanno pubblicato. Una risposta sbagliata plausibile, ben scritta e ampiamente ripetuta è esattamente la modalità di fallimento per cui serve un gate deterministico. Che la folla sia sicura di sé non fa spostare la deduzione sull'AGI. Lo decide la norma, e ora lo decide anche il codice.

L'errore fiscale più pericoloso non è quello che sembra sbagliato. È quello che sembra giusto, suona giusto e compare nelle guide di tre fornitori.

Se volete soffermarvi su qualcosa di tutto questo, la demo in esecuzione è su veriprajna.com/it/demos/statuteguard-verifica-le-posizioni-fiscali-redatte-dall-ai. Potete incollare la vostra posizione e guardare il gate decidere.

La funzione che ho quasi sbagliato: sapere quando dire «non lo so»

Devo ammettere l'errore che ho quasi incorporato, perché è quello che ogni ingegnere che costruisce uno strumento di verifica vuole fare. Il mio istinto iniziale era far rispondere la macchina a tutto. La copertura sembrava l'obiettivo. Uno strumento che restituisce un verdetto su ogni posizione sembra più finito di uno strumento che a volte alza le spalle.

Quell'istinto è sbagliato, e una posizione specifica me lo ha insegnato. Considerate la deduzione per home office del §280A. Se una camera da letto libera è usata «regolarmente ed esclusivamente» come luogo principale di attività è un test di fatti e circostanze. Non c'è una regola limpida da codificare, perché la risposta dipende da come una persona reale usa davvero una stanza reale. Se forzassi il motore deterministico a pronunciarsi, farei esattamente ciò che ho costruito questo per prevenire: fabbricare un verdetto sicuro dove la risposta onesta è «un umano deve guardare questo.»

Quindi il gate ha quattro verdetti, non due. PASS quando la posizione è difendibile. BLOCK quando contraddice la norma codificata. NEEDS-REVIEW quando è una vera area grigia. OUT-OF-COVERAGE quando la disposizione semplicemente non è codificata in questa versione. Gli ultimi due significano entrambi la stessa cosa onesta: decide una persona, non la macchina. Costruire il percorso di escalazione sembrava ammettere un limite. In realtà è la funzione più importante del prodotto, perché un livello di verifica che non dice mai «non lo so» è solo un secondo modello che bluffa con passi in più.

I numeri, e esattamente ciò che non pretendono

Sono cauto con il benchmark, più cauto di quanto un marketer vorrebbe, perché il modo in cui di solito si enunciano questi numeri è una menzogna. Ho fatto girare il motore deterministico contro un golden set etichettato di 42 posizioni preclassificate (14 pulite, 16 errore, 12 da escalare) e ho misurato ciò che il livello fa.

Su quel golden set di 42 casi: copertura deterministica del 71,4%, cioè il motore ha risolto quella quota in PASS o BLOCK da solo e ha escalato correttamente il resto. Precisione del gate al 100%, cioè zero posizioni corrette bloccate per errore. Completezza dell'error-catch al 100% sulle disposizioni codificate. Il 100% delle aree grigie correttamente escalate. Il throughput è corso nell'ordine delle decine di migliaia di posizioni al secondo (circa 58.000 nella run di cui ho fatto lo screenshot, anche se dipende dalla macchina), perché la verifica è infrastruttura, non una chiamata a un modello.

Ora la parte su cui insisto. Quei numeri sono veri su quel golden set, non come garanzia open-world. Non vi dirò che StatuteGuard è «accurato al 100%,» perché quella frase è disonesta nel momento in cui uscite dal set etichettato. Quello che vi dirò è più sottile e, credo, più durevole: poiché il verdetto è codice deterministico, il suo comportamento sulle disposizioni codificate è riproducibile e dimostrabile, non una probabilità che fluttua. Ho anche ricontrollato ognuno dei 42 verdetti contro OPA 1.17.1 e il gemello pure-Python, e corrispondevano esattamente. Quella è l'affermazione dietro cui posso stare. Descrive il livello, non il modello.

«Accuratezza al 100%» è un numero di marketing. «Riproducibile sulle disposizioni codificate, con escalazione onesta ovunque altrove» è un numero da engineering. Preferisco spedire il secondo.

Ed è per questo che non invecchia. Un modello base migliore l'anno prossimo non può comunque dimostrare a un esaminatore quale disposizione normativa ha sostenuto quale posizione. Copertura, precisione del gate e una traccia di audit depositabile sono proprietà del livello di verifica. Non sono un tasso di errore del modello che si riduce man mano che i modelli migliorano.

L'artefatto che non sapevo di stare costruendo finché un esaminatore non me l'ha chiesto

Non mi ero proposto di costruire un documento di compliance, ma più persone del tax incontravo, più la conversazione finiva sempre nello stesso posto: «va bene, ha intercettato l'errore, ma cosa consegno all'IRS?» Così ogni verdetto ora scrive un record di due diligence §6662 depositabile, un workpaper stampabile che documenta che la posizione è stata verificata rispetto alla norma prima del deposito. Workpaper sorgente, disposizione, fonte primaria, l'asserzione estratta, la narrativa della determinazione, la catena completa di citazioni. È la prova che è stata effettivamente assunta una posizione di reasonable cause e due care, cosa che conta direttamente ai sensi delle revisioni AICPA SSTS in vigore da gennaio 2024.

C'è un'altra ragione per cui mi importa dove gira, ed è diventata concreta dopo la sentenza Heppner (SDNY, febbraio 2026), che ha sollevato una questione di privilege waiver sul fatto di alimentare una ricerca del cliente in uno strumento di IA pubblico. StatuteGuard gira interamente in locale senza API key per default. Nessuna posizione e nessun dato del cliente lascia il perimetro. Dopo Heppner, un'architettura chiusa, locale e auditabile non è solo un nice-to-have in una review di sicurezza. È giuridicamente rilevante. Non ho progettato la postura local-first per quella sentenza. Ma la sentenza è il motivo per cui ora la metto in primo piano.

Per contestualizzare la posta in gioco, i costi di tax compliance delle imprese USA superano i 126 miliardi di dollari all'anno (ricerca della solution WP1, 2026), e la sanzione IRC §6662 è il 20% del underpayment, con l'esposizione per frode §6663 che arriva al 75%. Quando la redazione è automatizzata e la sanzione è personale, il passo di verifica è quello che dovrebbe tenere sveglio un Head of Tax.

Ciò in cui credo davvero adesso

Ho iniziato pensando di costruire una tax AI migliore, e voglio chiudere dicendo chiaramente che mi sbagliavo su quale fosse il problema. La vostra tax AI non ha un problema di accuratezza. Ha un problema di verifica, e un modello migliore non lo risolverà, perché la sanzione del 20% ricade sulla vostra firma, non sui suoi pesi. Personalizzare e automatizzare la redazione del lavoro fiscale è un progresso reale. E non è la stessa cosa che dimostrare che una posizione è difendibile, e il settore li ha trattati silenziosamente come se lo fossero.

La demo è su veriprajna.com/it/demos/statuteguard-verifica-le-posizioni-fiscali-redatte-dall-ai se volete provare a rompere il gate. Mi piacerebbe davvero che lo faceste.

E se preferite guardare il gate decidere piuttosto che leggermi mentre lo descrivo, ecco l'intera cosa in esecuzione da un capo all'altro.

Quindi ecco la domanda che continuo a fare ai leader del tax, e non ho ancora una risposta comoda. Quando un'IA redige una posizione e voi firmate la dichiarazione, qual è l'artefatto che prova che voi l'avete verificata, piuttosto che fidarvi? Se la risposta onesta è «niente, mi sono fidato del modello,» allora il modello non è il vostro assistente. È il vostro cosignatario, e non può essere convocato all'audit.