Como limitar a autonomia de agentes de IA

Um agente de inteligência artificial pode comentar em um ticket, preparar uma alteração de código ou executar uma mudança em um sistema real. O limite de autonomia de agentes deve nascer dessa diferença: qual ação ele executa, com qual permissão e com que facilidade a organização consegue desfazer o efeito se algo sair do esperado.

O limite de autonomia começa pela ação, não pelo agente

Autonomia de agentes é a capacidade concedida a um sistema de inteligência artificial para decidir ou executar etapas de uma tarefa com menor intervenção humana. Em software, isso pode significar ler um repositório, abrir uma alteração, comentar em uma ferramenta de gestão, ajustar uma configuração, acionar um script ou interagir com outro sistema.

O erro comum é discutir autonomia como uma característica única do agente: “ele pode agir sozinho” ou “ele precisa de aprovação”. Essa formulação é pobre para uma liderança de engenharia, qualidade ou produto. A mesma ferramenta pode ter autonomia ampla para uma ação e quase nenhuma para outra.

Comentar em um ticket é diferente de alterar código. Alterar código em um branch é diferente de publicar uma configuração. Publicar uma configuração para um grupo controlado é diferente de ativá-la para todos os usuários. O agente não muda de natureza em cada caso. O risco da ação muda.

Uma forma mais útil é separar três níveis:

Recomendar: o agente analisa o contexto e propõe uma ação, mas não muda o estado do sistema.
Preparar: o agente cria a alteração, organiza evidências, monta um plano ou deixa uma ação pronta para revisão.
Executar: o agente altera o estado de um sistema, ambiente, configuração, dado ou fluxo operacional.

Essa separação ajuda a evitar dois extremos ruins. O primeiro é bloquear qualquer uso porque o agente “pode errar”. O segundo é liberar execução ampla porque ele acertou em demonstrações controladas. Entre esses extremos existe desenho de processo.

Neste artigo, tratamos autonomia como uma decisão operacional sobre velocidade, contenção e julgamento humano. Não é um gesto de modernização. É uma escolha sobre onde a organização aceita ação automática, onde exige autorização e onde precisa preservar uma pessoa antes da execução.

Como classificar ações por impacto e reversibilidade

A reversibilidade é um critério mais operacional do que uma noção genérica de risco. Ela pergunta: se a ação der errado, conseguimos desfazer de forma rápida, segura e verificável?

Ações de baixo impacto tendem a ser fáceis de desfazer e ficam restritas a ambientes ou artefatos sem efeito direto sobre usuários. Exemplos: sugerir uma descrição de ticket, gerar uma hipótese de causa para uma falha, propor casos de teste ou preparar uma alteração em um branch isolado. Mesmo assim, baixo impacto não significa ausência de regra. Significa que a permissão pode ser mais ampla porque o custo de reversão é menor.

Ações de impacto médio mudam algum estado interno, mas ainda têm contenção razoável. Um agente que abre um pull request, altera uma configuração em ambiente de teste ou executa uma suíte de testes em homologação está mais próximo da operação real. Aqui, a pergunta deixa de ser “ele sabe fazer?” e passa a ser “o que impede essa ação de escapar do contexto previsto?”.

Ações de alto impacto têm efeito externo, custo difícil de recuperar, risco de segurança, impacto em disponibilidade, alteração persistente de dados ou comunicação com clientes. Nesses casos, o agente pode até preparar a ação, mas a execução exige autorização explícita, verificação objetiva e plano de reversão.

A regra prática é simples: quanto mais difícil for desfazer, mais explícita deve ser a autorização antes de executar.

Essa classificação não substitui políticas de segurança, privacidade ou gestão de risco. Ela organiza a conversa antes dessas políticas serem aplicadas. Em especial, a existência de testes bons não elimina a necessidade de permissão explícita quando a ação tem alto impacto ou baixa reversibilidade. O DORA recomenda testes ao longo do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade. A partir disso, para agentes, convém tratar testes como evidência de qualidade, não como autorização automática para qualquer execução.

Permissões devem ser específicas, temporárias e rastreáveis

Permissão precisa descrever o que o agente pode fazer, onde, por quanto tempo e com qual rastro.

Se um agente precisa alterar uma configuração, ele não precisa ter permissão genérica para administrar todo o sistema. Se precisa ler um conjunto de arquivos, não precisa acessar todo o repositório. Se precisa executar uma tarefa em ambiente de teste, não deve herdar permissão para produção por conveniência.

