Who should have access to which AI models?
5 minutes read
Most teams give everyone the same AI access by default. Here's a three-tier framework for assigning it by role instead, with a worked example.
Most teams hand out AI access the same way they hand out a laptop: everyone gets the same thing, and nobody revisits the decision. That works right up until someone asks two questions nobody can answer. Who has access to your most expensive model, and why? And whose access still works a month after they left?
Undifferentiated access is not a minor inefficiency. It is where runaway spend and avoidable risk both start.
The real cost of giving everyone the same access
Two problems show up the moment access isn't tiered.
Cost. If every role can reach the strongest, most expensive model, every role eventually does, even for work that didn't need it. A support reply and a client contract review are not the same task, but undifferentiated access treats them the same.
Risk. Access and data sensitivity are not the same axis, but they should move together. A junior team member drafting marketing copy and a partner reviewing a client's financial data need different tools and, often, different guardrails around what leaves the building. Flat access means the guardrail is either too loose for the sensitive work or too restrictive for the routine work. It is rarely right for both.
Three tiers, not one flat policy
A workable framework sorts roles into three tiers, matched to what they actually handle.
| Tier | Who | Model class | Data sensitivity |
|---|---|---|---|
| Restricted | Anyone handling client financials, legal, or regulated data | Strongest reasoning models, with logging | High |
| Standard | Most day-to-day roles: drafting, research, support | Mid-tier models | Moderate |
| Light | High-volume, low-stakes tasks: tagging, first-pass summarising | Efficient, low-cost models | Low |
The tiers map to the same logic as budgeting model spend by task, covered in how to budget AI usage across teams — access and cost control are two views of the same underlying decision, not two separate projects.
A worked example
Take a 60-person agency. Delivery has 30 people, creative has 15, and leadership plus finance make up the rest.
- Leadership and finance (8 people) sit in the Restricted tier. They handle client contracts and margin data, so they get the strongest model with full logging on.
- Delivery and creative (45 people) sit in Standard. Drafting, research, and client communication cover nearly everything they do, and a mid-tier model handles it well at a fraction of the cost.
- Support and ops assistants (7 people) sit in Light. Ticket tagging and first-pass summarising don't need reasoning depth, and an efficient model is both cheaper and fast enough for the volume.
Nobody in this agency has access to a model they don't need for their actual work. That is the whole framework. It is not more complicated than sorting 60 people into three groups and reviewing the list twice a year.
Two mistakes that undo the framework
The framework fails in the same two ways almost every time.
Tying access to seniority instead of task. A senior partner who spends most of their week on routine drafting doesn't need Restricted-tier access just because of their title. A junior analyst pulled onto a sensitive client matter does, for the duration of that work. Access should follow what someone is actually doing this quarter, not their position on an org chart.
Granting the broadest tier by default because it's easier to administer. It's genuinely less admin work to give everyone Restricted access and skip the sorting exercise. That's exactly the undifferentiated access this framework exists to fix, and it reintroduces both the cost problem and the risk problem in one step. The sorting takes an afternoon. Redoing it after an incident takes much longer.
Running the twice-yearly review
The review doesn't need to be complicated to be effective. Three steps, done on a fixed schedule rather than whenever someone remembers:
- Pull the current team roster and compare it against the last tier assignment. Flag anyone whose role has changed since the last review.
- For each flagged person, ask what they actually handle now, not what their title implies, and reassign their tier if it's changed.
- Cross-check the Restricted tier specifically against current employment status. This is the fastest way to catch the offboarding gap covered below before it becomes a real exposure.
Where this breaks: offboarding
Access frameworks are usually designed for people who are still there. The gap is what happens to access when they leave.
A departed employee's model access rarely gets revoked at the same moment their email does. It sits live, unused but unrevoked, for however long it takes someone to notice. For a Restricted-tier account with access to client-sensitive work, that gap is a real exposure, not a technicality. Tie access revocation to the offboarding checklist explicitly, not to whoever happens to remember.
The access checklist
- Sort every role into Restricted, Standard, or Light based on what they actually handle, not their seniority.
- Match each tier to a model class, not the strongest model by default.
- Review the tier list twice a year, since roles and responsibilities shift.
- Tie access revocation directly to offboarding, not to a separate, easy-to-forget step.
- Keep a log of who has access to the Restricted tier and why, so the answer is always ready if a client or auditor asks.
Where Hebno fits
Hebno assigns model access by role, keeps a full log of who has access to what, and ties revocation to the same admin action that removes a member. The framework in this article is the same framework the product enforces. See how it works on our pricing page.
