RLS en base de datos: qué es y cómo proteger tus datos

RLS (Row Level Security, seguridad a nivel de fila) es una función de las bases de datos que controla qué filas de una tabla puede ver o modificar cada usuario. En lugar de dar acceso a una tabla entera, la propia base de datos aplica reglas y devuelve solo los registros que corresponden a cada persona, según su rol, su departamento o su centro. Es una de las formas más sólidas de proteger información sensible sin duplicar tablas ni confiar solo en la aplicación.

¿Qué es RLS en una base de datos, explicado sin tecnicismos?

Imagina el archivo de una gestoría con los expedientes de todos los clientes. Sin RLS, quien tiene llave del archivo puede abrir cualquier cajón. Con RLS, la llave de cada empleado solo abre los cajones de sus clientes.

Técnicamente, se define una política asociada a una tabla: una condición que cada fila debe cumplir para ser visible para el usuario que consulta. Si la fila no la cumple, para esa persona simplemente no existe.

¿Cómo funciona Row Level Security?

El funcionamiento suele seguir estos pasos:

• Se activa RLS sobre una tabla concreta (por ejemplo, clientes, facturas o citas).
• Se crean políticas que indican quién puede leer, insertar, actualizar o borrar cada fila.
• Cada política compara un dato de la fila (por ejemplo, el centro o el responsable) con la identidad del usuario que hace la consulta.
• La base de datos filtra automáticamente los resultados, aunque el usuario lance una consulta sin filtros.

Motores como PostgreSQL, SQL Server u Oracle incluyen mecanismos de este tipo, y plataformas basadas en PostgreSQL, como Supabase, lo usan de forma muy habitual. Los detalles de sintaxis cambian entre sistemas, pero la idea es la misma.

¿Por qué importa RLS a una empresa que no es técnica?

Porque el problema que resuelve es de negocio, no solo informático:

• Confidencialidad: una clínica no quiere que recepción vea historiales clínicos, ni que un centro vea los datos de otro.
• Cumplimiento del RGPD: aplicar el principio de minimización y limitar el acceso a quien lo necesita es más fácil de demostrar si está forzado en la base de datos.
• Menos errores humanos: si el filtro vive en un solo sitio, no depende de que cada pantalla o informe lo programe bien.
• Una sola fuente de datos: no hace falta mantener copias separadas por departamento.

¿Qué ventajas tiene frente a controlar el acceso solo desde la aplicación?

Si la seguridad se programa únicamente en la aplicación, cualquier fallo, una consulta mal escrita o una integración nueva puede saltarse el filtro. Con RLS, la regla está en el origen del dato y se aplica siempre, venga la petición de donde venga.

Aun así, RLS no es una solución mágica:

• Hay que diseñar bien las políticas; una política mal escrita puede dejar datos abiertos o bloquear usuarios legítimos.
• Políticas complejas pueden afectar al rendimiento si no se revisan e indexan.
• No sustituye a otras medidas: autenticación, cifrado, copias de seguridad y registros de auditoría.

¿Cómo se relaciona RLS con la IA en la empresa?

Aquí RLS cobra un valor especial. Cuando conectas un asistente de IA a los datos de tu organización, la pregunta clave es: ¿qué puede ver ese asistente cuando le pregunta cada empleado? Si la IA accede a todo con una cuenta única, cualquiera podría obtener, preguntando bien, información que no le corresponde.

La respuesta correcta es que el copiloto herede los permisos de quien pregunta. Si la directora financiera pregunta por las facturas del trimestre, obtiene datos de todos los centros; si lo hace un responsable de sede, solo ve los suyos. Las reglas por fila en la base de datos son una de las maneras de garantizarlo.

En PAOSBrain trabajamos con esta idea: el sistema ordena la información dispersa de la empresa y da a cada equipo un copiloto de IA sobre sus propios datos, con acceso acotado según el puesto de cada persona. Así se puede preguntar en lenguaje natural sin abrir más información de la debida.

¿Cuándo conviene aplicar RLS?

Suele tener sentido cuando:

• Varios equipos, sedes o clientes comparten las mismas tablas.
• Manejas datos personales o especialmente protegidos.
• Quieres que informes, paneles o asistentes de IA respeten permisos sin programarlos uno a uno.
• Necesitas poder demostrar quién puede acceder a qué.

Si tu empresa es pequeña y todos pueden ver todo, quizá no lo necesites todavía. Pero en cuanto aparecen roles, centros o clientes diferenciados, planificarlo pronto evita rediseños costosos.

¿Qué hacer para empezar?

• Haz un inventario de qué datos tienes y quién debería ver cada uno.
• Define roles sencillos (dirección, administración, responsable de centro, empleado).
• Traduce esas reglas a políticas, empezando por las tablas más sensibles.
• Prueba con usuarios reales de cada rol antes de ponerlo en producción.
• Revisa los permisos de forma periódica.

Ordenar el acceso a los datos es la base de usar IA con confianza

RLS es una pieza técnica, pero la idea es muy de negocio: que cada persona vea lo que necesita y nada más. Si quieres tener un copiloto de IA sobre los datos de tu empresa respetando los permisos de cada puesto, es algo que ya se puede tener funcionando en tu organización.

Powered by PAOSBrain