Extração de dados de documentos com IA: além do OCR

Toda empresa tem uma caixa de entrada que ninguém quer: PDFs de fornecedores, fotos de comprovantes tiradas no celular, contratos escaneados, laudos, guias, formulários preenchidos à mão. Alguém abre um por um, lê, digita no sistema e confere. É trabalho lento, sujeito a erro de digitação e que cresce junto com a empresa.

A promessa de "a IA lê o documento e preenche o sistema" é real, mas incompleta. Ler é a parte fácil. O que decide se o projeto funciona em produção é o que vem em volta: saber que tipo de documento chegou, conferir o que foi extraído contra o que você já sabe, e decidir com critério quando uma pessoa precisa olhar.

Este texto mostra como montar um pipeline que aguenta o volume real, e quando você nem precisa de IA.

Antes da IA: o documento já tem XML ou API?

A pergunta mais barata do projeto é esta, e muita gente pula. Vários documentos que chegam em PDF já existem em formato estruturado em algum lugar.

• NF-e. O documento fiscal é o XML autorizado pela SEFAZ. O DANFE, aquele PDF, é só uma representação auxiliar. O XML traz emitente, itens, impostos e totais com precisão total, e o destinatário consegue obter os XMLs das notas emitidas contra o seu CNPJ pelo serviço de distribuição de documentos fiscais, com certificado digital ICP-Brasil. Fazer OCR de DANFE quando o XML está disponível é trocar certeza por probabilidade.
• NFS-e. Com o padrão nacional, a nota de serviço também é um XML. Mesmo em municípios com sistemas próprios, é comum existir consulta ou download estruturado.
• Boletos. O código de barras e a linha digitável seguem padrão bancário e carregam banco, vencimento e valor. Decodificar é determinístico. E o DDA mostra no banco os boletos registrados contra o seu CNPJ.
• Pix. O QR Code carrega um payload padronizado que pode ser lido diretamente.
• Extratos. Bancos oferecem OFX, arquivos de retorno CNAB e, cada vez com mais frequência, APIs.

Se o dado já existe estruturado, o projeto não é de IA. É de integração, e os critérios para escolher o caminho estão no texto sobre RPA ou integração via API. A IA entra onde o documento é, de fato, a única fonte: contratos, laudos, comprovantes de fornecedores pequenos, documentos pessoais, formulários de terceiros, correspondências.

OCR lê texto. O problema é entender o documento

OCR (reconhecimento óptico de caracteres) transforma a imagem em texto. Mas o resultado é uma sopa de palavras com posições na página. Ele não sabe que aquele número é o valor total e não o subtotal, nem que a data ao lado de "emissão" não é a de vencimento.

Durante anos, a solução foi escrever regras por layout: "o CNPJ está a tantos pixels do topo", "o total vem depois da palavra TOTAL". Funciona enquanto o fornecedor não muda o modelo do documento. Com cinquenta fornecedores, são cinquenta templates para manter.

Os modelos de linguagem e os modelos que leem imagem e texto juntos mudaram isso. Eles entendem o documento pelo significado: reconhecem que "Valor a pagar", "Total geral" e "Montante devido" são a mesma coisa, e acham o campo em layouts que nunca viram. É isso que "além do OCR" quer dizer: sair de regras por posição para extração por significado.

Só que essa flexibilidade tem um preço técnico. Um modelo de linguagem pode devolver um valor plausível e errado, com a mesma confiança com que devolve um valor certo. Por isso a IA é uma peça do pipeline, não o pipeline inteiro.

O pipeline: receber, classificar, extrair, validar

Um fluxo de documentos que funciona em produção costuma ter estas etapas, cada uma com responsabilidade clara.

1. Receber

Documentos chegam por e-mail, upload num portal, WhatsApp, pasta compartilhada ou digitalizadora. A entrada precisa registrar cada arquivo com origem, data e remetente, gerar um identificador e guardar o original. Nada é processado sem que o original esteja salvo e rastreável.

2. Pré-processar

Corrigir rotação, separar páginas, dividir um PDF que contém vários documentos grudados, melhorar contraste de foto de celular. Parece detalhe, mas é aqui que muitos erros de extração nascem.

