Seus agentes de IA precisam de descrições de cargo, não de prompts melhores

Pergunte a uma empresa o que uma nova analista de contas a pagar pode fazer, e você receberá uma resposta precisa. Ela trabalha nestes sistemas, com estes fornecedores, e qualquer valor acima de um limite de aprovação, digamos, de $10,000, vai para o gerente dela assinar. Ela fica em período de experiência durante os primeiros meses. Tudo isso costuma constar de uma matriz de delegação de autoridade, que a auditoria interna verifica todos os anos.

Pergunte à mesma empresa o que seu novo agente de processamento de faturas pode fazer, e muitas vezes você receberá uma captura de tela de um prompt.

Essa lacuna me incomoda mais do que qualquer benchmark de modelos. Estamos contratando uma força de trabalho digital sem o sistema de gestão que levamos um século para construir para as pessoas: ninguém registra sua autoridade, ninguém testa seu discernimento antes de começar e ninguém ensaiou como desligá-la.

Por que um prompt não dá conta do recado

Um prompt descreve a intenção. Diz para que serve o agente. Raramente diz o que ele nunca pode fazer, quais são seus limites ou quando precisa parar e deixar a decisão a cargo de uma pessoa.

E, mesmo quando um prompt diz essas coisas, nada as faz valer. Uma linha que instrui um agente a não emitir reembolsos acima de $500 é um pedido a um sistema probabilístico. Nenhum auditor aprovaria “pedimos com jeitinho à analista” como controle para uma pessoa, então não entendo por que aceitamos isso para um software.

O pessoal de segurança já tem um nome para esse resultado. A lista OWASP Top 10 for LLM Applications classifica a autonomia excessiva como um risco central, decorrente de funcionalidade excessiva, permissões excessivas ou autonomia excessiva. Em termos simples, é como entregar a um funcionário as chaves de tudo logo no primeiro dia. As orientações da OWASP parecem uma lista de verificação de um bom gerente: dê ao agente apenas as ferramentas de que precisa, delimite suas permissões, exija aprovação humana para ações de alto impacto e faça valer a autorização nos sistemas subsequentes, em vez de confiar que o modelo se controle sozinho.

Eu sublinharia esse último ponto. A concessão de autoridade precisa estar onde a ação ocorre: na identidade de serviço própria do agente, nas permissões de suas ferramentas e no limite de gastos definido no gateway da API. Executar agentes com uma conta de serviço compartilhada é como cinco pessoas compartilharem o mesmo crachá. Quando algo dá errado, o registro de auditoria diz que foi a conta de serviço, e você fica tentando adivinhar qual agente foi.

Os cancelamentos parecem um problema de gestão

A Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, citando custos crescentes, valor comercial pouco claro e controles de risco inadequados.

O hype e a imaturidade dos produtos fazem parte dessa história. Ainda assim, experimente ler as três causas como faria um diretor de operações. Os custos aumentam quando ninguém define um orçamento. O valor continua indefinido quando ninguém registra o que o trabalho deveria produzir. Os controles de risco são insuficientes quando não há limites, revisões nem ninguém claramente responsável. A Gartner não apresenta a questão dessa forma; essa é a minha interpretação. É o mesmo que acontece quando as pessoas são deixadas à própria sorte, sem um sistema de gestão, e esse problema é muito mais antigo que a IA.

As estruturas de referência identificam a mesma lacuna. O Framework de Gestão de Riscos de IA do NIST trata Governança como a função que permeia Mapear, Medir e Gerenciar, e seu Perfil de IA Generativa estende essa abordagem aos sistemas generativos. O que as estruturas de referência não podem oferecer é a engrenagem operacional: as concessões, os testes e as revisões que uma equipe realmente executa em uma terça-feira. Sem isso, a governança continua sendo um PDF em uma unidade compartilhada.

Como aplicar aos agentes as antigas ferramentas de gestão

Comece pela descrição do cargo, que, no caso de um agente, se torna uma concessão de autoridade. Antes de um agente acessar um sistema em produção, alguém deve conseguir redigir uma página que especifique o que ele pode fazer, o que nunca pode fazer, seus limites de aprovação, qual pessoa é responsável por ele e quem pode ampliar seus limites. Na matriz RACI, a parte responsável pela prestação de contas é uma pessoa. Se você não consegue escrever essa página, a função não está pronta para ser preenchida — e diria o mesmo de uma contratação humana.

