Dados sensíveis na memória de agentes de IA: o que nunca guardar

Os dados sensíveis na memória de agentes de IA devem se limitar ao que a função do agente realmente exige, e uma lista curta de categorias não deve ser guardada de forma alguma: credenciais, números completos de pagamento e de documentos, detalhes de saúde, circunstâncias pessoais privadas, assuntos de funcionários e material confidencial de terceiros. Você faz isso valer com três camadas que trabalham juntas: uma regra de memória escrita, um filtro que roda antes de qualquer gravação e uma revisão recorrente do que a memória de fato contém. Uma regra que o sistema não consegue verificar é só uma esperança, então cada categoria precisa de um mecanismo por trás.

Principais pontos

• A memória persiste: um detalhe sensível salvo uma vez pode reaparecer em sessões futuras, para outros usuários e em outros canais.
• Defina as categorias de nunca guardar antes de o agente entrar no ar e escreva uma alternativa restrita para cada uma, como uma referência no lugar do valor.
• Coloque o controle principal no sistema que grava a memória, e não apenas nas instruções do agente.
• Revise a memória armazenada em intervalos definidos, porque filtros deixam passar coisas e as pessoas colam material inesperado.
• Usar um dado sensível dentro de uma tarefa é diferente de retê-lo. Projete para usar sem reter.

Por que a memória persistente muda o risco?

Uma janela de chat esquece quando a sessão termina. A memória de um agente é construída para fazer o contrário: ela guarda fatos para que a próxima conversa comece com contexto. Esse é o valor, e também o risco. Um detalhe digitado com pressa, como uma senha colada em um atendimento, pode ser resumido, armazenado, recuperado no mês seguinte e mostrado a alguém que nunca deveria vê-lo.

Três propriedades tornam o dado armazenado mais difícil de controlar do que o dado de uma única conversa. Ele dura mais do que a tarefa que o criou. Ele viaja, porque a memória pode ser recuperada em outras sessões e, dependendo do desenho, por outras pessoas (a questão discutida em memória compartilhada ou pessoal). E ele é reescrito, porque resumos transformam texto bruto em notas curtas, fáceis de passar despercebidas em uma revisão.

As referências de segurança e de gestão de risco tratam isso como um problema conhecido. O OWASP Top 10 para aplicações com LLMs inclui a divulgação de informações sensíveis entre seus riscos, e o NIST AI Risk Management Framework trata a privacidade como parte da construção de uma IA confiável. Nenhum dos dois diz quais fatos o seu agente deve guardar. Essa decisão é sua, e é mais fácil tomá-la antes do lançamento do que depois.

Quais categorias de dados um agente nunca deve guardar?

A lista abaixo é um ponto de partida. Ajuste-a ao seu setor e à função do agente, mas mantenha o padrão como não. Tudo o que uma função precisa deve ser incluído de forma deliberada, com um responsável e um motivo.

• Credenciais e segredos: senhas, tokens de acesso, chaves de API, códigos de recuperação e chaves privadas. As ferramentas devem acessar os sistemas por fluxos de autorização adequados, de modo que o agente nunca precise lembrar de um segredo.
• Números completos de pagamento e de identificação: números de cartão, dados de conta bancária, CPF, RG, passaporte e outros identificadores fiscais. Se a função precisa se referir a eles, guarde um ponteiro, como forma de pagamento cadastrada no sistema de cobrança.
• Saúde, dados biométricos e categorias especiais semelhantes: condições médicas, deficiência, dados genéticos ou biométricos. Ficam de fora, a menos que uma função seja desenhada, aprovada e governada especificamente para eles.
• Circunstâncias pessoais privadas: situação familiar, dificuldade financeira, religião, posição política, estado civil ou de relacionamento. As pessoas mencionam isso de passagem, e comentários de passagem não devem virar registros permanentes.
• Assuntos de funcionários: avaliações de desempenho, histórico disciplinar, salário e detalhes de denúncias, a menos que o agente seja uma função de RH com regras de acesso compatíveis.
• Material confidencial de terceiros: contratos, preços, rascunhos ou documentos internos de outro cliente. O checklist prático de isolamento de dados de clientes em agentes de IA mostra como manter essas barreiras de pé.
• Registros privilegiados e regulados: aconselhamento jurídico, arquivos de investigação e qualquer coisa sujeita a dever de sigilo.
• Anexos brutos e conversas coladas: capturas de tela, cadeias completas de e-mail e formulários digitalizados, que carregam detalhes sensíveis que ninguém escolheu incluir.
• Inferências sobre indivíduos: palpites sobre humor, honestidade, capacidade de crédito ou personalidade. A opinião de um agente sobre uma pessoa não é um fato e não deve ser salva como se fosse.

