Data access control (RBAC): who can see what, and why it matters with AI

What RBAC is, with an example

Think of the keys of a building. You do not hand a master key to everyone: you define which doors each position opens (reception, maintenance, management). If someone changes position, they change keyring. RBAC (role-based access control) does the same with data: permissions are assigned to the role, and people inherit the role.

Why it matters more with AI

• Assistants inherit permissions. If a corporate assistant can read the whole shared drive, it can answer with information the employee should not see.
• Badly adjusted permissions come to light. Nobody used to find the sensitive document; now it takes one question to the AI.
• It is a regulatory expectation. The GDPR (Art. 32) asks for appropriate security measures and NIS2 (Art. 21) lists access control among its risk-management measures. The AI Act requires data governance (Art. 10) and cybersecurity (Art. 15) for high-risk systems.

How to set it up in four steps

1. Classify the data. For example: public, internal, confidential and restricted (sensitive personal data, financial data, trade secrets).
2. Define few roles. Start with five to ten, based on real functions (finance, HR, sales, support, analytics) rather than individuals.
3. Cross roles and data in a matrix. For each role and data type: no access, read, edit or admin. Apply least privilege: only what is needed to do the job.
4. Control privileged access. Administrator accounts need stronger authentication, approval and a record of what they do.

What to add when AI is involved

• The assistant must respect the permissions of the person asking, not those of an account that can see everything.
• Sources that feed the AI (documents, databases, tickets) should be classified before they are indexed.
• Exclude restricted data by default and keep a record of what is connected.
• Log which queries are made and on which data, so you can investigate an incident.

Reviews: what gets forgotten most

A well-designed RBAC degrades over time: joiners, leavers, role changes and temporary permissions that are never removed. Schedule a recertification every three to six months: each owner confirms which accesses are still needed. Remove access immediately for anyone who leaves or changes function.

Common mistakes

• Roles that are too broad (“everyone can see everything”).
• Permissions per person instead of per role, impossible to maintain.
• Shared accounts, which make it impossible to know who did what.
• Not reviewing permissions inherited from old folders and groups.

Frequently asked questions

Does RBAC work for a small company?

Yes, and it is simple if you start with a few roles and a spreadsheet. What matters is a documented decision and a periodic review.

What is the difference between RBAC and least privilege?

RBAC is the mechanism (permissions by role). Least privilege is the criterion for deciding what each role gets: only what is essential.

Who decides who accesses a piece of data?

Usually the data owner for that domain, supported by security and the people who run the systems. That is why it helps to assign the data governance roles first.

Informational content, not legal advice. AI regulation changes quickly: always check the current official text before deciding. Information reviewed as of October 15, 2026.

This gives you the method. If you want the finished document: RBAC Access Policy.