Como apagar a memória de um agente de IA: corrigir, expirar, excluir

Para apagar a memória de um agente de IA, localize todos os lugares em que o fato está guardado, corrija ou remova o registro de origem e depois limpe as cópias criadas a partir dele: resumos, índices de busca, caches e logs. Pedir no chat que o agente esqueça algo não é exclusão, porque o registro continua armazenado e pode ser recuperado de novo. Um processo confiável trata a memória como dado com responsável, regra de validade e trilha de auditoria.

Principais pontos

• Dizer ao agente para esquecer não muda nada no armazenamento. A exclusão acontece no repositório de memória, no índice e nos logs, não na conversa.
• Escolha primeiro a ação certa: corrigir um fato que mudou, expirar um fato que só valeu por um período, excluir um dado que não deveria ser mantido.
• A memória tem camadas. Um fato removido de um registro pode sobreviver em um resumo, um embedding, um cache ou um backup.
• Toda exclusão precisa de uma prévia, uma aprovação humana, um teste que prove que o fato não aparece mais e um comprovante que não repita o conteúdo apagado.
• O conhecimento embutido por fine-tuning é o mais difícil de remover. Por isso, mantenha fatos de negócio que mudam em registros recuperáveis, e não nos pesos do modelo.

Por que pedir ao agente que esqueça não funciona?

Um modelo de linguagem não mantém um livro-razão que possa ser editado sob demanda. O que parece memória em um agente de negócio é um conjunto de registros armazenados que o sistema carrega no contexto de trabalho do modelo antes de ele responder. Se o registro existe, ele pode ser carregado de novo na semana que vem, não importa o que o agente disse hoje.

Há um segundo problema. Quando alguém escreve "esqueça o antigo contato de preços" no chat, muitos sistemas guardam essa frase como uma nova anotação. A anotação passa a conter exatamente o detalhe que você queria eliminar. O agente também pode continuar usando o fato até o fim da sessão, porque a própria conversa faz parte do contexto de trabalho até a sessão terminar ou ser compactada.

Portanto, a pergunta útil não é se o agente consegue esquecer. É se sua equipe consegue encontrar, alterar e verificar todas as cópias armazenadas de um fato. Isso é uma tarefa de operação, e funciona melhor quando o desenho do sistema já a prevê desde o início.

Onde a memória de um agente realmente fica?

Antes de apagar qualquer coisa, você precisa de um inventário. Na maioria dos agentes de negócio, um mesmo fato pode estar em vários destes lugares ao mesmo tempo:

• Histórico de conversas: a transcrição das interações passadas, muitas vezes guardada para dar continuidade.
• Registros de memória de longo prazo: anotações, preferências e decisões que o agente salvou de propósito. O artigo sobre memória de IA ou histórico de chat explica por que elas devem ficar separadas das transcrições.
• Índice de busca: documentos divididos em trechos e guardados como embeddings para o agente poder pesquisá-los.
• Resumos: versões compactadas de trabalhos longos, que podem levar um fato adiante mesmo depois de o original sumir.
• Caches de integração: cópias de campos de CRM, eventos de agenda ou dados de chamados trazidos de outras ferramentas.
• Logs e rastros: registros do que o agente viu e fez, mantidos para depuração e revisão.
• Backups e exportações: cópias instantâneas de qualquer item acima.
• Pesos do modelo: apenas se alguém fez fine-tuning de um modelo com material da empresa.

O último item merece uma observação. Quando o conhecimento é treinado dentro de um modelo, não existe uma linha para apagar, e removê-lo geralmente significa retreinar. A recuperação de informação (RAG) mantém o conhecimento em um repositório externo que você pode editar, e essa é uma das razões para guardar fatos que mudam nele. A comparação da AWS entre recuperação e fine-tuning descreve essa diferença, e nosso texto sobre RAG ou fine-tuning para o conhecimento da empresa trata dessa escolha com mais profundidade.

Corrigir, expirar ou excluir?

São três ações diferentes, e confundi-las causa a maioria dos problemas de memória. Use este guia para escolher.

• Corrija quando um fato mudou, mas o histórico ainda importa. Grave o novo valor, marque o antigo como substituído com data e motivo, e garanta que a busca prefira o valor atual. Exemplo: um cliente passou a aprovação de entregas para outra pessoa.
• Expire quando um fato só é verdadeiro por um período. Dê a ele uma data de validade no momento em que for salvo, para que saia da busca por conta própria. Exemplo: um arranjo temporário de entrega, um horário sazonal de funcionamento, um contato interino.
• Exclua quando o dado não deveria ser mantido de forma alguma. Isso vale para dados pessoais cuja remoção alguém pediu, informação enviada por engano, uma senha colada no chat ou dados de um cliente guardados no contexto de outro.
• Coloque em quarentena quando houver dúvida. Marque o registro como não recuperável enquanto uma pessoa decide. É mais rápido que um debate e mais seguro que deixá-lo ativo.

