RAG multi-tenant seguro: cómo filtrar permisos antes de recuperar contexto

La keyword principal es `RAG multi-tenant`; la intención es implementar un chat de conocimiento que no entregue a un usuario chunks, citas o respuestas basadas en documentos de otro tenant, equipo o nivel de acceso.

El orden correcto es identidad verificada → política → filtro de retrieval → ranking → contexto → modelo. Si recuperas top-50 global, filtras top-5 al final y solo entonces construyes el prompt, ya has expuesto datos a una capa que puede registrar trazas, caché, métricas o errores.

Ejemplo con Postgres, pgvector y RLS

Postgres permite que la base aplique Row Level Security aunque alguien añada una ruta de aplicación defectuosa. Usa una cuenta de aplicación que no sea owner de la tabla, activa RLS y fuerza RLS para que el owner tampoco la eluda accidentalmente. La variable de sesión se fija dentro de una transacción, desde claims que el servidor validó.

CREATE TABLE rag_chunks (id uuid PRIMARY KEY, tenant_id uuid NOT NULL, classification text NOT NULL, content text NOT NULL, embedding vector(1536), revoked_at timestamptz); ALTER TABLE rag_chunks ENABLE ROW LEVEL SECURITY; ALTER TABLE rag_chunks FORCE ROW LEVEL SECURITY; CREATE POLICY tenant_can_read_chunks ON rag_chunks FOR SELECT USING (tenant_id = current_setting('app.tenant_id', true)::uuid AND revoked_at IS NULL); SELECT set_config('app.tenant_id', :verified_tenant_id, true); SELECT id, content FROM rag_chunks WHERE classification = ANY(:allowed_classifications) ORDER BY embedding <=> :query_embedding LIMIT 12;

Índice compartido, colección por tenant o aislamiento físico

Un índice compartido con filtros es eficiente cuando los tenants son numerosos, el motor ejecuta el filtro antes de devolver candidatos y puedes medir el coste de ACL de alta cardinalidad. Es la opción normal para SaaS, pero requiere una disciplina fuerte de ingesta, filtros obligatorios y tests negativos.

Una colección o namespace por tenant reduce el radio de blast y simplifica algunas consultas, a costa de operaciones, shards pequeños y migraciones. Úsalo cuando cada tenant tenga volumen suficiente o un modelo de retención distinto. Para clientes regulados o muy sensibles, una cuenta, índice o clave de cifrado dedicada puede ser una decisión de producto válida.

No elijas según la facilidad de la demo. Elige según dónde puedes demostrar aislamiento: permisos por chunk, backup y restauración, borrado, logs, caché, soporte operativo y capacidad de revocar acceso sin re-embeddar todo el corpus.

Reranking ocurre después del filtro. Si necesitas diversidad por documento o un mínimo de citas, aplícalo dentro del conjunto permitido. La mejora de relevancia nunca puede reintroducir un candidato que la política excluyó.

Pruebas de aislamiento que deben bloquear un despliegue

Crea dos tenants con documentos deliberadamente similares y una tercera identidad sin acceso. Comprueba que cada consulta, variante lingüística y prompt injection solo devuelve citas del tenant correcto. Incluye documentos de ACL vacía, grupos revocados, clasificación caducada y errores del proveedor de identidad; el comportamiento seguro es denegar o devolver cero contexto.

Prueba todas las superficies: retrieval directo, API de chat, streaming, historial, cache, búsqueda de archivos, enlaces citados, herramientas MCP y tareas en background. Haz también una prueba de conexión reutilizada para confirmar que no conserva `app.tenant_id` ni un cache key de otro usuario.

Registra request ID, política/version de ACL, número de candidatos antes y después del filtro, ids de chunks permitidos hasheados y decisión final. No guardes el prompt y los chunks íntegros por defecto: una traza de seguridad que se convierte en repositorio de datos sensibles no es observabilidad responsable.