Um agente que trabalha no processo financeiro lê uma nota fiscal, compara com o pedido, encontra uma diferença, prepara um pagamento e executa esse pagamento. É o mesmo agente, com a mesma tecnologia, nas cinco etapas.
A capacidade técnica existe nas cinco. A autoridade não precisa ser igual em nenhuma delas.
Consultar uma nota apenas lê. Encontrar uma diferença produz uma análise. Preparar um pagamento cria uma ação que ainda pode ser revista. Executar o pagamento movimenta dinheiro e sai do alcance de quem aprovou.
Dizer que esse agente tem alta autonomia esconde as cinco diferenças de uma vez. Alta autonomia para fazer o quê?
Este artigo trata de como decidir a autonomia de agentes de IA olhando para a ação concreta, com quatro fatores que podem ser respondidos antes de liberar qualquer execução. É o terceiro texto da série sobre empresa híbrida. O papel do gestor na era dos agentes de IA trata de escolher o modo de execução de cada parte do trabalho. Aqui a lente fecha um nível, e a unidade de decisão deixa de ser o agente e passa a ser a ação.
Capacidade responde uma pergunta, autonomia responde outra
Capacidade responde se o agente consegue fazer. Autonomia responde se ele pode fazer sozinho. As duas respostas não precisam coincidir, e tratá-las como sinônimo é o erro que abre a maior parte dos problemas seguintes.
A Cloud Security Alliance separa as duas no seu framework de níveis de autonomia. Capacidade é aquilo que o agente consegue executar com os recursos, as ferramentas e o conhecimento que tem. Autonomia é aquilo que ele está autorizado a executar sem intervenção humana. Um agente pode acumular muitas capacidades e receber pouca autonomia, e isso não indica imaturidade da empresa nem limitação do modelo.
A distinção parece óbvia quando escrita. Ela desaparece na prática, porque a conversa sobre agentes costuma começar pela demonstração. O agente resolve a tarefa na frente de todo mundo, a sala se convence de que ele consegue, e a pergunta sobre o que ele pode fazer sozinho nunca chega a ser feita separadamente.
Permissão é uma terceira coisa, e vale distinguir também. Permissão define a que dados, ferramentas e sistemas o agente tem acesso. Autonomia define quanto ele decide e executa sem nova aprovação. Uma permissão técnica concedida sem decisão consciente vira liberdade operacional por acidente.
O risco não termina na qualidade do modelo
É natural concentrar a avaliação no modelo. Qual a qualidade das respostas, com que frequência erra, se segue instrução. São perguntas legítimas e insuficientes.
Agentes introduzem outra variável. O que acontece depois que o sistema decide.
O OWASP registra isso como Excessive Agency, o risco de um sistema receber funções, permissões ou autonomia além do necessário. O efeito aparece quando o modelo interpreta mal uma situação, recebe uma instrução manipulada ou produz uma resposta inesperada, e a consequência escapa porque o agente tinha autorização para agir.
Um agente que só consulta informação carrega um tipo de poder. Um agente que altera preços, apaga registros, envia mensagens ou movimenta transação carrega outro. A tecnologia pode ser a mesma nos dois casos. A consequência possível não é, e é a consequência que a empresa vai administrar quando algo sair errado.
Quatro perguntas delimitam a autonomia de uma ação
Não existe nível universal de autonomia que sirva para todo agente, todo processo e toda empresa. Escadas de maturidade com cinco degraus ajudam a organizar vocabulário e não decidem nada sozinhas, porque o degrau certo muda de ação para ação dentro do mesmo agente.
A decisão precisa olhar para a ação concreta. Quatro perguntas dão conta da maior parte dos casos.
| Fator | Pergunta |
|---|---|
| Impacto | O que acontece se a ação estiver errada? |
| Capacidade de corrigir | Conseguimos desfazer a ação e também a consequência dela? |
| Tempo para perceber | Quanto tempo podemos levar para descobrir o problema? |
| Alcance | Quanto pode ser afetado antes que consigamos interromper? |
As quatro não produzem resposta automática. Elas mostram onde mais liberdade faz sentido e onde a empresa precisa manter limite. O modelo de quatro fatores é proposição consultiva da WatchZ, e combina princípios que aparecem em referências de segurança e governança sem corresponder a classificação regulatória ou padrão oficial.
Quanto maior a consequência, mais forte precisa ser a justificativa
Nem todo erro pesa igual.
Um documento vai para a pasta errada. Um preço é alterado incorretamente. Uma mensagem chega ao cliente errado. Um pagamento entra em conta errada. Uma configuração afeta um sistema que sustenta receita.
Existe erro em todos os cinco casos. A consequência de cada um vive em uma escala diferente, e por isso não basta perguntar qual a chance de o agente errar. Falta a segunda metade da conta, que é o tamanho do efeito quando o erro acontecer.
A AWS recomenda classificar ações de agentes por impacto e por possibilidade de desfazer, e propõe níveis distintos de supervisão para equilibrar velocidade e controle em vez de aplicar o mesmo controle a tudo. Quanto maior a consequência possível, mais forte precisa ser a justificativa para deixar a ação acontecer sem outro controle no caminho.
Desfazer a ação não desfaz o que ela causou
Algumas ações voltam atrás com facilidade. Um cadastro é restaurado, um arquivo volta para a versão anterior, uma alteração é cancelada.
Existe uma diferença entre desfazer a ação técnica e desfazer o que aconteceu por causa dela, e a Cloud Security Alliance separa as duas coisas no framework. Um dado exposto não deixa de ter sido visto porque o acesso foi removido depois. Uma alteração revertida no sistema pode continuar produzindo efeito fora dele, em cliente, em contrato, em relatório que já circulou.
A pergunta útil não é se temos como desfazer. É se conseguimos corrigir a ação e também aquilo que ela causou. Quanto mais difícil forem as duas, maior o cuidado antes da execução, e essa é a mesma lógica de reversibilidade que a arquitetura corporativa aplica a decisões estruturais.
Um erro que demora a aparecer continua produzindo consequência
Imagine dois casos.
No primeiro, o agente tenta alterar um dado e o sistema recusa na hora, com aviso imediato de operação inválida. No segundo, o agente envia informação errada para uma base de clientes e a empresa descobre quando as reclamações chegam.
O segundo erro teve tempo. E tempo importa porque agente executa em sequência. Enquanto ninguém percebe, novas ações continuam acontecendo sobre a premissa errada, e cada uma amplia o que vai precisar ser corrigido depois.
Monitorar, então, não significa guardar histórico para consultar quando alguém reclamar. Significa detectar enquanto ainda existe tempo de limitar o efeito. É a diferença entre observabilidade e arquivo, e ela aparece do mesmo jeito na observabilidade de plataforma que sustenta operação crítica.
O alcance mostra até onde o erro chega antes de alguém parar
Alterar um cadastro é uma coisa. Alterar cem mil cadastros é outra, e o mesmo raciocínio vale para mensagem, pagamento, arquivo e sistema acessado.
Por isso autonomia também precisa de limite de alcance. Valor máximo de uma transação. Número de registros que podem ser alterados de uma vez. Quantidade de mensagens enviadas. Sistemas que o agente alcança. Tipos de ação permitidos. Quantidade de ações dentro de um período.
O Governo do Canadá recomenda limitar dados, ferramentas, permissões e ações, e inclui limite de volume e de frequência exatamente para reduzir o efeito de comportamento indesejado. Nenhum desses limites torna o agente menos capaz. Eles reduzem quanto uma decisão errada consegue afetar antes de alguém intervir.
O mesmo agente opera com graus diferentes de liberdade
Voltando ao agente financeiro. Em vez de escolher entre autônomo e não autônomo, a empresa trata cada ação de forma diferente.
| Ação | Uma forma possível de controle |
|---|---|
| Consultar uma nota fiscal | Executa sozinho, com acesso apenas de leitura |
| Identificar uma diferença | Analisa e gera alerta |
| Preparar um pagamento | Deixa a ação pronta para revisão |
| Executar um pagamento relevante | Exige autorização antes da execução |
O exemplo não é regra. O tratamento correto depende do contexto da empresa, das leis aplicáveis, das políticas internas e do impacto daquela ação específica.
O ponto é outro. A autonomia muda dentro do mesmo processo, e reconhecer isso evita dois extremos. O primeiro é exigir aprovação humana para tudo. O segundo é liberar o fluxo inteiro porque o agente foi bem em algumas tarefas. Nos dois, ações de risco diferente recebem o mesmo tratamento.
Quem já definiu o modo de execução de cada parte do trabalho, no sentido descrito no papel do gestor na era dos agentes de IA, tem o mapa pronto para aplicar os quatro fatores. O modo de execução responde quem faz. Os quatro fatores respondem com quanta liberdade cada ação daquele modo acontece.
Um fator crítico não pode desaparecer dentro de uma média
Existe uma tentação de transformar os quatro fatores em nota. Impacto recebe pontuação, capacidade de corrigir recebe outra, tempo recebe outra, alcance recebe outra, e o resultado vira uma média.
Esse método esconde justamente o que mais importa.
Imagine uma ação de baixo impacto financeiro, alcance pequeno e detecção rápida, cuja consequência não pode ser corrigida. Três fatores parecem confortáveis. Um não. A média faz a ação parecer mais segura do que ela é, e a empresa aprova com número na mão.
A regra de prudência é observar também o fator mais crítico, isolado. Se a consequência não pode ser corrigida, isso pesa sozinho. Se a ação atinge milhares de pessoas antes de ser interrompida, o alcance pesa sozinho. Se o erro fica invisível por muito tempo, o tempo pesa sozinho. É recomendação consultiva da WatchZ, e não regra regulatória.
É a mesma armadilha dos scores agregados de maturidade, onde a nota média sobe e o gap que trava resultado continua exatamente onde estava.
Aprovação humana precisa estar onde reduz risco de verdade
Colocar uma pessoa no processo reduz risco. Isso não significa que toda ação precisa esperar aprovação.
Quando alguém recebe centenas de pedidos simples para revisar, a aprovação vira mais um clique. Existe uma pessoa no fluxo, e a decisão humana desapareceu dentro do volume. No sentido inverso, retirar uma aprovação que importava entrega ao agente mais liberdade do que a empresa consegue acompanhar.
O NIST, ao tratar de interação entre pessoa e sistema de IA, recomenda que os papéis humanos na decisão e na supervisão sejam definidos com clareza, e reconhece que a necessidade de supervisão muda conforme o uso. A pergunta que organiza isso é direta. Em qual ação a decisão de uma pessoa reduz risco de forma relevante?
Algumas ações pedem aprovação individual. Outras funcionam por exceção, por amostragem ou por indicador monitorado. Algumas não deveriam ser delegadas. Supervisão humana é mecanismo, e escolher onde ela entra vale mais do que aumentar a quantidade dela. É a diferença entre controle desenhado e controle acumulado, e ela aparece em toda pauta de IA estratégica que sai do piloto e entra em operação.
Mais autonomia exige limites mais fortes
Autonomia sem controle não é o objetivo de ninguém que já operou um incidente.
Na prática, quanto menos uma pessoa participa de cada execução, mais peso ganham os controles que cercam o agente. A Cloud Security Alliance propõe que níveis maiores de autonomia venham acompanhados de controles mais fortes, entre eles limite técnico, monitoramento, registro, forma de interromper o agente e caminho de recuperação.
O Governo do Canadá recomenda começar com escopo estreito, usar acesso somente de leitura quando possível e ampliar permissão de forma gradual, reavaliando risco sempre que ferramenta, dado, permissão ou escopo mudarem.
Autonomia é liberdade de agir dentro de limites conhecidos. Onde os limites não estão escritos, o que existe é ausência de decisão, e ausência de decisão costuma aparecer no relatório de incidente antes de aparecer na ata de reunião. Empresas que já operam inteligência artificial com governança proporcional tratam esses limites como parte do desenho, não como reação.
A decisão começa por uma lista de ações
Antes de definir quanta autonomia um agente recebe, liste o que ele consegue fazer de fato. Use verbo simples. Ler, criar, alterar, enviar, excluir, comprar, publicar, executar, conceder acesso.
Depois aplique as quatro perguntas a cada item. O que acontece se estiver errada. Se conseguimos corrigir a ação e a consequência. Quanto tempo até percebermos. Quanto pode ser afetado antes de conseguirmos parar.
As respostas produzem graus diferentes de liberdade dentro do mesmo agente. Ele pesquisa sozinho. Prepara uma ação e espera aprovação. Executa até certo limite. É impedido de executar uma ação específica.
Isso não reduz o valor do agente. Torna a delegação precisa, e delegação precisa é o que permite ampliar escopo depois sem refazer a discussão do zero.
Conclusão
Mais autonomia não significa mais maturidade. Menos autonomia não significa mais segurança. O objetivo não é liberar tudo nem controlar tudo.
O objetivo é permitir que o agente faça trabalho útil sem receber liberdade maior do que a empresa consegue observar, limitar e corrigir.
Por isso a pergunta inicial muda de forma. Em vez de perguntar quanta autonomia esse agente deve ter, pergunte o que ele pode fazer sozinho, dentro de quais limites, e o que acontece se estiver errado. A resposta muda de uma ação para outra, e é por isso que um agente pode ser muito capaz e continuar com pouca autonomia em uma decisão importante, enquanto executa sozinho atividades simples, limitadas e fáceis de corrigir.
A tecnologia é a mesma. O que muda é a ação.
Escolha um agente que já opera na sua empresa e liste as ações dele que produzem efeito real. Aplique os quatro fatores a cada uma e marque onde a resposta atual foi herdada de uma demonstração em vez de decidida. Se a lista revelar mais herança que decisão, o problema não está no agente, e um diagnóstico de capacidade mostra onde essa mesma ausência aparece no resto da operação.
Fontes
- Cloud Security Alliance AI Safety Initiative. "Agentic AI Autonomy Levels and Control Framework", versão 2.0 (18 de março de 2026). https://labs.cloudsecurityalliance.org/research/agentic-ai-autonomy-levels-control-framework-v2-csa-styled/
- OWASP GenAI Security Project. "LLM06:2025 Excessive Agency", edição 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html
- NIST. "Artificial Intelligence Risk Management Framework 1.0, Appendix C: AI Risk Management and Human-AI Interaction" (2023). https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/
- Amazon Web Services. "AGENTREL02-BP05 Establish tiered human oversight and approval workflows", Agentic AI Lens. https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentrel02-bp05.html
- Government of Canada. "Guide on the Use of Agentic Artificial Intelligence" (22 de maio de 2026). https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/guide-use-agentic-artificial-intelligence.html
- WatchZ. "Quanto de autonomia você deveria dar a um agente de IA". Versão editorial revisada, setembro de 2026.
Nota: o modelo de quatro fatores e a regra de observar o fator mais crítico são proposições consultivas da WatchZ, sem correspondência a classificação regulatória ou padrão oficial de terceiros. As referências citadas sustentam princípios isolados, e não o arranjo proposto aqui.
