Agentes de IA com freio de mão: como desenhar aprovações antes da ação

Um agente de IA pode parecer muito competente justamente no momento em que está prestes a fazer algo que você não gostaria que ele fizesse sozinho.

Ele pode editar um arquivo importante, enviar uma mensagem para um cliente, alterar o status de um pedido ou executar um comando no ambiente de produção. Em todos esses casos, a questão não é apenas se o agente consegue realizar a tarefa. A questão é se ele deve realizá-la agora, com aqueles dados, usando aquela ferramenta e sem uma decisão humana no meio do caminho.

É aí que entra o freio de mão: pontos de aprovação desenhados antes da ação.

Freio de mão não significa transformar o agente em um assistente que pede licença para cada passo. Também não significa colocar um botão “Confirmar” em toda tela e considerar o problema resolvido. Uma boa aprovação é uma decisão de produto: ela aparece quando há risco ou impacto suficientes para justificar a interrupção, mostra o que realmente será feito e permite que a pessoa decida sem precisar reconstruir o raciocínio do agente.

O objetivo é equilibrar três coisas que costumam entrar em conflito: autonomia para o agente trabalhar, segurança para impedir ações indesejadas e uma experiência de uso que não pareça um formulário de autorização a cada minuto.

Três estados diferentes: informar, pedir confirmação e exigir aprovação

O primeiro erro de projeto é tratar todos os avisos como se fossem iguais. Uma interface pode informar que algo aconteceu, pedir uma confirmação simples ou bloquear uma ação até que uma pessoa aprove. Esses três estados têm consequências diferentes e devem usar componentes, linguagem e regras diferentes.

Informar é comunicar uma ação de baixo risco ou já concluída. O agente pode ter organizado uma lista, preenchido um rascunho ou consultado dados sem alterar nada. A interface mostra o resultado, mas não interrompe o fluxo.

Um cartão pode dizer:

• Rascunho preparado: organizei os três arquivos relacionados ao componente de navegação.
• Consulta concluída: encontrei 18 registros com status “pendente”.
• Alteração aplicada: atualizei o texto do botão em dois arquivos.

Informar não é esconder. A pessoa pode consultar os detalhes, mas não precisa tomar uma decisão para o trabalho continuar.

Pedir confirmação é interromper uma ação que ainda é relativamente simples, previsível e reversível. O agente está prestes a fazer algo que o usuário provavelmente deseja, mas vale conferir o alvo, o escopo ou algum parâmetro importante.

Por exemplo, antes de mover cinco arquivos para uma pasta, a interface pode apresentar a lista e pedir uma confirmação objetiva. Antes de criar um compromisso, pode mostrar data, horário e participantes. A confirmação funciona bem quando o contexto já está claro e o custo de um engano é limitado.

Exigir aprovação é diferente. A ação não deve acontecer sem uma decisão explícita de alguém autorizado. Isso se aplica quando há impacto externo, risco financeiro, exposição de informação, alteração difícil de desfazer ou possibilidade de afetar outras pessoas.

Enviar uma mensagem para um cliente, apagar registros, publicar conteúdo, executar um comando com efeito amplo e alterar permissões são exemplos de ações que normalmente merecem aprovação. Nesses casos, não basta um aviso discreto no rodapé. O sistema precisa deixar claro que a ação está bloqueada até uma decisão.

Uma regra prática:

• Se a ação apenas observa, calcula ou prepara, informar costuma ser suficiente.
• Se a ação é limitada, esperada e facilmente desfeita, confirmação pode bastar.
• Se a ação comunica, compromete, remove, publica, gasta ou altera algo sensível, aprovação explícita é o caminho mais seguro.

Essa distinção também evita um problema comum: usar a palavra “aprovar” para tudo. Quando cada clique recebe o mesmo peso, a pessoa aprende a clicar no botão principal sem ler. O resultado é uma interface cheia de barreiras que, paradoxalmente, reduz a atenção justamente onde ela seria mais necessária.

O risco não está apenas na ferramenta

Classificar uma ação pelo nome da ferramenta é insuficiente. “Editar arquivo” pode significar corrigir uma vírgula em um rascunho ou substituir a configuração de autenticação de um serviço. “Enviar mensagem” pode significar responder a uma conversa interna ou disparar um comunicado para milhares de pessoas.

O risco nasce da combinação entre ação, alvo, dados, alcance e reversibilidade.

Uma classificação útil considera pelo menos estes eixos:

