Como parar um agente de IA com segurança sem apagar sua memória

Para parar um agente de IA de executar ações, coloque o controle de pausa no ponto em que as ações saem dos seus sistemas, como o servidor de e-mail, a API de pagamentos ou a ferramenta de mensagens, e bloqueie essas chamadas de forma centralizada. Mantenha a memória do agente e as tarefas não concluídas em registros separados e duráveis, para que a pausa interrompa o trabalho de saída sem apagar o que o agente sabe ou o que estava fazendo. Teste a pausa com o mesmo cuidado que dedica ao próprio agente, porque um controle de parada que nunca foi exercitado tende a falhar justamente quando mais importa.

Principais pontos

• Aplique a pausa onde as ações saem da empresa, e não apenas nas instruções do próprio agente.
• Trate a interrupção de ações externas, a retenção de novos trabalhos e o apagamento de estado como três operações separadas.
• Guarde memória e registros de tarefas em armazenamentos que a pausa não toca, e tire um snapshot antes de qualquer retomada.
• Torne as ações externas idempotentes, para que um agente retomado não repita um pagamento ou uma mensagem por acidente.
• Escreva um runbook de pausa, defina quem pode acioná-la e ensaie antes que alguém precise.

Por que uma instrução de parada dentro do agente não basta

Um agente instruído a parar continua sendo um modelo lendo entradas. Um e-mail de fornecedor, uma página da web ou um documento compartilhado pode conter texto que tenta substituir suas instruções, e o agente pode tratar esse texto como um novo comando. As orientações da OWASP sobre injeção de prompt enfatizam o menor privilégio e a aprovação humana para ações de alto impacto, o que aponta para a mesma conclusão: o modelo não deve ser a única coisa entre uma instrução e um efeito. Uma parada escrita no prompt é, portanto, um pedido. Uma parada aplicada pelos sistemas que o agente acessa é um controle.

O controle deve existir em três lugares: no gateway pelo qual o agente acessa ferramentas e canais, nas credenciais que o agente possui e nas contas de provedor por trás delas. Se o gateway recusa chamadas de saída, o agente não consegue enviar nada mesmo quando seu raciocínio falha. Se seus tokens podem ser suspensos do lado do provedor, uma sessão comprometida perde acesso mesmo que o gateway seja contornado. Quanta autoridade um agente tem em cada etapa é uma questão de desenho separada, tratada em Autorização de agentes de IA: níveis de permissão por confiança, e a pausa deve ser desenhada considerando esses níveis.

Separe três tipos de parada

A maioria das equipes imagina um grande botão vermelho. Na prática, há três respostas diferentes, e cada uma deve estar disponível para uma pessoa identificada.

• Reter: bloquear todas as ações de saída. O agente continua lendo, redigindo e registrando. Costuma ser a primeira resposta, porque interrompe o efeito externo preservando todo o resto.
• Esvaziar: parar de aceitar novas tarefas, deixar as tarefas em andamento chegarem a um estado seguro e então interromper o que ainda não começou.
• Encerrar: parar o processo do próprio agente, com memória e registros de tarefas preservados em um armazenamento que sobrevive à parada.

O erro comum é implementar apenas o encerramento, geralmente apagando a sessão do agente e reiniciando-o. Isso põe fim à ação imediata, mas também apaga o contexto das promessas feitas a clientes, a lista do que já foi enviado e os motivos por trás das tarefas abertas. A parada em si raramente é o que causa dano. O que causa dano é a amnésia que vem depois.

Uma pausa deve mudar o que o agente pode fazer, não o que ele lembra.

Como projetar um portão de saída que retenha todas as ações?

Direcione cada chamada de ferramenta, mensagem e escrita externa por um único gateway ou broker. O gateway verifica o estado de pausa para cada classe de ação, como mensagens a clientes, pagamentos, atualizações de registros e exportações de arquivos, e recusa chamadas que caem sob uma retenção ativa. A flag de pausa deve ficar em um armazenamento onde o agente não consegue escrever, para que ele não possa desligar a própria pausa.

Negue por padrão. As orientações de autorização da OWASP recomendam aplicar decisões de acesso no lado do servidor e conceder apenas as permissões que cada função precisa. No caso da pausa, isso significa que o gateway deve recusar qualquer classe de ação que não reconheça, em vez de permitir porque ninguém a listou. Registre cada decisão, inclusive as tentativas bloqueadas. Esses registros são evidência do que o agente tentou e são a primeira coisa que um revisor vai precisar depois de um incidente. Os conceitos de observabilidade do OpenTelemetry, baseados em traces e spans, oferecem um vocabulário útil para acompanhar uma requisição desde o agente, passando pelo gateway, até o sistema externo.

Com o gateway em funcionamento, uma retenção deve poder ser confirmada em minutos pela leitura dos registros. Se você não consegue demonstrar que nenhuma chamada de saída teve sucesso depois que a retenção foi acionada, o controle ainda não está pronto.

O que deve sobreviver a uma pausa: trabalho em andamento e memória?

Cada ação externa deve ter um registro de tarefa com estados explícitos, por exemplo: na fila, enviando, enviada, aguardando resposta, retida e cancelada. O registro que diz enviando é o mais importante de tratar com cuidado, porque o pedido pode ter chegado ao provedor mesmo que o agente nunca tenha recebido a resposta. Tentar de novo às cegas pode duplicar um pagamento ou uma reserva.

