À medida que delegamos mais tarefas para a IA, fica fácil perdermos o controle sobre cada detalhe do que ela faz. O problema é que ela faz em nosso nome.
No livro Vibe Coding, Gene Kim e Steve Yegge usam a cozinha para explicar isso. Todo mundo foi promovido a chefe de cozinha, e os agentes são os nossos cozinheiros. E, nas palavras deles, não existe opt-out dessa promoção.
Da mesma forma que um chefe de cozinha é responsável por todos os pratos que saem da sua cozinha, nós somos responsáveis por tudo que o nosso agente fizer em nosso nome.
Você delega a execução. A responsabilidade continua sua.
Isso já estava resolvido em 1955
Autoridade se delega. Responsabilidade, não.
Em 1955, Harold Koontz e Cyril O’Donnell chamaram isso de princípio da responsabilidade absoluta, em Principles of Management. A frase deles:
“since responsibility cannot be delegated, no superior can escape, through delegation, responsibility for the activities of subordinates, for it is he who has delegated authority and assigned duties.”
Ou seja: você responde porque foi você quem delegou.
A aviação levou tão a sério que escreveu como regra. O regulamento de voo dos Estados Unidos tem um artigo chamado responsabilidade e autoridade do piloto em comando, e ele diz que o piloto “is directly responsible for, and is the final authority as to, the operation of that aircraft”. O piloto automático voa boa parte do voo.
É exatamente essa a situação em que nós entramos com os agentes. Uma máquina executa, uma pessoa responde, e o arranjo é o mesmo que a aviação enfrentou décadas atrás. Com uma diferença que vale guardar até o fim deste texto: a aviação escreveu a regra dela, e o software ainda está escrevendo a sua.
Se foi o agente que fez, então eu reclamo pra quem?
A pergunta tem nome. Andreas Matthias chamou de responsibility gap em 2004: quando o comportamento do sistema não foi previsto por ninguém, a responsabilidade fica sem dono.
Dan Davies dá um nome melhor em The Unaccountability Machine: accountability sink. A responsabilidade é drenada até não sobrar ninguém a quem reclamar. Você liga, o atendente diz que o sistema não permite, e o sistema não atende telefone.
Um agente é um accountability sink excelente. Ele executa, o resultado sai, e quem foi prejudicado não acha uma pessoa do outro lado.
Já tentaram esse argumento, e perderam na justiça
Em fevereiro de 2024, uma companhia aérea foi ao tribunal sustentar exatamente a tese do Junior ali em cima. Um cliente seguiu uma informação errada do chatbot do site e pediu o dinheiro de volta, e a empresa respondeu que não podia ser responsabilizada pelo que o chatbot disse. O tribunal registrou o argumento e o desmontou em duas frases:
“In effect, [the airline] suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission. [...] It should be obvious to [the airline] that it is responsible for all the information on its website.”
Remarkable até parece elogio, mas nesse caso é eufemismo.
Um ano antes, dois advogados americanos protocolaram uma petição com decisões judiciais que uma IA tinha inventado. O juiz abriu a sentença marcando onde a linha está:
“There is nothing inherently improper about using a reliable artificial intelligence tool for assistance. But existing rules impose a gatekeeping role on attorneys to ensure the accuracy of their filings.”
A multa não foi por usar a ferramenta. Foi por não conferir, e depois insistir. A palavra que o juiz usou para o que eles fizeram foi abandonar as próprias responsabilidades.
E não precisa de tribunal para a conta chegar. O livro do Kim e do Yegge relata um caso de 2024: um agente empurrou para produção uma mudança que acrescentou um evento na montagem de um componente de banner, e aquilo virou 6,6 milhões de chamadas a um serviço externo, com a fatura que se imagina. A conclusão do time foi a mais óbvia e a mais cara de se aprender assim: era para ter revisado.
Se ninguém aceita a desculpa, o que sobra pra fazer?
Você responde pela cozinha, não pela panela
Volte para a cozinha do Kim e do Yegge. O que eles dizem que continua seu, mesmo com os cozinheiros fazendo tudo, é “the menu, the quality control, and the overall vision for what your kitchen produces”.
O chefe não prova cada panela. Ele monta o cardápio, define o padrão e prova o prato.
Na prática, isso é um conjunto de conceitos:
Guardrail
Least privilege
Gate
Eval
Guardrail
Guardrail é o limite que você desenha em volta do agente, e que não depende de ele concordar.
A OWASP trata como defesa em camadas e nomeia algumas: validação de entrada, least privilege, aprovação humana para ação destrutiva. E carrega um requisito: o controle não pode morar dentro do modelo.
Um levantamento de padrões de projeto para agentes conclui que tornar o modelo robusto por si só é extremamente difícil, e que o caminho está no desenho do sistema em volta dele.
Esse sistema em volta é o harness. O paper publicado na Kaggle sobre o novo SDLC diz que um modelo cru não é um agente: ele vira um quando o harness dá a ele estado, execução de ferramentas, ciclos de retorno e restrições que dá para fazer valer.
Birgitta Böckeler resume numa equação: Agent = Model + Harness. Só que harness é maior que guardrail, e o próprio paper separa os dois quando lista o que cabe ali dentro: arquivos de instrução e regra de um lado, guardrails e hooks do outro.
A regra que você manda no contexto e torce para o agente seguir é harness, e não impede nada: é pedido.
E aqui vão alguns lugares onde construir esse guardrail: o que o agente pode acessar e até onde ele pode agir, o bloqueio quando ele tenta passar do limite e a verificação de que o resultado faz sentido.
Least privilege
Least privilege diz o que o agente pode acessar e até onde ele pode agir. Saltzer e Schroeder escreveram em 1975 que todo programa deve operar com o menor conjunto de privilégios necessário para concluir o trabalho, e a OWASP recolocou a mesma ideia em 2025 como uma das três causas de Excessive Agency. A pergunta prática: quais são as permissões suficientes para executar a tarefa?
Repare no suficientes. Se o agente não consegue rodar o próprio teste, ele não tem autonomia.
O risco não mora em nenhuma permissão sozinha. Simon Willison chama de The lethal trifecta a combinação que faz o estrago: acesso ao seu dado privado, exposição a conteúdo não confiável e possibilidade de se comunicar externamente. Least privilege é como você impede que as três se encontrem.
Gate
Gate é o bloqueio quando o agente tenta passar do limite. CI, CD, linter, validador, teste, type checker. Os modelos de IA são não determinísticos, e essa verificação precisa de determinismo.
Gates determinísticos evitam que um humano precise fazer as verificações que podem ser automatizadas.
Com agentes isso aparece como hook, e vale saber a diferença: o agente não consegue pular um hook, você consegue. O mesmo mecanismo é guardrail de um lado e pedido do outro, e o lado que pode desligar é o seu.
Eval
Eval avalia se o resultado faz sentido de acordo com seus critérios.
Um pull request pode estar com a sintaxe perfeita, com todos os testes passando, e ainda assim implementar a regra de negócio errada. Com o eval dá pra medir isso.
Essa medida pode virar um guardrail se você definir qual é o limiar aceitável.
Nem todo guardrail é determinístico. Linter, type checker, escopo de permissão e teste dão sempre a mesma resposta para a mesma entrada: ou passa, ou não passa. Quando não existe checagem determinística para o que você precisa julgar, o caminho é mandar um prompt para verificar, e tem pesquisa fazendo exatamente isso: um LLM treinado para avaliar a entrada e devolver um veredito, e isso vira um gate e opera como guardrail.
LLM as a judge alcança o que o gate determinístico não alcança, mas traz junto um problema. A OWASP diz o mecanismo em uma frase: “A guardrail LLM is itself an LLM and is itself susceptible to prompt injection.” O Simon Willison reparou que os produtos vendidos como guardrail afirmam capturar “95% dos ataques”, e que em segurança de aplicação 95% é nota de reprovação.
Então a regra é: use o LLM as a judge como mais uma camada, mas saiba que ele não garante o limite. Sempre que possível, prefira as verificações determinísticas.
E repare no que os três têm em comum: o que o agente pode acessar, o que bloqueia quando ele tenta passar e o que verifica o resultado são decisões suas. Nenhuma delas torna o agente responsável. Todas tiram uma decisão de dentro da sua cabeça e criam ferramentas que a cumprem sozinhas, com ou sem agente.
A engenharia já concordou
O paper publicado na Kaggle sobre o novo SDLC descreve o que continua no seu ciclo de desenvolvimento com agentes: especificar, desenhar os guardrails e aprovar.
O eval faz parte do processo de verificação que deve ser feito de acordo com o que foi especificado. O gate está nos testes e verificação: o que falha volta pra fase de planejamento. Mas quem definiu o que deve ser testado e verificado foi você quando estava desenhando os guardrails. E o least privilege é o que decide o que o agente alcança, que é a única coisa que o desenho não mostra: ele já supõe o agente com o acesso de que precisa para trabalhar.
É essa parte que o roadmap do MCP está construindo. A autorização foi desenhada supondo uma pessoa com um navegador na hora do consentimento, e hoje quem chama é um agente.
O que está sendo construído é identidade própria para o agente e delegação de autoridade com escopo. O agente não precisa ter as mesmas permissões e privilégios que quem o criou. É o least privilege subindo de configuração para protocolo.
Isso é justamente pra que a responsabilidade continue endereçável à pessoa e não ao agente.
Quando se aumenta o throughput, a verificação cobra a conta
O preço dessa verificação já foi medido. A FAROS viu o tempo de revisão de pull request subir 91% em 2025 e 441% em 2026, com 31% mais PRs entrando sem revisão nenhuma. O DORA chama de imposto de verificação a parte disso que é conferir o que a IA gerou.
Na analogia da cozinha: cozinha que prova tudo de novo serve o jantar frio.
A saída não é revisar mais. É o gate, que tira da leitura humana tudo que uma máquina reprova sozinha. E gate também é uma parte da cozinha que você desenhou, então um gate frouxo continua sendo responsabilidade sua.
Quatro perguntas antes de deixar um agente agir
Quais são os guardrails?
Quais são as permissões suficientes para executar a tarefa?
O que impede o agente de atravessar o limite, sem alguém lembrar de olhar?
Como eu sei que o que saiu faz sentido?
Quem responde por elas é quem cria o agente.
Você já é o chefe
O agente entregou uma funcionalidade quebrada. Verdade. Mas foi você quem mandou ele fazer, com a sua credencial, dentro do escopo que você desenhou, e é em seu nome que ela roda agora.
Você não foi promovido a quem prepara mais rápido. Foi promovido a quem define as regras e os padrões.
Como você delega a implementação sem delegar a responsabilidade? Conta nos comentários o que você já experimentou: o gate que você colocou, o incidente que resultou do excesso de permissão do agente, a coisa que o agente nunca decide sozinho. Salva esse post pra reler quando for desenhar o seu próximo agente.
Se você já ouviu “foi a IA que gerou” numa reunião, manda esse texto pra pessoa que disse.