AI model policy for teams: who sets the allowed list
6 minutes read
Most consultancies never decided which AI models their people may use on client work. It was settled by whoever signed up for a tool first. Here is how to make it a decision with an owner.
An AI model policy for teams is a short list of the models the firm allows on client work, with a named person who maintains it and a date on which it gets reviewed. It fits on one page. Most consultancies do not have one, and the reason is rarely that they decided against it. The question never came up, so the answer was set by whichever tools people happened to sign up for.
This is a different question from matching the right model to each task. That post is about which model suits a piece of work. This one is about who decides what is on the menu in the first place.
Why an open choice of models causes trouble
An open choice causes trouble because nobody can answer for it afterwards. When each consultant picks their own model, the firm cannot say which models have handled a client's material, or under what terms. A client can ask exactly that in a security questionnaire or a contract schedule, and "it depends who did the work" is a poor answer to give.
There is a quality cost as well. The same recurring task gets a different model depending on who ran it, so the output varies for reasons unrelated to the work. Reviewers end up correcting for a difference they cannot see.
An allowed list fixes both without asking anyone to become a model expert. People choose from a short menu, and the firm knows what is on it.
Who should own the list
One named person should own the list, and it should be someone close to delivery. In a consultancy that is usually an operations lead, a practice lead, or a partner with an interest in how the work gets done. It does not need to be an IT project, and in a firm without an IT team it cannot be.
The owner does not need to follow model releases closely. Their job is to make sure every model on the list has had the questions below asked about it, and that someone asks them again on the review date. A committee tends to do this worse than one person, because each member assumes someone else has made the update.
What to decide before a model goes on the list
Ask the same five questions of every model before it is allowed.
| Question | Why it matters |
|---|---|
| Is customer data used to train the model? | Client material must not end up in a model other firms use |
| Where is the data processed and stored? | Some clients specify a region in their contract |
| What kind of work is it good enough for? | Sets which teams and tasks the model is allowed on |
| Is there a cheaper model that does this job as well? | Keeps the strongest model for the work that needs it |
| Who asked for it, and for what? | A model nobody can name a use for should not be on the list |
Write the answers down next to the model. When a client asks how the firm uses AI, the list and those answers are most of the reply.
Narrow the list by team where the work differs
A single firm-wide list is the right starting point. Narrow it per team only where the work differs enough to justify it. A research team doing long synthesis on client documents may need the strongest model on the list. A team producing routine status notes does not, and removing it from their menu saves a decision every time they start a task.
Narrowing should always go one way. A team's list is a subset of the firm's list, never an addition to it. If a team needs a model the firm has not approved, the answer is to put it through the five questions and add it for everyone who should have it. A side arrangement for one team is how the open choice comes back.
Make the list the only route
A policy document that sits beside an open tool is advice. The list only works when the models outside it are unavailable in the place people do the work. Otherwise the policy depends on every person remembering it under deadline, and the first tight week ends it.
This is also the difference between a policy and a ban. People who are given a good short list tend to use it. People who are told not to use AI on client work, with nothing offered instead, tend to use it anyway on a personal account.
Review the list on a date, not on a feeling
Review the list every quarter, and whenever a provider changes its data terms. A quarter is long enough that the review is not a standing chore and short enough that the list does not drift far from what is available.
The review itself is short. For each model on the list, check that the five answers still hold and that the model is being used. Usage by team shows which models are earning their place and which were added for a project that ended months ago. Remove what is not used, since every model left on the list is one more the firm has to answer for.
How this looks in Hebno
In Hebno an admin chooses which models the firm can use and can narrow that list for each team. Models outside the list are unavailable, so the policy is enforced where the work happens and nobody has to remember it. Usage is visible by team, member, and client project, which is what the quarterly review needs. The controls feature page shows the settings.
Model choice is one part of the right AI model, at a cost you control, which covers how the list and the usage view fit together.