• Impacto: o que pode mudar para o usuário, para a equipe ou para terceiros?
• Alcance: a ação afeta um item, um grupo pequeno ou todo o sistema?
• Sensibilidade: há dados pessoais, financeiros, estratégicos ou credenciais envolvidos?
• Reversibilidade: existe uma forma confiável de desfazer a ação?
• Intenção: o pedido está claro ou o agente está inferindo algo importante?
• Imediatismo: o efeito ocorre agora ou inicia uma cadeia difícil de interromper?
• Autorização: a pessoa que está usando a interface pode permitir essa ação?

Uma correção em um arquivo não publicado, com histórico de versões e escopo explícito, tende a ser menos arriscada do que uma alteração equivalente em um arquivo carregado por um serviço ativo. Uma mensagem de teste para um endereço interno não tem o mesmo peso de uma mensagem para clientes. A mesma ferramenta pode exigir nenhuma intervenção em um contexto e aprovação obrigatória em outro.

Em vez de criar uma tabela abstrata que o usuário nunca vê, o produto pode transformar essa classificação em regras simples:

1. O agente pode consultar dados sem aprovação quando a consulta respeita as permissões existentes.
2. O agente pode preparar rascunhos sem aprovação, desde que não os publique ou envie.
3. O agente pode fazer alterações locais e reversíveis sem aprovação, mostrando o resultado e oferecendo desfazer.
4. O agente precisa de aprovação para ações externas, destrutivas, financeiras ou que envolvam dados sensíveis.
5. Quanto mais incerta a intenção ou maior o alcance, mais explícita deve ser a revisão.

A classificação também deve ser dinâmica. Uma ação que começa pequena pode crescer. O agente pode descobrir que precisa editar 42 arquivos em vez de dois, que uma mensagem será enviada a uma lista maior ou que o comando produzirá uma alteração permanente. Quando o escopo muda, a aprovação anterior deixa de valer automaticamente.

O cartão de aprovação precisa responder às perguntas certas

Uma aprovação ruim apresenta apenas um verbo: “Executar”. O usuário precisa adivinhar o que será executado, em qual lugar, com quais dados e com qual consequência. Uma aprovação boa funciona como um contrato curto entre o agente e a pessoa.

Antes de decidir, o usuário deve conseguir responder:

• O que o agente pretende fazer?
• Por que ele acredita que essa é a próxima ação?
• Qual ferramenta será usada?
• Quais dados serão enviados ou modificados?
• Quais itens estão dentro do escopo?
• Qual efeito é esperado?
• O que pode dar errado?
• É possível revisar ou desfazer?

Isso não exige mostrar toda a cadeia interna de raciocínio do modelo. A interface não precisa despejar pensamentos intermediários nem uma narrativa interminável. Ela precisa mostrar uma justificativa operacional: intenção, parâmetros relevantes, entradas, efeito e limites.

Considere um agente que recebeu o pedido “atualize o texto da página inicial”. Em vez de mostrar somente “O agente quer editar arquivos”, a interface pode apresentar:

• Plano: substituir a frase do cabeçalho da página inicial e manter o restante do conteúdo.
• Arquivos:src/pages/home.tsx e src/content/home.json.
• Ferramenta: editor de arquivos do projeto.
• Alteração: trocar “Controle suas tarefas” por “Organize seu trabalho com clareza”.
• Efeito esperado: o novo texto aparecerá na próxima compilação da aplicação.
• Reversão: restaurar a versão anterior pelo histórico de alterações.

Se houver trechos longos, mostre um resumo e permita abrir a diferença completa. O resumo ajuda na decisão rápida; a diferença preserva a possibilidade de inspeção. Esconder detalhes atrás de quatro camadas de cliques transforma transparência em decoração.

Para uma mensagem, os dados essenciais são outros:

• destinatários e quantidade de pessoas;
• canal de envio;
• remetente usado;
• assunto e conteúdo final;
• anexos ou links;
• momento do envio;
• possibilidade de cancelar ou editar antes da entrega.

O botão principal deve usar um verbo específico. “Aprovar e enviar” é melhor do que “Continuar”. “Aplicar alterações” é melhor do que “Confirmar”. O texto do botão deve revelar o efeito da decisão, não apenas o movimento dentro da interface.

Também vale separar a aprovação da navegação. “Ver detalhes” não deve aprovar; fechar o painel não deve rejeitar; pressionar a tecla Enter não deve executar uma ação de alto impacto sem uma condição clara. Em ações relevantes, o sistema precisa evitar que uma decisão seja tomada por acidente.

Plano primeiro, execução depois

