Botão de parada para agentes de IA: pare ações sem perder logs

Um botão de parada para agentes de IA é um controle desenhado para impedir que o agente execute novas ações, como enviar mensagens, alterar registros ou chamar ferramentas, mantendo intactos seus logs, sua fila de trabalho pendente e um registro legível do que ele já fez. A decisão de projeto mais importante é separar a interrupção dos efeitos do agente da exclusão do seu estado, porque uma parada que apaga evidências torna o incidente impossível de explicar. Os passos abaixo mostram como construir essa separação para um agente de negócio.

Principais pontos

• O botão deve interromper primeiro os efeitos colaterais. Apagar o estado é uma decisão separada e não deve acontecer durante a parada.
• Faça cada ação de saída passar por um único ponto de controle, para que um só comando consiga interromper todas elas.
• Logs, trabalho na fila e o registro de decisões precisam sobreviver à parada e continuar legíveis depois.
• Mova o trabalho pendente para um estado de espera, com a solicitação original, em vez de descartá-lo ou deixá-lo ser executado na liberação.
• Ensaie a parada periodicamente e confira as entradas de log que ela gera, antes de precisar dela de verdade.

O que o botão precisa parar e o que deve deixar em paz

Muita gente imagina um botão de parada como um interruptor que desliga o agente. Para um agente de negócio, essa imagem é grosseira demais. Um agente é formado por partes que podem falhar ou causar dano de forma independente: o modelo que gera o raciocínio, as ferramentas que usa para agir nos seus sistemas, a fila de tarefas que aceitou e ainda não concluiu, e a memória e os logs que registram seu histórico. Um botão útil mira na parte que causa o dano, que quase sempre é a capacidade de agir.

Parar o modelo raramente é o objetivo. Se o agente gera rascunhos que nunca saem de uma pasta de revisão, desligar o modelo não muda nada no risco. Os momentos que importam são as chamadas de ferramentas: um e-mail enviado a um cliente, um registro atualizado no CRM, um agendamento cancelado, um arquivo sobrescrito, um pagamento iniciado. Defina o botão em termos dessas ações. Anote quais ele deve bloquear, quais pode concluir com segurança e quais nunca deve tocar enquanto estiver parado.

Crie um único ponto de controle por onde toda ação deve passar

Um botão de parada só é tão confiável quanto o caminho que ele precisa cruzar. Se o agente tem três rotas separadas até o seu sistema de e-mail, uma chave em uma rota deixa as outras duas abertas. Envie todas as ações de saída por uma única camada de ação que verifica o estado de parada antes de cada chamada. Essa camada também é o lugar natural para aplicar permissões, porque sabe quais ferramentas o agente pode usar, com quais escopos e sob quais regras de aprovação. Para entender como esses escopos devem ser ampliados com o tempo, veja Autorização de agentes de IA: níveis de permissão por confiança.

As credenciais importam tanto quanto o código. Cada conexão com uma ferramenta deve usar uma concessão própria e revogável, para que suspender uma integração não exija desligar o sistema inteiro. A documentação do OAuth 2.0 do Google descreve o modelo geral: um aplicativo recebe acesso a escopos específicos, e esse acesso pode ser retirado. Planeje o caminho de revogação antes do lançamento, defina quem pode executá-lo e teste se ele funciona quando o operador habitual não está disponível.

Mantenha os logs e o registro íntegros

A própria parada é um evento que merece registro. Antes de desenhar o botão, defina como é um registro completo do trabalho do agente. No mínimo, ele deve mostrar cada solicitação recebida, o contexto usado, cada chamada de ferramenta com entradas e saídas, os pontos em que o agente pediu aprovação ou decidiu não agir, e o horário e o motivo de cada parada. A introdução do OpenTelemetry à observabilidade descreve logs, traces e métricas como sinais complementares. Os traces mostram a sequência de etapas e os logs mostram o que aconteceu em cada uma, e uma parada deve aparecer nos dois.