A Stripe documenta um padrão claro para isso em sua API: o cliente envia uma chave de idempotência com a requisição, e repetir o pedido com a mesma chave devolve o resultado original em vez de criar um segundo objeto. Nem todo provedor oferece esse recurso, mas o seu gateway pode aplicar a mesma disciplina. Atribua a cada ação externa uma chave única, verifique se a ação já aconteceu após um timeout e só então tente novamente. Assim, um agente retomado não repete trabalho já concluído.

A memória merece a mesma separação. Guarde o conhecimento durável do agente como registros versionados fora da janela de contexto, para que a sessão atual possa ser descartada sem descartar o que foi aprendido. Durante uma retenção, gatilhos externos não devem gravar nova memória, mas o sistema ainda deve conseguir tirar um snapshot. Decida com antecedência quais ações esperam por uma pessoa antes de serem executadas, usando a abordagem de Quando seu agente de IA deve parar e perguntar?, para que a pausa e a fila de aprovação não entrem em conflito.

Como é uma pausa na prática?

Um runbook transforma o desenho em uma sequência que alguém não especializado consegue seguir sob pressão. Uma versão viável tem esta forma:

• Defina quem pode acionar uma retenção, com um substituto para cada uma dessas pessoas.
• Escreva as condições de acionamento: volume inesperado de envios, uma resposta que compromete a empresa com um preço ou uma data, uma falha em um sistema conectado ou evidência de que o agente recebeu instruções injetadas.
• Acione a retenção no gateway e confirme nos registros que nenhuma nova chamada de saída teve sucesso.
• Tire um snapshot da memória e da fila de tarefas antes de mudar qualquer outra coisa.
• Classifique cada tarefa retida como concluir manualmente, cancelar ou manter para retomada.
• Entre em contato com quem recebeu uma mensagem errada, com a correção escrita por uma pessoa.
• Registre o motivo, as evidências e cada decisão no registro de incidente.
• Retome somente quando um responsável nomeado aprovar e uma ação de teste passar pelo gateway.

Cenário ilustrativo (não é um cliente real): uma empresa de serviços de campo usa um agente para enviar lembretes de visita. Depois que a sincronização da agenda falha, o agente começa a redigir mensagens de reagendamento para visitas que não existem mais. O responsável de plantão aciona uma retenção no gateway. O agente continua lendo a agenda e redigindo, mas nada sai da empresa. A equipe tira um snapshot da fila, marca os rascunhos como retidos e conserta a sincronização. Depois, o responsável revisa os rascunhos retidos, envia manualmente os válidos e cancela os obsoletos. As mensagens enviadas antes da retenção não podem ser recuperadas, então o registro de incidente serve de base para as notas de acompanhamento aos clientes afetados.

Na operação gerenciada da Be Human, o gateway, os registros de tarefas, a rotina de snapshot e o runbook são definidos no primeiro projeto, junto com o papel do agente, para que o cliente saiba exatamente o que uma pausa interrompe. O monitoramento revisa os registros do gateway, a revisão de permissões confirma que as credenciais ainda correspondem aos níveis aprovados, e a resposta a incidentes segue o runbook. O cliente mantém a autoridade para pausar a qualquer momento.

Como testar uma pausa antes de precisar dela?

Uma pausa que nunca foi exercitada é uma hipótese. Monte um conjunto curto de testes que cubra as falhas previsíveis: interromper um envio enquanto a chamada está em andamento, simular um timeout depois que o provedor já aceitou uma requisição, pausar enquanto há gravações de memória pendentes, revogar um token e confirmar que o agente falha de forma visível em vez de silenciosa, e retomar verificando que nenhuma ação foi duplicada. As recomendações da Anthropic sobre avaliações de agentes de IA sugerem construir conjuntos de avaliação a partir de falhas reais, então cada incidente deve acrescentar um caso ao conjunto.

Execute esses testes sempre que o agente ganhar uma ferramenta, um canal ou uma permissão, e inclua-os em avaliações recorrentes em vez de tratá-los como tarefa de configuração única. Guarde os resultados no mesmo registro do runbook, para que quem acionar a pausa no futuro veja o que foi testado e o que não foi. Quando a pausa funcionar nos testes, a próxima pergunta é qual tarefa merece um agente primeiro, e o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar essa primeira tarefa.

Perguntas frequentes

A pausa pode apagar o que o agente aprendeu? Não, e não deve. Uma pausa bem desenhada interrompe as ações de saída e o novo trabalho externo, enquanto a memória e os registros de tarefas permanecem em armazenamentos que a pausa não altera. Se um incidente exigir uma parada total, o processo do agente pode ser encerrado, mas o conhecimento armazenado e o histórico de tarefas devem ser salvos em snapshot antes e mantidos para revisão.

O próprio agente deve poder se pausar? Ele pode sinalizar um problema e pedir uma retenção, e esse pedido é útil porque o agente pode notar anomalias cedo. Mas a autoridade para aplicar a retenção deve ficar com uma pessoa identificada e com o gateway, e não com o raciocínio do agente. Um agente que pode desligar os próprios controles não tem controle efetivo.

O que acontece com as mensagens já enviadas antes da pausa? A pausa não consegue desfazê-las. O registro de incidente deve identificar cada mensagem e ação enviada antes da retenção, e uma pessoa deve decidir se é necessária uma correção ou um acompanhamento. Por isso, registrar desde o início tanto as tentativas bloqueadas quanto os envios bem-sucedidos é tão importante.

Com que frequência devemos testar a pausa? Teste sempre que as ferramentas, permissões ou canais do agente mudarem, e inclua os testes em avaliações recorrentes para que rodem mesmo quando nada parecer ter mudado. Vale também fazer um ensaio curto do runbook com as pessoas que de fato acionariam a pausa, porque o primeiro uso real não deve ser a primeira vez que alguém lê os passos.

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