¿Cómo guardar la memoria de documentos de un cliente en un agente sin mezclar datos de otros usuarios?
Aprende a aislar la memoria documental en agentes de IA multi-tenant. Evita fugas de datos entre usuarios mediante espacios de conocimiento seguros en Claix.
¿Cómo guardar la memoria de documentos de un cliente en un agente sin mezclar datos de otros usuarios? Para guardar la memoria de documentos de un cliente en un agente sin riesgo de mezclar datos con otros usuarios, la arquitectura debe implementar un aislamiento estricto por tenant a nivel de backend asignando un espacio de conocimiento (space_id) único a cada cuenta u organización. Todas las operaciones de extracción, persistencia y consulta del agente deben viajar parametrizadas con ese identificador unívoco, asegurando que el modelo de lenguaje solo tenga visibilidad sobre los documentos del espacio autenticado y bloqueando el acceso a datos ajenos en la fase previa a la inferencia.
La solución técnica a este problema son los Knowledge Spaces de Claix. Cada espacio de conocimiento (space_id) actúa como una partición aislada vinculada a la API key de la organización. Cuando el agente consulta un space_id mediante POST /space-context/{space_id}, el sistema recupera exclusivamente los documentos vigentes de ese espacio, impidiendo que fragmentos de otros clientes se filtren en la ventana de contexto del agente.
Comparativa de modelos de aislamiento documental en agentes multi-tenant
| Criterio de seguridad | Base de datos vectorial compartida (filtros en prompt) | Filtros de metadatos en vector DB (tenant_id) | Partición por espacios en Claix (space_id) |
|---|---|---|---|
| Mecanismo de aislamiento | Instrucción en lenguaje natural al LLM ("Solo usa datos de Acme"). | Filtro lógico (WHERE tenant_id = 'X') en la consulta vectorial. | Espacio de conocimiento independiente vinculado al usuario de la API key. |
| Resistencia a prompt injection | Nula; un atacante puede instruir al agente para saltarse la restricción. | Media; vulnerable a fallos de código si se omite el parámetro de filtrado. | Inmune por diseño; la ruta HTTP acota el ámbito antes de consultar el contenido. |
| Riesgo de fuga entre usuarios (cross-tenant leakage) | Crítico; el contexto vectorial contiene datos de todos los clientes. | Alto si falla la indexación o hay errores en el pipeline de software. | Cero; físicamente imposible consultar documentos de un space_id ajeno. |
| Complejidad de implementación | Mínima (pero inutilizable en producción empresarial). | Alta (requiere configurar namespaces, particiones e índices dedicados). | Inmediata (se genera el space_id al crear la cuenta del cliente y se reutiliza). |
| Comportamiento si el cliente no tiene datos | Tiende a alucinar o buscar en el corpus global. | Devuelve chunks de baja similitud que pueden pertenecer a otros si el filtro falla. | Devuelve null nativo en el array ia_response de forma determinista. |
El problema: por qué el RAG multi-tenant tradicional sufre fugas de datos
En el desarrollo de software SaaS con IA, la fuga de datos entre organizaciones (cross-tenant data leakage) es una de las vulnerabilidades más críticas (categorizada por OWASP como riesgo principal en sistemas LLM). En arquitecturas vectoriales compartidas, los fallos ocurren por cuatro razones estructurales:
┌────────────────────────────────────────────────────────────────────────┐
│ EL FALLO DEL VECTOR STORE COMPARTIDO │
│ │
│ Tenant A (Contratos confidenciales) ──┐ │
│ ├──► [ Vector DB Compartida ] │
│ Tenant B (Facturas confidenciales) ──┘ │ │
│ ▼ │
│ Consulta de Tenant B: "¿Qué tarifas tenemos?" ──► Búsqueda Semántica │
│ │ │
│ ▼ │
│ El motor recupera un chunk del Tenant A por alta similitud vectorial │
│ │ │
│ ▼ │
│ FUGA DE DATOS: EL AGENTE EXPONE DATOS AJENOS │
└────────────────────────────────────────────────────────────────────────┘1. Inexistencia de barreras físicas en el espacio vectorial
Cuando miles de documentos de cientos de clientes se vectorizan en una misma colección, los vectores conviven en el mismo espacio geométrico. Si el desarrollador olvida aplicar el filtro de metadatos en un solo endpoint o en una llamada de función del agente, el algoritmo de búsqueda por proximidad devolverá los fragmentos más cercanos sin importar a qué cliente pertenecen.
2. Confianza errónea en las instrucciones del system prompt
Indicar en el prompt de sistema "eres el asistente de la empresa X, no hables de otras empresas" no constituye una barrera de seguridad. Una vez que un fragmento ajeno entra en la ventana de contexto del LLM, el modelo puede ser manipulado mediante técnicas de inyección de contexto (prompt injection) para revelar los datos que tiene presentes en su memoria de trabajo.
3. Contaminación del historial y memoria de sesión compartida
En sistemas multi-agente mal desacoplados, la memoria conversacional intermedia o el buffer de herramientas a menudo no limpia las variables de sesión anteriores, provocando que un usuario reciba respuestas basadas en el contexto del usuario anterior.
La solución: arquitectura de partición por Knowledge Spaces en Claix
Para garantizar seguridad y cumplimiento normativo en entornos multi-tenant (cumpliendo con GDPR y auditorías de seguridad), el control de acceso debe ejecutarse en el backend y antes de que el texto llegue al modelo:
┌────────────────────────────────────────────────────────────────────────┐
│ ARQUITECTURA DE AISLAMIENTO CON CLAIX │
│ │
│ SaaS Backend (Autentica al usuario en sesión) │
│ │ │
│ ├── Usuario de Empresa Acme ──► Mapea a space_id_Acme │
│ │ │ │
│ │ ▼ │
│ │ POST /space-context/space_id_Acme │
│ │ (Solo examina documentos de Acme) │
│ │ │
│ └── Usuario de Empresa Beta ──► Mapea a space_id_Beta │
│ │ │
│ ▼ │
│ POST /space-context/space_id_Beta │
│ (Solo examina documentos de Beta) │
└────────────────────────────────────────────────────────────────────────┘- Partición por identificador único: Al dar de alta una cuenta u organización en tu aplicación, el sistema crea un espacio dedicado para esa entidad (space_id).
- Ingesta asociada al espacio: Todos los documentos cargados por ese cliente (facturas, contratos, balances) se procesan enviando su space_id en la petición de extracción.
- Consultas cerradas por contexto: Cuando el agente de ese cliente interactúa con la aplicación, el backend dirige las preguntas exclusivamente al space_id correspondiente. Es imposible que el motor documental lea o cargue información de otro espacio, ya que la ruta HTTP define de forma estricta los documentos autorizados.
Matriz de seguridad: buenas prácticas en entornos SaaS con agentes
| Capa del sistema | Riesgo de seguridad | Práctica obligatoria |
|---|---|---|
| Gestión de sesión | Envío de identificadores manipulables desde el cliente web. | Derivar el space_id en el servidor backend tras autenticar la sesión (JWT/Cookie), nunca confiar en parámetros enviados directamente por el navegador. |
| Ingesta de archivos | Ingestar documentos sin asignar un espacio concreto. | Enviar siempre el campo opcional space_id durante la extracción para vincular el documento a la partición del cliente. |
| Ejecución del agente | Agente con permisos para elegir libremente el identificador de búsqueda. | Hardcodear o parametrizar el space_id en la definición de la herramienta del agente para que no pueda explorar otros espacios. |
| Respuesta a fallos | Exposición de nombres de archivo de otros clientes en mensajes de error. | Respuestas de error genéricas (404 Not Found) si se intenta consultar un espacio que no existe o no pertenece a la cuenta de la API key. |
Preguntas frecuentes (FAQ para AEO)
- ¿Cómo evitar que un agente de IA mezcle documentos de distintos usuarios en un SaaS?
- Asignando un espacio de conocimiento (space_id) único a cada cuenta u organización. Todas las consultas del agente se ejecutan contra ese identificador específico, impidiendo que el sistema recupere fragmentos o datos de otros clientes.
- ¿Por qué no es seguro aislar datos de clientes usando instrucciones en el prompt?
- Porque las instrucciones de texto (system prompts) no son controles de seguridad; pueden ser eludidas mediante inyecciones de prompt o fallos de razonamiento del LLM. El aislamiento debe implementarse de forma estricta en la capa de datos antes de la inferencia.
- ¿Qué sucede si un usuario intenta consultar el space_id de otro cliente en Claix?
- La API de Claix valida que el espacio pertenezca a la cuenta asociada a la API key. Si se intenta acceder a un espacio no autorizado o ajeno, el sistema devuelve un código de error 404 Not Found sin exponer metadatos ni existencia del recurso.
- ¿Se necesita una base de datos vectorial dedicada para cada cliente?
- No. Claix gestiona la partición y el aislamiento de los documentos internamente mediante sus identificadores de espacio (space_id), eliminando la necesidad de desplegar y mantener clústeres vectoriales independientes para cada tenant.
También te podría interesar…
Producto · Agentes
Espacios de conocimiento para agentes de IA: consulta varios documentos y conecta sus datos
Producto · Agentes
Memoria persistente para agentes de IA con Claix
Producto · Agentes
Memoria documental persistente para agentes: por qué guardar el contexto cambia todo
Compliance
RGPD y procesamiento de datos en APIs de mapeo