Ask a company how its AI programme is going and you get a percentage of people. Eighty per cent have a licence. Sixty per cent used something this month. Adoption is up nine points on the quarter.
The denominator is wrong. People are not where the value lives. Processes are.
A company where ninety per cent of staff use AI every day and zero processes have been rebuilt has not adopted anything. It has bought a faster way to produce the same artifacts, in the same sequence, reviewed by the same people, at a slightly higher cost. That is a real thing and it is worth some money, but it is not what anyone was sold and it is not what the board thinks it is buying.
Once you switch the denominator from people to processes, a piece of mathematics shows up that most rollouts are structured to lose to. Average adoption does not return the average. It returns less.
The curve is convex, and it starts below zero
Take a single process and ask how much of it the model owns. Value against that axis has two features that break every intuition built on headcount.
The first is a threshold, and below it the return is negative. You are paying a licence, a security review, the twenty minutes somebody spends checking an output they did not need, the meeting about the policy, and the second pair of eyes that exists because nobody trusts the first. A process that has been half handed over is often worse than one that was never touched, because now two parties are responsible for it and neither of them fully.
The second is that above the threshold the return accelerates. Once a step genuinely belongs to the model, with a written contract for its output and an eval that tells you when it broke, the step next to it gets cheaper to hand over too. It inherits the contract, the eval harness, the monitoring, the person who already knows how this goes wrong. Ownership compounds. That is what makes the curve convex rather than merely rising.
Now the inequality. Jensen says that for a convex function, the average of the outputs is at least the output at the average input. Translated into this argument: a company that has rebuilt half of every process earns less than a company that has fully rebuilt half its processes and left the rest alone. Identical average. Identical spend. Different return, and the gap is not a rounding error.
Both dots sit at the same average. Only one of them is what a company-wide rollout buys.
This is the most useful lens I have found for the MIT NANDA figure that went around last year, the one where 95% of corporate generative AI pilots showed no measurable P&L impact. The study is preliminary, was never peer reviewed, and has been fairly criticised for its sample and its measurement window, so I would not put the exact number in a budget. But the order of magnitude is what the curve predicts. Roll a tool out to everyone, let every process get lightly touched, and almost your entire portfolio sits to the left of the break-even line. The models were not the failure. The distribution was.
Assist is not automation
The reason this keeps happening is that one word covers four very different states, and only the top two are worth anything.
The gap between rung two and rung three is not effort. It is engineering, and a licence does not contain any.
Rung one is asking. A person asks, a person judges the answer, a person still does the work. Rung two is drafting: the model produces and a person edits every single output before it goes anywhere. Rung three is ownership, where a step has a defined output contract, an eval set that fails loudly when behaviour drifts, and a named human who is accountable for it. Rung four is retirement, where the step stops existing because the work it was doing is no longer necessary.
Nearly all enterprise AI lives permanently on rungs one and two, and the reason is structural rather than cultural. Getting to rung three means deciding what the step's output actually has to satisfy, building something that detects when it stops satisfying it, and putting a name against the result. That is engineering and organisational design. The licence did not include either, and no amount of enthusiasm from the user substitutes for them.
Rung two also has a ceiling that people consistently mistake for a floor. If a person edits every output, throughput is capped at that person's throughput no matter how good the model gets. The published numbers reflect this exactly: a UK government trial found about 26 minutes saved per day, and Forrester's commissioned study for Microsoft estimated around nine hours a month per user. Both are vendor-adjacent, both are plausible, and both describe a ceiling. Minutes saved is the natural metric of rung two, and it never compounds, because next quarter the same person is still editing the same outputs slightly faster.
Usage is skewed because processes are skewed
Look at how AI use is actually distributed inside companies and the shape gives the game away. In LayerX's 2026 usage report, the median enterprise user had twelve conversations in a quarter, the average user had thirty-six, and the user at the 95th percentile had 144. Roughly half of employees have used AI at work. Eighteen per cent use it weekly.
A mean three times the median is a long right tail. And the people in that tail are not simply keener than everyone else. They are, overwhelmingly, the people who have a process sitting on rung three and spend their day inside it. Heavy use is a symptom of a rebuilt process, not a cause of one. Which is why chasing the usage number directly, with training and nudges and internal comms, produces so little: you are treating the symptom of a thing you have not built.
It also explains why the pricing is wrong. A seat prices a person. Value accrues to a process. Those are two different objects, and a seat licence is a flat rate on a population whose consumption spans two orders of magnitude, which I have argued before from the vendor's side of the table.
The buyer's version has a trap in it that I have watched spring more than once. A company moves to consumption billing, finally gets visibility into spend by team, and discovers that a handful of people account for most of the bill. The instinct is to throttle them. Quotas, approval thresholds, a monthly cap. Those people are the ones running your rung-three processes. You have just taxed the only part of the portfolio that is above the break-even line, in order to protect a budget whose actual waste is the ninety dormant licences nobody looked at.
Talent density is what gets a process to rung three
Moving a process up the ladder is not a headcount problem. It is a density problem, and the difference matters because the two have opposite prescriptions.
The person who can take a step to rung three writes the output contract, assembles the eval set that tells you whether the new model version is safe to switch to, and builds the small internal tool that turns a two-hour task into a form. Everybody else then works inside what that person built. There is a line of recent work on internal AI tool building that calls the result builder saturation: plenty of artifacts get made, almost all of the attention lands on a handful of well-integrated ones, and the distribution one level up looks exactly like the distribution one level down. The same power law, drawn again.
The ninety on the right are not more motivated than the ninety on the left. They are better equipped.
So ten deep people in a company of a hundred are not ten units of value. They are the rails the other ninety run on, and without them the ninety generate usage and nothing else.
Which gives a clean way to separate two words that board decks use interchangeably. Adoption moves the mean. Transformation thickens the tail. They are different projects with different budgets, and a programme that reports on the first will never deliver the second by accident.
What this looks like on a Wednesday
Five changes I would make to any AI programme currently reporting a percentage of people.
Keep a register of processes, not a dashboard of users. One row per step that matters: what it is, which rung it is on, who owns it, what its eval set is, what it cost before. It will be embarrassingly short the first time. That is the finding.
Report one number: how many processes sit at rung three or above. It should be small, and it should move. A percentage of employees can rise for a year while that number stays at zero, which is precisely the failure mode this essay is about.
Find the people who have already got something to rung three. They exist and they are almost never the people the rollout was designed around. In my experience they sit two or three levels below whoever signed the contract, which is also why nobody has asked them anything.
Fix what is blocking them instead of buying more seats. The answer is usually boring and cheap: an API key, permission to call an internal service, a data export that currently requires a ticket, four uninterrupted days.
Stop expecting the ninety to become the ten. They will not, and a programme designed on that hope spends its budget training the middle instead of equipping the top. The ninety do not need to go deep. They need what the ten built.
One caveat on my own argument, because it deserves stating rather than burying. Convexity is an assumption, not a law. Some processes really are linear in how much the model owns, where a bit of help gives you a bit of value and full ownership gives you no more per unit. Transcription. Translation. Classification of things that were already being classified. If that is honestly your portfolio, a flat rollout is the right shape and none of this applies to you. The test is whether your best examples are doing something different in kind from your median ones, or just the same thing faster. If it is the same thing faster, you bought a utility, and you should price and manage it like one.
Close
The mean survives as a metric because it is the only number that fits in a quarterly update. It is also, specifically and provably, the wrong target: on a convex curve the return at the average is the worst return that average can produce.
None of this needs better models. It needs admitting that the interesting property of your AI programme is its variance, that the variance is not noise for a training plan to smooth away, and that the work is engineering rather than enablement.
Count the processes that crossed the line. That is the number. Everything else is licences.