LLM chegou às empresas como se fosse uma tecnologia só. Na prática, existem três padrões de uso com custos, riscos e manutenção bem diferentes: o copiloto, o RAG e a automação. A escolha entre eles não é preferência técnica, é decisão de investimento, e é onde a maior parte dos pilotos trava antes de chegar à produção.

O que cada padrão resolve de fato

Copiloto. O usuário continua no controle e a IA sugere dentro de uma ferramenta que já existe: redigir uma resposta, resumir um histórico, propor o próximo passo. O erro passa por revisão humana antes de virar efeito. O custo está na integração com a interface, na latência tolerável e no treinamento do time para revisar em vez de aceitar. Não exige acervo de conhecimento perfeito.

RAG (recuperação aumentada por geração). Serve para perguntas em linguagem natural sobre um acervo: contratos, políticas internas, manuais, laudos. O trabalho pesado não está no modelo, está no pipeline: curadoria das fontes, divisão dos documentos, rotina de atualização do índice e, principalmente, controle de permissão. Quem pode ver o quê precisa ser resolvido no índice, não no prompt.

Automação com LLM. O modelo executa uma etapa do fluxo sem humano no meio: classificar um chamado, extrair campos de um contrato, resumir um laudo para a etapa seguinte. Exige saída em formato fixo, validação por regra, caminho de fallback e trilha de auditoria. O risco real aqui não é a resposta ruim visível, é o erro silencioso que segue adiante e só aparece no fechamento do mês.

Como classificar o caso antes de escolher a tecnologia

  1. Qual é a ação no fim da linha? Se ninguém decide nem executa nada a partir da resposta, o teto é um copiloto.
  2. O erro é reversível e barato? Se não for, a automação precisa de validação determinística antes de gravar qualquer coisa no sistema de origem.
  3. A informação está em documento não estruturado? Então o gargalo é indexação e curadoria, não engenharia de prompt.
  4. Quem pode ver o quê? Permissão vive no índice, não na instrução do modelo.
  5. Existe forma de medir acerto? Sem um conjunto de avaliação com casos reais e respostas esperadas, não há como saber se a qualidade piorou depois de uma troca de modelo.

Exemplo: a distribuidora que começou pelo problema errado

Uma distribuidora de autopeças de porte médio tinha a política comercial espalhada em PDFs, planilhas e e-mails de exceção. O atendimento perdia tempo procurando a regra de frete e de desconto vigente para cada prazo e região, e respondia ao cliente com versões desencontradas. A primeira demanda interna foi um copiloto para redigir as respostas.

O diagnóstico mostrou que a escrita não era o gargalo. Localizar a regra vigente e saber qual versão valia era. A solução foi um RAG sobre a política versionada, com filtro por região e por canal, devolvendo o trecho de origem e a data de vigência para o atendente decidir. Depois, com o acervo já organizado, veio a automação de um passo isolado: classificar o motivo do contato e pré-preencher o formulário, com validação por regra e fallback para triagem manual quando a extração não fecha. O copiloto de redação ficou para o fim, quando o insumo já estava confiável.

Na prática

  • Versione prompts, índices e modelos como se fossem código. Mudança sem registro impede saber por que a resposta piorou.
  • Logue pergunta, trechos recuperados, resposta e ação tomada. Sem isso, a auditoria vira reconstrução de memória.
  • Trate o índice como dado de produção: rotina de reindexação, dono definido e alerta quando a base fica defasada.
  • Meça a taxa de escalonamento para humano. Ela é o termômetro mais honesto de qualidade em RAG e em automação.
  • Coloque o custo por requisição na conta do processo, não na conta de TI. Volume alto em fluxo automatizado muda a ordem de grandeza do projeto.
  • Comece pelo passo de menor risco e maior frequência. Ganho pequeno em volume alto costuma pagar melhor do que um caso sofisticado de uso único.