Duas regras antigas de delegação de autoridade continuam valendo. Não se pode delegar uma autoridade que não se possui; portanto, um subagente nunca deve receber uma concessão mais ampla que a do agente que o criou. A segregação de funções também continua valendo. Um agente capaz de cadastrar um fornecedor e pagar esse mesmo fornecedor configuraria a mesma constatação de auditoria que se fosse uma pessoa.

Depois, há o teste de contratação. Em geral, testamos agentes como testaríamos uma calculadora: verificando se a resposta está certa. Um teste para um trabalhador verificaria se ele respeitou os limites de sua concessão, pediu aprovação quando deveria, escalou a questão quando a situação ultrapassou o escopo de sua função e parou quando deveria.

Na minha própria pesquisa, venho desenvolvendo um benchmark com 50 cenários que abordam justamente estas falhas: ultrapassar limites de aprovação, agir com base em dados desatualizados, seguir instruções injetadas que ampliam o escopo e manter o acesso após uma mudança de função. Até agora, só o executei com agentes roteirizados, para verificar se os cenários se comportam como planejado; por isso, não tenho resultados de modelos a apresentar. O que me surpreendeu ao escrevê-los foi o quanto são corriqueiros. São as formas habituais de funcionários se desviarem das instruções, reformuladas para o software. A maioria dos rankings públicos ainda avalia a conclusão de tarefas, e muito poucos avaliam se o agente respeitou sua autoridade.

O período de experiência e a promoção são conceitos que se traduzem de forma bastante direta. Com as pessoas, começamos com um escopo restrito e o ampliamos à medida que demonstram discernimento. Os agentes podem conquistar limites mais amplos da mesma forma: mantendo um histórico de atuação dentro das regras, de encaminhamento adequado dos problemas e de interrupção correta das atividades. Esse histórico também pode justificar, com a mesma facilidade, a redução das permissões concedidas.

Os agentes trazem uma complicação que não existe com as pessoas. Quando um fornecedor atualiza o modelo subjacente, na prática você passa a ter um novo contratado usando o crachá antigo. Eu trataria isso como uma mudança e faria novos testes antes de manter as permissões concedidas.

O desligamento precisa ser ensaiado antes que seja necessário. Se você precisasse interromper este agente e revogar seu acesso na próxima hora, conseguiria? Quem tem autoridade para tomar essa decisão às 2h da manhã? O que deixaria de funcionar nos processos subsequentes, e quais compromissos em andamento alguém teria de desfazer manualmente? Se ninguém fez esse exercício, você está apenas torcendo para que o interruptor de emergência funcione.

Você pode responsabilizar um funcionário. Não pode responsabilizar um agente por nada, e é aí que a comparação deixa de funcionar. Essa também é a razão pela qual as permissões concedidas precisam ser aplicadas pelos sistemas e cada agente precisa ter uma pessoa identificada como responsável por ele. De um jeito ou de outro, alguém acaba sendo responsabilizado. Geralmente, é quem aprovou, tenha percebido ou não que estava dando essa aprovação.

O que a análise do incidente vai perguntar

Alguns desses agentes acabarão fazendo algo que não deveriam. Quando isso acontecer, a análise pós-incidente fará as mesmas perguntas que já faz sobre as pessoas. O que ele tinha permissão para fazer e onde isso está registrado? Quem aprovou a ampliação do acesso? Quanto tempo levou para interrompê-lo? Quem era responsável por ele?

Se as respostas sinceras forem “um prompt”, “ninguém se lembra”, “horas” e “não está claro”, um modelo melhor não teria salvado você.

Onde a vantagem acaba ficando

Os modelos estão se tornando insumos alugados, substituídos e atualizados de acordo com o cronograma dos fornecedores. Duas empresas podem usar o mesmo modelo e acabar em situações muito diferentes. Uma tem agentes com orçamentos, limites, responsáveis e uma trilha de auditoria para cada ação relevante; a outra tem um projeto-piloto caro prestes a engrossar as estatísticas de cancelamento de alguém.

A diferença está no sistema de gestão em torno do modelo. Esse sistema é construído lentamente, em grande parte por pessoas que já administraram organizações.

Se o seu agente mais recente ultrapassasse sua autoridade amanhã, alguém na sua empresa perceberia? E você conseguiria mostrar a um auditor, por escrito, onde estava o limite?