Uma permissão bem desenhada responde a algumas perguntas:

Qual ação exata o agente pode executar?
Em qual ambiente essa ação é permitida?
Quais dados, arquivos, serviços ou configurações ele pode acessar?
Por quanto tempo a permissão permanece ativa?
Quem ou qual regra concedeu a permissão?
Como a organização identifica o que foi executado depois?

Permissões amplas costumam ser justificadas pela fluidez: “assim o agente não trava”. Mas fluidez operacional sem limite claro apenas desloca o custo para depois. Quando algo sai errado, a equipe precisa reconstruir contexto, descobrir intenção, mapear efeitos e decidir reversão sob pressão.

A alternativa é conceder autonomia por escopo. O agente pode preparar alterações em qualquer branch de trabalho, mas só pode abrir pull requests com rótulo específico. Pode executar testes em ambiente controlado, mas não alterar variáveis de produção. Pode sugerir ajuste de roteamento, mas não ativar a regra para clientes sem aprovação.

Para esta decisão, importa menos se o modelo é próprio ou de terceiro e mais se há controle de contexto, permissão, avaliação e consequência. O ponto é limitar o que a ferramenta pode fazer quando estiver conectada ao trabalho real.

Quando exigir aprovação humana antes da execução

Aprovação humana não deve ser um ritual para aliviar ansiedade. Ela deve aparecer onde muda a qualidade da decisão.

Há situações em que o ser humano precisa estar antes da ação, não depois dela. Isso acontece quando a reversão é incerta, quando o efeito chega ao usuário, quando há alteração persistente de dados, quando uma configuração sensível muda o comportamento do produto, quando a ação afeta segurança ou disponibilidade, ou quando não existe verificador confiável do resultado.

Também vale exigir aprovação quando o estado do ambiente é ambíguo. Um agente pode propor uma ação correta para um ambiente que não está no estado esperado. Nesse caso, a falha não está necessariamente na recomendação, mas na execução fora de contexto.

A pergunta de aprovação deveria ser concreta: “esta ação, neste ambiente, com este plano de reversão e este verificador, pode ser executada agora?”. Isso é diferente de pedir que alguém “revise o agente”. Revisar o agente é abstrato. Autorizar uma ação delimitada é governável.

Esse critério protege a equipe de uma falsa dicotomia. Não é preciso escolher entre autonomia total e supervisão manual para tudo. O agente pode recomendar com liberdade, preparar com alguma permissão e executar apenas quando a ação for reversível, observável e compatível com o ambiente.

Como verificar se a tarefa aconteceu de verdade

Autonomia sem verificação vira confiança narrativa. O agente diz que terminou, apresenta um log, descreve o que fez e talvez pareça convincente. Mas a pergunta relevante é outra: o ambiente ficou no estado esperado?

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. Avaliações de agentes usam entradas, critérios de sucesso e verificadores, e podem exigir várias tentativas.

Essa distinção é central para definir autonomia. Se a organização não consegue verificar o resultado de uma ação, não deveria ampliar a autonomia dessa ação. O agente pode continuar recomendando ou preparando, mas execução independente exige evidência objetiva.

Verificadores podem assumir formas diferentes:

Estado final observável: a configuração esperada está ativa no ambiente correto.
Teste executado: a suíte relevante rodou e produziu resultado consultável.
Registro de auditoria: a ação aparece com autor, horário, escopo e identificador.
Comparação antes e depois: a mudança aplicada corresponde ao plano aprovado.
Sinal operacional: o sistema expõe um indicador verificável de que a alteração foi carregada.

Logs e justificativas ajudam na investigação, mas não substituem verificador. A liderança deve desconfiar de qualquer fluxo em que a única evidência seja a própria afirmação do agente.

Como liberar autonomia de forma gradual

Liberar autonomia não precisa ser um salto. Pode ser uma sequência de exposição controlada.

O primeiro estágio é observação. O agente acompanha tarefas, sugere análises e permite comparar suas recomendações com decisões humanas sem executar nada.

O segundo é recomendação. Ele propõe ações com base em contexto real, mas uma pessoa decide o que fazer.

O terceiro é preparação com aprovação. O agente monta a alteração, plano de reversão, evidências e verificadores. Uma pessoa autoriza ou rejeita a execução.