Repare que vários itens não são segredos no sentido estrito. Um detalhe familiar contado em uma mensagem amigável não é perigoso no momento. Ele vira problema quando fica na memória sem finalidade, sem prazo de validade e sem responsável.

Como decidir se um fato é seguro para lembrar?

Os casos de fronteira vão surgir todos os dias, então dê ao sistema e às pessoas que o revisam o mesmo guia de decisão curto. Um fato só é salvo se todas as respostas forem aceitáveis.

• A função precisa disso para fazer seu trabalho na semana que vem? Se não, não guarde.
• Um ponteiro pode substituir o valor? Guarde onde o dado está, não o dado em si.
• Quem poderia recuperá-lo depois? Se o público for maior do que a pessoa a quem o dado se refere e o responsável pela função, não guarde.
• A pessoa a quem ele se refere pode corrigi-lo ou removê-lo? Se não existe um caminho para isso, não guarde.
• Ele tem prazo de validade ou data de revisão? Se não tem, defina um antes de salvar.
• O responsável ficaria à vontade ao vê-lo em uma revisão de memória? Se a resposta é não, a resposta para guardar também é não.

Esse guia também separa uso de retenção. Um agente pode precisar de uma fatura de cartão em uma tarefa, como explicar uma cobrança recusada no momento. Usá-la dentro da tarefa é uma decisão diferente de gravá-la na memória, e a segunda exige uma justificativa própria. Uma fonte da verdade fora do agente, como o sistema de cobrança, permite que ele aponte para o dado sem copiá-lo.

Como regras, filtros e revisões fazem a política valer?

Cada camada pega o que as outras deixam passar, então use as três.

As regras são a política escrita. Elas nomeiam as categorias de nunca guardar, indicam a alternativa permitida para cada uma e dizem quem é o responsável pela política. Coloque a regra também nas instruções do agente, mas não trate isso como o controle. Instruções podem ser ignoradas, mal interpretadas ou sobrescritas por texto hostil dentro de um documento ou mensagem, e é por isso que a injeção de prompt é tratada como um risco à parte nas orientações do OWASP.

Os filtros ficam no harness, a camada em torno do modelo que decide o que é gravado, recuperado e registrado em log. Uma gravação de memória deve ser uma ação controlada, e não texto livre acrescentado a um arquivo. Comportamentos úteis de filtro incluem:

• Detectar formatos reconhecíveis antes de salvar, como números parecidos com cartão, padrões de documentos de identidade e formatos de token ou chave, e então ocultar ou rejeitar o conteúdo.
• Usar uma segunda verificação que classifique a nota proposta de acordo com as categorias de nunca guardar antes de ela ser gravada.
• Colocar em quarentena uma nota sinalizada para revisão humana, em vez de descartá-la em silêncio, para que a equipe aprenda o que escapa.
• Aplicar o mesmo filtro à ingestão de documentos, às saídas de ferramentas e aos resumos, porque dados sensíveis entram por todos esses caminhos.
• Limitar quem e o que pode ler a memória, seguindo o menor privilégio e a negação por padrão, como nas orientações de autorização do OWASP.

As revisões são a checagem humana recorrente. Os filtros vão falhar com formatos incomuns e detalhes que dependem do contexto, então alguém precisa ler amostras da memória real em intervalos definidos, buscar as categorias acima, tratar a fila de quarentena e atualizar os padrões do filtro. O método descrito em auditoria de memória de agente de IA mostra como conduzir essa revisão. Quando a revisão encontra algo, a correção é a exclusão com registro, e o guia como apagar a memória de um agente de IA explica a diferença entre corrigir, expirar e excluir.

Um outro ponto merece atenção: a memória não é o único repositório. Transcrições, logs, conjuntos de avaliação e backups podem guardar os mesmos detalhes. Aplique as mesmas categorias e os mesmos limites de retenção a eles, ou a política apenas muda o problema de lugar.

Um plano passo a passo para o primeiro mês

Você pode montar isso sem um grande projeto. Siga esta ordem.