3. Classificar

Antes de extrair, o sistema precisa saber o que chegou: nota de serviço, contrato, comprovante de endereço, atestado. Cada tipo tem um esquema de campos diferente e regras de validação diferentes.

4. Extrair para um esquema

A extração não devolve texto livre. Ela preenche um esquema definido: campos com nome, tipo e formato. CNPJ como texto com catorze dígitos, data em formato padronizado, valores como número, itens como lista. Modelos atuais aceitam saída estruturada, o que elimina muitos erros de interpretação.

5. Validar

A etapa que separa um protótipo de um sistema. É assunto da próxima seção.

6. Integrar

Só o que passou na validação, ou foi aprovado por uma pessoa, segue para o ERP, o sistema de RH ou o financeiro, com o vínculo ao documento original preservado.

Validação cruzada com o que o sistema já sabe

O melhor verificador de uma extração não é outro modelo de IA. É o próprio sistema da empresa, que já conhece fornecedores, pedidos, contratos e funcionários.

São três camadas, da mais simples à mais valiosa:

A validação cruzada é onde mora o ganho real. Se a IA leu um CNPJ que existe no cadastro, com um valor que bate com um pedido em aberto daquele fornecedor, a chance de erro nos dois campos ao mesmo tempo é pequena. Se leu um CNPJ válido mas desconhecido, pode ser um fornecedor novo ou um dígito trocado, e alguém precisa olhar.

Na admissão de funcionários, por exemplo, o nome extraído do RG pode ser comparado com o nome informado no cadastro, e o CPF com o que veio da proposta. Detalhamos esse fluxo específico em como automatizar a admissão de funcionários.

Confiança por campo e revisão humana nos casos duvidosos

O erro mais comum em projetos de extração é tratar o documento como um bloco: "passou" ou "não passou". Na prática, um documento pode ter nove campos corretos e um duvidoso. A decisão precisa ser por campo.

Cada campo recebe um nível de confiança que combina vários sinais:

• Qualidade da leitura, quando o motor de OCR informa quanto tem certeza dos caracteres.
• Resultado das validações: passou no formato, na consistência e na conferência com o sistema?
• Concordância entre métodos: quando duas formas de extrair o mesmo campo chegam ao mesmo resultado, a confiança sobe.
• Histórico: fornecedores e tipos de documento com muitos acertos passados merecem mais crédito.

Um alerta importante: a "confiança" que um modelo de linguagem declara sobre a própria resposta não é confiável por si só. Ela precisa ser calibrada contra resultados reais, o que depende da base de avaliação descrita adiante.

Com a confiança por campo, o fluxo fica assim:

1. Todos os campos com alta confiança e validados: o documento segue direto para o sistema.
2. Algum campo duvidoso: o documento vai para a fila de revisão, com o campo destacado, a imagem ao lado e a sugestão preenchida. A pessoa confirma ou corrige em segundos, sem redigitar o resto.
3. Documento ilegível, tipo desconhecido ou validação crítica falhou: tratamento manual, com o motivo registrado.

A tela de revisão merece tanto cuidado quanto o modelo. Se revisar for mais lento que digitar do zero, a equipe vai contornar o sistema. E cada correção feita ali mostra onde o pipeline erra.

Os limites de confiança não são fixos. No começo, é prudente mandar mais para revisão. Conforme os números mostram acerto consistente em um tipo de documento, o limite pode ser ajustado. Campos de alto impacto, como valor e dados bancários de pagamento, podem exigir revisão sempre, independentemente da confiança.

Medindo precisão com uma base de avaliação real

"A IA acerta quase tudo" não é métrica. Antes de escalar, você precisa saber a precisão real nos seus documentos, não nos exemplos da demonstração.

Para isso existe a base de avaliação: um conjunto de documentos reais da empresa com os valores corretos anotados à mão, campo por campo. Ela precisa ser representativa:

• Todos os tipos de documento que o pipeline vai receber, na proporção em que chegam.
• A variedade real de layouts: fornecedores grandes e pequenos, modelos antigos e novos.
• Os casos difíceis: foto torta, digitalização ruim, documento com carimbo sobre o texto, manuscrito.
• Documentos que não deveriam ser processados, para medir se a classificação os barra.

