The AI Mandate Problem
Before you hire a CAIO, fund another pilot, or scale AI across the business, clarify what AI is for and who has the authority to decide.
A lot of organisations now have plenty of AI activity. Pilots, licences, working groups, champions, policies, vendor demos, internal tools, executive updates, and at least one slide saying AI is a strategic priority. What they often do not have is a mandate strong enough to turn all that activity into disciplined organisational change.
That is where I think a lot of AI work is getting stuck.
AI has been declared important before the organisation has clarified the authority around it. Everyone is encouraged to explore, but few people are clearly authorised to choose. People are told to find use cases, but not always told what kind of value the organisation actually wants. Teams are pushed to experiment, but the decision rules for scaling, narrowing, redesigning, or stopping the work are often vague.
That vagueness creates motion. It does not create judgement and value.
I have written before about the AI absorption problem. Adoption asks whether people are using AI. Absorption asks whether the organisation can carry what AI changes. But there is a related problem underneath that one. Before an organisation can absorb AI well, someone has to be authorised to decide what AI should change in the first place.
This is why “where can we use AI?” is often such a weak starting question. It sounds practical, but it is too loose. Almost every function can find a plausible answer. That is part of the problem. The question starts with possibility rather than importance, so it invites scattered activity.
A better question is what business problem is real enough to deserve intervention, valuable enough to justify the effort, bounded enough to test properly, and important enough that the organisation is willing to change the surrounding work if the test succeeds.
That last part matters. If the organisation is not willing to change the surrounding work, the AI initiative has probably already been contained. It may still make individuals faster, but it is unlikely to become serious operating value. The workflow remains mostly the same. The bottleneck moves. The bottleneck always moves. The review burden appears somewhere else. The system produces more output than the organisation can interpret, govern, or use. People feel acceleration, but the business does not necessarily get better. Spinning one cog faster.
This is the gap between usage and transformation.
It also explains why so much AI work gets pulled back into efficiency. Cost reduction is easier to mandate because it fits the organisation that already exists. There is usually a baseline, a budget, a team, an owner, and a familiar language of savings. If AI reduces handling time, automates a back-office task, cuts external spend, compresses analysis, or removes manual work, the benefit can often be made legible inside existing management machinery.
Growth is harder. Not because growth is less important, but because growth asks more awkward questions. What can the business now sell that it could not sell before? Which customers can it now serve better or more cheaply? Which channels change? Which products become possible? Which bottleneck has moved? Which assumptions about service, quality, margin, pricing, capacity, or response time are now out of date?
Those questions do not sit perfectly inside one function. They cut across product, operations, finance, risk, sales, technology, data, legal, service, and the board’s appetite for change.
That is why efficiency has a home, and growth often needs a new one.
This is also why the CAIO conversation can become confused. Organisations start with the title before they have designed the mandate. They ask whether the person should be technical, strategic, operational, commercial, product-led, data-led, governance-led, or transformation-led. Those questions are not irrelevant, but they can miss the harder point. They can also cause organisations to miss some of the strongest candidates, because recruitment still tends to sort people back into the boxes the role is supposed to cut across.
The serious question is not which professional tribe the person belongs to. It is what decisions the role is meant to force that the current organisation keeps avoiding.
If the CAIO is only there to coordinate initiatives, speak fluently about AI, attend committees, reassure the board, and collect pilots into a more senior-looking programme, then the organisation has not solved much. It has given anxiety a job title.
The stronger version of the CAIO role is about integration and decision quality. It connects capability to constraint, ambition to evidence, risk to authority, and experiments to operating consequence. It is close enough to the technology to know what is real, close enough to operations to know what will break, close enough to finance to know what is worth funding, close enough to governance to know where risk accumulates, and close enough to the board to force prioritisation.
That is not empire-building. It is mandate design.
A serious AI mandate should make some things explicit that organisations often leave implied. What is AI for in this business? What kind of value is being pursued beyond efficiency? What kinds of work are worth changing? What level of risk is acceptable in different contexts? Who can approve delegated action by a system? What evidence decides whether a pilot continues? What costs are being counted, and which ones are being hidden in review, supervision, exception handling, latency, token consumption, or management time? Who owns the outcome when the work is partly shaped by AI? Who has the authority to say no when the work is exciting but not yet justified?
Without that clarity, AI activity starts to accumulate in the gaps between functions. Technology can say the system works. Product can say the use case is promising. Operations can say the process is messy. Risk can say the controls are not clear. Finance can ask where the value is. Legal can ask who is accountable. HR can ask what this means for work. The board can ask why things are not moving faster.
Everyone is partly right, and the programme still drifts.
Not because people are ignorant. Not because they are lazy. Not because they lack enthusiasm. Because the organisation is full of capable people, each seeing part of the truth, with no mandate strong enough to turn competing truths into a decision.
That is often what passes for AI transformation: reasonable objections, plausible pilots, rising spend, growing expectation, and no one with the authority to resolve what should actually happen next.
This is where the translator problem comes back in. Organisations say they need people who can sit between domains, but then often assess them as though they should belong to one. Too technical for commercial roles, too commercial for technical teams, too strategic for delivery, too practical for strategy, too broad for the job spec, too nonlinear, too hard to benchmark.
But the reason these people are hard to place is the same reason they matter. AI does not respect the old boundaries. The work sits between them.
The best AI translators are not just explainers. They are not there to make technical things sound business-friendly or to make business people feel included in a technology programme. That is only the surface version. The real work is translation under consequence.
What does this capability mean for this workflow, under these constraints, with this data, this risk, this margin, this customer expectation, this regulatory exposure, this review burden, and this operating model? What has to change around the tool for the tool to matter? What looks impressive but should not scale? What looks modest but might create real institutional advantage if it were redesigned properly?
Those are mandate questions as much as capability questions.
The banks are starting to show the more serious shape of this. The interesting lesson from Santander and Lloyds is not that large institutions are suddenly using AI. It is that the evidence of value starts to look operational: fraud, KYC, credit, customer service, claims, governance, human override, production automation, measurable workflows. Not just broad access to tools, but AI being absorbed into the operating fabric of the institution.
That is the distinction I keep coming back to. Access is not value. Usage is not transformation. The value appears when AI is attached to work that can be measured, governed, improved, and scaled.
Not AI as a tool rollout. AI as operating change.
Once you see that, a lot of apparently separate AI topics start to join up. Model choice is not just a technical preference. It is a decision about cost, dependency, resilience, policy exposure, security, control, and what the workflow now relies on every time it runs. Token consumption is not just a bill. It is a signal of how much reasoning, retrieval, context, orchestration, checking, tool use, memory, latency, and retrying the work now requires. Agents are not just clever software. They are delegated action, and delegated action raises questions of permission, monitoring, revocation, evidence, and accountability.
The more serious AI becomes, the less credible it is to treat these things as implementation details that can be sorted out later.
That is the bridge problem.
If someone said they wanted to build a bridge over a ravine with new materials and put people on it to see if it could hold their weight, we would not call that innovation. We would call it madness. But in AI, organisations keep doing a softer version of the same thing. They get excited by capability, route work towards it, widen usage, and only later ask what weight the structure can bear.
The point is not to stop traffic forever. The point is to know what the bridge can carry before everyone drives over it.
AI forces that discipline because it changes the terrain as it enters. It changes what people trust, what they delegate, where judgement sits, who feels responsible, what customers expect, what work appears around the work, and where authority moves before accountability has caught up.
That is why mandate matters.
It has to say what AI is for in the actual operating reality of the business. It has to distinguish between productivity that helps an individual, automation that improves a process, intelligence that improves a decision, and capability that changes what the organisation can now do. Those are not the same thing, and they should not be funded, measured, or governed as though they are.
Boards and executive teams do not need to demand false certainty. But they should demand better decision conditions. If an AI programme cannot explain what outcome matters, what evidence will be accepted, who owns the risk, what cost is being created, what authority is being widened, and what would cause the work to stop, then it does not yet have a mandate. It has permission to wander around and drift.
That may be fine at the earliest stage. Exploration has its place. But exploration cannot remain the governing logic forever. At some point, AI activity hardens into cost, dependency, workflow expectation, vendor commitment, internal politics, and public claims. By then, the missing mandate becomes expensive.
The organisations that do this well may not look especially glamorous from the outside. They may not have the most pilots or the loudest slogans. They will simply become better at choosing. They will know where frontier capability is worth paying for and where open model sufficiency is enough. They will know which workflows deserve redesign and which should be left alone. They will know when broad access is useful and when production automation needs tighter authority. They will know when an agent should act, when it should recommend, when it should ask, and when it should not be in the workflow at all.
That is not anti-innovation. It is what makes innovation valuable.
The uncomfortable truth is that AI forces organisations to reveal how they make decisions. If decision rights are vague, AI exposes that. If value is poorly defined, AI exposes that. If nobody owns the process end to end, AI exposes that. If governance is mostly retrospective, AI exposes that. If the business cannot distinguish activity from improvement, AI exposes that too.
The serious work is not to make everyone use AI more. It is to give the organisation a clearer way to decide where AI should matter, what should change around it, and what evidence is strong enough to earn the next commitment.
That is the work behind the work: not the demo, not the launch announcement, not the reassuring strategy deck, but the mandate.
Because without a mandate, AI becomes everybody’s priority and nobody’s decision.
And that is how activity turns into cost.
Before you hire a CAIO, fund another pilot, or scale AI across the business, clarify the mandate.
What is AI for here? Who owns the decision? What evidence counts? What risk is acceptable? What cost is hidden? What should scale, narrow, redesign, or stop?
That is the work I do.
Stuart Winter-Tear


The line that lands for me: agents are delegated action, and delegated action needs permission, monitoring, revocation, and accountability. Most mandates I see name who can start an agent but never who can stop one. That's where orphaned agents pile up, still touching production after the team that built them moved on. When you design a mandate, do you write the "who can pull it" rule before the pilot ships, or after?
Oddly enough I just emailed a client saying this same sentiment.