Memória de agente é armazenamento de dados da empresa, mesmo quando ninguém chama de banco de dados

A maioria dos agentes nas empresas hoje esquece por desenho. Cada sessão começa vazia, busca o que precisa e termina. Os times de produto querem cada vez mais o contrário: um agente que lembra o que aprendeu na semana passada, liga isso ao que leu hoje e melhora com o tempo. É uma capacidade real. É também um novo repositório de dados, com todas as obrigações que vêm junto.

O que o exemplo do Google Cloud faz

O repositório de exemplos de IA generativa do Google Cloud traz um agente com memória sempre ativa, construído com o Agent Development Kit e o Gemini 3.1 Flash-Lite. Ele funciona em três fases:

• Ingestão. Texto, imagens, áudio, vídeo e PDFs (27 tipos de arquivo em cinco categorias) viram memórias estruturadas, com resumos, entidades e notas de importância. O conteúdo chega por uma pasta monitorada, por upload no dashboard ou por um endpoint HTTP.
• Consolidação. A cada 30 minutos, por padrão, o agente revisa as memórias novas, encontra conexões entre elas, gera insights transversais e comprime informação relacionada.
• Consulta. As perguntas são respondidas lendo as memórias e os insights da consolidação, com citação das fontes.

As memórias ficam num SQLite. O desenho roda continuamente em segundo plano, por isso usa um modelo rápido e barato.

Para ser preciso sobre o status: é código de exemplo num repositório público, não um produto gerenciado do Google Cloud. É uma referência de desenho que vale estudar, não algo para colocar em produção do jeito que está.

Por que memória muda o modelo de risco

Busca pergunta “o que o agente pode ler agora?”. Memória acrescenta quatro perguntas mais difíceis:

O que ele pode guardar? A ingestão copia conteúdo para fora do sistema de origem. A classificação e as regras de acesso que a origem tinha não viajam sozinhas.

Por quanto tempo? Um repositório de memória sem regra de retenção guarda tudo para sempre, inclusive o que o sistema de origem apagou depois.

Quem pode recuperar? No exemplo, uma consulta lê todas as memórias. Tudo bem para o assistente de uma pessoa. Num agente compartilhado, a recuperação precisa respeitar as permissões de quem pergunta, ou o dado confidencial de uma pessoa vira resposta para outra.

Dá para corrigir ou apagar? A consolidação cria dados derivados: insights e resumos que combinam várias fontes. Apagar o documento de origem não apaga o insight construído a partir dele, a menos que o sistema registre a procedência.

1. Ingerir com origem e classificação
2. Guardar com dono e retenção
3. Consolidar mantendo a procedência
4. Recuperar filtrando pelas permissões de quem pergunta
5. Corrigir ou eliminar, inclusive o derivado

• Escrever: Ingerir com origem e classificação · Guardar com dono e retenção
• Derivar: Consolidar mantendo a procedência
• Ler e eliminar: Recuperar filtrando pelas permissões de quem pergunta · Corrigir ou eliminar, inclusive o derivado

Rótulos viajam com o dadoTodo insight conhece suas fontes

As regras de desenho que aplicaríamos

Leve os rótulos da origem. Cada memória deve registrar de onde veio, o rótulo de sensibilidade e quem podia ver o original. É isso que torna possível a recuperação com permissão.

Mantenha a procedência na consolidação. Um insight deve listar as memórias de que foi construído. Sem esse vínculo, não dá para atender um pedido de eliminação nem explicar uma resposta.

Defina o escopo da memória por tenant, time ou usuário. Decida a fronteira antes de guardar o primeiro byte. Misturar memórias de contextos diferentes é decisão de produto com consequência de privacidade, não otimização de desempenho.

Defina retenção e teste a eliminação. Escolha um prazo por tipo de memória e faça um exercício de eliminação que prove que os insights derivados também somem.

Coloque a memória no mapa de custódia. Onde o repositório fica, quem opera e sob qual jurisdição é a pergunta de custódia aplicada a uma nova cópia dos seus dados. Se você já usa busca gerenciada, vale o mesmo raciocínio da análise sobre construir ou comprar a camada de busca.

A LGPD alcança a memória do agente de forma direta. O princípio da necessidade limita o tratamento ao mínimo necessário para a finalidade, o que vai contra o reflexo de “guardar tudo, pode ser útil”. O artigo 16 manda eliminar os dados ao fim do tratamento, e o artigo 18 garante ao titular correção e eliminação, o que inclui a memória do agente e o que foi derivado dela. Quando a ANPD ou um titular perguntar onde estão os dados de alguém, “na memória do assistente” precisa ser uma resposta que a empresa saiba dar.

O que fazer agora

1. Encontre a memória que você já tem: históricos de chat, repositórios de sessão de agentes, índices vetoriais e recursos de “anotações” nas ferramentas que seus times usam.
2. Dê a cada um dono, classificação e prazo de retenção.
3. Exija procedência em qualquer recurso de consolidação ou resumo que você construir ou comprar.
4. Faça a recuperação respeitar permissões antes que qualquer memória atenda mais de um usuário.
5. Faça um exercício de eliminação que inclua insights derivados, e mapeie a memória no registro de operações de tratamento.
6. Pergunte aos fornecedores onde a memória fica, por quanto tempo e como a eliminação se propaga.

Em resumo

Memória persistente é uma das coisas mais úteis que um agente pode ganhar, e o exemplo do Google mostra um jeito limpo de construí-la. Ela também transforma um assistente num sistema de registro de tudo o que ele lembra. Trate como banco de dados desde o primeiro dia: rótulos, donos, retenção, acesso e eliminação. Sai muito mais barato do que descobrir depois que o agente lembra o que a empresa deveria ter esquecido.