Copiloto vs. agente: por que a distinção importa mais que o termo da moda

Nos últimos dois anos, “agente” virou a palavra que quase todo fornecedor usa — às vezes para descrever um sistema que apenas responde a perguntas, às vezes para descrever um software que consulta ferramentas, decide os próximos passos e executa uma tarefa inteira. O resultado é que o termo ficou menos útil na conversa cotidiana. A distinção por trás dele, porém, continua importante.

O problema é que “copiloto” e “agente” não são categorias técnicas universais nem mutuamente exclusivas. Um copiloto pode incorporar recursos agentivos; um agente pode operar com aprovação humana em pontos críticos. O que importa não é o rótulo do produto, mas o modelo de operação: quem define o objetivo, quem escolhe o próximo passo, quem tem autoridade para agir e em que momento uma pessoa pode intervir.

Uma definição operacional

Uma regra prática separa os dois casos.

Um copiloto normalmente trabalha em um ciclo curto: a pessoa pede, o sistema busca, redige, resume ou recomenda, e a pessoa decide o que fazer em seguida. A iniciativa e a decisão final continuam predominantemente humanas. Um assistente de escrita, uma ferramenta de busca ou um recurso de autocompletar código se encaixam nesse modelo — mesmo quando usam os mesmos modelos de linguagem que sistemas mais autônomos.

Um agente recebe um objetivo e pode persegui-lo em várias etapas. Ele escolhe ou recebe ferramentas, executa ações, observa os resultados, ajusta o plano e continua até concluir a tarefa, atingir um limite ou pedir ajuda. O ciclo entre uma etapa e outra é fechado pelo sistema, não por uma aprovação humana a cada passo. Essa formulação é próxima da distinção feita pela Anthropic entre workflows, em que o caminho é pré-programado, e agentes, em que o modelo direciona dinamicamente o processo e o uso de ferramentas: Building effective agents.

A diferença, portanto, não é simplesmente “responde” versus “age”. É uma combinação de autonomia em dimensões diferentes:

• iniciativa: o sistema espera um pedido ou também reage a eventos e gatilhos;

• planejamento: segue uma sequência fixa ou decide a sequência durante a execução;

• uso de ferramentas: apenas sugere uma chamada ou a realiza;

• autoridade: lê e recomenda ou também altera registros, envia mensagens e movimenta recursos;

• persistência: termina após uma resposta ou mantém um ciclo de tentativa, observação e adaptação;

• supervisão: exige aprovação por ação, por classe de risco ou apenas em exceções.

Essa visão evita uma falsa dicotomia. Um fluxo pode ser agentivo no planejamento, mas exigir aprovação antes de qualquer alteração externa. Outro pode ser altamente automatizado, mas seguir um roteiro determinístico — e, nesse caso, talvez seja melhor chamá-lo de workflow ou automação do que de agente.

Por que a precisão importa

As duas configurações têm perfis de risco diferentes, embora nenhum dos dois seja automaticamente seguro.

O modo de falha típico de um copiloto é uma recomendação incorreta, incompleta ou mal fundamentada. Isso pode ser relativamente fácil de corrigir quando a pessoa realmente revisa o resultado. Mas “ter um humano no ciclo” não elimina o risco: estudos sobre automation bias mostram que usuários podem aceitar recomendações automatizadas com confiança excessiva, especialmente quando elas parecem fluentes, reduzem esforço ou aparecem em situações de pressão. Veja a revisão Exploring automation bias in human–AI collaboration.

O modo de falha de um agente inclui tudo isso e acrescenta efeitos operacionais: uma ferramenta usada com parâmetros errados, uma permissão ampla demais, uma sequência de ações que amplifica um erro, um loop que consome recursos, uma informação maliciosa que desvia o objetivo ou uma ação que já produziu efeito externo. É a diferença entre um erro de digitação num rascunho e um e-mail que já saiu — mas também entre um erro isolado e um erro que se propaga por vários sistemas.