Com a base pronta, cada versão do pipeline é medida da mesma forma:

• Acerto por campo e por tipo de documento. Um acerto médio alto pode esconder um campo crítico que erra com frequência.
• Erros que passariam sem revisão. O número mais importante: quantos valores errados teriam chegado ao sistema com confiança alta. É ele que define se o limite de revisão está bem calibrado.
• Taxa de envio para revisão. Quanto trabalho humano sobra.

Essa base também protege contra regressão: trocar de modelo ou ajustar instruções pode melhorar um tipo de documento e piorar outro. Sem base fixa, você só descobre em produção.

Privacidade e onde os documentos são processados

Documentos são, quase sempre, cheios de dados pessoais: CPF, endereço, dados bancários, informações de saúde em laudos e atestados. A LGPD (Lei 13.709/2018) se aplica integralmente, e dado de saúde está entre os dados pessoais sensíveis, com exigências mais rígidas.

As decisões que precisam ser tomadas no desenho, não depois:

• Onde o processamento acontece. Usar a API de um provedor de modelos, um serviço gerenciado na nuvem (AWS e GCP oferecem serviços de extração de documentos) ou um modelo rodando em infraestrutura própria. Cada opção tem implicações diferentes de custo, desempenho e controle.
• O que o provedor faz com os dados. Leia os termos: retenção, uso para treinamento, região de processamento, subprocessadores. Isso entra no contrato e no registro das operações de tratamento.
• Minimização. Extraia só os campos que o processo usa. Se o fluxo precisa do número do documento, não há motivo para guardar a foto dele para sempre.
• Retenção e descarte. Quanto tempo o original fica guardado, por obrigação legal ou necessidade do negócio, e o que acontece depois.
• Logs sem dado pessoal. O registro de execução deve apontar o identificador do documento, não copiar o conteúdo dele.
• Acesso à fila de revisão. Quem revisa atestados não precisa ver contratos, e vice-versa.

O texto sobre LGPD no desenvolvimento de sistemas aprofunda esses requisitos. E se o objetivo não é extrair campos, mas responder perguntas sobre o conteúdo dos documentos, o caminho é outro: veja assistente de IA que responde com os documentos da empresa.

Erros comuns e como evitá-los

• Começar pela IA sem perguntar se existe XML ou API. O projeto fica mais complexo e menos preciso do que precisava.
• Mandar tudo direto para o sistema. Sem validação e sem fila de revisão, o erro silencioso chega ao financeiro e só aparece no fechamento.
• Avaliar com meia dúzia de documentos bonitos. A demonstração impressiona; a produção traz a foto de celular com reflexo.
• Ignorar a tela de revisão. Se ela for ruim, a equipe volta para a digitação manual.

Um roteiro para começar

1. Liste os documentos que chegam, com volume por tipo e o que é feito com cada um hoje.
2. Verifique quais já existem em formato estruturado e resolva esses por integração.
3. Escolha um tipo de documento de volume relevante e regra clara para o primeiro ciclo.
4. Defina o esquema de campos e, para cada um, a validação e o impacto de um erro.
5. Monte a base de avaliação com documentos reais anotados.
6. Construa o pipeline com revisão humana e rode em paralelo com o processo atual.
7. Meça, ajuste os limites de confiança e só então amplie para outros tipos.

Esse trabalho é essencialmente de arquitetura de software: a IA é um componente, e o resultado depende de como ele se encaixa com validação, filas, integração e segurança.

Como a Pervian Tech constrói esse pipeline

Começamos por um diagnóstico dos documentos que chegam, dos sistemas envolvidos e do que já pode ser obtido de forma estruturada. A partir daí, desenhamos o pipeline sob medida: classificação, extração, validação cruzada com os seus dados, fila de revisão e a base de avaliação que mostra a precisão real antes de escalar.

O investimento é definido sob consulta, depois de entender volume, tipos de documento e requisitos de privacidade. O cronograma segue fases (diagnóstico, protótipo com avaliação, primeiro tipo em produção, evolução) e é fechado após o diagnóstico.

Se há uma pilha de documentos sendo digitada na sua empresa, conte como ela chega hoje.