Por que o seu projeto de IA não sai do piloto — e o que isso tem a ver com os seus documentos

O seu piloto de IA não morreu por falta de modelo

A reunião de encerramento tem sempre a mesma frase: "ficou legal, mas os números não bateram". E a conclusão que se tira dela costuma ser a errada — que a tecnologia ainda não está madura, que o modelo escolhido era fraco, que faltou treinar melhor.

Quando a gente vai olhar, quase nunca é isso. O piloto morre na entrada, não no meio. O modelo lê o que você entregou e responde com confiança sobre um dado que já chegou torto — e a resposta confiante e errada é o pior resultado possível quando o assunto é dinheiro, porque ela não parece um erro. Parece um relatório.

Os três casos abaixo são de documentos financeiros brasileiros reais que passaram pela nossa leitura. Nenhum deles é um problema de inteligência artificial. Os três são problemas de documento. E os três derrubam qualquer automação que não os trate antes de qualquer outra coisa.

Caso 1: o sinal vem depois da cifra — e 41 de 74 lançamentos entram invertidos

Extrato bancário brasileiro tem uma convenção tipográfica que quase nenhum software estrangeiro espera: o sinal negativo aparece depois do número, e às vezes entre parênteses. Você vê coisas assim numa mesma página:

• 6,50 (-) — débito de seis reais e cinquenta
• 52,80- — débito de cinquenta e dois e oitenta
• 1.200,00 — crédito, sem marca nenhuma

Uma regra ingênua de leitura procura o sinal antes do valor, não encontra, e classifica tudo como entrada. Num extrato real de teste, isso produziu 41 de 74 lançamentos invertidos — uma diferença acumulada de R$ 5.732,21 em um único mês. O saldo final não bate, mas todos os lançamentos individuais parecem plausíveis, o que torna o erro caríssimo de achar a olho.

E tem uma segunda camada, pior: o mesmo símbolo significa duas coisas diferentes no mesmo arquivo. O (-) ao lado de um lançamento indica débito; o (-) ao lado do saldo indica saldo devedor, que não é despesa nenhuma — é a conta no vermelho. Quem trata os dois casos com a mesma regra transforma um saldo negativo numa saída de caixa fantasma.

Nada disso é resolvível com um modelo melhor. É resolvível conhecendo a convenção. Essa é a diferença entre leitura do extrato feita por quem já quebrou a cara com extrato brasileiro e leitura feita por quem testou com um arquivo de exemplo bonitinho.

Caso 2: o PDF que parece cheio e chega vazio

"PDF" não é um formato, são dois — e a diferença decide se o seu projeto funciona.

Tipo	Como nasceu	O que o software enxerga
PDF com camada de texto	gerado pelo sistema do banco ou do emissor	texto selecionável, com posição e valor exatos
PDF que é imagem	documento escaneado ou fotografado	uma fotografia; sem leitura ótica, nada

Até aqui é o que todo mundo já sabe. O caso que derruba piloto é o terceiro, que quase ninguém prevê: um PDF com camada de texto no documento inteiro, menos em uma página. Acontece quando o conteúdo daquela página está embutido como objeto, e não como camada de texto.

Já encontramos faturas em que a página é devolvida em branco pelo renderizador em qualquer resolução. Para o olho humano a página está cheia — tem tabela, valores, tudo. Para o software, é uma folha vazia. O resultado no piloto é o pior tipo de falha: não dá erro. A automação processa o documento, informa sucesso e simplesmente não viu um pedaço dele. O relatório sai limpo, com um mês faltando dentro.

Por isso a pergunta técnica certa a fazer a qualquer fornecedor não é "vocês leem PDF?" — todo mundo lê. É: "o que acontece quando uma página não tem texto extraível?" Se a resposta não mencionar detectar a página vazia e cair para leitura ótica, o sistema vai perder páginas em silêncio.

Caso 3: o mesmo extrato enviado duas vezes duplica o caixa inteiro

Este é banal, humano e devastador. Alguém sobe o extrato de julho. Na semana seguinte, sem lembrar, sobe de novo — ou sobe o extrato do trimestre, que contém julho outra vez.

Se o sistema não tem como reconhecer que aquele lançamento já entrou, o caixa de julho dobra. E lançamento de extrato é difícil de identificar: data, valor e descrição em texto livre se repetem legitimamente o tempo todo — duas compras iguais na mesma padaria no mesmo dia não são uma duplicata, são duas compras.

Comprovantes são o caso oposto e mostram a saída: eles trazem um identificador próprio da transação, o que dá uma chave natural confiável para o reconhecimento do comprovante. Extrato, na maioria dos formatos, não traz. É por isso que a checagem de duplicidade precisa ser desenhada por documento, e não resolvida com um "se for igual, ignora" genérico.

O sintoma clássico deste caso no piloto: o número fica bom demais. Faturamento maior do que a empresa lembra de ter faturado. Quando o resultado agrada mais do que deveria, desconfie da duplicata antes de comemorar.

