Como a Thrive e a OpenAI transformaram correções de revisão fiscal num ciclo Codex de auto-aperfeiçoamento

O que foi lançado para as mais de 30 firmas de Crete

Ao longo de seis meses, engenheiros da OpenAI em destacamento e a Thrive Holdings construíram o Tax AI para a rede de mais de 30 firmas de contabilidade de Crete, aplicando-o a 7000 declarações 1040 e 1041 durante esta época piloto. O problema de partida era concreto: a mera introdução de dados pode demorar oito horas numa declaração de complexidade média a elevada, ao lidar com documentos do ano anterior, folhas de cálculo e notas manuscritas desorganizados.

Os resultados em destaque são números de eficiência — cerca de um terço do tempo de preparação poupado, até 97% de precisão, aproximadamente 50% mais rendimento. Mas a afirmação que realmente interessa aos autores é que o sistema melhorou enquanto estava em funcionamento. No lançamento, apenas um quarto das declarações atingia 75% de preenchimento correto de campos; seis semanas depois, esse valor era de 86%, com ganhos ainda mais rápidos nos limiares de 90% e 100%, à medida que o agente avançava dos W-2 e 1099 para os K-1 e mapas de arrendamento.

O ecrã de correção é o pipeline de dados

A decisão de design de frontend que sustenta todo o sistema é tratar a revisão dos profissionais não como um passo final, mas como um evento estruturado. Quando um contabilista aprova ou edita um valor extraído, o produto regista exatamente o que o Tax AI propôs, o que o profissional alterou e o que acabou por constar na declaração submetida. Esse trio é a matéria-prima para tudo o que se segue.

É fácil subestimar isto. A maioria das interfaces de revisão capta apenas a resposta final e descarta a discordância. Aqui, a discordância é o produto. A equipa desenhou explicitamente o fluxo de trabalho de forma a que 'as pessoas que fazem o trabalho orientem o que o produto aprende' — os profissionais geram o sinal de melhoria simplesmente ao fazer o seu trabalho, sem uma tarefa de anotação separada nem um formulário de feedback acoplado ao processo.

Porque é que a proveniência tinha de ser uma superfície de primeira classe

Uma correção em bruto é ambígua. Um valor alterado antes da submissão pode ser um verdadeiro erro de extração, um problema de mapeamento, um valor transportado de uma declaração do ano anterior, uma preferência do profissional, ou apenas ruído do fluxo de trabalho. Se a interface apenas guardasse a entrada e a saída, os engenheiros teriam ainda de reconstruir qual destes casos se aplicava — o ciclo manual e lento que o artigo descreve na abertura.

O Tax AI evita isso ao preservar todo o percurso: documentos organizados e classificados, campos de propriedades arrendadas extraídos com citações para o material de origem, valores mapeados no motor fiscal e, por fim, a edição do profissional. É esse registo de proveniência que permite ao sistema produzir linhas de revisão ao nível do campo, agrupar falhas recorrentes — a repetida omissão dos 'dias de arrendamento justo', o tratamento incorreto de 'outras despesas', a confusão entre várias propriedades num mesmo conjunto — e separar bugs genuínos do produto de ruído esperado antes de chegar ao Codex.

O Codex trabalha depois dentro de um ambiente limitado que reflete essa separação: uma worktree com permissão de escrita que contém a superfície do produto de rendimentos de arrendamento e as suas avaliações direcionadas mais as de regressão, e um contexto apenas de leitura que fornece o registo de produção, os documentos de origem, a previsão e a declaração submetida. O agente pode inspecionar as evidências sem as alterar, propor um pull request e encaminhar os casos ambíguos de volta para os engenheiros em vez de os forçar a passar pelo ciclo.

A implicação: construir a interface de revisão antes do agente

A lição reutilizável aqui é a ordem dos passos. A funcionalidade de propriedades arrendadas demorou cerca de seis semanas e uma forte supervisão de engenharia até atingir 90% de precisão e exaustividade, mas o retorno foram abstrações reutilizáveis, convenções de avaliação e artefactos de revisão que tornaram o Schedule C e o Schedule A mais baratos de implementar. Nada disso teria sido possível até que a interface de correção passasse a produzir evidência estruturada, citada e agrupável.

Para equipas que constroem agentes de domínio onde o julgamento especializado define a qualidade, a conclusão é que o frontend onde os humanos corrigem a máquina não é cosmético — é a camada de captação para a auto-melhoria. Fazê-lo mal significa que cada correção permanece manual; fazê-lo bem significa que cada alteração lançada gera a evidência para o ciclo seguinte. Vale a pena reter o resumo do princípio feito pela própria Thrive:

Os melhores agentes são orientados por pessoas para aprenderem a tornar-se mais capazes, mais fiáveis e mais valiosos ao longo do tempo.Montana Labs

A prova humana é uma contabilista sénior que passou 180 horas em preparação fiscal no ano passado e apenas 15 este ano — tempo que redirecionou para contactar todos os clientes e assumir novo trabalho. Esse resultado só existe porque a interface que ela usou para corrigir o agente foi, discretamente, aquilo que o ensinou.