Três padrões, três tipos de risco

Copiloto, RAG e automação com LLM costumam ser tratados como sinônimos de "projeto de IA", mas resolvem problemas diferentes e falham de formas diferentes.

No copiloto, o modelo sugere e a pessoa decide. O risco é de adoção: se a sugestão erra com frequência, o time passa a ignorar a ferramenta e o investimento morre por desuso. O custo de um erro isolado, porém, é baixo, porque existe revisão humana antes da ação.

No RAG, o modelo responde consultando documentos da empresa (contratos, políticas, catálogo técnico, base de conhecimento). O risco está na recuperação: quando o trecho correto não é encontrado, a resposta sai segura e errada. A qualidade depende menos do modelo escolhido e mais da curadoria do acervo, da granularidade dos trechos e de o sistema citar a fonte.

Na automação com LLM, o modelo executa uma ação sem revisão caso a caso: classifica um chamado, extrai dados de um e-mail, monta uma proposta. Aqui o risco é operacional e financeiro, e o desenho precisa prever validação, limites de atuação e reprocessamento.

O erro mais comum é escolher o padrão pelo entusiasmo, não pelo processo: colocar copiloto onde a regra já era determinística, ou tentar automatizar de ponta a ponta um processo cujo conhecimento nunca foi documentado.

O que decide a escolha

Cinco perguntas resolvem a maior parte das decisões:

  1. Qual o custo de um erro não detectado? Se a resposta errada gera prejuízo jurídico ou financeiro direto, comece com copiloto e revise antes de automatizar.
  2. Existe fonte de verdade consultável? Sem acervo organizado, RAG vira gerador de texto plausível. Documentar é pré-requisito, não etapa posterior.
  3. O processo é repetitivo e bem delimitado? Quanto mais estável a entrada, mais a automação compensa; quanto mais aberta a pergunta, mais o copiloto faz sentido.
  4. A ação é reversível? Cancelar um rascunho é barato; corrigir um pedido faturado não é.
  5. Quem assume a revisão? Se ninguém, o processo precisa de validação automática por regra, não de confiança no modelo.

Na prática, os padrões se combinam. Um caminho comum é começar com copiloto, medir onde as pessoas corrigem a sugestão e, quando a taxa de correção cai e as regras ficam claras, mover aquela etapa para automação com trilho de validação.

Exemplo em uma distribuidora

Uma distribuidora de autopeças que atende oficinas por WhatsApp precisa responder prazo de entrega, disponibilidade e política de troca. Um LLM solto, sem acesso a dados, inventa prazo. Com RAG sobre a tabela de prazos por região e o regulamento comercial, a resposta cita a fonte e o atendente confere em segundos.

O mesmo canal recebe pedidos em texto livre. Aí o padrão muda: emitir pedido é automação. O sistema precisa extrair item, quantidade e condição de pagamento, validar o SKU no cadastro, checar limite de crédito e só então gravar. Se a validação falha, o pedido vai para uma fila de exceção com o texto original anexado. O custo de token dessa operação é irrelevante perto do custo de uma nota fiscal errada, que volta como devolução, frete perdido e retrabalho de logística.

Na prática

Para quem mantém software em produção, alguns hábitos evitam a maior parte dos problemas:

  • Trate cada integração com LLM como integração com contrato: versão de prompt, versão de modelo, log de entrada, saída e fontes recuperadas.
  • Separe a camada de decisão da camada de execução. O modelo propõe, a regra de negócio valida, o sistema grava.
  • Meça a taxa de correção humana por etapa. É o indicador que mostra se o padrão escolhido está maduro para reduzir supervisão.
  • Tenha um caminho de saída: se o provedor mudar preço, limite ou qualidade, o processo precisa continuar rodando com revisão manual.
  • Deixe explícito no sistema qual padrão está em uso em cada etapa. Isso evita que uma automação nasça sem validação porque alguém a confundiu com um copiloto.