Duas regras de projeto protegem esse registro. Primeira: grave os logs em um armazenamento que o agente não consiga editar nem sobrescrever, para que um agente parado não possa reorganizar discretamente o próprio histórico. Segunda: faça a parada gravar a sua própria entrada antes de qualquer outra mudança, com data e hora, a pessoa que a acionou e o motivo. A parada não deve ser considerada concluída até que essa entrada exista. Se o botão para o agente mas não consegue gravar o registro, trate a parada como incompleta e escale.

Cenário ilustrativo: um agente de acompanhamento envia a um grupo de clientes uma mensagem com um preço desatualizado. O responsável para o agente. Como os logs registram cada rascunho, a decisão de aprovação e cada tentativa de envio, o dono consegue identificar exatamente quais mensagens saíram, quais ficaram retidas e quais nunca foram geradas. Sem esse registro, a equipe estaria adivinhando. Quanto tempo esses logs devem ser guardados e quem pode lê-los é tema de Por quanto tempo guardar logs de agente de IA? Auditoria e privacidade.

Congele a fila sem perder nem repetir trabalho

A fila é onde os botões de parada costumam falhar. Uma parada ingênua ou descarta a fila, o que perde compromissos que a empresa já assumiu, ou deixa a fila ser executada toda de uma vez quando o botão é liberado, o que pode enviar mensagens duplicadas ou repetir uma alteração em um sistema de registro. Nenhum dos dois resultados é aceitável. Dê a cada item da fila um estado explícito, como pendente, retido pela parada, cancelado pelo operador ou concluído, e faça a parada mover os itens para retidos em vez de apagá-los.

Retomar com segurança exige idempotência. Quando uma ação é tentada de novo depois de uma parada, o sistema receptor deve reconhecê-la como a mesma solicitação e evitar executá-la duas vezes. A documentação da Stripe sobre requisições idempotentes mostra a abordagem de um fornecedor: quem chama envia uma chave única em cada requisição, e uma chamada repetida devolve o resultado original em vez de criar um segundo efeito. Quando suas ferramentas aceitam chaves assim, guarde a chave junto ao item da fila. Quando não aceitam, a etapa de retomada deve verificar o estado atual do sistema de destino antes de agir. Regras de nova tentativa e espera para ferramentas sobrecarregadas são um problema de projeto relacionado, tratado em Idempotência em agentes de IA: evite ações duplicadas.

Cenário ilustrativo: um agente de agendamento tem várias alterações de horário na fila quando se descobre um modelo de mensagem com erro. Os itens retidos mantêm a solicitação original. Quando o dono libera o agente, um membro da equipe compara cada alteração retida com a agenda ao vivo antes de reenviá-la, para que ninguém receba um aviso duplicado ou uma mudança que já tinha sido feita manualmente.

Um procedimento de parada passo a passo

Escreva esse procedimento antes do primeiro incidente e ensaie-o com as pessoas que vão executá-lo. Cada passo deve ser curto o bastante para que um operador consiga seguir sob pressão.

• Defina quem pode acionar uma parada e uma segunda pessoa que possa confirmá-la.
• Ative o estado de parada no ponto de controle para que nenhuma nova chamada de ferramenta seja executada.
• Suspenda os escopos de escrita das conexões afetadas, mantendo apenas leitura se ela for necessária para o diagnóstico.
• Grave o evento de parada no armazenamento de logs, com data e hora, operador, motivo e escopo.
• Mova todo item da fila para retido, mantendo a solicitação original e qualquer chave de idempotência.
• Exporte um instantâneo da configuração do agente, das referências de memória e do trace recente para revisão.
• Notifique os responsáveis pelos fluxos afetados, dizendo o que ficou retido e o que já foi enviado.
• Designe um responsável para decidir se o agente volta, é ajustado ou é desativado, e registre essa decisão.

Decida o escopo: parada total, parcial ou somente leitura