O erro mais comum é excluir quando corrigir bastaria. Se você apaga um contato antigo, o agente perde o motivo pelo qual uma decisão passada foi tomada. Se você apenas corrige um registro que legalmente precisava ser excluído, continua guardando um dado que não deveria. Decida de propósito e registre o motivo.

Uma falha parecida é a memória que nunca esteve errada, mas simplesmente envelheceu. O guia sobre como evitar que contexto antigo engane seu agente de IA mostra como identificar isso antes de alguém pedir uma correção.

Passo a passo para remover uma memória

Use a mesma sequência sempre, para que o trabalho seja repetível e outra pessoa possa executá-lo. O plano abaixo supõe que o agente guarda a memória em registros sob seu controle.

• Passo um: receba o pedido e confirme quem tem permissão para fazê-lo. O contato de um cliente pode pedir mudanças nos próprios dados. Um colega pode não ter autorização para excluir registros de outra equipe.
• Passo dois: defina o escopo com exatidão: qual fato, qual pessoa ou cliente, qual período, quais canais.
• Passo três: pesquise em todas as camadas do inventário. Busque por identificadores estáveis, como IDs de registro, e-mails e IDs de cliente, e não apenas pelas palavras de que alguém se lembra.
• Passo quatro: gere uma prévia. Liste cada registro, trecho, resumo e entrada de log que corresponda, e o que acontecerá com cada um: corrigir, expirar, excluir ou colocar em quarentena.
• Passo cinco: obtenha aprovação humana da prévia. A exclusão é irreversível, então deve ficar atrás de uma etapa de aprovação. Defina com clareza em que ponto o agente deve parar e pedir confirmação.
• Passo seis: aja primeiro na origem. Corrija ou exclua o registro ou documento original, porque todo o resto deriva dele.
• Passo sete: reconstrua as cópias derivadas. Remova os trechos e embeddings correspondentes por ID, gere de novo os resumos afetados e limpe os caches relacionados.
• Passo oito: teste. Faça ao agente, em uma sessão nova, as perguntas que antes traziam o fato à tona e confirme que ele não aparece. Verifique também se a substituição correta aparece, quando houver uma.
• Passo nove: escreva um comprovante com o que foi pedido, quem aprovou, quando rodou, quais camadas foram tocadas e o resultado do teste. Não copie o conteúdo apagado para o comprovante.

A ordem importa. Se você apagar as cópias derivadas antes de corrigir a origem, a próxima reindexação ou sincronização trará o fato de volta sem ninguém perceber.

E os resumos, embeddings e logs?

É nesses três que os fatos apagados costumam sobreviver.

Os resumos são os mais traiçoeiros. Quando um trabalho longo é compactado em um briefing curto, um detalhe pode migrar para o briefing e durar mais que o original. Se um fato é removido, qualquer resumo produzido a partir de material que o continha deve ser regenerado ou editado. Projetar resumos que citem seus registros de origem torna isso possível, e o artigo sobre como compactar contexto sem perder decisões importantes mostra como manter as decisões rastreáveis ao longo da compactação.

Embeddings são representações numéricas guardadas em um índice vetorial. Apagar um documento de uma pasta compartilhada não remove seus trechos do índice. Dê a cada trecho um identificador que aponte para o documento de origem, de modo que remover o documento remova todos os seus trechos em uma única operação. Arquiteturas de recuperação, como a descrita na referência do Google Cloud para geração aumentada por recuperação, separam o repositório de dados do modelo justamente por isso: dá para atualizar o repositório sem mexer no modelo.

Os logs puxam em duas direções. Você quer registro suficiente para investigar um erro e quer que o conteúdo sensível suma quando precisar sumir. Um bom meio-termo é registrar por padrão referências e identificadores (ID do registro, ferramenta chamada, resultado) em vez do conteúdo completo, e definir um prazo de retenção para os logs que contenham conteúdo. A exposição de informações sensíveis é uma categoria de risco reconhecida no OWASP Top 10 para aplicações com LLM, então vale tratar o conteúdo dos logs como parte do mesmo inventário.

Backups precisam de uma regra declarada. Ou os backups expiram em um calendário conhecido, ou o procedimento de restauração reaplica os comprovantes de exclusão antes de os dados restaurados voltarem a valer. Escolha uma das duas opções e escreva, porque senão uma restauração pode ressuscitar tudo o que você removeu.

Cenário ilustrativo: um contato sai e chega um pedido

