IA em produção: o que separa uma demo de um sistema confiável

Qualquer desenvolvedor consegue fazer um modelo de linguagem extrair o valor de um boleto em cinco minutos. Colar o PDF no prompt, ver o output, mostrar para o cliente. Demo pronta.

O problema é que demo não é sistema. Sistema é o que funciona quando o boleto está torto, fotografado com celular na penumbra, com carimbo sobrepondo o código de barras. Sistema é o que você confia às três da manhã sem ninguém monitorando.

O que vou descrever aqui vem de automações de documentos financeiros em produção, extraindo dados de boletos e faturas em volume. Não é teoria.

O problema específico com documentos financeiros

Boletos e faturas têm uma característica que torna o problema mais exigente do que parece: erro tem consequência financeira direta. Valor extraído errado num pagamento automático não é um bug de UX que alguém vai reportar no dia seguinte. É um problema de compliance que pode custar mais do que o projeto inteiro.

O fluxo envolvia classificação e extração. Primeiro o modelo precisava decidir se o documento enviado era de fato um boleto ou fatura válida. Depois, se fosse, extrair os campos relevantes. Dois problemas diferentes, tratados separadamente.

O teste que a maioria pula

A diferença entre um sistema que funciona em demo e um que funciona em produção começa nos testes. Não nos testes do happy path, que qualquer um faz. Nos testes adversariais.

O conjunto de testes que usamos incluía:

• Documentos reais — boletos e faturas dos tipos que o sistema ia processar, com toda a variação natural de diagramação, fonte e qualidade
• Documentos fictícios — criados para cobrir casos extremos sem expor dados reais no ambiente de desenvolvimento
• Desenhos feitos à mão — para testar os limites do classificador: o modelo sabe dizer "isso não é um boleto" quando o input é claramente inválido?
• Fotos completamente fora de contexto — paisagem, selfie, screenshot de jogo. O classificador precisa rejeitar isso com confiança

O teste com imagens fora de contexto é o que separa um classificador de brinquedo de um classificador de produção. Em demo, você só mostra os casos onde funciona. Em produção, o usuário vai enviar exatamente o que você não testou.

Além da classificação, cada campo extraído era validado contra regras de negócio: o valor numérico é plausível para o contexto? O CNPJ tem formato correto? A data não está no passado distante? O modelo pode extrair com confiança mas o campo pode continuar sendo validado por lógica determinística. São camadas independentes.

Observabilidade: saber que o sistema está saudável sem olhar cada resposta

Em produção, você não vai revisar manualmente o output do modelo para cada execução. Isso não escala. A questão é: como você sabe que está tudo certo?

O que tínhamos:

• Sentry para falhas — erros 5xx chegavam como alerta imediato. Quando o sistema quebrava, a equipe sabia antes do usuário reportar
• Grafana para execuções — log de cada execução do fluxo: input recebido, resposta do modelo, campos extraídos, resultado final. Rastreabilidade completa para diagnóstico
• Equipe de operações acompanhando qualidade — a parte que ferramentas não substituem. Alguém precisa olhar para as respostas do modelo periodicamente e identificar padrões de degradação antes que virem problema

Degradação de modelo é real. Um provider pode atualizar o modelo subjacente sem aviso. O comportamento muda sutilmente. Sem alguém olhando para os outputs, você descobre quando o cliente reclama.

Gestão de prompts: quem pode mudar e com qual processo

Prompt é código. Mudar prompt muda comportamento do sistema. Mas prompt também é linguagem natural, e às vezes quem entende melhor o domínio não é o engenheiro.

Nos projetos que construímos, usamos duas abordagens dependendo do contexto:

Prompt no código, em arquivo .txt — versionado com git, auditável, qualquer mudança passa por revisão de código e deploy. Mais lento para ajustar, mas rastreável. Bom para prompts que ficam estáveis.

Prompt no Drive — a equipe de operações consegue ajustar sem engenheiro. Útil quando o domínio muda com frequência e o time de ops tem o conhecimento. O trade-off é rastreabilidade: sem git, você não sabe quem mudou o quê e quando, e não consegue reverter facilmente.

A escolha não é técnica. É sobre quem precisa ter controle e com qual frequência o prompt vai mudar. O importante é que seja uma escolha consciente, não o caminho que foi mais fácil de implementar.

Custo real de API em escala

Em volume, o custo de API deixa de ser desprezível. O que conta não é só o preço por token: é o custo de prompts longos com contexto redundante, o custo de retries quando o provider falha, o custo de um modelo mais caro usado onde um mais barato resolveria.

Usamos LiteLLM como intermediário entre a aplicação e os providers. Isso traz flexibilidade para trocar de provider sem alterar o código da aplicação. Se o GPT-4o fica caro, você aponta para Claude ou Gemini com uma linha de configuração. Se um provider fica instável, você tem fallback.

O que observar em produção:

• Tamanho médio dos prompts por execução — prompt que cresce com o tempo (contexto acumulado sem limpeza) é custo crescente invisível
• Taxa de retry — alta taxa de retry indica instabilidade do provider ou limite de rate sendo atingido
• Distribuição de uso por modelo — se você está usando um modelo caro onde um barato resolveria, é otimização direta

Segurança com dados sensíveis

Dado financeiro tem implicações de compliance que dado genérico não tem. Algumas práticas que aplicamos:

• Ambiente de desenvolvimento só com dados fictícios ou anonimizados. Dado real nunca sai da infraestrutura de produção para teste local
• O modelo processa o documento, não armazena. O que vai para o banco é o campo extraído, não o documento original com todos os dados do pagador
• Logs têm nível de detalhe calibrado: suficiente para diagnóstico, sem expor PII completo em texto livre nos registros

Na Chiarelli Labs

Quando construímos automações com IA, essa disciplina entra no projeto desde o início, não como retrofit depois do primeiro bug em produção.

Antes de qualquer deploy, o conjunto de testes inclui os casos adversariais, não só o happy path. A observabilidade é parte da entrega, não um extra. A gestão de prompts é decidida junto com o cliente baseada em quem precisa ter controle.

Se você está avaliando fornecedores para um projeto com IA, a pergunta certa não é "vocês já fizeram isso antes?" A pergunta é "o que acontece quando o modelo erra?" e "como eu vou saber que está funcionando daqui a seis meses?"

Se quiser essa conversa, entre em contato.