O OWASP Top 10 for Agentic Applications chama atenção justamente para riscos como sequestro do objetivo, uso indevido de ferramentas, abuso de identidade e privilégios, envenenamento de memória, falhas em cascata e exploração da confiança humana. A questão deixa de ser apenas “o modelo respondeu errado?” e passa a incluir “o que o sistema conseguiu fazer depois dessa resposta?”.

Quando a autonomia compensa

Isso não é um argumento contra agentes. É um argumento a favor de delegação calibrada.

A autonomia tende a fazer sentido quando o objetivo é claro, o processo é frequente, as ações são observáveis, o resultado pode ser verificado e os efeitos são reversíveis ou limitados. Triar tickets para a fila correta, reunir informações de várias fontes, preparar um primeiro relatório de status, investigar uma falha em um ambiente de testes ou sugerir uma resposta interna são bons candidatos — desde que o acesso e os critérios de sucesso estejam bem definidos.

Mas nem todo trabalho com várias etapas precisa de um agente. Um relatório que reúne dados de cinco sistemas pode ser resolvido por uma integração determinística ou por uma busca com síntese. A pergunta não é “há múltiplos passos?”, e sim “o sistema precisa decidir dinamicamente quais passos executar e agir sobre o ambiente para alcançar um objetivo?”. Essa distinção evita adicionar autonomia — e risco — onde uma automação mais simples seria suficiente.

Quando manter uma pessoa na decisão

Ações financeiras, comunicação externa, mudanças em produção, acesso a dados sensíveis e decisões que afetam direitos ou relacionamento com clientes merecem controles proporcionais ao impacto. Isso não significa que devem permanecer para sempre no modo copiloto. Significa que a autonomia deve ser limitada por políticas: alçadas, valores máximos, escopo de dados, listas de destinatários, ambientes permitidos, amostragem, escalonamento e aprovação para ações irreversíveis.

Na prática, há mais de um modelo de supervisão:

• human-in-the-loop: uma pessoa aprova antes da ação de maior impacto;

• human-on-the-loop: o sistema age dentro de limites predefinidos e uma pessoa monitora, interrompe ou trata exceções;

• supervisão por política: o sistema executa apenas ações que passam por regras, limites e verificações automatizadas.

A documentação do Google Cloud sobre padrões de sistemas agentivos recomenda inserir intervenção humana em pontos de decisão críticos e destaca três princípios de segurança: supervisão humana, autonomia cuidadosamente definida e observabilidade. O perfil de IA generativa do NIST complementa essa abordagem ao recomendar papéis claros de supervisão, avaliação contínua, monitoramento pós-implantação, mecanismos de substituição e resposta a incidentes.

A pergunta que vale mais que o rótulo

Ao avaliar uma ferramenta, pare de perguntar apenas “isso é um agente?”. Pergunte:

• Qual objetivo o sistema pode perseguir?

• Quais ferramentas, dados e credenciais ele pode usar?

• Quem autoriza cada classe de ação?

• Qual é o pior resultado plausível — e qual é o raio de impacto?

• Como o erro será detectado, interrompido, explicado e revertido?

• Existe uma trilha que registre o objetivo, o contexto, as ferramentas chamadas, as decisões e a intervenção humana?

• O sistema tem limites de tempo, custo, número de etapas e destinatários?

Essas perguntas convertem uma discussão de marketing em uma decisão de arquitetura e governança. Também tornam comparáveis produtos que usam rótulos diferentes.

A recomendação prática é começar pelo modo de falha, não pelo nível máximo de autonomia. Escolha primeiro um fluxo delimitado, meça a qualidade e a taxa de exceção, aplique permissões mínimas, registre as execuções e aumente a alçada apenas quando os dados justificarem. Dê ao agente autonomia onde o erro é detectável e reversível; mantenha aprovação onde o impacto é alto, difícil de desfazer ou difícil de atribuir.

Prefiro ver uma equipe lançar um copiloto bem delimitado, que realmente seja usado, do que um “agente” ambicioso que vire revisão manual em um mês porque ninguém decidiu o que acontece quando ele erra. A tecnologia pode ser a mesma. O que muda é a autoridade concedida, a forma de supervisão e o custo de uma falha.