Este é um cenário ilustrativo, não um caso real.

Uma empresa de serviços usa um agente que prepara atualizações semanais para clientes. A gerente de operações de um cliente deixa a empresa, e o cliente pede que os dados dela sejam removidos. Na mesma semana, o cliente indica um novo contato de aprovação.

A equipe trata primeiro o novo contato como uma correção. O antigo aprovador é marcado como substituído, a nova pessoa é adicionada com data de início e a busca é configurada para preferir o registro atual. As decisões passadas assinadas pela antiga aprovadora permanecem no histórico, porque explicam o trabalho anterior.

O pedido de remoção é tratado como exclusão. A equipe pesquisa pelo e-mail da ex-gerente e pelo ID do cliente. A prévia mostra uma anotação de memória com as preferências dela, dois trechos de documento no índice, um resumo compactado que a menciona pelo nome e uma entrada de cache sincronizada do CRM. Um revisor aprova. A anotação e o documento de origem são alterados primeiro, os trechos são removidos por ID, o resumo é regenerado sem os dados dela e o cache é limpo. Em uma sessão nova, a equipe pergunta quem aprova as atualizações daquele cliente e pede as preferências da ex-gerente. O agente cita o novo contato e não tem nada sobre a anterior. O comprovante registra as etapas sem repetir os dados dela.

O que tornou isso rápido: IDs estáveis, um registro de origem definido e uma prévia e um teste repetíveis.

Como a Be Human trata correção e exclusão de memória

A Be Human projeta a memória como dado gerenciado desde o primeiro projeto. Cada camada de memória recebe um responsável, um registro de origem, uma regra de validade quando cabe e um limite de aprovação para exclusão. Correções e remoções seguem a sequência de prévia, aprovação, aplicação e verificação, com um comprovante guardado para revisão. As rotinas recorrentes incluem conferir se os itens expirados realmente saíram da busca, revisar o que os logs retêm e testar se os fatos removidos deixaram de aparecer. Quando o agente depende de uma fonte da verdade confiável, a correção feita nela se propaga para as cópias derivadas, em vez de ser remendada em vários lugares.

O que preparar antes do primeiro pedido chegar?

É muito mais fácil construir a exclusão desde cedo do que adaptá-la depois. Uma lista curta de prontidão:

• Um inventário escrito de todos os lugares em que o agente guarda ou copia dados.
• Um identificador estável em cada registro, trecho e resumo, ligando-o à sua origem.
• Um campo de validade nos fatos que são temporários por natureza.
• Uma pessoa nomeada para aprovar exclusões e uma regra sobre quem pode solicitá-las.
• Um prazo de retenção para logs e uma regra declarada para backups.
• Um roteiro de teste em sessão nova para confirmar que um fato sumiu.
• Um formato de comprovante que registre a ação sem o conteúdo.

Se você consegue marcar a maioria desses itens, um pedido de exclusão vira trabalho de rotina, e não uma emergência. Para dados regulados, pergunte ao seu assessor jurídico quais deveres de retenção e exclusão se aplicam à sua empresa, pois o processo técnico deve seguir esses deveres, e não o contrário.

Perguntas frequentes

Posso fazer o agente esquecer apenas uma conversa? Sim, se as conversas forem guardadas como registros separados. Exclua ou coloque em quarentena essa transcrição e depois verifique se alguma anotação de longo prazo ou resumo foi gerado a partir dela, pois eles podem levar o conteúdo adiante. Teste em uma sessão nova ao final.

Apagar a memória altera o modelo em si? Não quando o conhecimento está em registros recuperáveis, porque o modelo não é alterado pelos dados armazenados. Se o modelo passou por fine-tuning com o material, o conhecimento pode estar embutido nos pesos, e a remoção pode exigir retreinar ou trocar o modelo. Esse é um bom motivo para manter fatos que mudam fora do fine-tuning.

Por quanto tempo um agente deve guardar memória por padrão? Guarde cada tipo de memória apenas pelo tempo em que ela serve à função do agente e defina o prazo no momento em que a memória é criada. Preferências e decisões permanentes podem ficar até serem alteradas, enquanto arranjos temporários e transcrições brutas devem ter prazos curtos e explícitos. Revise os prazos periodicamente com quem é responsável pelo processo.

Quem deve poder pedir ao agente que exclua algo? Limite a exclusão direta a pessoas nomeadas e deixe todos os demais enviarem um pedido que passe pelas etapas de prévia e aprovação. O agente pode propor uma exclusão, mas a aprovação deve vir de uma pessoa com autoridade sobre aqueles dados. Isso também protege contra alguém apagar um registro por engano ou manipulando o agente.

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