O Problema com o "Prompt & Pray" [Capítulo 3 - Série AI Deep Dives]
George
Cheif of AI na Moveo
10 de setembro de 2025
in
✨ AI Deep Dives
Chegamos ao Capítulo 3: "The Problem with Prompt & Pray"!
Nos capítulos anteriores, discutimos como os sistemas de IA podem ser orquestrados para executar processos de negócio complexos e vimos por que a arquitetura Multi-Agents System é superior à abordagem de Wrapper.
Agora, vamos aprofundar um erro ainda mais comum e perigoso: a crença de que um LLM (Large Language Model) “mais inteligente” pode resolver tudo sozinho.
Se a orquestração de agentes era a resposta para a fragilidade dos Wrappers, a próxima questão é: por que não podemos simplesmente confiar que o modelo mais avançado fará o trabalho de forma autônoma?
A resposta está nos riscos de alucinação e na incapacidade de um simples prompt de codificar a complexidade de um processo de negócio. Confira!
Apesar de sua capacidade fenomenal de produzir texto fluente e contextualizado, os LLMs são, em essência, caixas pretas.
Eles são difíceis de guiar ou depurar, e até mesmo modelos de ponta geram resultados confiantes, mas errados: respostas que parecem perfeitas, mas são factualmente ou processualmente falsas.
Exemplo: Um chatbot em um banco lê uma transação pendente como liquidada e diz a um cliente que seu "saldo disponível" é maior do que realmente é. A redação é impecável, mas o número está errado. Esse único deslize aciona uma reclamação, um chargeback e um rastro regulatório.
Em domínios regulados, como finanças, saúde ou cobranças, o custo de uma falsidade que soa plausível é inaceitável. Relatórios de governança e estudos de caso recentes (IAPP, Stanford Law School) continuam a sinalizar as alucinações como um risco sistêmico que deve ser mitigado por processos e controles, e não apenas por prompts.
→ Leia o capítulo 2 da série "AI Deep Dives": Wrappers vs. Multi-Agent Systems: O grande debate na IA Corporativa
Precisão de quase 100% não é negociável no cenário corporativo
Para funções críticas, as metas de precisão em finanças não são de 80-95%, elas se aproximam de 100%.
Se um chatbot de varejo informa um estoque errado 1% das vezes, é problema. Mas se o agente de um banco relata transações incorretamente 1% das vezes, as consequências são catastróficas. Isso leva à perda de confiança do cliente, a um aumento nas reclamações e a uma fiscalização pesada dos órgãos reguladores.
Cálculo rápido: Uma taxa de erro de 1% em 10.000 disputas de transação por mês resulta em 100 incidentes. Cada um deles é uma reclamação de cliente, uma recuperação manual e, potencialmente, uma visita de um auditor. As empresas não podem se dar ao luxo de correr esse risco.
A aposta no "Prompt & Pray" para estas funções essenciais é, portanto, uma estratégia falha que coloca em risco a reputação e a conformidade de qualquer empresa.
Prompts não codificam processos de negócio complexos
Etapas críticas como verificações de elegibilidade, autenticação de dois fatores (OTP/2FA), portões de consentimento, resolução de disputas, reembolsos, tentativas e limites de taxa são mais do que meras frases em um prompt, são fluxos de trabalho complexos.
Veja como seria tentar codificar um fluxo de disputa diretamente em um único "mega-prompt":
Tentativa de Prompt
"Quando um cliente disputa uma transação, primeiro verifique sua identidade. Se o cliente já estiver verificado na sessão, pule a verificação, mas, caso contrário, envie um OTP para seu dispositivo cadastrado e certifique-se de que o código corresponde. Depois disso, peça explicitamente o consentimento para prosseguir. Apenas se o consentimento for afirmativo e o OTP for validado, então chame a API de transação usando o ID de transação correto fornecido pelo usuário. Se o ID não corresponder a nenhuma transação conhecida, não prossiga. Finalmente, gere um recibo de confirmação, mas apenas após o sucesso da API."
À primeira vista, isso parece minucioso. Na prática, está repleto de ambiguidades:
O que exatamente conta como "já verificado"?
Como o modelo "se certifica" de que o código corresponde?
O que acontece se o usuário der um consentimento parcial (por exemplo, "talvez" ou "acho que sim")?
Como o modelo sabe que o ID da transação é válido antes da chamada da API?
E se a API falhar, deve tentar novamente reverter a operação ou escalar o problema?
A linguagem natural nunca foi projetada para codificar uma execução determinística, passo a passo. Pequenas mudanças na redação (como "pular a verificação se o usuário parecer verificado") podem levar a etapas ignoradas ou à aplicação inconsistente das regras.
É por isso que fluxos corporativos críticos não podem residir dentro de prompts. Eles devem ser modelados em fluxos de trabalho estruturados e com controle de versão, onde a ordem, o consentimento, a autenticação e o tratamento de erros são explícitos e aplicáveis.
Conforme destacado pela O'Reilly, sistemas eficazes exigem uma distinção clara entre interfaces conversacionais e a execução da lógica de negócio. A lógica de negócio deve ser gerenciada com o rigor do desenvolvimento de software tradicional: versionada, observável e testável.
Você sabe o que é RAG (Retrieval-Augmented Generation)? Descubra aqui!
Conformidade e segurança exigem reforço fora do modelo
Você pode instruir um modelo a "manter-se educado" ou "sempre verificar o consentimento". Mas prompts não são garantias. A conformidade exige portões rígidos e uma aplicação determinística fora do modelo:
Portões de consentimento: capture um "Sim/Não" explícito do cliente antes que qualquer coisa aconteça.
Autenticação: OTP/2FA deve ser validado por um motor de regras que verifica o código com o banco de dados. Não se pode confiar que um modelo "decida" se um código parece correto.
Validadores pré/pós: garantem que as saídas não sejam apenas bem formatadas (válidas em termos de esquema), mas também corretas no contexto (válidas em termos de negócio). Um ID de transação pode ter um formato perfeito, mas pertencer ao cliente errado ou à cobrança errada, e os validadores capturam isso.
Trilhas de auditoria: cada etapa (consentimento capturado, OTP verificado, ação executada) precisa ser registrada em um sistema que possa ser reproduzido. Isso não é apenas para depuração, é o que os reguladores esperam ao perguntar: "Você pode provar que isso foi feito corretamente?".
Sem isso, as empresas operam com base na confiança, não na prova, e os reguladores não aceitam confiança.
Como se livrar do "Prompt & Pray"
A chave para superar a armadilha do "Prompt & Pray" não é correr atrás do próximo grande modelo, é mudar a arquitetura. As empresas não precisam de "prompts mais inteligentes", precisam de sistemas projetados para previsibilidade, conformidade e robustez.
Aqui estão três maneiras práticas de fazer essa mudança:
1. Separe a lógica do modelo
O primeiro passo é separar sua lógica de negócio da camada do modelo. Em vez de tentar "ensinar" regras complexas ao LLM através de prompts, use o modelo para o que ele faz de melhor: entender perguntas, gerar respostas fluentes e manter um fluxo de conversa natural.
O processo de negócio em si (validação, autorização, autenticação) deve ser gerenciado por um motor de regras ou fluxo de trabalho determinístico, externo ao modelo.
Exemplo prático
Considere um sistema de disputa de transações. O LLM pode interagir com o usuário, coletar informações e mostrar empatia. No entanto, o fluxo de trabalho para verificação de identidade, confirmação de consentimento e criação do tíquete de disputa deve ser gerenciado por um sistema com regras e APIs predefinidas. O LLM atua como a interface, não como o executor.
2. Adote uma abordagem modular com agentes especializados
Como explorado no capítulo anterior, um Multi-Agent System é o antídoto para wrappers frágeis e mega-prompts. Cada agente tem uma responsabilidade estreita e bem definida. Essa decomposição torna o sistema mais fácil de testar, mais seguro de operar e muito mais confiável em escala.
O fluxo de trabalho do Multi-Agent Systems
Usuário: "Como faço para disputar uma cobrança de R$200?" (Pergunta inicial)
Agente de Planejamento: analisa a intenção do usuário e ativa o processo correto (ex: "Ativar fluxo de disputa de transação").
Agente de Resposta (LLM): mantém uma conversa fluida e empática, solicitando os detalhes necessários (ex: "Precisamos de mais detalhes sobre a cobrança de $200...").
Agente de Validação/Conformidade: garante que todas as políticas internas e regulamentações sejam seguidas (ex: "Verificar consentimento do usuário", "Confirmar identidade").
Agente de Execução/API: executa a tarefa de negócio no sistema de backend relevante (ex: "Criar um tíquete de disputa", "Notificar o banco sobre a solicitação").
Agente de Auditoria/Insights: registra cada etapa, categoriza os resultados (disputa, dificuldade financeira, ameaça legal) e mantém uma trilha de auditoria.
Essa arquitetura substitui prompts frágeis e de disparo único por fluxos de trabalho estruturados que aplicam ordem, conformidade e confiabilidade, garantindo que cada etapa seja executada da maneira que a empresa exige.
3. Crie uma cultura de governança e teste
Para transformar a IA de um experimento em um ativo de produção, você deve tratar o desenvolvimento de IA como o desenvolvimento de software tradicional. Isso significa implementar:
Versionamento: a lógica de negócio e as políticas devem ter controle de versão. Se uma regra muda, você deve poder rastrear a alteração e o impacto.
Observabilidade: monitore o comportamento dos agentes. Logs detalhados em cada etapa permitem auditar o fluxo e identificar falhas ou desvios de política.
Testes automáticos: não confie na fluidez do modelo. Crie casos de teste robustos para garantir que os fluxos de trabalho críticos (por exemplo, aprovação de crédito, processamento de disputa) sempre sigam as regras, independentemente da resposta do LLM.
Ao adotar essas práticas, você move sua equipe da mentalidade de "rezar para que o modelo acerte" para a confiança de que o sistema foi projetado para ser previsível, seguro e auditável.
→ Acesse a série completa "AI Deep Dives", clique aqui.
Não é um modelo mais inteligente, é um sistema mais inteligente
Prompting não é produção.
As demonstrações recompensam a fluência. As empresas recompensam as garantias. Um único mega-prompt pode mostrar inteligência, mas não pode impor ordem, garantir conformidade ou entregar robustez em escala. Isso exige arquitetura.
Os vencedores não serão aqueles que encontrarem os prompts mais inteligentes, mas sim aqueles que projetarem sistemas: agentes especializados, fluxos determinísticos e aplicação de políticas externalizadas. É assim que as empresas alcançam tanto experiências semelhantes às humanas quanto a confiabilidade de nível corporativo.
Não perca os próximos capítulos da nossa série "AI Deep Dives"! No Capítulo 4: "Cobrança de Dívidas: Por que a sensibilidade e a estrutura importam", exploraremos como a sensibilidade e a estrutura são cruciais em um processo tão delicado quanto a cobrança de dívidas.