Memory Bank en Producción: 3 Patrones para No Filtrar PII Entre Sesiones de Clientes

TL;DR El Memory Bank de la Gemini Enterprise Agent Platform es poderoso y peligroso en la misma medida. Sin aislamiento por tenant ID, un agente de atención al cliente puede responder la sesión del cliente B con datos del cliente A. Este artículo documenta los 3 patrones que aplicamos en producción para evitar ese escenario.

La Gemini Enterprise Agent Platform introdujo el Memory Bank como un recurso de primera clase: el agente persiste contexto entre sesiones, aprende preferencias del usuario y retoma conversaciones interrumpidas sin perder el hilo. Para casos de uso de atención — seguros, banca, salud — esto tiene valor real.

El problema: la memoria persistente sin aislamiento de tenant es una fuga programada.

En un despliegue multicliente, un agente compartido almacena y recupera memoria. Si la clave de partición está ausente o es incorrecta, la búsqueda vectorial del Memory Bank devuelve fragmentos de sesiones anteriores — de otros clientes. El modelo completa la respuesta con esos fragmentos sin señalar la contaminación. El usuario ve datos que no son suyos. El ingeniero no recibe ninguna alerta.

Este escenario no es hipotético. Es el comportamiento predeterminado de la plataforma sin configuración adicional.

Por qué el Memory Bank expone PII por defecto

El Memory Bank está implementado sobre un índice vectorial. Cada entrada es un fragmento de memoria con metadatos opcionales. Cuando un agente recupera contexto para una nueva sesión, consulta el índice usando embeddings semánticos de la conversación actual — no filtros de identidad, a menos que se configuren explícitamente.

La búsqueda semántica encuentra lo que es relevante, no lo que es tuyo. Sin particionamiento, “¿cuál es el saldo de mi cuenta?” puede devolver memoria de una sesión anterior de otro cliente que hizo la misma pregunta.

La memoria persistente bien configurada es lo que diferencia a un agente que aprende de uno que filtra datos. La diferencia está en un único campo de metadato.

Patrón 1 — Memory profiles con alcance por tenant

El patrón más directo: cada cliente (tenant) tiene su propio Memory Profile — un namespace aislado dentro del Memory Bank. El agente solo lee y escribe dentro del perfil del tenant activo.

En la Gemini Enterprise Agent Platform, esto significa pasar el tenant_id como filtro obligatorio en todas las operaciones de memoria:

# Incorrecto — sin alcance de tenant
memory_bank.search(query=user_message, top_k=5)

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

El filtro de metadato elimina de la búsqueda cualquier fragmento que no pertenezca al tenant actual. No es una función opcional — es la línea que separa el aislamiento real del aparente.

Cuándo usar: cualquier despliegue multicliente. Siempre. Sin excepción.

Patrón 2 — TTL diferenciado por nivel de sensibilidad de datos

No toda la memoria tiene la misma vida útil — ni el mismo riesgo. Los datos de preferencia (tono de comunicación, formato preferido de informe) son de bajo riesgo y se benefician de mayor longevidad. Los datos transaccionales (saldo consultado, operación autorizada) tienen una ventana de relevancia corta y alto riesgo.

Configura TTL (time-to-live) diferenciado por categoría de dato:

MEMORY_TTL = {
    "preference":    60 * 60 * 24 * 90,   # 90 días  — bajo riesgo
    "interaction":   60 * 60 * 24 * 30,   # 30 días  — riesgo medio
    "transactional": 60 * 60 * 24 * 1,    # 1 día    — alto riesgo
    "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"]
)

El TTL corto para datos sensibles no es solo una medida de cumplimiento del RGPD — minimiza la ventana de exposición si el filtrado por tenant falla por un error.

Cuándo usar: cualquier sistema que maneje datos financieros, de salud o identificadores personales. El TTL corto es una capa de defensa en profundidad.

Patrón 3 — Log de auditoría con trazabilidad de origen

Los patrones 1 y 2 previenen fugas en condiciones normales. El patrón 3 detecta cuando algo salió mal.

Cada fragmento escrito en el Memory Bank debe llevar un rastro de auditoría mínimo: quién lo escribió, en qué sesión, con qué tenant asociado, y cuándo. En producción:

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)]
)

Con este log, cualquier lectura de memoria puede ser auditada. Cuando un cliente reporta haber visto datos de otro, tienes trazabilidad completa para investigar — y para demostrar cumplimiento regulatorio.

Cuándo usar: cualquier sistema regulado (salud, finanzas, educación) donde la auditabilidad es un requisito legal.

Los tres patrones juntos

Patrón 1

Aislamiento de Tenant

Filtro obligatorio de tenant_id en todas las operaciones del Memory Bank. Previene acceso cruzado entre clientes.

Previene la fuga

Patrón 2

TTL por Sensibilidad

Los datos transaccionales expiran en horas, las preferencias en semanas. Minimiza la ventana de exposición si el aislamiento falla.

Limita el daño

Patrón 3

Log de Auditoría

Trazabilidad completa del origen de cada fragmento. Detecta anomalías entre sesiones y demuestra cumplimiento.

Detecta lo que pasó

¿Construyendo agentes con datos sensibles?

Autenticare diseña arquitecturas de agentes con aislamiento de tenant, auditabilidad y cumplimiento de LGPD desde el primer sprint. Habla con nuestro equipo antes de ir a producción.

Hablar con especialista Ver Fábrica de Agentes