Tentei fazer um LLM pegar os próprios erros tributários. Ele não consegue, e isso acabou sendo o negócio inteiro.
A alegação estava gramaticalmente perfeita. Esse era o problema.
Ainda me lembro da primeira posição que me fez parar e pousar o café. Uma IA tinha redigido uma linha sobre a nova dedução de juros de empréstimo de carro da OBBBA, e dizia: "a nova dedução de juros de empréstimo de carro da OBBBA é uma dedução acima da linha que reduz o AGI do cliente." A frase estava limpa. Estava confiante. Estava formatada como toda posição defensável que eu já tinha lido. E estava errada exatamente do jeito que custa dinheiro de verdade a uma pessoa de verdade.
A dedução de juros de empréstimo de veículo de passageiros qualificado (QPVLI) é uma dedução abaixo da linha sob o §63(b)(7). Ela não reduz a renda bruta ajustada. Colocá-la acima da linha não é um erro de ortografia que você pega numa releitura. Ela move o AGI em silêncio, e o AGI é o número em que metade da declaração se apoia. O que me surpreendeu não foi um modelo errar ligeiramente um dispositivo legal. Foi o quão boa a resposta errada parecia.
Uma citação alucinada é fácil de pegar. Uma classificação errada confiante, escrita em inglês tributário perfeito, é a que acaba sendo apresentada.
Foi nesse momento que o problema real ficou claro para mim. O setor passou três anos automatizando a redação do trabalho tributário, e fez um trabalho genuinamente bom. A Thomson Reuters prepara automaticamente 1040s. O CCH Axcess redige insights consultivos em milhares de escritórios. O Blue J responde perguntas de pesquisa em linguagem simples. A preparação está sendo resolvida. Mas a etapa depois da preparação, aquela em que alguém precisa decidir se a posição é de fato defensável sob o estatuto, foi entregue ao mesmo modelo probabilístico que a redigiu. E sob o IRC §6662, a multa de 20% relacionada à precisão cai sobre o humano que assinou a declaração, não sobre o algoritmo que a escreveu.
Passei uma semana tentando fazer o modelo corrigir o próprio dever de casa.
Meu primeiro instinto foi o óbvio, e quero ser honesto: eu o perssegui por mais tempo do que deveria. Se o modelo consegue redigir a posição, certamente um prompt bom o bastante pode fazê-lo checá-la. Então tentei. Dei a ele o estatuto. Dei a regra do QPVLI por escrito. Pedi que auditasse a própria saída e sinalizasse qualquer coisa que colocasse uma dedução na linha errada.
Ele pegou algumas. Perdeu outras. E as falhas eram do tipo assustador, porque quando errava na auditoria errava com a mesma confiança fluente que tinha ao redigir. A autoavaliação passou pelos mesmos pesos que produziram o erro em primeiro lugar. Pedir a um modelo que se policie é pedir à coisa que cometeu o erro que também seja a coisa que nota o erro, usando o raciocínio idêntico que o produziu.
Lembro de explicar isso a um colega e de me ouvir dizer em voz alta: "não podemos confiar em um LLM para policiar um LLM." Essa frase foi quando o desenho virou para mim. Eu tinha tentado tornar o modelo mais preciso. A resposta real era parar de confiar no modelo como juiz de vez.
Você não torna um sistema probabilístico determinístico pedindo com jeitinho. Você tira o veredito dele.
A distinção que demorei demais para internalizar é que redação e verificação não são a mesma tarefa tornada mais fácil ou mais difícil. São problemas diferentes. A redação recompensa fluência, cobertura e plausibilidade, exatamente para o que um modelo de linguagem foi feito. A verificação recompensa estar comprovadamente certo sobre uma regra específica, e ser capaz de mostrar o trabalho a um examinador que não estava na sala. São temperamentos opostos. Parei de tentar fazer um sistema fazer os dois.
O que "o agente aconselha, o código decide" realmente significa?
Quero ser preciso sobre a arquitetura a que cheguei, porque a frase pode soar a marketing até você ver onde a linha é traçada. No StatuteGuard, a demo que construí, o modelo de linguagem faz exatamente um trabalho: lê linguagem tributária bagunçada em linguagem natural e propõe uma alegação estruturada e tipada. Esse é o único passo neural. Ele é genuinamente bom nisso, e quando não tem certeza, se abstém e a posição sobe para um humano em vez de receber um veredito chutado.
Tudo depois disso é código. O veredito é decidido por um motor de política determinístico, OPA/Rego de verdade com um gêmeo idêntico em pure-Python, rodando regras que escrevi contra a lei primária. Extração neural, verificação simbólica. O modelo aconselha. O código decide. E a diferença não é acadêmica, porque o código não pode ser dissuadido da resposta por um parágrafo bem escrito.
A parte com a qual eu não esperava me importar tanto quanto me importo é a legibilidade. As políticas não são uma caixa-preta que peço que você confie. São tabelas de decisão e código-fonte Rego que você pode abrir e checar contra o estatuto você mesmo.
Aquela captura de tela é a tese inteira em um painel. Um Head of Tax deveria poder sentar com o parceiro de compliance, abrir a regra e confirmá-la contra o §30D antes de confiar em um único veredito. Quando a lógica é um parágrafo de raciocínio do modelo, você não consegue fazer isso. Quando é uma regra que você pode ler, consegue.
Então o que acontece quando o código diz não?
Na primeira vez que passei aquela posição de empréstimo de carro da OBBBA pelo gate pronto, eu realmente sorri. O modelo tinha redigido a alegação "acima da linha, reduz o AGI" exatamente como antes. Mas desta vez o motor determinístico olhou a alegação extraída, confrontou-a com a regra codificada do §63(b)(7) e devolveu um veredito duro: BLOCK. Não apresente.
O que acho persuasivo nessa visão, e o que espero que um leitor tributário ache persuasivo, é a cascata. O motor não diz só "linha errada." Ele mostra a você os cinco lugares downstream que uma redução falsa de AGI corromperia: a própria renda bruta ajustada, o imposto de renda estadual acoplado ao AGI, a sobretaxa de prêmio Medicare IRMAA, o piso de dedução de despesas médicas de 7,5% e o reembolso baseado em renda de empréstimo estudantil. Uma dedução classificada errado não é um erro. É um pequeno raio de explosão, e o painel torna o raio visível.
Depois ele anima o motivo, que é a peça a que mais me apego. Ele percorre a cadeia de citações pelo grafo de referências cruzadas do IRC, nó a nó, para que o "não" nunca seja uma mera afirmação nua.
Aqui está o detalhe a que continuo voltando, porque é o que prova que isto não é um problema de brinquedo. Segundo o próprio README da demo, o rótulo errado "acima da linha" não é algo que inventei para ter um vilão. É um erro de consenso documentado que a orientação mainstream de preparação tributária, incluindo o site da H&R Block, publicou. Uma resposta errada plausível, bem escrita e amplamente repetida é exatamente o modo de falha para o qual um gate determinístico existe. A multidão estar confiante não faz a dedução se mover para o AGI. O estatuto decide isso, e agora o código também.
O erro tributário mais perigoso não é o que parece errado. É o que parece certo, soa certo e aparece na orientação de três fornecedores.
Se quiser se demorar nisso, a demo em execução está em veriprajna.com/pt-BR/demos/statuteguard-verifique-posicoes-tributarias-redigidas-por-ia. Você pode colar a própria posição e ver o gate decidir.
O recurso que quase errei: saber quando dizer "não sei"
Tenho de admitir o erro que quase embuti, porque é o que todo engenheiro que constrói uma ferramenta de verificação quer cometer. Meu instinto inicial foi fazer a máquina responder tudo. Cobertura parecia o objetivo. Uma ferramenta que devolve um veredito sobre toda posição parece mais acabada do que uma que às vezes dá de ombros.
Esse instinto está errado, e uma posição específica me ensinou o porquê. Considere a dedução de home-office do §280A. Se um quarto sobressalente é usado "regular e exclusivamente" como principal local de negócios é um teste de fatos e circunstâncias. Não há regra limpa a codificar, porque a resposta depende de como uma pessoa real realmente usa um cômodo real. Se eu forçasse o motor determinístico a decidir sobre isso, estaria fazendo exatamente o que construí isto para impedir: fabricar um veredito confiante onde a resposta honesta é "um humano precisa olhar isto."
Então o gate tem quatro vereditos, não dois. PASS quando a posição é defensável. BLOCK quando contradiz o estatuto codificado. NEEDS-REVIEW quando é uma zona cinzenta genuína. OUT-OF-COVERAGE quando a disposição simplesmente não está codificada nesta versão. Os dois últimos significam a mesma coisa honesta: uma pessoa decide este, não a máquina. Construir o caminho de escalonamento pareceu admitir um limite. Na verdade é o recurso mais importante do produto, porque uma camada de verificação que nunca diz "não sei" é só um segundo modelo blefando com passos a mais.
Os números, e exatamente o que eles não afirmam
Sou cuidadoso com o benchmark, mais cuidadoso do que um marketer gostaria que eu fosse, porque o jeito como esses números costumam ser enunciados é uma mentira. Rodei o motor determinístico contra um golden set rotulado de 42 posições pré-classificadas (14 limpas, 16 com erro, 12 a escalar) e medi o que a camada faz.
Nesse golden set de 42 casos: 71,4% de cobertura determinística, significando que o motor resolveu essa parcela para PASS ou BLOCK por conta própria e escalou corretamente o resto. 100% de precisão do gate, significando zero posições corretas bloqueadas erroneamente. 100% de completude de captura de erros nas disposições codificadas. 100% das zonas cinzentas corretamente escaladas. O throughput rodou na casa das dezenas de milhares de posições por segundo (cerca de 58.000 na execução que capturei, embora isso dependa da máquina), porque verificação é infraestrutura, não uma chamada de modelo.
Agora a parte em que eu insisto. Esses números são verdadeiros naquele golden set, não como garantia de mundo aberto. Não vou dizer que o StatuteGuard é "100% preciso," porque essa frase é desonesta no momento em que você sai do conjunto rotulado. O que vou dizer é mais sutil e, acho, mais durável: porque o veredito é código determinístico, seu comportamento nas disposições codificadas é reproduzível e comprovável, não uma probabilidade que deriva. Eu até cruzei cada um dos 42 vereditos com o OPA 1.17.1 e o gêmeo pure-Python, e eles bateram exatamente. Essa é a alegação atrás da qual posso ficar. Ela descreve a camada, não o modelo.
"100% de precisão" é um número de marketing. "Reproduzível nas disposições codificadas, com escalonamento honesto em todo o resto" é um número de engenharia. Prefiro entregar o segundo.
E é por isso que isto não envelhece. Um modelo-base melhor no ano que vem ainda não consegue provar a um examinador qual disposição estatutária respaldou qual posição. Cobertura, precisão do gate e um rastro de auditoria apresentável são propriedades da camada de verificação. Não são uma taxa de erro de modelo que encolhe conforme os modelos melhoram.
O artefato que eu não sabia que estava construindo até um examinador pedir
Eu não parti para construir um documento de compliance, mas quanto mais gente de tributos eu conversava, mais a conversa terminava no mesmo lugar: "ok, pegou o erro, mas o que eu entrego ao IRS?" Então todo veredito agora escreve um registro de due diligence §6662 apresentável, um workpaper imprimível que documenta que a posição foi verificada contra o estatuto antes da apresentação. Workpaper-fonte, disposição, fonte primária, a alegação extraída, a narrativa da determinação, a cadeia completa de citações. É a evidência de que uma posição de causa razoável e devido cuidado foi de fato tomada, o que importa diretamente sob as revisões do AICPA SSTS vigentes em janeiro de 2024.
Há mais um motivo para eu me importar com onde isto roda, e ficou concreto depois do acórdão Heppner (SDNY, fevereiro de 2026), que levantou uma questão de renúncia a privilégio sobre alimentar pesquisa de cliente em uma ferramenta pública de IA. O StatuteGuard roda totalmente local, sem chave de API por padrão. Nenhuma posição e nenhum dado de cliente sai do perímetro. Depois de Heppner, uma arquitetura fechada, local e auditável não é só um item desejável em uma revisão de segurança. É juridicamente material. Eu não desenhei a postura local-first por causa daquele acórdão. Mas o acórdão é por que agora abro com ela.
Para contexto do que está em jogo, os custos de compliance tributário empresarial dos EUA passam de US$ 126 bilhões por ano (pesquisa da solução WP1, 2026), e a multa do IRC §6662 é 20% do pagamento a menor, com exposição a fraude sob o §6663 chegando a 75%. Quando a redação é automatizada e a multa é pessoal, a etapa de verificação é a que deveria tirar o sono de um Head of Tax.
O que eu realmente acredito agora
Comecei isto achando que estava construindo uma IA tributária melhor, e quero terminar dizendo com clareza que eu estava errado sobre qual era o problema. Sua IA tributária não tem um problema de precisão. Tem um problema de verificação, e um modelo melhor não vai resolvê-lo, porque a multa de 20% cai sobre a sua assinatura, não sobre os pesos dele. Personalizar e automatizar a redação do trabalho tributário é progresso real. Também não é a mesma coisa que provar que uma posição é defensável, e o setor tem tratado as duas em silêncio como se fossem.
A demo vive em veriprajna.com/pt-BR/demos/statuteguard-verifique-posicoes-tributarias-redigidas-por-ia se você quiser tentar quebrar o gate. Eu genuinamente gostaria que tentasse.
E se preferir ver o gate decidir a me ler descrevê-lo, aqui está a coisa inteira rodando de ponta a ponta.
Então aqui está a pergunta que continuo fazendo a líderes tributários, e ainda não tenho uma resposta confortável. Quando uma IA redige uma posição e você assina a declaração, qual é o artefato que prova que você a verificou, em vez de confiar nela? Se a resposta honesta for "nada, confiei no modelo," então o modelo não é seu assistente. É seu coassinante, e ele não pode ser convocado à auditoria.
