Utilizando IA para automatizar o processamento de 8.000 notas fiscais mensais
Um caso prático de automação de IA com ferramentas low‑code para extração de informações de notas fiscais
Contexto
O cliente recebe aproximadamente 8.000 notas fiscais por mês e precisa extrair e estruturar as informações em planilhas que, posteriormente, são convertidas em arquivos .txt e enviados ao sistema de um parceiro.
Até então, todo o trabalho era manual, apoiado apenas por algumas fórmulas no Google Sheets — as notas chegam em múltiplos formatos, o que inviabiliza soluções tradicionais de RPA.
Três colaboradores dedicavam-se a essa rotina.
Processo automatizado
Abrir cada nota fiscal.
Identificar os campos a extrair.
Inserir dados na planilha.
Transformar os dados para atender ao formato exigido pelo sistema.
Gerar o arquivo
.txt.Fazer upload no sistema do parceiro.
Problemas identificados
Custo de capital humano proporcional ao crescimento: mais notas a serem processadas exigem mais horas de trabalho.
Risco elevado de erro humano: múltiplas revisões são necessárias.
Conhecimento tácito concentrado em poucos colaboradores; inexistência de documentação formal.
Solução adotada
Automação completa do fluxo com:
Ferramentas low-code: Make, Zapier e n8n.
Modelos de LLM (inteligência artificial) para leitura, interpretação e extração de dados das notas.
APIs externas (por exemplo, Receita Federal) para validação de campos críticos.
OCR para extração de texto de PDFs.
Google Apps Script para etapas de formatação de planilha e criação de
.txt.
Metodologia
MVP pré-venda
Antes da contratação, foi construído um protótipo no Zapier que lia PDFs de uma pasta no Google Drive, extraía campos-chave e inseria as informações em um Google Sheets. A solução foi aplicada em uma pequena amostra de notas fiscais, pois o objetivo foi comprovar a viabilidade técnica da solução.
Execução em quatro etapas
Definição de grupos prioritários — análise 80/20 para descobrir quais tipos de nota representavam a maior fatia do volume com menor esforço de automação. A depender do grupo, diferentes informações devem ser extraídas e diferentes tratamentos devem ser realizados nos arquivos. Por isso, entender esses grupos se fez importante. Sete grupos foram identificados, e o primeiro foi priorizado pelo projeto.
Mapeamento detalhado do processo atual — separando o que se beneficiaria de IA do que poderia ser resolvido com métodos de automação tradicionais. Spoiler: nem tudo precisa e deve ser automatizado via IA.
Implementação e testes — sete ciclos (“batches”) avaliaram diferentes LLMs e técnicas de prompt-engineering - como few-shot prompting - até atingir a versão final.
Acompanhamento de performance — solução em produção, documentação técnica entregue e treinamento da equipe do cliente. Uma quinta etapa (expansão) foi pré-acordada para abranger os demais grupos de notas.
Resultados
A IA extrai informações com 97 % de assertividade média, e nenhum campo fica abaixo de 94 %.
A solução implementada já contempla a automação de 5.000 notas pertencentes ao grupo prioritário; as demais serão incluídas na fase de expansão.
Escalabilidade operacional: estimativa de redução de até 80% no tempo total de execução do processo.
Custo de sustentação (8.000 notas/mês)
Modelos de linguagem (LLM): ~ R$ 2.000/mês
Plataforma low-code: ~ R$ 1.000/mês
APIs externas: ~ R$ 500/mês
Total estimado: cerca de R$ 3.500 por mês para operar a solução em escala plena.
Desafios e limitações
Alucinações de LLM — Modelos de IA são inerentemente probabilísticos, não determinísticos. Por isso, grande parte do projeto concentrou-se não só em elevar a taxa de acerto, mas também em criar mecanismos de identificação de erros. Uma falha recorrente aparecia na extração de CNPJs: a LLM inverte dígitos, retornando, por exemplo, “21.345.678/0001-95” em vez de “12.345.678/0001-95”. Para filtrar esses casos, conectamos a API da Receita Federal; se a consulta falhava, o CNPJ era marcado para revisão humana. Esses dispositivos de segurança—conhecidos como guardrails ou evals—podem assumir três formas: validação humana, checagem programática (como a verificação na Receita) ou auditoria por uma segunda LLM que confirma a resposta da primeira.
O guardrail por LLM funciona como uma votação entre modelos: múltiplos agentes independentes — cada um com prompts ou arquiteturas distintas — extraem o valor (ou qualquer informação) da mesma nota fiscal; o dado só é aprovado quando há consenso entre todos eles. O problema, como você deve ter imaginado, é que o custo de LLM é multiplicado com base no número de agentes.
Falta de leitura nativa de PDFs — algumas APIs de LLM, como a da OpenAI, ainda não processam PDFs diretamente. Para contornar essa limitação na API do GPT, implementamos duas abordagens: (i) converter o documento em imagem antes de enviá-lo ao modelo e (ii) aplicar OCR para extrair o texto do PDF e então submetê-lo ao GPT. Em paralelo, avaliamos o Claude, cuja API já oferece suporte nativo à leitura de PDFs.
Páginas sem nota fiscal — entre 20% e 25% do custo de sustentação está ligado à análise de documentos que não são NFs.
Próximos passos
Automatizar os demais grupos de notas.
Reduzir custos de plataforma — Escolhemos o Make por apresentar a melhor relação custo-benefício: oferece uma experiência de uso semelhante à do Zapier, mas a um preço significativamente menor. Existem opções ainda mais baratas — como o n8n ou uma solução totalmente hard-coded —, porém o Make manteve o projeto dentro do orçamento aprovado e acelerou a implementação. Para o médio prazo, estudamos migrar o fluxo para o n8n, possivelmente em modo self-hosted, o que poderia zerar o custo de plataforma, já que, diferentemente de Make e Zapier, o n8n não cobra por execução, e sim pela infraestrutura em que roda. Caso a solução migrada ao n8n e hospedada em servidor próprio, o gasto recorrente com a plataforma low-code tende a zero
Um guia de instalação encontra-se na documentação oficial da plataforma(https://docs.n8n.io/hosting/installation/docker/).
Otimizar custos de LLM — Também há espaço para cortar despesas com LLMs. Novos modelos, em geral mais baratos e performáticos, são lançados historicamente a cada trimestre. Um bom exemplo recente é o Gemini 2.5 — disponível nas variantes Pro e Flash — que o Google posiciona como alternativa direta ao GPT-4o e ao Claude 3.5/3.7. O Gemini 2.5 Pro pode reduzir o custo por token em até 38 % em relação ao Claude 3.5 Sonnet, mantendo (ou superando) o nível de qualidade.
Informações adicionais
Esforço total de implementação: 110h (10h/semana).
Contrato: entrega da implementação + três meses de suporte. A fase de expansão está em negociação e pode incluir (i) suporte contínuo e (ii) um modelo de outsourcing dos custos de sustentação, no qual assumo todas as despesas operacionais e cobro apenas por nota fiscal processada sem erros. Além de garantir recorrência, é uma maneira de alinhar os interesses, pois há incentivos do meu lado - como fornecedor - de buscar o aumento da taxa de assertividade da solução.
Dada a imprevisibilidade inicial da taxa de acerto da IA, propusemos um contrato em duas etapas:
Pagamento inicial para desenvolver o piloto e gerar as métricas de assertividade.
Pagamento final somente se o índice de acerto alcançar o patamar acordado.
Esse arranjo distribui o risco de incerteza entre ambas as partes.
Insights
“One-shot prompts” não bastam — criar um prompt que resolva um único caso é simples; o desafio está em escalar a solução para 8 mil ocorrências mensais, mantendo consistência e mecanismos de detecção de erros. Por isso, ajustar modelos de LLM exige várias rodadas de testes para garantir desempenho uniforme. Em projetos de IA, ciclos de iteração extensivos precisam ser planejados desde o início — reserve, no mínimo, o dobro do tempo inicialmente estimado. Não há como antecipar quais imprevistos surgirão, apenas ter certeza de que eles virão.
A IA não resolve tudo — nem todo desafio exige — ou deve exigir — inteligência artificial. Relembrando, o fluxo do cliente abrange: (1) abrir cada nota fiscal, (2) identificar os campos a extrair, (3) inserir os dados na planilha, (4) transformar os dados para o formato exigido pelo sistema, (5) gerar o arquivo
.txte (6) fazer upload no sistema do parceiro. Embora cada etapa demande esforço semelhante, apenas a segunda faz uso de IA; as demais são automatizadas por métodos tradicionais. Por isso, é fundamental discernir, em qualquer iniciativa, quais fases realmente requerem IA e quais podem ser resolvidas por abordagens convencionais.OpenAI vs Anthropic — os modelos utilizados nos testes foram as últimas versões do gpt4o e Claude Sonnet 3.5. Após os ciclos de iteração, ambos os modelos apresentaram resultados e custos similares. Porém, o modelo escolhido para produção foi o Claude, visto que este tem capacidade nativa de ler PDFs.
Identificar erros é necessidade básica — como mencionei, tão crucial quanto criar uma IA que funcione é entregar um produto completo, equipado com mecanismos sólidos de detecção de erros — seja por validação humana, lógica de código ou modelos de linguagem. O trade-off aqui é entre custo e performance. É possível colocar diversos guardrails de LLM, por exemplo, mas o custo tende a ficar mais elevado que o da própria solução.
Priorize os guardrails a serem implementados — guardrails baseados em LLM são onerosos e, mesmo assim, não oferecem precisão absoluta; atuam como uma auditoria imparcial extra (afinal, também é uma IA). Antes de investir em soluções mais sofisticadas, é fundamental mapear quais erros causam maior impacto — por exemplo, na extração de notas fiscais, determinar quais campos incorretos gerariam os maiores prejuízos.
Contexto linguístico pode ter impacto na performance — obtivemos 100% de assertividade na extração dos valores das notas fiscais, mas o mesmo não se verifica para os CNPJs: possivelmente o obstáculo não está nos algarismos e sim no contexto linguístico. Há indícios de que modelos treinados em um idioma perdem desempenho ao operar em outro. Como os modelos da OpenAI são treinados sobretudo em inglês — lidando com invoices em vez de notas fiscais — a precisão na extração de CNPJ em documentos brasileiros pode acabar comprometida.
Evolução constante dos modelos — embora novos modelos tragam melhorias de performance e custo, sua evolução acelerada traz efeitos colaterais: na Cloud Humans, notamos que cada nova versão lançada pela OpenAI (como a gpt-4o-20-11-2024) impactava imediatamente as anteriores, ainda em uso pelos nossos clientes. Assim, manter os modelos atualizados não é apenas uma iniciativa de vanguarda, mas uma necessidade operacional para preservar a estabilidade e a qualidade do serviço. Por isso, uma contratação com serviço de suporte contínuo tende a ser uma estratégia positiva para garantir a perenidade da solução.
Zapier × Make × n8n — Zapier possui uma interface bastante amigável, mas é significativamente mais caro; Make se mantém dentro do orçamento e oferece uma experiência tão amigável quanto o Zapier; já o n8n custa pelo menos 60% menos que o Make, mesmo com contratação de hospedagem terceirizada, mas penaliza a usabilidade por não trazer integrações prontas, como Google Drive e Google Sheets.
Mantenha a simplicidade — no momento em que precisei automatizar as etapas (1) transformar os dados para atender ao formato exigido pelo sistema e (2) gerar o arquivo
.txt, usar o Google Apps Script — o “VBA” do Sheets — foi muito mais fácil e barato do que recorrer a uma plataforma low-code. Claro que usei o GPT para me apoiar na construção dos códigos.