Control de acceso a los datos (RBAC): quién puede ver qué, y por qué importa con la IA

Qué es RBAC, con un ejemplo

Piensa en las llaves de un edificio. No se entrega una llave maestra a cada persona: se define qué puertas abre cada puesto (recepción, mantenimiento, dirección). Si alguien cambia de puesto, cambia de llavero. RBAC (role-based access control) hace lo mismo con los datos: los permisos se asignan al rol, y las personas heredan el rol.

Por qué importa más con la IA

• Los asistentes heredan permisos. Si un asistente corporativo puede leer toda la unidad compartida, puede responder con información que el empleado no debería ver.
• Los permisos mal ajustados salen a la luz. Antes nadie encontraba el documento sensible; ahora basta con preguntárselo a la IA.
• Es una exigencia normativa. El RGPD (Art. 32) pide medidas de seguridad adecuadas y NIS2 (Art. 21) incluye el control de acceso entre las medidas de gestión de riesgos. El AI Act exige gobernanza de datos (Art. 10) y ciberseguridad (Art. 15) en los sistemas de alto riesgo.

Cómo montarlo en cuatro pasos

1. Clasifica los datos. Por ejemplo: públicos, internos, confidenciales y restringidos (datos personales sensibles, financieros, secretos comerciales).
2. Define pocos roles. Empieza por entre cinco y diez, basados en funciones reales (finanzas, RR. HH., ventas, soporte, analítica) y no en personas.
3. Cruza roles y datos en una matriz. Para cada rol y cada tipo de dato: sin acceso, lectura, edición o administración. Aplica el mínimo privilegio: solo lo necesario para trabajar.
4. Controla los accesos privilegiados. Las cuentas de administrador, con autenticación reforzada, aprobación y registro de lo que hacen.

Qué añadir cuando hay IA de por medio

• El asistente debe respetar los permisos de quien pregunta, no los de una cuenta con acceso a todo.
• Las fuentes que alimentan la IA (documentos, bases de datos, tickets) deben estar clasificadas antes de indexarlas.
• Excluye por defecto los datos restringidos y deja constancia de lo que se conecta.
• Registra qué consultas se hacen y sobre qué datos, para poder investigar un incidente.

Revisiones: lo que más se olvida

Un RBAC bien diseñado se degrada con el tiempo: altas, bajas, cambios de puesto y permisos temporales que no se retiran. Programa una recertificación cada tres a seis meses: cada responsable confirma qué accesos siguen siendo necesarios. Retira de inmediato los accesos de quien se va de la empresa o cambia de función.

Errores habituales

• Roles demasiado amplios («todos los de la empresa pueden verlo todo»).
• Permisos por persona en lugar de por rol, imposibles de mantener.
• Cuentas compartidas, que impiden saber quién hizo qué.
• No revisar los permisos heredados de carpetas y grupos antiguos.

Preguntas frecuentes

¿RBAC vale para una pyme?

Sí, y es sencillo si empiezas por pocos roles y una hoja de cálculo. Lo importante es que haya una decisión documentada y una revisión periódica.

¿Qué diferencia hay entre RBAC y mínimo privilegio?

RBAC es el mecanismo (permisos por rol). El mínimo privilegio es el criterio con el que se decide qué permisos tiene cada rol: solo los imprescindibles.

¿Quién decide quién accede a un dato?

Normalmente el propietario del dato (data owner) de ese dominio, con apoyo de seguridad y de quien gestiona los sistemas. Por eso conviene tener los roles de gobierno del dato asignados primero.

Contenido informativo, no asesoramiento jurídico. La regulación de la IA cambia con rapidez: comprueba siempre el texto oficial vigente antes de decidir. Información revisada a 15 de octubre de 2026.

Esto te da el método. Si prefieres el documento ya hecho: Política de Acceso RBAC.