Copiloto, RAG e automação resolvem problemas de naturezas diferentes
Copiloto, RAG e automação com LLMs aparecem juntos em qualquer apresentação sobre IA aplicada, mas são três decisões de engenharia distintas, com riscos distintos:
- Copiloto: sugere texto, resposta ou trecho de código dentro do fluxo de trabalho, e a pessoa decide o que aproveita. O erro custa tempo e qualidade, não uma transação errada.
- RAG: o modelo responde ancorado em documentos da própria empresa, recuperados no momento da pergunta. O risco está na base: documento vencido, trecho de acesso restrito, recuperação que traz o arquivo errado.
- Automação com LLM: o modelo executa uma etapa sem revisão humana, como classificar um e-mail, extrair campos de um contrato ou registrar um chamado. O erro tem consequência operacional direta e exige auditoria, limite de escopo e ponto de reversão.
O erro mais comum é usar automação onde cabia copiloto. O processo ganha um revisor humano informal no meio, alguém que confere tudo depois, e o ganho desaparece.
A base vem antes do prompt
Na prática, a maior parte do trabalho de um projeto de IA aplicada está fora do modelo.
- Documento com dono. Alguém responsável por manter atualizada a política comercial, o procedimento interno e o contrato-modelo que alimentam o índice.
- Permissão na recuperação. O filtro de acesso precisa entrar na consulta ao índice, não apenas na interface. Sem isso, o RAG entrega o documento certo para a pessoa errada.
- Conjunto de avaliação. Perguntas reais, incluindo as ambíguas, rodadas a cada mudança de prompt, de modelo ou de indexação, para medir regressão.
- Observabilidade. Registrar pergunta, trechos recuperados, resposta, latência e custo por chamada.
- Plano de saída. O que acontece se o provedor falhar, mudar o comportamento do modelo ou reajustar preço.
Exemplo: distribuidora com a política comercial espalhada
Numa distribuidora de insumos, o time comercial respondia prazo por região, condição de pagamento e limite de desconto consultando uma pilha de PDFs e planilhas. O tempo de resposta dependia de quem sabia onde procurar, e a política mudava todo mês.
A primeira tentativa, um copiloto com todos os arquivos colados no prompt, funcionou na demonstração e falhou na operação: resposta baseada em versão vencida da tabela e um vendedor lendo condição de pagamento de outra regional.
O caminho que funcionou foi RAG com ingestão versionada (cada documento com data de vigência), filtro de acesso por regional na recuperação e respostas sempre citando o documento de origem. O copiloto continuou existindo, mas com a base organizada atrás. A automação ficou restrita ao pré-atendimento de pedidos de baixo risco, com fila de exceção para o que o modelo não classificou com confiança.
O custo que o piloto não mostra
Piloto de IA é barato. Operação não é. Os custos que aparecem depois:
- Reindexação quando documentos mudam de formato ou de sistema de origem.
- Ajuste de prompt a cada versão de modelo, porque o comportamento não é estável entre versões.
- Suporte a usuário que confia demais na resposta e não confere a citação.
- Revisão de escopo quando o fornecedor muda limite de uso ou preço por token.
Na prática
Para quem mantém software em produção com IA embutida, algumas rotinas separam o que aguenta o dia a dia do que só funciona em demonstração:
- Trate prompt, índice e conjunto de avaliação como artefatos versionados no mesmo repositório do código.
- Faça a resposta citar a fonte e mostre a citação na interface. Isso muda o comportamento de quem usa.
- Deixe ação irreversível atrás de confirmação humana explícita.
- Meça custo por interação e latência desde o primeiro dia, não quando a conta chega.
- Defina um dono de produto para a funcionalidade. Copiloto sem dono vira recurso esquecido com custo mensal.