RAG con Row-Level Security: cómo proteger los datos de tus clientes en sistemas de IA multi-tenant
Imagina que implementas un asistente de IA para tu empresa y lo conectas a toda la documentación interna: contratos, reportes financieros, expedientes de clientes. Ahora imagina que ese mismo sistema lo usan diez empresas distintas desde una sola plataforma. ¿Estás seguro de que el usuario de la empresa A no puede ver los datos de la empresa B? Si no tienes Row-Level Security bien implementado en tu arquitectura RAG, la respuesta puede ser incómoda.
Este es uno de los problemas más subestimados en la implementación de IA empresarial en Latinoamérica. Los equipos técnicos se enfocan en que el modelo responda bien, pero dejan la capa de seguridad de datos como una tarea secundaria. En julio de 2026, con la adopción acelerada de sistemas RAG en empresas medianas y grandes, este tema ya no puede seguir siendo un pendiente.
En este artículo explicamos qué es RAG Row-Level Security, por qué es crítico en entornos multi-tenant, y cómo aplicarlo de forma práctica en tu empresa o en los sistemas que estás construyendo.
¿Qué es RAG y por qué importa la seguridad a nivel de fila?
RAG (Retrieval-Augmented Generation) es la arquitectura que permite que un modelo de lenguaje no solo responda desde su entrenamiento base, sino que primero busque en una base de conocimiento específica —tus documentos, tu base de datos, tus registros— y luego genere una respuesta basada en esa información recuperada.
Es una tecnología poderosa. Pero ese poder tiene una condición: el sistema necesita saber exactamente qué información puede recuperar para cada usuario. Sin esa restricción, el modelo puede responder con datos que el usuario no debería ver.
La Row-Level Security (RLS) es el mecanismo que resuelve esto. A nivel de base de datos, RLS permite definir políticas que filtran automáticamente qué filas de una tabla son visibles para cada usuario o rol. Cuando integras RLS con la capa de recuperación de un sistema RAG, logras que la IA solo tenga acceso a la información que le corresponde a quien está preguntando.
Según el artículo publicado por Subodh Kc en Dev.to, este enfoque es especialmente crítico en industrias reguladas como salud (donde aplica HIPAA) y servicios legales (donde aplica GDPR), pero la necesidad se extiende a cualquier plataforma donde múltiples organizaciones o departamentos compartan la misma infraestructura de IA.
Los cinco pasos para implementar RAG con Row-Level Security
El artículo de referencia propone un framework práctico que vale la pena desglosar con claridad para equipos técnicos en la región:
1. Definir los requerimientos de seguridad. Antes de escribir una sola línea de código, hay que tener claro qué regulaciones aplican, qué niveles de sensibilidad tienen los datos y qué derechos de acceso tiene cada tipo de usuario o tenant. Este paso es estratégico, no técnico.
2. Elegir una base de datos con soporte nativo de RLS. PostgreSQL y SQL Server son las opciones más sólidas. Ambas permiten definir políticas de seguridad directamente en el motor de base de datos, lo que significa que la restricción existe independientemente de la aplicación que consulte los datos. Esto es importante: la seguridad no puede depender solo del código de la aplicación.
3. Implementar las políticas de seguridad. Aquí se definen las condiciones bajo las cuales un registro es visible para un usuario. En PostgreSQL, esto se hace con CREATE POLICY y ALTER TABLE ... ENABLE ROW LEVEL SECURITY. El proceso incluye definir la política, implementarla con funciones SQL y probarla exhaustivamente antes de integrar la capa de IA.
4. Integrar la arquitectura RAG con las políticas de RLS. Este es el paso técnicamente más delicado. El mecanismo de recuperación del RAG debe ejecutar sus consultas en el contexto del usuario autenticado, de forma que las políticas de RLS se apliquen automáticamente al momento de buscar documentos o registros relevantes. Si el retriever ejecuta consultas con un usuario administrador o sin contexto de sesión, las políticas de RLS no tendrán efecto.
5. Monitorear y auditar continuamente. Implementar RLS no es un evento único. Hay que registrar los accesos, detectar anomalías y revisar periódicamente que las políticas sigan siendo correctas a medida que el sistema evoluciona y se agregan nuevos tipos de datos o usuarios.
¿Cómo aplica esto en empresas de Perú y Latinoamérica?
En la región, el escenario más común no es necesariamente una plataforma SaaS con cientos de clientes. Es más frecuente encontrar empresas medianas que están construyendo o adquiriendo sistemas de IA para uso interno, donde diferentes áreas —finanzas, recursos humanos, operaciones— no deberían tener acceso a la información de las otras.
También es muy común el caso de empresas de servicios —consultoras, estudios jurídicos, clínicas— que manejan información de múltiples clientes desde el mismo sistema. En todos estos escenarios, la lógica de Row-Level Security es aplicable y necesaria.
Un aspecto adicional relevante para la región es la normativa local. Si bien HIPAA es estadounidense y GDPR es europea, Perú cuenta con la Ley N° 29733 de Protección de Datos Personales, que establece obligaciones claras sobre el tratamiento de datos sensibles. Implementar RLS en sistemas de IA no es solo una buena práctica técnica: en muchos casos es un requisito legal.
Otro punto que vale mencionar: muchas empresas en Latinoamérica ya tienen PostgreSQL o SQL Server como su base de datos principal. Eso significa que la infraestructura para implementar RLS probablemente ya existe. El desafío no es tecnológico, es de diseño y de voluntad de hacerlo bien desde el principio.
¿Cómo aplica esto en tu empresa?
Si estás evaluando o ya implementando un sistema de IA que accede a datos internos, estas son las preguntas concretas que deberías responder hoy:
- ¿Qué datos puede ver el sistema de IA y quién tiene acceso a esos datos actualmente?
- ¿La capa de recuperación del RAG ejecuta consultas con un usuario con privilegios elevados o con el contexto del usuario final?
- ¿Tienes políticas de RLS definidas en tu base de datos, o la seguridad depende solo del código de la aplicación?
- ¿Tienes logs de qué información recuperó el sistema para cada usuario y en qué momento?
Si alguna de estas preguntas no tiene una respuesta clara, hay un riesgo de seguridad activo en tu sistema. La buena noticia es que con las herramientas correctas y un diseño bien pensado, esto es completamente resoluble.
Conclusión
La inteligencia artificial empresarial es tan confiable como la seguridad de los datos que maneja. RAG es una arquitectura poderosa para conectar modelos de lenguaje con el conocimiento real de una organización, pero sin Row-Level Security bien implementado, ese poder se convierte en un vector de riesgo.
El enfoque correcto combina políticas de seguridad definidas a nivel de base de datos, integración cuidadosa con la capa de recuperación del RAG, y monitoreo continuo. No es el camino más rápido, pero sí el único que permite escalar con confianza.
En Consultoría-Ti ayudamos a empresas en Perú y Latinoamérica a diseñar e implementar sistemas de IA que no solo funcionan bien, sino que están construidos con los estándares de seguridad que el negocio requiere. Si estás evaluando una implementación de IA o quieres revisar la arquitectura de un sistema existente, conversemos.
Fuentes y Referencias
Implementing RAG Row-Level Security for Multi-Tenant AI — Subodh Kc, Dev.to
✨ Contenido generado con ContentFlow — Consultoría-Ti