The next divide at work may not be technical versus non-technical.
It may be between people who can turn an idea into evidence quickly and people who still need permission to try.
The first AI policy most companies write is usually about risk.
What employees can paste into a tool. Which model is approved. Whether a consumer account is allowed. How much the licenses cost.
Those are sensible questions. They are not the whole question.
The harder one is: who gets to experiment with intelligence?
I keep returning to this because an employee with access to a strong model, useful context, enough tokens to try several approaches, and permission to build a small workflow is not just more efficient. They have a different rate of learning. They can test an idea before a meeting instead of after three meetings. They can make a rough tool instead of writing a request for one. They can discover where their work is repetitive, where it requires judgment, and where the organisation has been mistaking administrative friction for necessary work.
That is leverage.
So an AI budget is not only a bill. It is a quiet decision about who gets leverage inside the company.
Most firms will make this decision accidentally.
The senior people will get the best tools because they have budgets. The technical people will get more access because they know how to ask. A few curious people will build private systems around their jobs. Everyone else will receive a basic chatbot, a short training session, and a reminder not to paste anything sensitive.
Then the company will be surprised when the people with the most access become more capable, more visible, and harder to replace.
It should not be surprising. Access to a new means of production has always changed who can move first.
The false choice between open access and control
The usual argument is simple.
Either give everyone unlimited access and accept the waste, or tightly control access and accept the slower adoption.
Neither is a serious operating model.
Unlimited access is not generous if nobody knows what people are learning, which tools are safe, or where the useful work is going. It can turn into a collection of private experiments, duplicated spend, and polished output that nobody has checked.
Tight control is not responsible if it means every useful experiment needs to survive a procurement process before it can begin. That does not remove shadow use. It mostly moves it somewhere the company cannot see.
The useful distinction is not between open and closed.
It is between different kinds of work.
Some AI use is personal and low-risk. Drafting an internal note, organizing a personal task list, or asking for a first pass on material the employee is already allowed to handle does not need a committee.
Some use is exploratory. A team is testing whether a workflow can be improved. It needs a real owner, a limited budget, a question it is trying to answer, and enough room to discover that the idea may not work.
Some use is production. The system is repeatedly affecting customers, records, decisions, money, code, or sensitive data. At that point, the company needs to know what it does, what it costs, what it gets wrong, and who is accountable.
These are not three levels of intelligence. They are three levels of consequence.
The mistake is giving every level the same rules.
Token spend is a weak signal on its own
There is a temptation to measure AI maturity through usage. How many seats? How many active users? How many tokens? How many prompts?
Those measures are easy to count. They are also easy to misunderstand.
A person using many tokens may be doing deep research, running a useful agent loop, iterating on a hard problem, or simply asking a weak question ten different ways. A person using few tokens may have found a reliable workflow, may not have access to a better tool, or may be avoiding the tool because it has failed them before.
The number cannot explain itself.
What matters is the work around the number.
What was the employee trying to do? What changed because they used AI? What required human review? What became faster, better, safer, or newly possible? What did they learn that someone else should not have to learn again?
This does not mean demanding an ROI calculation for every chat.
That would turn basic experimentation into expense reporting. Nobody learns much in an environment where every imperfect attempt has to defend itself as a business case.
It means asking more of the work as it becomes more consequential.
The first exploratory budget should buy a question, not a promise.
By the time a workflow becomes recurring, it should be able to explain its cost, its review burden, and what it has changed.
The access question is also a talent question
There is an uncomfortable implication here.
If companies reserve the best AI tools for a small group, they are not merely concentrating spend. They are concentrating the chance to become AI-native.
The people with the best tools learn the limits of the tools. They develop taste for where AI helps. They learn how to give it context, test it, and recover when it fails. Over time, they accumulate a working relationship with the technology that cannot be replaced by a later training deck.
The people without that access do not stand still. They learn other things. But they are learning in a world whose operating rules are being written by someone else.
That is why the answer cannot be to give only an innovation group serious access forever.
The company needs a path by which a person with a real problem can earn more capability. Not because every employee needs the same tools, but because the firm needs more than one group of people able to discover what the tools are for.
This path should not be based only on seniority. Seniority often tracks authority. It does not always track proximity to the work that is changing.
The better test is whether the person can name:
- the work they are trying to improve;
- the decision or outcome that matters;
- the information the system would need;
- the risk if it is wrong;
- and what they will share if the experiment teaches something useful.
That is enough for a bounded experiment. It is also a better signal than enthusiasm.
The company has to offer something in return
There is another problem that most knowledge-management programs avoid naming.
Why would a capable employee share the workflow that makes them unusually valuable?
If someone has spent months learning how to use AI with their domain knowledge, their personal setup may be part of what makes them fast, useful, and promotable. Asking them to document it so the company can standardize it may feel less like collaboration and more like being asked to train their replacement.
Sometimes that fear will be overstated. Sometimes it will be correct.
The company cannot solve this with a request to be a team player. It has to make the exchange visible.
If you turn a local AI workflow into a team standard, what happens to the person who developed it? Do they get recognition, time to improve it, a new role, a share in the upside, or simply more work because they proved they can handle it?
The answer tells employees whether the firm is building shared capability or extracting private capability for free.
The question to ask before setting the budget
The wrong question is: how many tokens should each employee receive?
It is too early and too narrow.
Ask instead:
What kind of learning do we want this access to create, and how will useful learning travel?
The answer may still include limits. It should. Limits are part of good experimentation.
But a token budget should follow a theory of learning, risk, and promotion. It should not substitute for one.
The company that gets this right will not be the company with the largest AI bill or the strictest policy. It will be the company where more people can earn the right to build, useful patterns travel, and the people who create those patterns have a reason to keep doing it.