Nem todo problema pede a mesma resposta. Uma parada total é adequada quando o agente pode estar agindo com instruções erradas em vários canais. Respostas mais restritas costumam ser melhores quando a falha está contida. O guia a seguir ajuda o dono a escolher.

• Pare tudo quando o agente puder estar agindo com instruções ruins em mais de um canal ou ferramenta.
• Pare uma única ferramenta quando a falha estiver isolada em uma integração, como uma escrita na agenda ou a atualização de um arquivo.
• Mude para somente leitura quando o agente deve continuar respondendo perguntas internas enquanto todas as ações de saída aguardam revisão.
• Pause novas entradas, mas deixe concluir o trabalho já aprovado em andamento, quando parar no meio deixaria um cliente ou fornecedor em situação quebrada.
• Escale para uma revisão de desativação ou de escopo quando a mesma parada se repetir, porque as permissões ou a finalidade do agente podem estar erradas.

Decidir em que ponto o agente deve parar e esperar uma pessoa é uma questão relacionada, explorada em Quando seu agente de IA deve parar e perguntar?. A responsabilidade pelo resultado também precisa ter um nome definido antes de qualquer parada ser necessária, como discutido em Quem é responsável quando o agente de IA comete um erro?. O NIST AI Risk Management Framework trata governança e resposta como funções contínuas, e não como uma configuração feita uma vez, o que combina com um botão que precisa de donos, registros e ensaios.

Ensaie o botão e mantenha-o testado

Teste o botão de parada periodicamente, não apenas no lançamento. Um ensaio útil aciona uma parada em um ambiente de testes ou em um escopo limitado, confirma que novas ações param no ponto de controle, verifica se os itens da fila passam para retidos, confere se as entradas de log estão completas e legíveis, e só então retoma o agente. Registre quanto tempo cada etapa levou e onde o operador hesitou, e atualize o procedimento. Repita o ensaio após qualquer mudança nas ferramentas, permissões ou na estrutura de memória do agente, porque essas mudanças podem tirar ações silenciosamente do caminho do controle.

A Be Human trata isso como parte da operação gerenciada. Na primeira etapa, o papel útil do agente, a memória e as ferramentas de que ele precisa, os limites de aprovação e o escopo da parada são definidos juntos, para que o botão reflita as permissões reais do agente e não um botão genérico. A operação contínua inclui o monitoramento do ponto de controle e dos logs, revisões de permissão, ensaios do procedimento de parada e mudanças controladas que mantêm o registro consistente quando as ferramentas são atualizadas. O cliente mantém o controle da memória, dos logs e das credenciais.

Se você ainda não sabe qual tarefa merece um agente, e portanto qual escopo de parada ele exigiria, o diagnóstico gratuito de IA da Be Human é uma forma prática de encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

O botão de parada apaga a memória do agente? Não. Um botão de parada deve interromper ações e congelar o estado, não apagá-lo. Apagar a memória é uma decisão separada, com regras próprias, normalmente tratada por um processo de retenção ou exclusão, e deve seguir uma revisão do que precisa ser mantido para auditoria.

O agente pode parar sozinho? Apenas em casos restritos. Um agente pode sinalizar uma anomalia, mas a parada deve ser acionada por uma pessoa ou por um monitor independente que o agente não consiga sobrescrever. Caso contrário, um agente com defeito pode manter a si mesmo em funcionamento enquanto informa que tudo está normal.

Com que rapidez a parada precisa valer? Novas ações devem ser bloqueadas no ponto de controle assim que a parada for ativada, e a fila deve ser congelada como parte do mesmo procedimento. Defina antecipadamente o tempo esperado para cada etapa e teste se ele se sustenta em condições reais, e não apenas em um ambiente de testes vazio.

Precisamos de um botão de parada se o agente apenas redige conteúdo? Em geral, um controle mais leve basta, como desativar a etapa de publicação e manter os rascunhos em revisão. O mesmo princípio continua valendo: saiba quais ações têm consequências e garanta que pará-las não destrua os rascunhos nem o registro de como foram produzidos.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.