Muita empresa trata "usar IA" como um único projeto. Na prática, copiloto, RAG e automação com LLMs são três padrões distintos, com custos, riscos e formas de manutenção diferentes. Escolher o padrão errado para o processo errado é a causa mais comum de piloto que nunca vira produção.

Três padrões, três contratos diferentes com o usuário

O que separa os casos não é a tecnologia, e sim quem responde pelo erro.

  • Copiloto: o modelo sugere, o humano decide e assina. Vive dentro da ferramenta onde o trabalho já acontece (CRM, editor de código, sistema de atendimento). Erro é barato porque passa por revisão antes de sair.
  • RAG (Retrieval-Augmented Generation): o modelo responde com base em documentos da própria empresa. O sistema recupera trechos relevantes de uma base (políticas, catálogo, contratos, procedimentos) e injeta no contexto antes de gerar a resposta. Serve para perguntas cuja resposta existe, mas está espalhada em arquivos e sistemas.
  • Automação com LLM: o modelo executa uma etapa do fluxo sem humano no meio, como classificar um e-mail, extrair campos de um PDF ou rotear um ticket. Aqui o erro chega ao cliente ou ao ERP, então exige validação, limites e caminho de exceção.

Misturar os três no mesmo escopo é o que produz cronograma irreal. Copiloto se mede por adoção. RAG se mede por precisão da recuperação. Automação se mede por taxa de exceção.

O caso de uma distribuidora de autopeças

Uma distribuidora de médio porte tem um time comercial que responde a um volume alto de pedidos de cotação por e-mail. As informações estão espalhadas: tabela de preços em planilha, política de desconto por cliente em PDF, histórico de compra no ERP.

O processo atual é manual: o vendedor abre três sistemas, monta a resposta e às vezes aplica o desconto errado porque a regra mudou e ninguém avisou.

A solução foi dividida nos três padrões:

  1. RAG sobre catálogo, tabelas de preço e políticas. O vendedor pergunta o preço do item para determinado cliente e recebe a resposta junto com o trecho do documento que a sustenta.
  2. Copiloto no cliente de e-mail: sugere o rascunho da cotação com itens e valores, e o vendedor revisa antes de enviar.
  3. Automação para os e-mails em formato padronizado: o modelo extrai os itens e joga numa fila de conferência, em vez de digitar tudo de novo.

O ganho não veio do modelo, veio de tirar a consulta de três telas e colocar a regra comercial no lugar certo. O erro de desconto caiu porque a política passou a ser citada junto da sugestão, e não memorizada pelo vendedor.

O que decide se isso sobrevive em produção

  • Qualidade e atualização do dado. RAG sobre documento desatualizado entrega resposta confiante e errada. A base precisa de dono e rotina de revisão.
  • Rastreabilidade. Toda resposta deve apontar a fonte consultada. Sem isso, ninguém confia e o recurso é abandonado.
  • Custo e latência por chamada. Eles definem onde usar modelo maior e onde um menor resolve.
  • Avaliação contínua. Um conjunto de perguntas com resposta esperada, rodado a cada mudança de prompt ou de base, funciona como teste de regressão.
  • Comportamento na incerteza. O sistema precisa saber dizer que não sabe, abrir um ticket ou escalar para humano.
  • Guardrails e LGPD. Definir o que pode entrar no prompt, o que precisa ser mascarado e o que fica registrado em log.

Na prática

Para quem mantém software rodando, um LLM é uma dependência de terceiro como qualquer API externa: precisa de timeout, retry idempotente, cache para consultas repetidas e um plano para quando o provedor degradar. Prompt e base de conhecimento devem ser versionados como código, com revisão e rollback, não ajustados direto no ambiente de produção. Coloque feature flag em todo ponto que chama o modelo, para poder desligar sem deploy, e monitore consumo de tokens, latência e taxa de exceção junto com os demais indicadores do sistema. Comece sempre pelo fluxo com revisão humana e só remova o humano depois de medir o erro real em produção, não o erro do laboratório.