Blog
Agentes de IA em processos de negócio: o que o código precisa garantir
Um problema comum
Imagine um assistente de IA que participa de reuniões comerciais. Ao final, ele gera um resumo com os pontos discutidos. No resumo, aparece uma frase entre aspas, atribuída a um dos participantes: "o orçamento está fechado para este trimestre."
Ninguém disse isso. A frase soa plausível, tem o tom certo e encaixa no contexto da reunião. Mas é uma invenção do modelo. Você não tem como saber, a menos que volte à gravação inteira e confira frase por frase, o que anula o motivo de ter um assistente.
Esse tipo de erro não é raro nem exótico. É um comportamento esperado de modelos de linguagem: eles são treinados para produzir texto coerente, não para verificar se cada afirmação é verdadeira. Quando o texto vira uma citação atribuída a uma pessoa real, um número usado numa decisão comercial ou um status reportado a um cliente, coerência não basta. É preciso garantia.
Por que colocar a regra no prompt não resolve
A resposta mais comum para esse problema é instrução: "cite só o que foi dito, nunca invente uma fala." Funciona em boa parte dos casos. Falha em alguns. E falha exatamente nos casos que mais importam, porque não há como prever quando o modelo vai obedecer.
Isso acontece por um motivo estrutural. Uma instrução no prompt é um pedido, não uma restrição. O modelo processa o pedido como mais um texto de entrada, ao lado da transcrição, do histórico da conversa e de tudo mais que compõe o contexto. Nada no funcionamento do modelo impede que ele gere uma saída que contraria a instrução. A cada geração, existe uma probabilidade de a regra ser ignorada, e essa probabilidade não chega a zero só porque a frase foi escrita com mais ênfase, repetida duas vezes ou movida para o topo do prompt.
Isso vale para qualquer regra que dependa de fidelidade ao dado de origem: citar só o que foi dito, calcular só o que pode ser calculado, não misturar inferência com fato. Prompt bem escrito reduz a frequência do erro. Não elimina o erro. Para eliminar, ou pelo menos capturar o erro antes que ele chegue a quem lê, a garantia precisa sair do texto da instrução e virar código que roda depois da geração, sobre a saída do modelo.
A arquitetura de garantias
Divido essa garantia em quatro camadas. Cada uma resolve uma parte do problema, e nenhuma substitui as outras.
Entrada. Antes de qualquer geração, o sistema define o que existe como evidência e o que não existe. Uma transcrição de reunião, um registro de sistema, uma nota inserida por uma pessoa: cada um tem uma origem rastreável. Dados de um cliente ficam isolados dos dados de outro cliente neste ponto, por controle de acesso, não por instrução ao modelo. Se a separação falhar aqui, nenhuma camada seguinte consegue corrigir isso.
Geração. O modelo produz o resumo, a sugestão ou a síntese. Essa camada assume, por padrão, que a saída pode conter erro, invenção ou mistura entre o que é evidência e o que é interpretação do modelo. Ela não é tratada como resultado final. É tratada como rascunho a verificar.
Validação. Aqui entra o código que checa a saída antes de ela seguir adiante. Uma citação atribuída a alguém é comparada, palavra por palavra, com a transcrição de origem. Se não bate, o sistema descarta a citação ou pede uma nova geração, com um número limitado de tentativas. Um número apresentado como métrica passa por essa camada com uma regra simples: se não veio de um cálculo determinístico sobre dados reais, ele é removido da saída. Não existe meio-termo de "número aproximado, mas informativo." Ou o número foi calculado, ou não aparece.
Apresentação. Mesmo depois de validada, a saída chega à interface com marcação visível: isto é evidência direta da fonte, isto é inferência do modelo, isto é observação inserida por uma pessoa. As três coisas não se misturam visualmente. Você sabe, olhando, o grau de confiança de cada trecho, sem precisar confiar cegamente no sistema inteiro.
Nenhuma camada é opcional. Um validador sem uma camada de apresentação clara ainda entrega um texto onde fato e hipótese parecem iguais. Uma apresentação cuidadosa sem validação ainda deixa passar uma citação inventada, só que agora rotulada como se fosse confiável.
Como testar isso
Garantia que não foi testada é promessa, não garantia. Nos projetos onde apliquei esse método, testei essas camadas com casos nomeados, e o requisito mais importante não é o caso que deve passar. É o caso negativo, que precisa falhar do jeito certo.
Alguns exemplos de casos que uso como referência:
- Citação verbatim presente na fonte. Uma fala existe, palavra por palavra, na transcrição. O validador aceita e a citação segue para a saída.
- Citação inventada (caso negativo). O modelo gera uma fala plausível que não existe na transcrição. O validador precisa rejeitar essa saída e disparar uma nova tentativa, não deixar passar porque "parece razoável."
- Citação atribuída à pessoa errada (caso negativo). A fala existe na transcrição, mas foi dita por outra pessoa. O teste verifica que o validador checa autoria, não só a existência da frase.
- Número resultado de cálculo determinístico. Uma métrica vem de uma soma ou de uma consulta direta ao banco de dados. Ela passa como está.
- Número estimado pelo modelo (caso negativo). O modelo tenta apresentar uma estimativa como se fosse um valor calculado. O teste confirma que essa saída é removida ou sinalizada, nunca apresentada como se fosse exata.
- Vazamento entre clientes (caso negativo). Um teste tenta fazer uma consulta de um cliente retornar, mesmo que parcialmente, um dado de outro. Esse teste tem que falhar sempre, sem exceção: é o tipo de teste que precisa rodar antes de qualquer mudança ir para produção.
Uma suíte de testes que só cobre o caminho feliz não prova nada sobre o que acontece quando o sistema é forçado a errar. O valor real está nos casos que deveriam falhar e falham do jeito esperado.
O que isso custa, e quando vale
Construir essas quatro camadas custa mais do que escrever um prompt bem redigido. Exige código de validação, uma suíte de testes com casos negativos, uma camada de apresentação desenhada para distinguir tipos de conteúdo e, geralmente, uma lógica de nova tentativa quando a validação falha. Isso significa mais tempo de engenharia antes de colocar um agente em produção, e uma manutenção contínua conforme o sistema evolui.
Esse custo não faz sentido para toda aplicação de IA. Uma ferramenta interna de rascunho, revisada por uma pessoa antes de qualquer uso, tolera mais erro, porque existe uma revisão humana entre a saída do modelo e a decisão final. Um resumo informal, sem consequência prática, também tolera.
O custo vale quando a saída do agente influencia uma decisão de negócio, aparece atribuída a uma pessoa real, envolve dados de mais de um cliente no mesmo sistema, ou é apresentada a alguém que não tem como verificar a fonte original antes de agir sobre ela. Nesses casos, o preço de um erro que passa despercebido é maior do que o custo de construir a garantia. É esse critério, e não o entusiasmo com o que a IA consegue gerar, que decide onde vale colocar código de verificação e onde um bom prompt já é suficiente.