Verifica AI della conformità fiscale
StatuteGuard è un livello neutrale rispetto ai fornitori che prova le posizioni fiscali redatte dall'AI rispetto allo statuto codificato, in modo deterministico. Incolla una posizione da qualsiasi piattaforma e restituisce un PASS, BLOCK o NEEDS-REVIEW netto, con una catena di citazioni normative e un verbale di audit IRC §6662 archiviabile. L'agente consiglia, il codice decide.
71.4%
Copertura deterministica
Golden set etichettato di 42 casi
100%
Precisione del gate, 0 falsi blocchi
Golden set etichettato di 42 casi
20%
Penalità di accuratezza IRC §6662
Ricade su chi ha firmato
Una demo eseguibile, non un deployment. Tutte le posizioni sono sintetiche; la logica normativa è fondata sul diritto primario. Non è consulenza fiscale o legale.
Il settore si è lanciato ad automatizzare la redazione. Thomson Reuters "Ready to Review" predispone automaticamente i 1040, CCH Axcess Expert AI redige insight consulenziali in migliaia di studi, e Blue J risponde a domande di ricerca. Ciò che nessuno ha automatizzato è il passo con la penalità più alta: questa posizione è davvero difendibile ai sensi dello statuto?
Il vero modo di fallimento non è la grammatica sbagliata. È la misclassificazione sicura di sé: una posizione plausibile, ben scritta, che mette una detrazione sulla riga sbagliata. Quando un'AI classifica erroneamente una detrazione come above-the-line invece che below-the-line, la penalità correlata all'accuratezza del 20% IRC §6662 si applica a chi ha firmato la dichiarazione, non all'algoritmo che l'ha redatta. La penalità per frode §6663 arriva fino al 75%. La conformità fiscale delle imprese USA costa già più di $126B all'anno, e il tasso di audit IRS sulle grandi società è salito dall'8.8% al 22.6% (ricerca della soluzione WP#1, 2026).
Non puoi fidarti di un LLM per sorvegliare un LLM attraverso gli stessi pesi che hanno prodotto l'errore. Un autocontrollo in-model esegue esattamente il ragionamento che ha misclassificato la posizione in primo luogo. La risposta duratura è una verifica che vive fuori dal modello.
StatuteGuard inverte il modello di fiducia. Un'AI può redigere, ma un motore di policy deterministico decide se la posizione è difendibile. L'unico passo LLM è l'estrazione, che trasforma il linguaggio naturale disordinato in un claim strutturato e tipizzato. Si astiene quando non è sicuro. Tutto ciò che segue è codice che il modello non può sovrascrivere. Lo chiamiamo neuro-symbolic: estrazione neurale, verifica simbolica.
| Fase | Cosa viene eseguito | Chi decide |
|---|---|---|
| Extract | L'LLM legge il memo della posizione e propone un claim tipizzato, riportando la propria confidenza. Sotto la soglia di confidenza fa escalation invece di risolvere. | LLM (solo consultivo) |
| Retrieve | GraphRAG attraversa il grafo della conoscenza dei rinvii incrociati dell'IRC per recuperare le disposizioni in gioco e le loro relazioni tipizzate. | Deterministico |
| Verify | Policy OPA/Rego reali (o un gemello identico in Python puro) verificano il claim rispetto allo statuto codificato. | Deterministico |
| Gate | PASS (difendibile), BLOCK (contraddice lo statuto codificato), NEEDS-REVIEW (zona grigia genuina), o OUT-OF-COVERAGE (non codificato in V1). | Deterministico |
| Audit | Scrive un verbale di due diligence IRC §6662 archiviabile come JSON più un certificato HTML stampabile. | Deterministico |
Poiché il verdetto è codice di policy e non una chiamata al modello, puoi leggere il Rego e confermare che corrisponde allo statuto. Il livello di verifica gira come infrastruttura, misurato a decine di migliaia di posizioni al secondo (circa da 40k a 60k tra le esecuzioni, dipendente da macchina e run), non come un'inferenza del modello per posizione.
Le disposizioni codificate in questa versione: OBBBA QPVLI (§163(h)(4) / §63(b)(7)), §199A QBI, la limitazione sugli interessi passivi d'impresa §163(j), lo scambio like-kind §1031, l'ufficio domestico §280A, il credito per veicoli puliti §30D, e la distinzione AGI §62/§63. Tutto al di fuori di questo insieme restituisce OUT-OF-COVERAGE e viene instradato a un umano. StatuteGuard non pretende di codificare l'IRC per intero.
La demo percorre un BLOCK, un PASS e un'escalation, tutti su posizioni sintetiche. Gli screenshot sotto sono catture reali dell'app in esecuzione.
Una dichiarazione redatta recita: "The new OBBBA car-loan interest deduction is an above-the-line deduction that reduces the client's AGI." È plausibile, ben scritta, e sbagliata. Gli interessi qualificati sul prestito per veicoli passeggeri sono una detrazione below-the-line ai sensi del §63(b)(7); non riducono l'AGI. Secondo il README della demo stessa, le guide mainstream di preparazione fiscale (incluso il sito di H&R Block) l'hanno etichettata erroneamente come above-the-line. StatuteGuard restituisce BLOCK: DO NOT FILE, anima la catena di citazioni §163(h)(1) → §163(h)(4)(A) → §63(b)(7) → §62/§63, e segnala una cascata a valle a 5 vie di ciò che si rompe se presentata come redatta: AGI, imposta statale accoppiata all'AGI, premi Medicare IRMAA, la soglia della detrazione per spese mediche, e il rimborso dei prestiti studenteschi basato sul reddito.
Il passo di estrazione ha richiesto 5.93s; l'ancoraggio deterministico ha reso il verdetto in microsecondi.
Uno scambio like-kind conforme di immobili da investimento restituisce CLEARED: safe to file as drafted, con la propria catena di citazioni a due nodi (§1031(a)(1) e §1031(a)(2)-TCJA). Questa è la disciplina che conta: una posizione corretta non viene mai segnalata per errore. La precisione del gate è 100% con 0 falsi blocchi sul golden set.
Una posizione su ufficio domestico in cui il fascicolo non dimostra l'uso esclusivo per l'attività è un test sui fatti e le circostanze, fuori dalla copertura deterministica. StatuteGuard restituisce NEEDS HUMAN REVIEW anziché bluffare. L'LLM propone un claim verificabile e riporta la confidenza; sotto la soglia, la posizione fa escalation, mai risolta dal modello.
Il visualizzatore Policy Rules mostra la logica normativa deterministica come tabelle decisionali leggibili accanto al codice sorgente OPA/Rego reale. Questo è il punto di un livello di verifica che puoi difendere: confermi che il codice corrisponde allo statuto, invece di fidarti del riassunto di un modello.
Lo stadio di audit produce un foglio di lavoro di due diligence Form SG-6662: la fonte, l'autorità normativa primaria, il claim estratto, la narrativa della determinazione, e la catena completa di citazioni, pronto da stampare o salvare come PDF e conservare nel fascicolo del cliente. Supporta una posizione di reasonable-cause ai sensi del §6662; non è consulenza.
Run Benchmark ripete un golden set etichettato di 42 posizioni (14 pulite, 16 errore, 12 da escalation). Il tabellone riporta 71.4% di copertura deterministica, 100% di precisione del gate con 0 falsi blocchi, 100% di completezza nell'intercettare gli errori, e 100% di escalation corretta delle zone grigie, con ogni verdetto coincidente con la sua etichetta. Questi descrivono il livello di verifica, non un tasso di errore del modello, quindi restano validi al migliorare dei modelli di base. Durante la build i verdetti sono stati ricontrollati rispetto a OPA 1.17.1 e hanno coinciso esattamente con il gemello in Python puro su tutti i 42 casi.
Questi numeri sono misurati su un golden set etichettato fisso di 42 casi delle disposizioni codificate, non una garanzia a mondo aperto.
StatuteGuard non compete con il tuo strumento di redazione né sostituisce una piattaforma di conformità. Si colloca sopra ciò che già usi e controlla l'unica cosa che quelli non possono: se la posizione redatta regge rispetto allo statuto.
| Domanda | AI di redazione (ONESOURCE, CCH Axcess, Blue J, ChatGPT) | Autocontrollo LLM | StatuteGuard |
|---|---|---|---|
| Compito primario | Predisporre e redigere posizioni | Rileggere la propria bozza | Verificare una posizione redatta rispetto allo statuto |
| Chi emette il verdetto | Un modello linguistico | Lo stesso modello, gli stessi pesi | Un motore di policy deterministico (OPA/Rego) |
| Su una zona grigia genuina | Produce prosa sicura di sé | Produce prosa sicura di sé | Fa escalation a un umano (NEEDS-REVIEW / OUT-OF-COVERAGE) |
| Verbale §6662 archiviabile | No | No | Sì, un foglio di lavoro di due diligence stampabile |
| Legge l'output di qualsiasi piattaforma | Legato al proprio prodotto | Legato al proprio modello | Neutrale rispetto ai fornitori per progettazione |
Quegli strumenti redigono e preparano. StatuteGuard verifica. È un livello neutrale rispetto ai fornitori che si colloca sopra la piattaforma che già usi: incolla una posizione da ONESOURCE, CCH Axcess, Blue J, ChatGPT o un modello interno, e restituisce un PASS, BLOCK o NEEDS-REVIEW netto rispetto allo statuto codificato. Non predispone dichiarazioni né sostituisce una piattaforma di conformità; controlla gli errori a livello di posizione che lo strumento di redazione non può vedere.
No, e StatuteGuard non te lo chiede. L'unico passo LLM è l'estrazione, che trasforma il linguaggio disordinato in un claim strutturato. Il verdetto è emesso da un motore di policy deterministico (OPA/Rego reale, o un gemello identico in Python puro), che il modello non può sovrascrivere. Non puoi fidarti di un LLM per sorvegliare un LLM attraverso gli stessi pesi che hanno prodotto l'errore, quindi la decisione vive fuori dal modello, in codice di policy che puoi leggere rispetto allo statuto.
Fa escalation a un umano invece di indovinare. Una genuina questione di fatti e circostanze (un ufficio domestico §280A, per esempio) restituisce NEEDS-REVIEW; una disposizione non codificata in questa versione restituisce OUT-OF-COVERAGE. Entrambe vengono instradate a un revisore piuttosto che a un bluff sicuro di sé. Sul golden set etichettato di 42 casi, le zone grigie hanno ricevuto escalation corretta il 100% delle volte; la copertura è dichiarata onestamente al 71.4%.
La demo gira interamente in locale senza chiave API, usando per default l'estrazione cached-replay, quindi nessuna posizione o dato cliente deve uscire dal perimetro. Quella postura locale, chiusa e auditabile è deliberata dopo la sentenza Heppner (SDNY, febbraio 2026) che ha sollevato una questione di rinuncia al privilegio su una query di ricerca con uno strumento AI pubblico. L'architettura è progettata per essere privilege-safe, non per inviare posizioni a un servizio esterno.
Non in questa demo. I connettori REST ONESOURCE, CCH Axcess e Blue J, le chiamate LLM live e il grafo Neo4j sono simulati o stubbati; la demo gira su replay in cache e un grafo JSON in memoria così funziona sempre offline. Il meccanismo di verifica è reale e neutrale rispetto ai fornitori per progettazione; la build di produzione documenta FastAPI, Neo4j e i connettori live come percorso di swap-in.
Sono misurati su un golden set etichettato fisso di 42 posizioni delle disposizioni codificate, non una garanzia a mondo aperto. Su quel set: il 71.4% delle posizioni è stato risolto in modo deterministico senza escalation, la precisione del gate era 100% con 0 falsi blocchi, e ogni verdetto coincideva con la sua etichetta. Questi descrivono la copertura e la precisione del livello di verifica, non un tasso di errore del modello, ed è per questo che restano validi al migliorare dei modelli di base. Supporta una posizione di due diligence §6662; non è consulenza fiscale o legale.
La ricerca dietro questa demo — l'architettura, il disegno di verifica e il blueprint enterprise.
Soluzione completa
Esplora la soluzione Verifica AI della conformità fiscale →La penalità del 20% ricade su chi firma, non sul modello che ha redatto. Un verificatore deterministico è il modo per provare quale disposizione normativa ha sostenuto quale posizione.
Se il tuo team sta valutando come verificare le posizioni fiscali redatte dall'AI senza fidarsi di un modello per sorvegliarne un altro, ci farebbe davvero piacere confrontare le note su come ci state pensando. Il problema è di tutto il settore e lo saranno anche le risposte.