How do we tell whether our roles still mean anything?

Count them against people. A few dozen roles across a large organisation is a working scheme; a number approaching the headcount means exceptions have been absorbed as new roles until the grouping stopped grouping anything. The ratio is the quickest signal available.

Does this cover AI tools automatically?

Only where the tool acts as the person rather than as itself. Many deployments hold their own connection with its own reach, so the roles govern who may open the tool while the tool's own access is set somewhere else entirely. Those are separate questions worth asking separately.

What should we ask a vendor about it?

Whether permissions are inherited from the source systems at the moment of answering, or configured once inside the tool. The first stays correct as your own roles change; the second is a copy that ages, and the difference only becomes visible when somebody changes team.

Glossary

Role-based access control (RBAC)

Granting access by job role rather than person by person, so what somebody can reach follows from what they do rather than from what they once asked for.

In plain terms

Deciding what the job can open rather than what the person can open, and then putting people into jobs. The advantage is obvious the first time somebody changes team: their access changes with them, and nobody has to remember what to take away.

Why it matters

Because managing permissions one person at a time does not survive contact with an organisation of any size. Individual grants are made in response to individual requests, which means nobody holds a picture of who can reach what, and the picture is precisely what an auditor asks for. Grouping by role turns thousands of individual facts into a few dozen decisions that can be read and argued about.

How it works

A role is a named bundle of permissions, and people are assigned to roles rather than to permissions. The bundle is where the thinking happens: it is defined once, argued over once, and then applied without further debate to everybody who holds it. That is the whole economy of the arrangement.

Its real advantage is at the edges of employment rather than in the middle. Somebody joining gets a role and is correct on day one; somebody moving teams has one role swapped for another; somebody leaving loses everything at once. Each of those is a single action rather than a checklist of systems that somebody has to remember.

Roles multiply, and that is the characteristic failure. Every genuine exception is a request, and the easiest way to grant a request is a new role, so an estate accumulates roles that differ from each other in one permission. Past a certain point there are as many roles as people and the scheme has quietly become individual grants with extra steps.

Reading the bundle is the part that gets skipped. A role named after a department describes who holds it and not what it opens, and the two drift apart as systems are added to it over years. The name stays reassuring while the contents change, which is why the interesting question about any role is what is actually in it.

Where an AI tool is involved, the question shifts to whose role applies. A deployment may act with its own permissions rather than the reader's, in which case a carefully designed set of roles governs the people and not the tool sitting in front of them, and answers can be assembled from material no individual role would have opened.

Where the scheme earns its keep

The reason to hold these apart is that the left-hand column is what gets demonstrated when somebody asks whether access is managed, and it is genuinely impressive: a leaver losing everything in one action is a real improvement on a checklist somebody works through from memory. But it says nothing about the right-hand column, and the right-hand column is where the interesting failures live. Roles accumulate contents quietly, because adding a system to an existing role is easier than arguing about whether it belongs there, and the role's name never changes to reflect it. Exceptions become new roles because that is the path of least resistance for whoever is handling the request, and nobody is measuring the count. And the AI question is newest and least often asked: a deployment that holds its own connection is not governed by any of this, so an organisation can have an exemplary role scheme and a search tool sitting beside it reaching everything. None of those three is a failure of the mechanism. They are what the mechanism does not cover, which is worth knowing before treating its presence as an answer.

Seen in the wild

Giving an assistant deployment a role scoped to one team's material rather than the administrator's own reach.
ChatGPT
Checking whether a search tool answers from the reader's role or from the connection that installed it.
Glean
Assigning workspace roles so a departing contractor loses every connected system at once.
Notion AI

Common misconceptions

People assume

Having roles means access is under control.

In fact

It means access is described. Whether it is controlled depends on what the bundles contain, and a role named after a department can accumulate systems for years while its name stays reassuring. The name is not the contents.

People assume

More roles means finer control.

In fact

Past a point it means the opposite. Every exception granted as a new role moves the estate back towards individual grants, and when there are nearly as many roles as people the scheme has stopped doing the one thing it was for.

Questions

How do we tell whether our roles still mean anything?: Count them against people. A few dozen roles across a large organisation is a working scheme; a number approaching the headcount means exceptions have been absorbed as new roles until the grouping stopped grouping anything. The ratio is the quickest signal available.
Does this cover AI tools automatically?: Only where the tool acts as the person rather than as itself. Many deployments hold their own connection with its own reach, so the roles govern who may open the tool while the tool's own access is set somewhere else entirely. Those are separate questions worth asking separately.
What should we ask a vendor about it?: Whether permissions are inherited from the source systems at the moment of answering, or configured once inside the tool. The first stays correct as your own roles change; the second is a copy that ages, and the difference only becomes visible when somebody changes team.