Quem vigia o agente?

Durante a primeira fase da inteligência artificial generativa, a pergunta operacional era relativamente simples: como obter uma resposta melhor? O time discutia prompt, modelo, contexto, temperatura e custo por chamada. O humano continuava no centro do processo porque a máquina produzia texto, recomendação ou rascunho, e alguém ainda precisava decidir o que fazer. O agente muda essa equação. Ele interpreta um objetivo, consulta dados, escolhe ferramentas, encadeia passos e altera o estado do mundo. Pode abrir uma tarefa, movimentar dinheiro, mudar uma configuração, enviar uma mensagem para um cliente ou excluir um registro. A partir daí, o erro deixa de ser uma resposta ruim na tela. Vira uma ação com consequência.

O salto não é de inteligência, é de autoridade

É por isso que a pergunta mais importante sobre um agente não é qual modelo ele usa. É qual autoridade recebeu. Um sistema pode ter um modelo excelente e ainda ser uma péssima automação se possuir acesso amplo demais, não registrar o que fez ou não tiver uma forma confiável de parar. A governança começa quando a empresa transforma a intenção vaga, "esse agente cuida do suporte", em uma fronteira verificável: ele pode ler quais dados, escrever em quais sistemas, executar quais ações, até que valor, sob qual identidade e com qual responsável humano. O objetivo não é impedir autonomia. É fazer a autonomia caber dentro de um contrato operacional claro.

A distinção entre governar um modelo e governar um agente é decisiva. Um modelo normalmente produz uma saída que outra pessoa avalia. Um agente produz uma mudança de estado diretamente, sem precisar de um intermediário humano em cada etapa ^[2]. Isso desloca o foco da qualidade da resposta para o comportamento completo: quais dados entraram, quais ferramentas foram chamadas, quais permissões foram usadas, que decisão intermediária levou à próxima ação e quem autorizou a cadeia. O risco também se acumula. Um passo aparentemente inofensivo pode conceder contexto para o seguinte, que pode ampliar permissões, alcançar outro sistema e transformar uma pequena falha em uma sequência difícil de reverter.

O contrato mínimo de cada agente em produção:

• Finalidade: qual problema o agente resolve e qual resultado não faz parte do trabalho dele.
• Identidade: sob qual conta, token ou usuário delegado ele opera, com um responsável nominal pela revisão.
• Escopo de dados: quais fontes pode consultar, quais campos são sensíveis e quais informações estão fora dos limites.
• Permissões de ação: quais ferramentas pode chamar, quais operações são somente leitura e quais exigem aprovação antes da execução.
• Critérios de escalonamento: em que situações deve parar, pedir contexto ou transferir a decisão para uma pessoa.
• Registro e interrupção: onde cada ação fica auditável e como o fluxo é suspenso sem depender da boa vontade do próprio agente.

A revisão humana não pode ser um botão genérico

O desenho mais comum de supervisão é também o mais preguiçoso: colocar uma pessoa para aprovar tudo. Na demonstração, parece seguro. Em produção, destrói o ganho da automação e treina o revisor a clicar em aprovar sem ler. O extremo oposto é liberar tudo e olhar somente depois, quando a ação já pode ter sido enviada, paga ou apagada. A supervisão eficaz é definida ação por ação, não agente por agente ^[1]. Um assistente pode responder internamente sem revisão, preparar um reembolso até determinado valor com aprovação e ser bloqueado completamente para encerrar uma conta. O mesmo agente pode ter três políticas diferentes porque cada ação tem um risco diferente.

Supervisão não é escolher entre confiar cegamente e revisar cada clique. É desenhar a fronteira exata entre o que pode ser automático e o que precisa de uma pessoa antes de acontecer.

- Gabriel Krüger, Arquiteto de Operações com IA

Uma forma prática de desenhar essa fronteira é pontuar cada ação por cinco dimensões: reversibilidade, impacto potencial, sensibilidade dos dados, grau de autonomia e domínio regulado ^[1]. Ler uma tarefa interna é reversível e tem baixo raio de impacto. Enviar uma mensagem externa, alterar milhares de registros ou movimentar dinheiro não tem a mesma tolerância. A regra pode ser simples: quanto mais irreversível, amplo, sensível e autônomo for o ato, mais cedo deve aparecer uma barreira humana. A aprovação deve ocorrer antes da execução quando o dano não puder ser desfeito. Para ações menores, a revisão posterior pode preservar velocidade sem abandonar a prestação de contas.

Como transformar supervisão em mecanismo, não em intenção:

• Comece com limites concretos: valor máximo, quantidade máxima de registros, sistemas permitidos e horários de operação.
• Use aprovação por faixa de risco. Abaixo do limite, o agente segue; acima dele, prepara a ação e aguarda um aprovador nomeado.
• Configure timeout com negação segura. Se ninguém responder, o agente não executa por silêncio.
• Envie a solicitação de aprovação com contexto suficiente: ação proposta, dados usados, motivo, impacto provável e alternativa reversível.
• Meça a taxa de aprovação e de override. Se todo pedido é aprovado automaticamente, você criou um ritual, não uma supervisão.
• Teste o botão de parada antes do lançamento e depois em intervalos definidos. Um kill switch que nunca foi exercitado é uma promessa, não um controle.

O último componente é a prova. Governança sem observabilidade vira opinião depois do incidente. Cada aprovação, negativa, override, timeout, chamada de ferramenta e mudança de permissão precisa deixar um registro com contexto: o que o agente propôs, qual política foi aplicada, quem decidiu e por quê ^[1][2]. A empresa também precisa saber quando o controle falhou silenciosamente, por exemplo, um agente que nunca dispara uma aprovação porque a regra está apontando para o evento errado, ou um aprovador que substitui a política em quase todos os casos. O log não serve apenas para culpar alguém depois. Ele mostra se a operação está aprendendo, se as fronteiras estão bem calibradas e se o agente continua dentro do trabalho para o qual foi contratado.

Há ainda um risco que aparece quando vários agentes trabalham juntos: a cadeia de delegação. Se uma pessoa autoriza o agente A e A chama o agente B, a autoridade original precisa continuar rastreável até a ação final. Sem essa continuidade, cada etapa pode emitir uma nova credencial com mais poder do que a pessoa autorizou. Estudos e guias recentes sobre identidade agentiva destacam problemas como privilégio acumulado, agentes ocultos fora do inventário, desvios do caminho de acesso aprovado e cadeias de delegação quebradas ^[3]. Na prática, isso significa manter um inventário de agentes, revisar permissões reais em vez de apenas permissões concedidas e evitar credenciais compartilhadas que tornam impossível responder quem fez o quê. Sua jogada não é instalar um fiscal abstrato para toda a empresa. Escolha um único agente que já existe, de preferência aquele que acessa um sistema real. Escreva o contrato dele em uma página, reduza suas permissões ao mínimo, classifique as ações por risco e crie uma única aprovação para o passo mais sensível. Depois acompanhe uma semana de logs. O resultado dessa experiência dirá mais do que qualquer manifesto de governança: você vai descobrir quais decisões são realmente repetitivas, quais exceções exigem contexto humano e onde a operação estava confiando em permissões que ninguém lembrava de ter dado.