O agente não deve misturar planejamento e execução quando a ação exigir aprovação. Primeiro, ele interpreta o pedido, reúne informações permitidas e monta um plano. Depois, apresenta esse plano. Só então, após a decisão, usa a ferramenta que produzirá o efeito.

Essa separação torna o sistema mais previsível. O usuário consegue revisar uma intenção antes de lidar com as consequências dela. O agente também pode detectar que o plano ficou amplo demais e pedir uma nova orientação antes de avançar.

Imagine o pedido “limpe os dados antigos”. Um plano responsável não executa uma exclusão imediatamente. Ele pode propor:

1. Localizar registros sem atividade há mais de 24 meses.
2. Encontrar 137 registros que correspondem ao critério.
3. Separar os registros que possuem retenção obrigatória.
4. Exportar uma cópia para o armazenamento autorizado.
5. Remover apenas os 129 registros restantes.

Nesse ponto, a aprovação deve destacar que a ação é destrutiva, mostrar a quantidade, explicar o critério e indicar o que ficará de fora. “Limpar dados” é uma intenção vaga; “remover 129 registros sem atividade há mais de 24 meses, preservando oito itens retidos” é uma operação revisável.

O plano também deve ter limites. Se o agente pode editar arquivos, informe quais diretórios estão incluídos. Se pode executar comandos, mostre o comando completo ou uma representação equivalente e indique o ambiente. Se pode alterar registros, mostre o filtro utilizado e a quantidade afetada.

Uma interface madura mostra ainda o que o agente não fará:

• não enviará a mensagem antes da aprovação;
• não modificará arquivos fora dos dois caminhos listados;
• não alterará registros que estejam protegidos;
• não executará o comando em produção sem uma aprovação específica.

Esses limites reduzem a ambiguidade e ajudam o usuário a perceber quando o plano saiu do trilho.

Ferramentas e dados devem aparecer no momento da decisão

O nome da ferramenta não é um detalhe técnico irrelevante. Ele informa o tipo de acesso que será usado e o caminho pelo qual o efeito acontecerá. Um agente que “altera o cadastro” pode estar usando uma integração com o sistema principal, um arquivo local ou uma operação administrativa com permissões muito diferentes.

Mostre a ferramenta em linguagem compreensível e, quando necessário, permita consultar detalhes técnicos. Por exemplo:

• Editor de arquivos: modifica somente os arquivos listados no projeto aberto.
• Mensagens: envia pelo canal corporativo conectado à conta escolhida.
• Base de dados: atualiza os registros que correspondem ao filtro apresentado.
• Terminal: executa o comando no ambiente selecionado, com as permissões disponíveis.

Os dados também precisam ser tratados como parte da aprovação. Não basta dizer “vou usar os dados do cliente”. Mostre quais campos serão lidos ou enviados, especialmente quando houver informação pessoal, financeira ou confidencial.

Se um agente vai enviar uma mensagem com o nome, o pedido e o valor de uma compra, esses campos devem estar visíveis. Se vai anexar um arquivo, mostre o nome, o tamanho e o destino. Se vai enviar dados para uma ferramenta externa, deixe claro o que sai do ambiente atual.

Quando houver informação sensível, a interface pode resumir o conteúdo sem expô-lo desnecessariamente, mas não deve ocultar sua existência. “Contém dados pessoais” é um alerta importante; “dados diversos” não é.

Rejeitar não é apenas clicar em “não”

Uma rejeição encerra a ação atual, mas não precisa encerrar o trabalho. O melhor fluxo preserva o contexto e ajuda a pessoa a corrigir o plano.

Há pelo menos três formas úteis de rejeição:

• Rejeitar e encerrar: o agente descarta o plano e não tenta novamente.
• Rejeitar com orientação: a pessoa explica o que deve mudar, e o agente prepara um novo plano.
• Rejeitar parte do escopo: a pessoa remove itens específicos e aprova o restante, quando isso for seguro.

Se o agente propõe editar dez arquivos e o usuário não quer tocar em config/producao.yml, a interface pode permitir remover esse arquivo do plano e recalcular as alterações. Se o texto de uma mensagem está correto, mas os destinatários estão errados, o usuário deve conseguir corrigir a lista sem começar a conversa do zero.

A rejeição precisa deixar claro o que não aconteceu. Depois de recusar o envio, informe que nenhuma mensagem foi entregue. Depois de recusar uma exclusão, informe que os registros continuam intactos. Esse retorno evita a dúvida perigosa entre “o agente ignorou minha decisão” e “a ação foi parcialmente executada”.

