O abismo entre um bom demo e um recurso lançado
Toda empresa com quem conversamos em 2026 já viu o demo. Alguém do time conectou um LLM a uma planilha, ou construiu um chatbot sobre documentos internos em um fim de semana, e aquilo ficou ótimo na reunião geral. Depois ficou parado num canal do Slack por três meses, sem uso em produção, porque ninguém conseguia responder à pergunta: o que acontece quando ele erra na frente de um cliente, ou pior, na frente de um auditor?
Esse abismo — entre "o modelo deu uma boa resposta uma vez" e "isso roda sem supervisão contra dados reais, para usuários reais, todos os dias" — é para onde vai praticamente todo o tempo dos nossos projetos de IA/ML. Montar o prompt é coisa de uma tarde. Torná-lo seguro o suficiente para deixar rodando é o projeto inteiro.
Aqui está o que realmente separa um demo de um sistema em produção, e o que custa fechar esse abismo.
Demos pulam as partes que garantem confiabilidade
Um demo é uma entrada, executada uma vez, por alguém que sabe formular a pergunta certa. Produção é milhares de entradas imprevisíveis, executadas continuamente, por pessoas que não sabem nem se importam com como o modelo funciona. Três coisas quebram primeiro nessa transição:
1. Não há como saber se uma mudança no prompt melhorou ou piorou as coisas. Sem um conjunto fixo de casos de teste e respostas esperadas — um eval set — cada ajuste de prompt é um chute. Construímos um eval set a partir de perguntas reais de usuários antes de mexer em qualquer prompt de produção, e o rodamos novamente a cada mudança de modelo ou prompt. Se um cliente não consegue nos dizer que a taxa de acerto foi de um número para um número melhor, ele não pode lançar uma mudança com segurança — está apenas torcendo.
2. O modelo só é tão bom quanto o que ele consegue recuperar. Para qualquer coisa fundamentada nos seus próprios dados — documentos de suporte, contratos, wikis internas — a qualidade da recuperação importa mais do que qual modelo você está chamando. Chunking ingênuo e uma única busca vetorial te dão um demo que funciona nas três perguntas que você testou. RAG em produção precisa de busca híbrida (palavra-chave mais vetorial), reranking, e a exigência inegociável de que cada resposta cite seu documento de origem. Se o sistema não consegue apontar de onde tirou uma resposta, não a lance para nada voltado ao cliente.
3. Agentes que usam ferramentas precisam de um modelo de permissões, não só de um prompt. No momento em que um agente pode gerar um reembolso, atualizar um registro no CRM ou enviar um e-mail em nome de alguém, "o modelo decidiu" deixa de ser uma explicação aceitável. Cada ação precisa de um raio de impacto definido: o que o agente pode fazer de forma autônoma, o que precisa de uma etapa de aprovação humana, e o que ele nunca pode tocar. Mantemos uma lista explícita de proibições para cada agente que construímos — geralmente qualquer coisa irreversível ou financeira — antes mesmo de escrever a primeira definição de ferramenta.
O modo de falha que ninguém planeja: respostas erradas com confiança
Uma queda de API é óbvia. Um modelo que responde com fluência e de forma incorreta não é. Esse é o risco específico que destrói a confiança em um recurso de IA mais rápido que qualquer outra coisa — uma resposta errada entregue com total confiança, e o time que defendeu o projeto passa o trimestre seguinte tendo que justificá-lo.
A solução não é um modelo melhor. É estrutural: exigir citações em tudo que for fundamentado nos seus dados, adicionar um limiar de confiança que direcione respostas incertas para um humano em vez de arriscar um chute, e registrar cada prompt, recuperação e completion para que você consiga reconstruir exatamente o que aconteceu quando algo dá errado. Tratamos essa camada de logging como inegociável, do mesmo jeito que trataríamos o registro de erros num fluxo de pagamentos. Ninguém repara nela até o dia em que precisa desesperadamente dela.
Automação interna é o retorno mais rápido de IA agora
Agentes voltados ao cliente chamam a atenção, mas o trabalho de IA com maior certeza de retorno que fazemos em 2026 é interno: triagem de tickets de suporte antes que um humano os veja, resumo de chamadas de vendas em notas de CRM, extração de itens de linha de faturas e contratos, e permitir que a equipe faça perguntas sobre documentos internos em vez de acionar alguém no Slack. O risco é menor — uma ferramenta interna que erra ocasionalmente é corrigida por um colega, não por um cliente — então as salvaguardas podem ser mais leves e o retorno chega mais rápido.
Um assistente de RAG com escopo definido sobre a documentação própria de uma empresa é, realisticamente, um projeto a partir de $7.000, com um protótipo funcional em 2 a 4 semanas, e uma versão pronta para produção — autenticação, logging, eval set, citação de fontes — em 8 a 12 semanas. Agentes que usam ferramentas conectados a sistemas reais (um CRM, um sistema de tickets, um ERP) começam a partir de $20.000, porque o trabalho de permissionamento e testes escala com o que o agente tem permissão para tocar. Automação de fluxos de trabalho pura — sem modelo envolvido, apenas movimentação confiável de dados entre ferramentas — começa mais barato, a partir de $3.000 para uma única integração.
O que exigimos antes de escrever o primeiro prompt
Em todo projeto de IA, quatro coisas são decididas antes de qualquer código ser lançado, não depois:
- Um responsável pelo eval set. Alguém cujo trabalho seja notar quando a qualidade cai, não "o time" de forma abstrata.
- Uma lista documentada de proibições. As ações específicas que o sistema nunca pode tomar sem a confirmação prévia de um humano.
- Um teto de custo. Orçamentos de tokens por usuário ou por dia, com alertas antes que a fatura surpreenda alguém. Triagem com modelo barato mais escalonamento para modelo de ponta, não modelo de ponta em tudo.
- Um plano de rollback. Provedores de modelos mudam de comportamento sob um nome de API estável com mais frequência do que os times esperam. Se a precisão cair após uma atualização silenciosa do fornecedor, você precisa de uma versão anterior do prompt e um score anterior do eval para comparar.
Ignore qualquer um desses pontos e o projeto não falha com estardalhaço — falha silenciosamente, semanas depois do lançamento, quando alguém percebe que o sistema vem errando com confiança há um tempo e ninguém estava de olho.
Conclusão
O modelo raramente é o gargalo em 2026. APIs de ponta da OpenAI e da Anthropic, combinadas com frameworks de recuperação como LlamaIndex e bancos de vetores como pgvector, são boas o suficiente para a esmagadora maioria dos casos de uso de negócio. O que determina se um recurso de IA sobrevive ao contato com usuários reais é a engenharia pouco vistosa ao redor dele: evals, fundamentação, permissões, logging, e um modelo de custo que não surpreende o financeiro.
É esse o trabalho que nosso time de IA e machine learning faz — transformar um demo funcional num sistema que uma empresa consegue realmente operar sem supervisão constante. Se o lado da automação interna for a sua maior necessidade — conectar ferramentas e eliminar trabalho repetitivo em vez de construir um novo recurso de IA — nosso time de automação e integrações avalia esses projetos da mesma forma: protótipo rápido, e reforço antes de tocar em qualquer coisa que importe de verdade.
