Executive summary:

When enterprises roll out frontier AI models like Claude or ChatGPT, weekly active usage routinely stalls at around 14%, devolving into basic email rewriting while high-friction manual work remains untouched. Treating frontier AI like traditional SaaS procurement fails because the value does not live inside the model—it lives in the distance between the model and the company’s internal data, permissions, and daily workflows. Value is governed by a simple arithmetic: Value=Model x Deployment x Layer. Without closing that distance, a company does not have an AI capability; it only has a subscription.

A few months ago a CIO showed me his Claude Enterprise dashboard. Two thousand seats, rolled out in six weeks, single sign-on through the corporate identity provider, a usage policy signed off by Legal and acknowledged by every employee at first login. Then he scrolled to the second tab. Weekly active users: 14%. The most common prompt: “summarise this email.” The second most common: “rewrite this in a more professional tone.” Not one connection to the ERP, the data warehouse or the document repositories. Not one agent in production. Three floors below us, the accounts payable team was opening supplier PDFs one by one, reading the invoice number, the amount and the cost centre, and typing them into the finance system by hand — roughly a hundred invoices a month, about a day and a half of someone’s time.

I have stopped finding this surprising. I now think it is the default outcome of how enterprises buy AI, and I want to be blunt about why.

We have collectively decided to treat frontier models like software: procure the licence, provision the seats, run a webinar, move on. That worked for email and for CRM, because the value of those tools was inside the tool — the inbox was the product, the pipeline view was the product. The value of a frontier model is not inside the model. It is in the distance between the model and a specific company’s data, permissions, habits and processes: whether the model can see last quarter’s sales by SKU, whether it knows that “net revenue” in this company excludes trade spend, whether a sales director has ever once used it on a question she actually had to answer that week. Nobody in the organisation is paid to close that distance. IT owns the tenant and measures uptime. The business owns the use cases and measures nothing. The vendor owns the roadmap and measures seats. The space in between belongs to no one, and that space is where the value lives.

My conviction, after a year of walking into companies at the 14% moment, is that this space is a discipline in its own right. It is not change management with better slides, and it is not systems integration with a new API. It is engineering, data, security and adoption work done together, inside the client, by people who also sit inside the lab’s roadmap and who are accountable for an outcome rather than a deliverable. I call it the deployment layer, and this article is my argument for why it matters more than the next model release.

Why enterprise AI stalls after the licence is signed

The pattern is the same in banking, in consumer goods, in real estate and in telecoms, and it unfolds in a recognisable sequence. A pilot succeeds: a small team in marketing or customer service, a sympathetic sponsor, a clear use case, a demo that makes the executive committee lean forward. A second pilot succeeds in another function. Leadership approves an enterprise rollout, often with a target like “AI for everyone by Q2.” The rollout happens. Adoption rises for three weeks on novelty, flattens at the level of a better search engine, and the agents that were supposed to follow the rollout stay on a slide titled “Phase 2.”

The usual explanations are wrong. It is not that employees resist change; the ones I meet are desperate for the tool to work on their actual job and frustrated that it cannot see the spreadsheet they are looking at. It is not that the models are immature; they were capable of most of this two generations ago, and the gap between what Claude or GPT can do and what the organisation asks of them has only widened since. And it is not a lack of use cases. Every workshop I have run produces eighty of them in a morning, half of which are variations of “stop making me re-key this.”

It stalls because three questions have no owner:

  • What does the model know about us? Which systems can it see — the warehouse, the document stores, the ticketing system, the HR platform? Under whose permissions does it see them: the service account’s, or the person asking? And when it gives a number, can anyone trace it back to the table or the document it came from?
  • Who is accountable for adoption in each department? Not for licence counts — for the Monday-morning habit of using the tool on real work in Sales, in Finance, in Legal, in Operations, each of which has different data, different vocabulary and a different definition of “useful.”
  • Who builds the agents, and who maintains them when the consultants leave? An IT backlog that is already eighteen months deep, an external vendor on a time-and-materials contract, or people who sit in the business and understand the process they are automating?

I have yet to see a programme succeed where these questions were answered by a steering committee. They are answered by people doing the work, in the building, with authority to decide.

The arithmetic of AI value

The arithmetic I keep coming back to is simple: Value=Model x Deployment x Layer

The model is a very large number. Multiply it by zero, and you get zero. Every release from the labs makes the first factor bigger and the second factor more decisive.

And here is the uncomfortable part for anyone hoping to buy their way out: the deployment layer cannot be purchased as software. The labs sell the model and the platform, and they are right to stop there. The context, the permissions, the department-level habits and the first agents are specific to each company’s data and politics — to which system is the source of truth for a customer, to who is allowed to see margin by product, to how the finance team actually closes a month. They have to be built in the building, by people who understand both the model’s roadmap and the client’s systems. There is no shortcut, and I am suspicious of anyone who sells one.

⏭️ Up next in Part 2 – The blueprint: Deploy, ground, adopt, build

If the deployment layer cannot be bought as off-the-shelf software, what constitutes it? In Part 2, we break down the four concrete components that turn a generic model into an internal colleague—Deploy, Ground, Adopt, Build—and examine how haircare group Bora Brasil solved the classic Monday-morning sales query by grounding Claude in live company data.