Método: os três casos vêm de medições internas da nossa esteira de leitura sobre documentos financeiros brasileiros reais de teste — extratos, faturas e comprovantes —, apuradas até 09/08/2026. É amostra pequena e não representativa do mercado brasileiro. O que ela sustenta é o padrão e a existência do problema, não uma estatística de frequência.

O padrão por trás dos três: a IA não erra por burrice, erra porque o documento veio torto

Os três casos têm a mesma assinatura, e vale nomear:

1. O erro não se anuncia. Nenhum dos três gera mensagem de falha. Todos geram resultado. Automação que quebra alto é barata de consertar; automação que quebra em silêncio custa o projeto.
2. O problema está na convenção local, não na inteligência. Sinal depois do valor, objeto embutido em vez de texto, ausência de chave natural — nada disso melhora quando você troca de modelo. É engenharia de documento brasileiro.
3. O teste bonito esconde os três. Todo mundo testa com um arquivo limpo, de um mês tranquilo, com dez lançamentos. Os três casos só aparecem no mês inteiro, com o extrato feio e o PDF que veio do jeito que veio.

E há um agravante externo: o documento muda debaixo da sua automação. Em 3 de agosto de 2026 começou a obrigatoriedade do destaque de IBS e CBS em NF-e, NFC-e e no grupo de transporte, conforme o cronograma publicado pela Receita Federal e pelo Comitê Gestor do IBS — leiaute novo, campos novos, no meio do ano. Quem tratou o formato do documento como constante já começou o piloto com prazo de validade. O calendário completo está em cronograma do IBS e da CBS por tipo de documento fiscal.

O que perguntar ao fornecedor — e que resposta acende o alerta

Cinco perguntas que separam quem já processou documento brasileiro de verdade de quem montou uma demonstração. Não são perguntas técnicas: são perguntas cuja resposta ruim é reconhecível por qualquer pessoa.

Pergunte	Resposta que tranquiliza	Resposta que acende o alerta
Como vocês tratam sinal negativo depois do valor no extrato?	reconhece o problema de imediato e cita formatos concretos	"o modelo entende o contexto"
O que acontece quando uma página do PDF não tem texto extraível?	detecta a página, cai para leitura ótica e avisa	"nosso OCR lê qualquer PDF"
Se eu subir o mesmo extrato duas vezes, o que acontece?	explica qual chave usa por tipo de documento	"o sistema identifica automaticamente"
Como eu confiro um número que vocês me deram?	cada linha aponta para o documento e a página de origem	painel bonito sem rastro até o arquivo
Qual a taxa de acerto e como foi medida?	número, amostra, período e baseline declarados	percentual alto e redondo, sem método

A regra prática: desconfie de toda resposta que atribui ao modelo uma capacidade em vez de descrever um mecanismo. "A IA entende" não é resposta de engenharia, é resposta de vendas. A lista longa está em 12 perguntas para fazer ao fornecedor de IA antes de assinar.

Como medir se desta vez saiu do piloto

Piloto que não tem critério de saída não sai — ele só acaba. Combine os três números antes de começar, por escrito:

1. Diferença entre o saldo calculado e o saldo do extrato, em reais. É o teste mais duro e o mais honesto. Se o sistema fecha o mês com o saldo do banco, ele leu certo. Se não fecha, nenhum outro indicador importa.
2. Percentual de lançamentos que precisaram de correção manual. Meça no primeiro mês e no terceiro. Caindo, a amarração do caixa está aprendendo o seu negócio. Parado, você comprou um digitador caro.
3. Dias entre o fim do mês e o mês fechado. É o número que o dono sente. Sem ele, o projeto vira discussão de opinião na reunião de resultado.

Um piloto de leitura de documento financeiro deveria dar resposta para os três em um ciclo de fechamento. Se depois de um mês inteiro ninguém consegue dizer se melhorou, o problema não é o prazo: é que ninguém definiu o que era melhorar. Para desenhar isso antes de escolher qualquer ferramenta, comece por implementar IA no financeiro da sua empresa.

Se você vai tentar de novo, comece diferente

Quem já se queimou tem uma vantagem sobre quem nunca tentou: sabe que a demonstração impressiona e que o mês seguinte é que decide. Três mudanças de método bastam para a segunda tentativa não repetir a primeira:

• Teste com o mês feio. Não com o arquivo bonito. Pegue o mês que teve estorno, transferência entre contas próprias, pagamento em duplicidade e aquele PDF que veio esquisito. É o único teste que informa alguma coisa.
• Exija rastro até o documento. Todo número apresentado precisa apontar para o arquivo e a página que o gerou. Sem isso não há conferência — há fé.
• Escolha um processo só e um critério só. Na maior parte das empresas pequenas, é o extrato virando caixa. O caminho está em do extrato bancário ao fluxo de caixa, e o que fazer quando os números não batem em conciliação bancária: quando não bate.

A IA não precisa ser perfeita para valer a pena. Precisa ser conferível. É essa a diferença entre um piloto que vira operação e um piloto que vira uma história que se conta na reunião seguinte.