AuditCopilot: LLMs para Detecção de Fraude em Contabilidade por Partidas Dobradas

O artigo que estou lendo esta semana é AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping (arXiv:2512.02726), submetido em dezembro de 2025 por Kadir, Macharla Vasu, Nair e Sonntag. Ele se situa na interseção da pesquisa de agentes LLM e conformidade financeira: usando modelos fundamentais para detectar lançamentos contábeis fraudulentos em livros-razão corporativos reais. De todos os artigos na lista de leitura do Bean Labs até agora, este é o que mais diretamente se preocupa com o mesmo formato de dados brutos que nos interessa.

O artigo

Toda auditoria de empresa pública — obrigatória pela Norma de Auditoria AS 2401 do PCAOB — deve incluir o Teste de Lançamentos Contábeis (JET): verificações sistemáticas no livro-razão em busca de lançamentos que acionem heurísticas baseadas em regras. As regras são coisas como "lançamento postado após a meia-noite", "valor redondo", "par de contas incomum" ou "lançamento postado por um usuário raramente ativo". Essas regras funcionam, mas geram volumes enormes de falsos positivos: os auditores passam a maior parte do tempo descartando ruídos óbvios.

O AuditCopilot questiona se os LLMs podem substituir ou aumentar essas regras. O sistema passa cada lançamento contábil — estruturado como um snippet de texto tipo JSON com campos para data de lançamento, valores de débito/crédito, IDs de conta, taxas de imposto e um conjunto de flags de anomalia binárias pré-computadas — para um prompt de LLM que retorna um rótulo de anomalia binário e uma explicação em linguagem natural. Os autores comparam Mistral-8B, Gemma-2B, Gemma-7B e Llama-3.1-8B em um livro-razão empresarial sintético e em um único livro-razão fiscal real anonimizado, comparando com JETs tradicionais e uma linha de base de Isolation Forest.

Ideias principais

• No conjunto de dados sintéticos (5.000 IDs de lançamento, ~1% de taxa de anomalia real), o Mistral-8B com o prompt completo atinge Precisão de 0,90, Recall de 0,98, F1 de 0,94 — em comparação com a Precisão de 0,53, Recall de 0,90 e F1 de 0,50 da linha de base JET, e criticamente apenas 12 falsos positivos contra os 942 do JET.
• O prompt "completo" do AuditCopilot inclui não apenas os recursos brutos do lançamento, mas também estatísticas globais do conjunto de dados (média, mediana, valores dos percentis 95 e 99) e uma pontuação de Isolation Forest pré-computada por linha. Essa engenharia de contexto é fundamental para o desempenho.
• No conjunto de dados do mundo real, o Gemma-7B com o prompt completo atinge Precisão de 0,89, Recall de 0,78, F1 de 0,83. Quando a dica do Isolation Forest é removida, a precisão desmorona para 0,14 — o LLM sozinho não está sustentando o peso.
• As explicações são a contribuição mais defensável do sistema: ao contrário de uma pontuação numérica de anomalia, cada lançamento sinalizado vem com uma justificativa em prosa ("este valor excede o percentil 99 para este grupo de contas e foi postado fora do horário comercial"), que um auditor pode aceitar ou descartar rapidamente.
• Sem ajuste fino (fine-tuning) em lugar nenhum. Tudo funciona via zero-shot ou com um breve prompt de papel de sistema, o que é bom para o custo de implantação, mas também significa que os resultados dependem muito do template do prompt.

O que se sustenta — e o que não

O resultado da redução de falsos positivos é impressionante e real. Passar de 942 para 12 falsos positivos nos mesmos dados é o tipo de ganho operacional que realmente muda se uma ferramenta é usada na prática. Eu acredito na direção.

Mas tenho sérias ressalvas sobre o design da avaliação.

Primeiro, os rótulos de verdade fundamental (ground-truth) no conjunto de dados sintéticos são, eles mesmos, construídos a partir de regras JET. As anomalias que foram injetadas são exatamente os tipos de padrões que os JETs foram projetados para capturar. Portanto, "o LLM supera o JET" em um conjunto de testes rotulado por JET pode refletir, em parte, o LLM aprendendo a imitar as mesmas regras a partir das estatísticas contextuais no prompt, e não generalizando além delas.

