A conversa sobre IA aplicada costuma começar pelo modelo. Deveria começar pelo processo. Copiloto, RAG e automação com LLMs são três formas distintas de inserir um modelo de linguagem no fluxo de trabalho, e cada uma resolve um tipo de problema, com exigências próprias de avaliação, rastreabilidade e tratamento de erro. Escolher o padrão errado gera um sistema que parece funcionar na demonstração e cobra a conta na operação.

Três padrões, três problemas distintos

  • Copiloto: o usuário conduz a tarefa e o modelo acelera. Faz sentido quando o julgamento humano é parte do valor entregue (revisão de contrato, redação de proposta, atendimento a casos sensíveis). O erro aparece na tela e é corrigido na hora, o que reduz o custo de uma resposta ruim.
  • RAG: pergunta em linguagem natural sobre uma base documental fechada (políticas internas, manuais, contratos, catálogo técnico). A resposta precisa vir com a fonte consultada, e a resposta correta para uma pergunta fora da base é "não encontrado".
  • Automação com LLM: entrada não estruturada, saída estruturada, sem humano no meio. Extração de itens de nota fiscal, triagem de chamados, classificação de e-mails. Exige schema rígido, validação e uma fila de exceções para o que não passar na validação.

Uma mesma empresa costuma precisar dos três, mas não no mesmo processo. O erro mais comum é misturar: usar automação onde o julgamento importa, ou copiloto onde a tarefa é repetitiva e mensurável.

O exemplo de uma distribuidora

Uma distribuidora de médio porte recebe pedidos por e-mail e WhatsApp em texto livre e mantém as políticas de desconto em PDFs espalhados por pastas. Três dores convivem no mesmo time comercial. O vendedor precisa responder rápido sobre desconto e condições, e a resposta tem que citar a cláusula vigente: isso é RAG. O pedido chega em linguagem solta e precisa virar linha de pedido no ERP, com código de produto e quantidade: isso é automação com saída estruturada. O contrato de um cliente grande passa por revisão jurídica antes de assinar: isso é copiloto.

Se os padrões forem trocados, o dano é concreto. Um RAG respondendo pedido livre gera item errado no ERP e erro silencioso no faturamento. Uma automação respondendo dúvida de desconto inventa cláusula que não existe e cria compromisso comercial que a empresa não assumiu. E um copiloto usado como extração em massa transforma cada exceção em trabalho manual não previsto. O efeito colateral mais caro, no entanto, é a perda de confiança: depois do primeiro erro visível, a equipe volta ao processo antigo e o investimento fica parado.

O que cada padrão exige para não quebrar

  • Conjunto de avaliação com casos reais: perguntas, entradas e saídas esperadas, rodado a cada mudança de prompt ou de versão de modelo. Sem isso, toda alteração é aposta.
  • Rastreabilidade: registro da entrada, dos trechos recuperados no RAG e da saída gerada. É o que permite explicar um resultado errado semanas depois.
  • Contrato de saída: JSON schema para automação, validação de campos e rejeição para fila humana quando a confiança for baixa.
  • Custo por operação: tokens, chamadas de embedding e reindexação. Automação de alto volume é sensível a esse número; copiloto de baixo volume, quase nunca.
  • Dono da base de conhecimento: alguém responsável por atualizar o índice do RAG quando a política muda, com prazo definido. Base desatualizada produz resposta confiante e errada.

Na prática

Antes de escolher o modelo, descreva a tarefa em uma frase e responda três perguntas: quem decide o resultado final, a resposta precisa vir de um documento existente e a saída precisa ter formato fixo. As respostas apontam para copiloto, RAG ou automação, nessa ordem.

Em produção, trate cada padrão como um componente com contrato próprio. O copiloto precisa de interface que deixe claro o que é sugestão. O RAG precisa exibir a fonte e saber recusar. A automação precisa falhar para uma fila visível, com contexto suficiente para uma pessoa resolver. E os três precisam de uma rotina de reavaliação sempre que o prompt, a base ou o modelo mudarem, porque o comportamento de um LLM muda sem aviso e sem deploy.