Se houve execução parcial antes da falha ou da rejeição, a interface deve dizer exatamente quais itens foram afetados. Nunca use uma confirmação genérica quando o resultado foi incompleto.

Editar o plano é melhor do que editar a justificativa

Em ações que exigem revisão, a pessoa não deveria precisar conversar em linguagem vaga para corrigir cada detalhe. A interface pode oferecer controles diretos para os parâmetros mais importantes: destinatários, arquivos, registros, horário, ambiente, quantidade e mensagem final.

Isso não transforma o agente em um formulário tradicional. O agente continua interpretando a intenção e montando o plano, mas o usuário ganha pontos claros de intervenção.

Por exemplo, um plano de execução de comando pode permitir:

• trocar o ambiente de produção por um ambiente de teste;
• reduzir o conjunto de arquivos;
• alterar o limite de registros;
• incluir uma opção de simulação;
• pedir uma prévia do resultado antes da execução.

Depois de qualquer edição relevante, o plano deve ser recalculado e apresentado novamente. Não mantenha a aprovação anterior como se nada tivesse mudado. A pessoa aprovou uma versão específica do plano, não uma intenção abstrata que o agente pode modificar livremente.

Expiração, mudança de contexto e aprovação válida

Uma aprovação não deve durar para sempre. O contexto pode mudar: os dados podem ser atualizados, as permissões podem expirar, o destinatário pode deixar de ser válido ou o plano pode ficar antigo.

Defina uma validade para aprovações sensíveis. Ao expirar, o agente deve preparar uma nova versão e pedir revisão novamente. Não basta exibir um aviso depois de executar.

A aprovação também deve ser invalidada quando:

• o escopo da ação aumentar;
• os dados relevantes forem alterados;
• a ferramenta ou o ambiente mudar;
• os destinatários mudarem;
• o conteúdo final for editado;
• as permissões da pessoa forem revogadas;
• o sistema detectar uma condição de risco diferente.

Uma aprovação deve estar ligada a uma versão concreta do plano. Na prática, isso pode ser representado por um identificador interno, um resumo das entradas e um registro do momento em que a decisão ocorreu. O usuário não precisa ver todos esses detalhes o tempo inteiro, mas o sistema precisa deles para impedir que uma decisão antiga seja reutilizada em uma ação nova.

Expiração não deve parecer uma punição. A interface pode explicar: “Este plano foi criado há muito tempo e os dados podem ter mudado. Atualizamos a prévia; revise antes de continuar.” O foco é proteger a decisão, não culpar a pessoa.

Reexecução exige uma nova leitura do resultado

Quando uma ação falha, é tentador oferecer um botão “Tentar novamente” que repete exatamente a operação. Isso pode ser seguro em uma consulta idempotente, mas perigoso em mensagens, pagamentos, criação de registros ou comandos com efeito cumulativo.

Antes de reexecutar, o sistema precisa saber se a primeira tentativa produziu algum efeito. Para uma mensagem, deve informar se foi enviada, recusada ou se o estado é desconhecido. Para uma alteração em arquivos, deve comparar a versão atual com a versão que recebeu aprovação. Para uma atualização de dados, deve verificar quantos registros já foram alterados.

O botão pode assumir formas diferentes:

• Reexecutar com segurança: quando o sistema consegue garantir que o efeito não será duplicado.
• Revisar e tentar novamente: quando o resultado parcial ou desconhecido exige uma nova análise.
• Preparar uma nova operação: quando a ação original já aconteceu e uma nova execução teria outro significado.

Em caso de dúvida, prefira revisar. Uma experiência ligeiramente mais lenta é melhor do que enviar duas mensagens, criar dois registros ou aplicar duas vezes uma alteração difícil de desfazer.

Registrar decisões sem construir um painel burocrático

Registrar aprovações é importante para entender o que aconteceu, investigar erros e oferecer continuidade. Mas registrar tudo na interface principal é uma forma rápida de transformar o produto em um painel administrativo.

A solução é separar o momento da decisão do histórico detalhado. Durante a aprovação, mostre apenas o necessário para decidir. Depois, mantenha um registro acessível com:

• qual ação foi proposta;
• qual versão do plano foi apresentada;
• quem aprovou, rejeitou ou editou;
• quando a decisão ocorreu;
• quais ferramentas e dados foram envolvidos;
• qual foi o resultado real;
• se houve falha, execução parcial ou reexecução.