Segundo, a ablação do Isolation Forest em dados reais é contundente de uma forma que o artigo sub-discute. O F1 cai de 0,83 para 0,24 sem as pontuações IF. Isso me diz que o LLM está funcionando principalmente como um limite flexível sobre o sinal do IF, e não como um detector de anomalias independente. O sistema está mais próximo de um ensemble de ML com uma interface de linguagem natural do que de um "modelo fundamental realizando raciocínio de auditoria".

Terceiro, apenas um conjunto de dados do mundo real, extraído de um único parceiro do setor. Os autores reconhecem isso, mas significa que não podemos avaliar a generalização entre tamanhos de empresas, sistemas contábeis ou setores.

Quarto, o artigo compara com JETs e uma única linha de base de ML (Isolation Forest). Detecção de anomalias baseada em Autoencoder, XGBoost com recursos de engenharia e regressão logística simples em pontuações IF estão todos ausentes. O espaço do que conta como "ML clássico" aqui é estreito.

A questão da alucinação não é abordada. Os autores chamam as explicações de uma contribuição fundamental, mas não há avaliação se as justificativas em prosa são factualmente corretas ou consistentes com a previsão binária.

Por que isso importa para a IA financeira

Este é o artigo existente mais próximo do que o Bean Labs está construindo. Os livros-razão do Beancount são sistemas de contabilidade por partidas dobradas. Cada transação é um conjunto de linhas de lançamento. A detecção de anomalias nessas linhas — contas incomuns, valores fora do intervalo, padrões de data implausíveis — é uma primeira funcionalidade óbvia para um assistente financeiro autônomo.

O resultado do AuditCopilot sugere que a abordagem correta para a auditoria do Beancount provavelmente não é "enviar um lançamento bruto para um LLM e perguntar se é suspeito", mas sim "computar um contexto estatístico leve (baselines por conta, distribuição temporal, pontuações de Isolation Forest) e fornecer ao LLM esse contexto enriquecido". O valor do LLM está na síntese e na explicação, não na pontuação bruta de anomalias.

A redução de falsos positivos também é diretamente relevante. Uma ferramenta de auditoria Beancount que apresenta 942 candidatos a anomalias por execução será ignorada. Uma que apresente 12 candidatos de alta confiança com explicações será usada. Isso não é uma métrica de desempenho — é uma métrica de produto.

A preocupação com a segurança da gravação (write-back) que mais me importa não é abordada neste artigo. O AuditCopilot apenas lê e sinaliza; ele não propõe correções nem modifica o razão. Esse é o escopo correto para um primeiro artigo, mas o problema difícil para o Bean Labs permanece: uma vez que você tem uma anomalia sinalizada, como decidir com segurança o que fazer a respeito?

O que ler em seguida

• Understanding Structured Financial Data with LLMs: A Case Study on Fraud Detection (arXiv:2512.13040, ACL 2026) — introduz o FinFRE-RAG, que adiciona exemplos em contexto aumentados por recuperação ao mesmo problema de detecção de fraude e realiza benchmarks em quatro conjuntos de dados de fraude públicos; aborda diretamente a limitação de conjunto de dados único do AuditCopilot.
• Anomaly Detection in Double-entry Bookkeeping Data by Federated Learning System with Non-model Sharing Approach (arXiv:2501.12723) — aborda a restrição de privacidade que impede o agrupamento de dados de livros-razão entre empresas; a abordagem federada é provavelmente necessária para qualquer serviço de auditoria Beancount em produção que queira treinar em dados de clientes sem centralizá-los.
• GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning (arXiv:2406.09187) — o problema de aplicação de segurança que o AuditCopilot deliberadamente ignora: uma vez que as anomalias são sinalizadas, como garantir que um agente de gravação não cometa alterações que violem invariantes contábeis?