Memory Bank em Produção: 3 Padrões para Não Vazar PII Entre Sessões de Clientes

A Gemini Enterprise Agent Platform introduziu o Memory Bank como um recurso de primeira classe: o agente persiste contexto entre sessões, aprende preferências do usuário e retoma conversas interrompidas sem perder fio. Para casos de uso de atendimento — seguro, bancário, saúde — isso tem valor real.

O problema: memória persistente sem isolamento de tenant é um vazamento programado.

Em produção multicliente, um agente compartilhado armazena e recupera memória. Se a chave de partição for ausente ou incorreta, a busca vetorial do Memory Bank retorna fragmentos de sessões anteriores — de outros clientes. O modelo completa a resposta com esses fragmentos sem sinalizar a contaminação. O usuário vê dados que não são seus. O engenheiro não recebe alerta nenhum.

Esse cenário não é hipotético. É o padrão-padrão da plataforma sem configuração adicional.

Por que o Memory Bank expõe PII por padrão

O Memory Bank é implementado sobre um índice vetorial. Cada entrada é um fragmento de memória com metadados opcionais. Quando um agente recupera contexto para uma nova sessão, ele consulta o índice com embeddings semânticos da conversa atual — não com filtros de identidade, a menos que você os configure explicitamente.

A busca semântica encontra o que é relevante, não o que é seu. Sem particionamento, “qual o saldo da conta?” pode retornar memória de uma sessão anterior de outro cliente que fez a mesma pergunta.

Memória persistente bem configurada é o que diferencia um agente que aprende de um agente que vaza. A diferença está em uma única linha de metadado.

Padrão 1 — Tenant-scoped memory profiles

O padrão mais direto: cada cliente (tenant) tem seu próprio Memory Profile — um namespace isolado dentro do Memory Bank. O agente só lê e escreve dentro do perfil do tenant ativo.

Na Gemini Enterprise Agent Platform, isso se traduz em passar o tenant_id como filtro obrigatório em todas as operações de memória:

# Errado — sem escopo de tenant
memory_bank.search(query=user_message, top_k=5)

# Correto — com filtro de tenant
memory_bank.search(
    query=user_message,
    top_k=5,
    filter={"tenant_id": session.tenant_id}
)

O filtro de metadado elimina da busca qualquer fragmento que não pertença ao tenant atual. Não é uma feature opcional — é a linha que separa isolamento real de aparente.

Quando usar: qualquer deployment multicliente. Sempre. Sem exceção.

Padrão 2 — TTL diferenciado por nível de sensibilidade de dados

Nem toda memória tem o mesmo tempo de vida útil — nem o mesmo risco. Dados de preferência (tom de comunicação, formato preferido de relatório) são de baixo risco e ganham com longevidade. Dados transacionais (saldo consultado, operação autorizada) têm janela de relevância curta e risco alto.

Configure TTL (time-to-live) diferenciado por categoria de dado:

MEMORY_TTL = {
    "preference":    60 * 60 * 24 * 90,   # 90 dias — baixo risco
    "interaction":   60 * 60 * 24 * 30,   # 30 dias — médio risco
    "transactional": 60 * 60 * 24 * 1,    # 1 dia   — alto risco
    "pii_explicit":  60 * 60 * 4,          # 4 horas — crítico
}

memory_bank.write(
    content=fragment,
    metadata={
        "tenant_id": session.tenant_id,
        "category": "transactional",
    },
    ttl=MEMORY_TTL["transactional"]
)

A vantagem do TTL curto para dados sensíveis não é só conformidade com LGPD/GDPR — é que minimiza a janela de exposição caso a filtragem por tenant seja violada por bug.

Quando usar: qualquer sistema que manipule dados financeiros, de saúde ou identificadores pessoais. O TTL curto é uma camada de defesa em profundidade.

Padrão 3 — Memory audit log com rastreabilidade de origem

Os padrões 1 e 2 previnem vazamentos em condições normais. O padrão 3 detecta quando algo deu errado.

Todo fragmento escrito no Memory Bank deve carregar um audit trail mínimo: quem escreveu, em qual sessão, com qual tenant associado, e quando. Em produção, isso significa:

memory_bank.write(
    content=fragment,
    metadata={
        "tenant_id":  session.tenant_id,
        "session_id": session.id,
        "agent_id":   agent.id,
        "written_at": datetime.utcnow().isoformat(),
        "category":   classify_pii(fragment),   # enum: none / low / high
    },
    ttl=MEMORY_TTL[classify_pii(fragment)]
)

Com esse log, qualquer leitura de memória pode ser auditada: “esse fragmento veio de qual sessão, de qual tenant?”. Quando um cliente relata “vi dados que não são meus”, você tem rastreabilidade completa para investigar — e para demonstrar conformidade.

Combine com um alerta automático quando classify_pii(fragment) == "high" em uma leitura cross-session. Falsos positivos vão existir, mas o custo de um falso negativo é incomparavelmente maior.

Quando usar: qualquer sistema regulado (saúde, finanças, educação) onde auditabilidade é requisito legal.

Os três padrões juntos

Cada padrão resolve uma camada diferente do problema:

Aplicados juntos, eles formam uma defesa em profundidade: o Padrão 1 previne o caso normal, o Padrão 2 limita o dano se o Padrão 1 falhar, e o Padrão 3 dá rastreabilidade para auditoria regulatória.

O que não está na documentação oficial

A documentação da Google para o Memory Bank descreve a API com clareza. O que ela não faz é avisar que o comportamento padrão é inseguro para deployments multiclientes. O filtro por tenant não é o default — é uma configuração que precisa ser explícita.

Esse é o tipo de armadilha que só aparece em produção, quando o primeiro cliente relata ter visto dados de outro. Nesse ponto, o retrabalho de retroativamente isolar memórias existentes é custoso — e potencialmente envolve notificação regulatória.

O custo de implementar os três padrões desde o início é de algumas horas. O custo de não implementar pode ser uma violação de LGPD com dever de notificação em 72 horas.

Posts relacionados

Fonte primária: Google Cloud Blog — Introducing Gemini Enterprise Agent Platform