Por que a Amazon rejeita o human-in-the-loop na governança de IA

A Amazon não está apenas trocando um modelo de governança por outro: está redefinindo o que significa responsabilidade em sistemas agenticos. Em vez de confiar em aprovações humanas repetidas, que, segundo Eric Brandwine, se deterioram com a frequência do uso, a empresa construiu uma arquitetura de governança baseada em identidade vinculada, permissões dinâmicas por risco e limites explícitos de comportamento. Isso não é abdicação de controle, mas sim uma migração estratégica da supervisão pontual para a governança estrutural: cada agente tem credenciais únicas, aparece nos logs como entidade distinta (‘agente X em nome de Y’), e sua autorização é calculada em tempo real com base na tarefa, no contexto e no perfil de risco do usuário que o acionou.

O cerne técnico dessa virada é a recusa em tratar agentes como ‘caixas pretas com botão de aprovação’. A Amazon reconhece que, em ambientes de alta velocidade operacional, como os seus próprios sistemas internos, o human-in-the-loop vira um ponto único de falha sistêmica. E isso se alinha diretamente ao que o Slack já observou: tarefas agenticas prolongadas degeneram por ruído de contexto, não por má intenção. A solução, então, não é mais revisão humana, mas disciplina de permissão e clareza de propósito embutida na arquitetura, inclusive com instruções explícitas sobre consequências (ex: ‘não delete bancos porque causa impacto em produção’), não só proibições.

Na cobertura anterior de 22/06, o CEVIU já havia destacado a posição da Amazon contra o human-in-the-loop, mas como uma declaração de princípio. Agora, com a entrevista completa de Brandwine, sabemos *como* ela opera na prática: não há apenas rejeição conceitual, há implementação concreta de identidades agenticas, políticas geradas automaticamente a partir de prompts e intenções, e guardrails hierárquicos (estáticos + dinâmicos). Também mudou a clareza sobre o problema central: não é só inconsistência humana, mas a *natureza não-determinística compartilhada entre humanos e agentes*, exigindo modelos de falha diferentes, e, crucialmente, sem supor que humanos ‘sentem medo de consequências’, ao contrário dos agentes.

Para CISOs e arquitetos de nuvem, isso muda o foco do debate: deixar de discutir ‘quanto humano colocar no loop’ e passar a projetar *estruturas de responsabilidade que sobrevivam à escala*. Se sua empresa ainda depende de aprovações manuais para cada ação de agente em pipelines CI/CD ou infraestrutura como código, você está construindo um gargalo operacional e um risco de compliance crescente, especialmente com normas como a IA Act da UE, que exige rastreabilidade de decisões autônomas. A proposta da Amazon não é copiável 1:1, mas seu núcleo é replicável: vincular identidade humana a ações agenticas, isolar permissões por risco e tratar ‘por que não’ como parte do prompt, não como exceção.