Muita empresa brasileira avalia copiloto, RAG e automação com LLM como três projetos independentes, cada um medido pela qualidade da demonstração. Em produção, eles são camadas da mesma stack e cobram manutenção de formas diferentes. O fator que decide o resultado raramente é o modelo: é a qualidade do contexto que o sistema consegue entregar e a disciplina de avaliar e monitorar as respostas depois do go-live.

Copiloto: produtividade que depende do contexto que o sistema expõe

Copiloto é a camada mais simples de começar e a mais fácil de virar decepção. Ele funciona quando a aplicação já sabe o que o usuário está fazendo: qual cliente está aberto na tela, qual pedido está em edição, qual é o histórico de atendimento. Se essa informação só existe na cabeça do operador ou em uma planilha paralela, o copiloto preenche a lacuna com texto genérico.

O trabalho de engenharia aqui é expor contexto: endpoints internos que devolvem dados do cliente, regras de negócio em formato consultável e um contrato claro do que o copiloto pode sugerir. A decisão continua com a pessoa. Um copiloto que redige a resposta ao cliente e cita a política vigente economiza tempo; um que inventa prazo de entrega cria prejuízo.

RAG: a resposta é tão boa quanto o acervo que a sustenta

RAG resolve um problema específico: responder com base em documentos internos que mudam com frequência (políticas comerciais, contratos, catálogo técnico, atas). O modelo não decora o conteúdo, ele consulta um índice. Isso significa que a manutenção do acervo passa a ser parte do sistema:

  • Indexar documentos com filtro por permissão, para que cada área recupere apenas o que pode ver.
  • Versionar o índice e reprocessar quando uma política muda, senão a resposta antiga continua circulando com aparência de atual.
  • Exigir citação da fonte na resposta, o que permite auditoria e reduz alucinação.
  • Tratar documento desatualizado como bug, não como conteúdo aproximado.

Esse último ponto é onde muita implementação tropeça. O índice não se atualiza sozinho a partir da intranet, e uma cláusula revogada recuperada com confiança faz mais estrago do que uma resposta admitindo que não encontrou a informação.

Automação com LLM: ganho real exige validação determinística

Automação com LLM faz sentido quando a entrada é texto livre e a regra não cabe em expressão regular: triagem de chamados, classificação de e-mails, extração de campos de um PDF de nota fiscal. O erro comum é deixar o modelo executar a ação final. O desenho mais seguro separa decisão e execução: o modelo classifica, extrai e propõe, e o código valida contra o schema, aplica a regra de negócio e executa com idempotência.

Em ações irreversíveis (cancelar pedido, emitir cobrança, liberar acesso) o fluxo precisa de aprovação humana, log da decisão e um caminho de fallback determinístico para quando o provedor estiver lento ou fora do ar. Sem isso, a automação transforma uma fila em um incidente.

Um exemplo: uma distribuidora que recebe pedidos por e-mail, telefone e representante externo. A triagem manual consumia o dia do time comercial, e a política de desconto era consultada em sistemas diferentes. A empresa não trocou o ERP: aplicou RAG sobre as políticas comerciais, colocou um copiloto dentro do CRM para sugerir condições e automatizou a classificação e o cadastro inicial dos pedidos recebidos por e-mail, com revisão humana antes da confirmação. O ganho não veio do modelo, veio de deixar o contexto disponível e o processo auditável.

Na prática

Para quem mantém software em produção, quatro rotinas separam piloto de sistema:

  1. Trate prompt, versão de índice e configuração de modelo como artefatos versionados, com revisão e histórico, não como texto editado direto no ambiente.
  2. Monte um conjunto de casos reais com resposta esperada e rode esse conjunto antes de cada mudança, medindo acerto, custo e latência.
  3. Registre entrada, saída, fontes recuperadas e versão do modelo em log, o que atende auditoria e investigação de incidentes.
  4. Revise o envio de dados ao provedor sob a ótica da LGPD: o que sai, por quanto tempo fica retido, qual cláusula contratual cobre o tratamento e como o sistema se comporta se for preciso trocar de fornecedor.