• Defina a função em uma frase e liste os fatos que ela realmente precisa lembrar. Todo o resto fica fora do escopo por padrão.
• Escreva a lista de nunca guardar para essa função, com o ponteiro ou resumo permitido em cada caso.
• Nomeie um responsável pela política e uma pessoa substituta que possa aprovar exceções.
• Transforme as gravações de memória em uma ação controlada, com formato de nota fixo, e adicione detecção de formato para os casos mais claros, como credenciais e números de pagamento.
• Inclua uma etapa de quarentena para notas sinalizadas e decida quem as examina e com que frequência.
• Teste antes do lançamento com dados falsos: cole números de cartão inventados, tokens falsos e histórias pessoais fictícias, e confirme que nada sensível é armazenado, registrado em log ou resumido.
• Defina um ritmo de revisão, com leitura de amostras da memória e checagem dos logs, e registre toda mudança nas regras e nos filtros.
• Dê aos usuários um jeito simples de dizer remova isto, e garanta que esse pedido chegue a um processo real de exclusão.

A etapa de teste é a mais importante. Muitas equipes confirmam que o agente se comporta bem em uma demonstração, mas nunca verificam o que foi gravado nos bastidores.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: um agente de atendimento de uma empresa de assinaturas responde a mensagens de clientes. Um cliente escreve que um pagamento falhou e cola o número completo do cartão para ajudar. O filtro de gravação reconhece o formato do cartão e bloqueia a nota. O agente responde que não pode usar dados de cartão neste canal e indica a página segura de cobrança. A nota armazenada diz: pagamento falhou, cliente direcionado à cobrança, resolvido pelo cliente. Nenhum número chega à memória, ao resumo ou ao log.

Mais tarde, o mesmo cliente explica que uma situação médica causou o atraso e pede mais prazo. O agente salva apenas que uma prorrogação foi solicitada e quem a aprovou. O motivo não é guardado, porque a função precisa da decisão, não do diagnóstico. Se o pedido exige uma pessoa, o agente o encaminha com os fatos necessários, e o humano decide o que, se for o caso, registrar no sistema adequado.

Na revisão semanal, a responsável lê uma amostra de notas, confere a fila de quarentena e encontra uma nota com uma cadeia de e-mails colada que o filtro não pegou. Ela remove a nota, adiciona um padrão para esse caso e registra a mudança. Esse pequeno ciclo é o que torna a política real.

Como a Be Human trata dados sensíveis na memória de agentes?

A Be Human define a memória como parte da função logo no primeiro projeto: o que a função precisa lembrar, quais categorias ela nunca pode guardar e onde é exigida aprovação. As regras de memória, os filtros de gravação e as permissões são implementados no harness em torno do agente, e, na operação gerenciada, realizamos revisões recorrentes da memória armazenada, revisões de permissões e melhorias controladas nos filtros. O cliente mantém o controle da política e das exceções, e toda mudança em qualquer uma delas é registrada.

Perguntas frequentes

Basta dizer ao agente para não lembrar de dados sensíveis? Não. As instruções são uma camada, e podem falhar por interpretação equivocada, entrada incomum ou texto hostil dentro de um documento. Coloque um filtro no sistema que grava a memória e revise o que foi armazenado, para que a política não dependa de o modelo se comportar perfeitamente.

Um agente pode usar dados sensíveis durante uma tarefa sem armazená-los? Sim, se o desenho permitir. O agente pode ler o dado no sistema de registro para uma tarefa e descartá-lo, guardando apenas uma nota como a ação realizada. Verifique se logs e resumos não capturam o mesmo dado, porque essa é a forma mais comum de retenção acidental.

O que fazer se já houver dados sensíveis na memória? Remova-os, registre o que foi removido e por quê, e procure cópias em resumos, logs e backups. Depois descubra como o dado entrou e adicione um filtro ou uma regra para fechar esse caminho. Uma rotina de revisão como a do guia de auditoria de memória ajuda a encontrar casos semelhantes antes que se acumulem.

Isso substitui uma orientação jurídica ou de proteção de dados? Não. Este artigo descreve controles de engenharia e de operação, não exigências legais. Suas obrigações dependem do seu setor, dos seus clientes e da sua jurisdição, então envolva seu contato jurídico ou de proteção de dados e, no Brasil, siga as orientações da ANPD ao decidir quais categorias a sua política precisa cobrir.

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