Esse registro deve distinguir intenção, decisão e efeito. “O agente propôs apagar 129 registros” não significa que “129 registros foram apagados”. “A pessoa aprovou o envio” não garante que o serviço de mensagens tenha concluído a entrega. Uma linha do histórico para cada etapa evita reconstruções confusas.

Também é útil registrar o motivo quando a pessoa rejeita ou altera um plano, mas isso não deve ser obrigatório em toda situação. Exigir uma justificativa formal para cada recusa adiciona atrito e incentiva respostas vazias. Peça contexto quando ele realmente ajudar: em uma operação sensível, em uma revisão de equipe ou quando o sistema precisa melhorar o próximo plano.

Na interface cotidiana, o histórico pode aparecer como uma frase curta: “Aprovado por você às 14h32; 12 arquivos alterados”. Um detalhe expansível revela a ferramenta, a versão do plano e o resultado. A transparência continua disponível sem ocupar a tela inteira.

Como evitar a fadiga de aprovação

Se o agente pede aprovação para tudo, o usuário perde o senso de prioridade. Se nunca pede, a pessoa deixa de confiar nele. O equilíbrio vem de combinar risco, contexto e reversibilidade.

Algumas decisões ajudam:

• agrup ar operações de baixo risco que fazem parte do mesmo plano, em vez de interromper a cada item;
• manter aprovação obrigatória para ações externas, destrutivas ou sensíveis;
• usar prévias e desfazer para alterações locais e reversíveis;
• não pedir aprovação novamente para cada passo interno de uma ação já aprovada, desde que o escopo não mude;
• interromper imediatamente quando surgir uma nova ferramenta, um novo ambiente ou um alcance maior;
• permitir que a pessoa defina preferências para classes de ação, sem transformar essa preferência em autorização irrestrita.

Há uma diferença importante entre “não perguntar novamente nesta sessão” e “nunca perguntar”. A primeira opção pode ser adequada para uma sequência previsível de alterações de baixo risco. A segunda cria uma permissão ampla demais e difícil de entender.

Preferências de autonomia também devem ser específicas. Em vez de “deixe o agente fazer tudo sozinho”, prefira regras como “pode editar arquivos dentro da pasta de rascunhos sem aprovação” ou “pode consultar registros, mas nunca alterar dados sem aprovação”. Quanto mais concreta a permissão, menor a chance de uma interpretação perigosa.

Autonomia conquistada por contexto e reversibilidade

Autonomia não deve ser um atributo fixo do agente. Ela deve ser conquistada pela qualidade do contexto e pela capacidade de corrigir o efeito.

Um agente pode agir com mais autonomia quando conhece bem o escopo, tem dados suficientes, usa uma ferramenta limitada e consegue desfazer o resultado. Pode agir com menos autonomia quando a intenção é ambígua, o alvo é amplo, os dados são sensíveis ou o efeito é permanente.

Essa lógica produz uma progressão saudável:

1. O agente observa e explica o que encontrou.
2. O agente prepara um plano concreto.
3. O usuário revisa e aprova ações relevantes.
4. O sistema mostra o resultado e oferece reversão quando possível.
5. Com contexto suficiente, ações semelhantes podem exigir menos interrupções.

O ganho de confiança não vem de uma promessa de que o agente “entende tudo”. Vem de limites visíveis, decisões localizadas e resultados verificáveis. A pessoa sabe quando o agente está apenas informando, quando está aguardando confirmação e quando não pode prosseguir sem aprovação.

Um padrão simples para começar

Para cada ação que o agente pode executar, descreva cinco coisas antes de desenhar o componente:

1. Intenção: qual objetivo do usuário a ação atende?
2. Ferramenta: qual mecanismo produz o efeito?
3. Dados: quais informações serão lidas, enviadas ou alteradas?
4. Impacto: quem ou o que será afetado?
5. Reversão: como desfazer, corrigir ou investigar o resultado?

Depois, escolha o nível de intervenção. Informar quando o agente apenas consulta ou prepara. Pedir confirmação quando a ação é limitada e reversível. Exigir aprovação quando há impacto externo, risco sensível, escopo amplo ou efeito difícil de desfazer.

Por fim, desenhe o caminho completo, não apenas o modal de aprovação: plano, revisão, edição, rejeição, expiração, execução, falha, resultado e histórico. É nesse percurso que a confiança se forma.

O melhor agente não é o que age sempre sozinho. É o que sabe quando avançar, quando mostrar o próximo passo e quando parar com clareza. O freio de mão bem projetado não reduz a autonomia: ele torna possível aumentá-la sem transformar cada erro em uma surpresa irreversível.