Role-based access control sounds simple on a whiteboard: figure out what job functions exist, build a role for each one, assign people to roles instead of hand-picking entitlements one at a time. Most RBAC deployments don't actually do this. They build roles around job titles instead — because titles are already sitting in HR's system, tidy and pre-labeled, while the actual job function underneath a title is messier and nobody owns describing it.
The problem is that titles and functions drift apart almost immediately. A title is a slow-moving HR record, updated on a promotion cycle. A job function is whatever someone is actually doing this quarter — covering for a teammate, running a project outside their normal remit, inheriting a system nobody else wants to own. Build the access model on the label instead of the behavior, and you've modeled something that was already slightly wrong on day one and gets more wrong every month after.
The visible symptom is role explosion. Once a generic "Analyst" role turns out to be wrong for half the people who hold that title, the fix that seems obvious is to make a more specific role — "Senior Analyst, West Region, Reporting Only" — instead of asking why the role was built around a title in the first place. A few hundred of these later, the role catalog is longer than the entitlement list it was supposed to simplify, and nobody can tell you what any given role actually grants without opening it up and reading the raw permissions. At that point the access review process, which is supposed to be the safety net, becomes a rubber stamp — reviewing a thousand narrowly-scoped roles nobody fully understands isn't meaningfully different from reviewing the raw entitlements directly, except it now takes longer and feels more official.
The way out isn't a cleverer naming convention for roles. It's building the model from two directions and reconciling them: top-down from what a function is actually supposed to be able to touch, and bottom-up from what people holding that function are actually using day to day. The gap between those two views is where the real access model lives — not in whatever the org chart happens to call someone. Often the two views disagree in instructive ways: the top-down design says a function needs read access to a system, the bottom-up data shows nobody in that function has opened it in a year, and now there's a real question worth asking instead of an assumption worth automating.
None of this survives as a one-time project. A role model built once and left alone starts rotting the moment the org changes shape underneath it, which is immediately. It needs the same maintenance discipline as anything else that decays on contact with reality — a recurring pass that checks whether the function-to-role mapping still describes what people do, not a slide deck from the original rollout that everyone still points to two reorgs later.
RBAC isn't the wrong idea. It's just named for the wrong noun when the "role" in role-based access control describes a title instead of a function. Fix what the role actually represents, and the rest of the model holds together on its own.