How do you measure AI adoption in an enterprise?
On 1 October 2026, Anthropic published an account of its expanded collaboration with Barclays. The bank states its goal as a share of developers using Claude Code and cites no number of licences.
Measuring AI adoption means tracking the share of the people concerned who actually use a tool in their work over a given period. The active usage rate against a target population is the base indicator. The value produced is measured separately, with its own indicators.
What Barclays announced, and what remains a target
According to the release, Barclays aims for 50% of its developers on Claude Code by the end of 2026, then a majority of its software engineers in 2027. Those are targets. The figures already observed sit elsewhere: more than 16,000 colleagues use the Barclays UK Knowledge Assistant, more than a million searches have been handled, and the Global Markets division has roughly 120,000 client emails a day classified and routed.
These figures come from a release published by Anthropic that relays statements from Barclays, and no independent verification has been published. They serve here as an example of method. The text says nothing about the value delivered, and it does not detail the controls applied: it only states that governance and human oversight frame the use cases.
For an IT leader in a European group, the lesson is a choice of vocabulary. A target expressed as a share of the population can be checked, discussed at the executive committee and compared from one quarter to the next. A target of the form “N licences deployed” can only be checked against an invoice.
Why does a licence count say nothing about adoption?
A licence is a right of access. It is ordered at contract level, sometimes before the first user has been trained, and it stays billed whether the person uses it every day or never. A licence count therefore answers the purchasing question, without saying anything about use.
What a licence count hides
Two companies report the same number of licences. In the first, half the holders open the tool every week. In the second, a handful of enthusiasts use it and everyone else never got past the home page. The purchase ledger puts the two companies on the same level, although their situations have nothing in common. The more advanced one has no way to demonstrate it, and the other can believe it is ahead.
The problem grows with size. The larger the group, the wider the gap between the perimeter bought and the perimeter actually used, and the less the figures reported to the executive committee allow anyone to see it.
Pilots that succeed without changing the work
The same blind spot appears in studies of AI projects. S&P Global found in 2025 that 46% of AI proofs of concept are abandoned before production, and an MIT study from the same year concludes that 95% of generative AI pilots have no measurable effect on the profit and loss account. Both figures concern projects. They still point to the same difficulty: we know how to count what was launched, and much less what has entered daily work.
A pilot that succeeds technically can lead nowhere if nobody checks, a few weeks later, how many people still use it. Our analysis of the move from pilot to production, in the article on AI projects stuck between pilot and production, starts from the same observation.
Which indicators should you track instead of licence counts?
An adoption dashboard fits on a few indicators, each with an explicit denominator. Without a denominator, a percentage means nothing: 50% of what, over which period, with which activity threshold?
The active usage rate by target population
The active usage rate divides the period’s users by the population you meant to equip. Anyone who used the tool at least once in the period counts as active. The period depends on the rhythm of the job: a week for a development team working continuously, a month for a function whose tasks are more spread out. The denominator is the target population: using the company headcount dilutes the measure across jobs the tool was never designed for.
Depth of use
The active usage rate separates those who use from those who do not, and says nothing about how. A person who asks one question a month and another who hands over whole tasks every day each count for one unit. Depth shows in frequency, task variety and completed deliverables: a change request reviewed and merged, a case processed, a summary sent.
This second reading brings the measure closer to value. It remains a usage indicator, and it does not replace the business indicators, such as handling time or rework rate, which must be set before deployment.
The share of the flow handled under supervision
For an agent that processes a flow, the natural indicator is a volume. The 120,000 daily emails in Barclays’ Global Markets division are an example: the number of items classified and routed to the right channel. A volume alone says nothing about how far it can be trusted. It must be paired with the share of items reviewed by a person and the correction rate, because a correction rate that falls to zero often signals a review that has stopped, and rarely a perfect model.
Does one indicator fit an assistant, a coding agent and a flow agent?
No. The Barclays release describes uses of different natures, and each calls for its own indicators and level of control. Filing them under one “AI adoption” percentage mixes risks that have nothing in common.
The knowledge assistant
The Barclays UK Colleague Knowledge Assistant is described as built on a retrieval-augmented architecture with Claude, and serves the bank’s colleagues. The main indicator is the active usage rate of that colleague population, completed by a measure of perceived quality: the share of answers judged useful by those who receive them. The dominant risk is a wrong answer delivered with confidence, and control runs through the quality of the indexed sources.
The coding agent
For software development, the indicator is the share of active developers, which is the one Barclays chose for its target. It is completed by the share of generated code that passes review and tests. The dominant risk is silent debt: code accepted without being understood. Our page on Claude Code in the enterprise details the deployment framework we recommend around this use.
The flow agent
An agent that sorts, enriches or routes messages acts at a scale nobody reviews in full. The indicator is the volume handled, together with the escalation rate to a human and the correction rate. The dominant risk is an error repeated a thousand times before anyone sees it. This is the ground of governance: which decisions the agent takes alone, which are escalated, who answers for it. The trust zones of LOOP™ governance serve to set those limits before volume is measured, and our AI governance page gives the general framework.
How do you set an adoption target without it becoming a showcase number?
An adoption target can fail in two ways. It can be too vague to be checked, or too precise to survive the use made of it: once a figure becomes a management objective, behaviour adjusts to the figure, which the following precautions help to limit.
Choose the denominator before the target
“50% of developers” only makes sense because the developer population is defined: who counts, in which teams, with which contractors. Writing that definition before setting the percentage avoids discovering, at year end, that the denominator moved. For another job, such as compliance or customer service, the definition takes longer and deserves to be written with the team leads.
Set the threshold for “active”
A threshold that is too low turns every login into adoption. One that is too high discourages teams that progress in steps. The activity threshold is decided job by job, starting from the use observed among the first serious users rather than from a theoretical value. It is reviewed when the tool changes nature, for example when an assistant becomes an agent that executes tasks.
Tie each target to a governance perimeter
Widening use without widening responsibility produces avoidable incidents. Before taking a population from 10% to 50% active users, the question is who validates access, who reviews, who stops the agent. Koneetiv’s AI maturity assessment helps place the organisation on those axes, and our article on AI maturity levels in the enterprise explains why a high level of adoption requires a comparable level of governance.
Where should an IT department start measuring?
Measurement starts with data the company already holds: the usage logs of the vendor platform, the authentication logs and the list of teams. No new tool is needed for a first reading.
- Pick one specific use and a target population, for example the development teams already using a coding assistant.
- Write the definition of “active user” with the business leads, period and threshold included.
- Extract the number of active users from existing logs and divide by the target population.
- Add a depth indicator that fits the use: completed deliverables, volume handled or correction rate.
- Name one person who answers for the indicator, and revisit the perimeter at each quarterly review.
This approach fits in a shared spreadsheet. It usually brings out two things: teams moving ahead without anyone knowing, and licences that can be reassigned. To go further on preparing teams, our article Is my company ready for AI? offers a set of questions, and the Adopting AI in the enterprise hub gathers the other analyses in this cluster.
Our reading: the useful question for an executive committee is “what share of the target population uses the tool, and under what supervision?”. The licence count is only the ceiling. If you want to place your organisation before setting a target, the AI maturity assessment is the entry point.