O quarto é execução em ambiente controlado. O agente executa ações reversíveis em teste, homologação ou contextos sem impacto direto no usuário.

O quinto é execução limitada em produção. Mesmo aqui, a autonomia deve ser restrita por ação, ambiente, exposição, permissão e verificador.

O capítulo de Google SRE sobre lançamentos graduais trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição. Também distingue disponibilizar código de ativar funcionalidades e discute configurações para separar essas decisões. Aplicada à operação de agentes, a distinção é útil: disponibilizar a capacidade do agente não é o mesmo que ativar sua autonomia para todos os fluxos.

Essa diferença importa para produto e engenharia. Você pode ter o agente tecnicamente pronto para executar uma ação e, ainda assim, ativar essa autonomia apenas para um time, um tipo de tarefa, um ambiente ou uma classe de usuários. Para planejar a adoção, essa separação ajuda a diferenciar funcionalidade disponível de autonomia operacional efetivamente liberada.

Exemplo fictício: agente que altera configuração de atendimento

Imagine um exemplo fictício: uma empresa usa um agente para apoiar a configuração de roteamento de atendimentos. A regra define quais solicitações vão para quais filas internas. Não é um caso médico, jurídico ou financeiro. Ainda assim, uma alteração ruim pode piorar a experiência do cliente, sobrecarregar uma equipe ou esconder solicitações que precisam de resposta.

No modo recomendação, o agente analisa descrições de filas, histórico de categorias e regras existentes. Ele sugere uma nova regra de roteamento e explica a hipótese: determinados pedidos seriam direcionados para uma equipe mais adequada. Esse efeito é uma hipótese a medir, não um resultado assumido.

No modo preparação, o agente cria a mudança em ambiente de teste. Ele registra a regra proposta, indica quais categorias seriam afetadas, prepara uma instrução de reversão e define o verificador: a regra precisa aparecer como ativa apenas no ambiente de teste, e um conjunto de atendimentos simulados deve ser encaminhado para as filas esperadas.

No modo execução controlada, a organização poderia permitir que o agente aplique a configuração em teste sem aprovação prévia, desde que a ação seja rastreável e reversível. Em produção, a regra muda. Como a ação afeta clientes indiretamente, o agente pode deixar tudo pronto, mas a ativação exige autorização humana.

Para produção, a matriz ficaria assim em linguagem operacional:

Ação: ativar nova regra de roteamento.
Permissão: somente para a regra preparada e revisada, no ambiente definido.
Reversibilidade: desativar a regra e retornar à configuração anterior de forma verificável.
Verificador: confirmar estado da configuração e testar encaminhamento com casos controlados.
Exposição: ativar de forma limitada antes de ampliar.
Rastro: registrar quem autorizou, quando executou, o que mudou e como reverter.

A discussão deixa de ser se o agente “é bom o suficiente” e passa a ser se aquela ação tem condições de execução responsável.

Checklist de autorização para ações de agentes

Antes de ampliar permissões de agentes, valide a autorização por ação com produto, engenharia, qualidade e operação:

Ação: o agente vai apenas recomendar, preparar ou executar? Se a ação muda estado em sistema real, não trate como simples recomendação.
Ambiente: a ação ocorre em rascunho, teste, homologação ou produção? Quanto mais perto do usuário final, menor deve ser a autonomia inicial.
Reversibilidade: é possível desfazer a ação de forma rápida, segura e verificável? Se a reversão depende de investigação manual ou recuperação de dados, exija aprovação antes da execução.
Impacto externo: a ação afeta cliente, segurança, privacidade, disponibilidade ou comunicação pública? Se afeta partes externas ou obrigações sensíveis, o agente pode preparar, mas não deve executar sem autorização definida.
Permissão: a permissão é específica para aquela ação, naquele contexto e por tempo limitado? Se permite ações além do necessário, reduza o escopo.
Verificador: existe uma forma objetiva de confirmar que o resultado esperado aconteceu no ambiente? Se só há mensagem do agente dizendo que terminou, a autonomia não deve aumentar.
Rastro: é possível saber quem autorizou, o que foi executado, quando aconteceu e como reverter? Se não houver rastreabilidade suficiente, mantenha o agente no modo de recomendação ou preparação.

Autonomia deve ser concedida por ação, não por confiança geral no agente. Se a equipe não consegue delimitar permissão, reversibilidade e verificação, ainda não está diante de um problema de modelo. Está diante de um problema de desenho operacional.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.