A licence is potential energy
An assistant licence is one of the easiest purchases a business will ever make. It is priced per seat, it needs no integration, and it can be rolled out in an afternoon. That is exactly why it rarely changes anything on its own.
What the organisation has bought is capability. What it needs is capability applied to a specific process, wired into the systems where the work actually lives, with enough evidence around it that somebody is willing to rely on the output. None of that arrives with the seats.
This is not an argument against buying the licences. They are the right foundation and the pricing is generous. It is an argument about what has to happen next, and about why the gap between “we have AI” and “our costs changed” is an engineering gap rather than a training gap.
Six things that are probably true right now
Organisations that bought assistant seats twelve months ago tend to share a set of symptoms. Most have not been named internally, because each one sits with a different team.
Adoption has plateaued. A few hundred licences were issued. A couple of dozen people use them weekly, and it is the same enthusiasts every month. Usage reporting shows a healthy activation number and a flat engagement curve.
It stops at the last mile. Drafting an email works. Summarising a document works. Assembling the monthly compliance pack from the seven systems it lives in does not, because that is not a language problem, it is an integration problem.
Nobody can say what has been sent where. Staff paste customer data, contract terms and incident details into a chat window because it is the fastest way to get an answer. There is no log, no retention position and no answer if someone asks.
There is a verification tax. In any regulated or safety-relevant task, output has to be checked. If checking takes as long as writing would have, the saving is zero, and the people doing the checking quietly stop using the tool.
Knowledge evaporates. Every useful thing produced sits in an individual chat history nobody else can see. The organisation is generating more insight than before and retaining less of it.
No advantage was created. The competitor down the road bought the same licence from the same vendor and gets the same answers. Nothing done with a stock assistant is defensible for long.
The last mile is engineering
The distance between a chat window and a completed process is almost always underestimated, because the demo is so convincing. The demo has one input, one output and a human in the middle supplying the context.
Real work has none of those properties. A completed process needs to read from a system of record, respect permissions that differ per user, handle the case where a field is missing or a service is down, write back somewhere durable, and leave a trace of what it did. That is ordinary software engineering, and it is the part that determines whether the process runs at three in the morning without a person present.
The distinction worth holding on to is between a tool and a system. A tool waits to be picked up by a motivated person who remembers it exists. A system runs whether or not anyone remembers. Assistant licences buy tools. Almost all of the durable value sits in the second category, and it has to be built.
Evidence, or it did not happen
In financial services, rail, utilities and the public sector, the blocker on AI is rarely capability. It is assurance. The model is good enough; the problem is that nobody can demonstrate to a regulator, an auditor or a board what it did and why.
That evidence layer has a specific shape. Every decision the model contributed to needs to be logged with its inputs, the version of the model and prompt used, what a human changed, and who approved it. Answers need citations to the source that produced them. Where a decision affects a person, there has to be a route to a human who can overturn it.
Retrofitting this after a pilot succeeds is expensive and usually incomplete, because the information needed was never captured at the time. Designing it in from the start costs comparatively little. In safety-critical work the standard is unambiguous: “the model said so” is not an acceptable answer, and a system that cannot show its reasoning will not be allowed near the operation.
How do you know it is still right?
Assistant behaviour changes underneath you. Vendors update models, adjust safety layers and deprecate versions. A prompt that produced reliable output in March can quietly degrade in September, and unless somebody is measuring, the first sign is a complaint.
Anything relied upon needs an evaluation harness: a fixed set of representative cases with known good answers, run automatically against the current model, with results tracked over time. This is unglamorous and it is the single clearest divider between an experiment and a production system. Very few organisations that have deployed assistants have it.
The same harness answers the procurement question that stalls so many rollouts. When risk or security asks how accuracy is assured, “we test it continuously and here are the results for the last six months” is a different conversation from “the vendor is very good.”
The part that is actually yours
Strip away the branding and every organisation using a mainstream assistant has the same model as its competitors. The model is a commodity and it is getting cheaper. Whatever advantage exists cannot come from it.
It comes from what the model is given: the organisation’s own decisions, precedents, specifications, pricing history, incident reports and hard-won context, in a form a system can actually use. An assistant with access to a clean, current, well-structured record of how this business works will beat an identical assistant answering from a general corpus and a messy shared drive, every time.
That asset does not come with the licence. It has to be built, and building it is the most defensible investment available, because it is the one thing a competitor cannot buy.
Most organisations are further from having it than they think. AI adoption tends to increase the volume of material dramatically while reducing its signal density: every meeting transcribed, every decision summarised, several versions of the same document with nothing marking which is current. Pointing retrieval at that corpus produces confident answers from superseded sources, which is worse than no answer at all.
What actually converts a licence into value
Five pieces of work, roughly in the order they pay off.
Pick a process, not a department. Something with a number attached: hours spent, cases handled, days to close, error rate. Broad enablement programmes generate activity; process-level work generates evidence.
Wire it into the systems of record. The measure of success is that the output lands where the work already happens, not in a chat window somebody has to copy from.
Build the evidence layer as you go. Logging, citation, human sign-off, retention. Cheap now, expensive later.
Put an evaluation harness around it before anyone depends on the output.
Structure the corpus the assistant draws on: what is current, what is superseded, what was drafted by a model and never checked. This work compounds, and it is what makes the next process cheaper to automate than the last.
Two questions worth asking internally
The first: if the assistant were switched off tomorrow morning, which processes would stop? If the honest answer is none, the organisation has bought tools and has not yet built any systems, and the licence spend is a training budget rather than an operating change.
The second: what can we do with this that a competitor with the same licence cannot? If there is no answer, the work has not started on the only part that is genuinely proprietary.
Neither question is an argument for spending more. Often the right conclusion is that a particular process does not need a model at all, and that a scheduled job or a fixed form would deliver the same saving with less to assure. Knowing which is which is most of the value, and it is worth establishing before the next round of licences renews.