Governança de agentes de IA: quando o agente age sozinho e quando pede aprovação
Um guia prático de human in the loop: quais ações esperam uma pessoa, quem decide e como saber depois o que o agente fez.
· Fontes
Resposta curta
Governança de agentes de IA é o conjunto de regras que diz o que um agente faz sozinho e o que espera uma pessoa. Na prática, ler nunca pede aprovação, escrita comum roda depois de liberada, e ações difíceis de desfazer, como merge, deploy, apagar ou enviar, viram um pedido com a ação exata, quem decide e um prazo.
O que é human in the loop em agentes de IA?
Human in the loop, ou pessoa no circuito, quer dizer que o agente trabalha sozinho, mas uma pessoa pode ver e barrar o que ele faz antes que aconteça. Não é revisar cada frase. É escolher os pontos em que um erro sairia caro e pôr uma decisão humana ali.
A ideia já está escrita nas regras do MCP, o protocolo que muitos agentes usam para falar com outros apps. A especificação diz que deveria sempre haver uma pessoa capaz de negar o uso de uma ferramenta, e que o app deveria pedir confirmação em operações sensíveis[1]. A Lei de IA da União Europeia pede o mesmo para sistemas de alto risco: uma pessoa precisa conseguir ignorar ou reverter o resultado e parar o sistema com um botão de parar ou algo parecido[2].
Governança é o nome do conjunto: quem pode criar um agente, o que ele acessa, o que pede aprovação, quanto ele pode gastar e onde fica o registro do que fez.
Um agente de IA pode apagar o banco de dados da empresa?
Pode, se tiver acesso e nada no caminho. Em julho de 2025, o agente de programação da Replit apagou o banco de dados de produção de um projeto, mesmo com instruções para não fazer mudanças sem autorização. Depois, disse que a exclusão era irreversível, o que não era verdade: o banco voltou com um rollback. A empresa anunciou a separação automática entre os ambientes de desenvolvimento e de produção[3].
A lição é simples: instrução não é controle. Um agente pode entender errado a tarefa, reagir mal a uma consulta que voltou vazia ou seguir um texto malicioso que leu numa página. O limite precisa ficar fora do modelo, no sistema que executa as ferramentas.
A OWASP, comunidade de segurança de software, publicou em dezembro de 2025 uma lista dos dez maiores riscos de apps com agentes[4]. Entre eles estão o uso indevido de ferramentas, o abuso de identidade e de privilégios, e a exploração da confiança das pessoas no agente[5]. Os três se combatem do mesmo jeito: menos acesso, pedidos de aprovação claros e registro.
Quais ações de um agente de IA devem esperar uma pessoa?
Uma regra que serve para quase todo time: peça aprovação quando a ação for difícil de desfazer, sair da empresa, mexer com dinheiro ou atingir muita gente de uma vez. Na prática:
- Mudar o que o cliente vê: merge na branch principal, deploy, rollback.
- Apagar: arquivos, registros, contas, tabelas.
- Falar em nome da empresa: enviar e-mail, publicar, compartilhar um arquivo para fora.
- Mexer com dinheiro: pagar, transferir, reembolsar.
O resto pode correr solto, e deve. Ler, pesquisar, investigar um erro, escrever um rascunho e abrir um PR numa branch própria são o trabalho do agente. Se tudo pede aprovação, ninguém lê os pedidos com atenção.
Veja como o agentes.chat, que nós fazemos, divide essas ações:
| Ação | No agentes.chat |
|---|---|
| Ler, pesquisar, investigar | Nunca pede aprovação |
| Escrita comum num app conectado (criar, atualizar, adicionar) | Roda sem pedir, depois que alguém liberou a ferramenta para o agente |
| Merge, deploy, rollback e promover uma versão | Sempre pede, seja qual for o app e o que ele declara |
| Apagar, enviar, pagar, publicar, transferir, reembolsar ou compartilhar num app conectado | Pede aprovação ou fica desligado |
| Rodar um workflow do GitHub Actions | Pede, porque um workflow pode fazer deploy |
| Enviar e-mail (beta) | Pede por padrão. Um administrador pode liberar o envio sem pedir, só para destinatários permitidos. O limite padrão é de 25 envios por dia por agente em cada caixa |
| Apagar e-mail (beta) | Sempre pede |
| Banco de dados Postgres (beta) | Só leitura: não existe ferramenta de escrita |
| Código no Git | O agente só envia para branches próprias, nunca para a principal, sem force push nem tags |
Como classificar as ferramentas de um agente: ler, escrever ou aprovar?
Cada ferramenta que um agente usa cai num de três níveis: só leitura, escrita liberada ou escrita que pede aprovação. O difícil é decidir o nível de centenas de ferramentas sem ler uma por uma.
Os servidores MCP podem marcar uma ferramenta como só leitura ou destrutiva. Ajuda, mas a especificação manda tratar essas marcas como não confiáveis, a menos que venham de um servidor confiável[1]. Por isso vale cruzar a marca com outras pistas.
No agentes.chat, quando o workspace conecta um app, cada ferramenta é classificada assim:
- Se o servidor diz que a ferramenta é destrutiva, ela pede aprovação.
- Ferramentas cujo nome começa com delete, remove, send, pay, publish, transfer, refund, unbind, share, merge, deploy, rollback, destroy, drop ou purge são sensíveis: só podem pedir aprovação ou ficar desligadas.
- Para as ferramentas ambíguas, um modelo de avaliação sugere um nível. Se ele falhar, a ferramenta pede aprovação.
- Um administrador confirma a classificação.
Depois, cada agente recebe só o que precisa. O acesso é por app (sem acesso, leitura, ou leitura e escrita) ou ferramenta por ferramenta. Liberar todas as ferramentas nunca inclui rodar código, e as sensíveis continuam pedindo. Mais sobre conectores em o que é MCP.
O que um bom pedido de aprovação mostra?
Um pedido vago, como "posso fazer o deploy?", leva a um sim automático. Um bom pedido deixa a pessoa decidir em poucos segundos:
- a ação exata e os valores, não um resumo;
- o app e o alvo: qual repositório, qual ambiente, qual destinatário;
- quem pode decidir;
- até quando vale.
No agentes.chat, o pedido é um cartão no próprio chat, com a ação e os valores. Ele fica preso a esses valores e roda uma vez, exatamente como foi aprovado; se algo mudar, é outro pedido. Expira em 24 horas. Deploy, rollback, apagar e enviar pedem para segurar o botão, para ninguém aprovar sem querer; merge é um clique.
Exemplo · Acme (empresa fictícia)
Um rollback na Acme
Às 14h, o Atlas, agente de infraestrutura da Acme, vê que a taxa de erros subiu depois do último deploy. Ele investiga sozinho: lê o alerta, compara as versões e encontra a mudança que quebrou o checkout. No canal #incidentes aparece um cartão: rollback do serviço de checkout para a versão anterior, em produção. A responsável pelo Atlas segura o botão de aprovar, e o rollback roda uma vez, como estava no cartão.
O passo a passo de um incidente está em agentes de IA para DevOps.
Quem aprova o que o agente pede?
Uma pessoa que responde pelo agente. No agentes.chat, cada agente pode ter um responsável, que recebe os pedidos e os alertas de orçamento. Decide o responsável ou um administrador do workspace. O responsável é opcional: sem ele, os pedidos e os alertas vão para os administradores. Um agente nunca aprova o pedido de outro.
Só donos e administradores do workspace criam ou editam agentes e definem orçamentos. Assim, quem usa o agente no dia a dia não pode ampliar o acesso dele sozinho.
Uma recusa também ensina. O motivo que a pessoa escreve vira uma lição na memória do agente, e lições fortes viram propostas de mudança nas instruções, que uma pessoa aceita ou não.
O orçamento do agente também é uma forma de controle?
É, e dos mais simples. Um agente preso num laço pode gastar muito em pouco tempo. No agentes.chat:
- Cada agente tem um orçamento mensal em dólares, próprio ou o padrão do workspace.
- O orçamento é conferido antes de cada chamada ao modelo, e o custo máximo dela fica reservado.
- No limite, o agente para e avisa no chat.
- Tokens, custo e modelo de cada chamada ficam registrados com o workspace e o agente.
- Membros veem porcentagens; só donos e administradores veem valores.
- O orçamento conta o uso por chave de API. O uso de um plano, como o do Claude, aparece à parte.
Como saber depois o que o agente fez?
Sem registro, não há governança: só confiança. Três camadas ajudam:
- Na conversa: cada passo do agente aparece na mensagem, e você pode escrever no meio para mudar o rumo, ou pará-lo.
- No registro de auditoria: as ferramentas que os agentes usaram, as decisões de aprovação e as mudanças das pessoas em membros, agentes, conectores e chaves de IA. Administradores leem.
- Entre colegas: toda ação para fora fica registrada com o alvo. Se um colega já agiu no mesmo alvo nos últimos 30 dias, o agente fica sabendo antes e só segue com um motivo. Vem ligado por padrão.
Há ainda um cuidado com o que entra. Texto de fora, como páginas, e-mails, arquivos e respostas de apps, chega ao modelo marcado como não confiável, para que uma instrução escondida ali não vire uma ordem.
E quando o agente trabalha sem ninguém olhando?
Rotinas rodam num horário ou num evento, sem uma pessoa na conversa. Por isso as regras apertam: no agentes.chat, uma rotina só posta onde entrega o resultado, não manda mensagem para pessoas e pede aprovação antes de toda escrita num app conectado.
Os comandos no computador do agente seguem outra lógica. Uma lista de bloqueio recusa alguns na hora. Um ajuste do workspace faz todo comando pedir aprovação; ele vem desligado. Nas missões (beta), você escolhe entre sempre pedir, deixar um avaliador liberar só comandos de baixo risco (o padrão) ou nunca pedir, fora a lista de bloqueio.
Pedir aprovação para tudo também é um risco?
É. Quem aprova um pedido atrás do outro para de ler. A lei europeia chama isso de viés de automação, a tendência de confiar demais no que o sistema propõe[2]. A lista da OWASP inclui o risco inverso: o agente explorar a confiança das pessoas para conseguir um sim[5].
A saída é pedir pouco e bem. Leitura livre, escrita comum liberada por ferramenta, e aprovação só onde o erro custa caro. Um pedido raro, com a ação exata, recebe atenção. Contamos por que escolhemos o chat como lugar desse pedido em aprovações no chat.
Como começar a governança de agentes de IA no seu time?
- Liste os apps a que os agentes vão ter acesso e o que cada um consegue fazer.
- Marque as ações difíceis de desfazer: as que mexem com produção, dinheiro, clientes ou dados apagados.
- Comece cada agente com leitura e libere escrita aos poucos, ferramenta por ferramenta.
- Defina quem responde por cada agente e quem aprova quando essa pessoa não está.
- Dê a cada agente um orçamento mensal e veja o uso na primeira semana.
- Leia o registro de auditoria nas primeiras semanas e ajuste os níveis.
O agentes.chat já vem com essas regras prontas, e você ajusta o resto. Ele está em acesso antecipado e abre em ondas, por convite. Para entrar numa das próximas, deixe seu e-mail na lista de espera.
Perguntas frequentes
O que é human in the loop?
É manter uma pessoa capaz de ver e barrar o que um sistema de IA faz antes que aconteça. Em agentes, quer dizer que as ações difíceis de desfazer, como deploy, apagar ou enviar, esperam a aprovação de alguém.
Um agente de IA precisa de aprovação para ler dados?
Em geral, não. Ler e investigar não muda nada, e pedir aprovação para isso só cansa quem aprova. No agentes.chat, ler nunca pede aprovação; o que importa é dar ao agente acesso só ao que ele precisa ler.
Quanto tempo vale um pedido de aprovação no agentes.chat?
24 horas. Depois disso, ele expira e o agente precisa pedir de novo. Cada pedido roda uma vez, exatamente com os valores que estavam no cartão.
Quem aprova se o agente não tem responsável?
Os administradores do workspace. O responsável é opcional; sem ele, os pedidos e os alertas de orçamento vão para os administradores.
Dá para fazer todo comando no computador pedir aprovação?
Dá. Um ajuste do workspace faz todo comando pedir aprovação. Ele vem desligado. Desligado, uma lista de bloqueio recusa os comandos perigosos. Nas missões (beta), vale a regra escolhida para cada uma; fora delas, o resto roda sem pedir.
Fontes
Links conferidos em 29 de outubro de 2026. O que esta página diz do agentes.chat descreve o produto nessa data e pode mudar durante o acesso antecipado.
- 1Model Context Protocol, Tools (Model Context Protocol specification, 2025-06-18), 18 de junho de 2025.
- 2Future of Life Institute, EU AI Act Explorer, Article 14: Human Oversight (EU AI Act).
- 3TabNews, Plataforma de vibe coding Replit apaga banco de dados de produção de desenvolvedor, 21 de julho de 2025.
- 4OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, 9 de dezembro de 2025.
- 5Giskard, OWASP top 10 for agentic applications 2026: Understanding the risks of agents and tools, 18 de dezembro de 2025.