Why AI Contracts Keep Paying for Hours When the Value Lies Elsewhere
The greatest source of friction in enterprise artificial intelligence adoption is not technical. It does not reside in the models, nor in the quality of the data, nor in computing capacity. It lies in the contract. While organisations invest hundreds of millions in AI implementations expecting structural returns, the majority continue to sign agreements that reward time invested, not impact generated. That misalignment is not an administrative detail: it is the root cause of why so many AI initiatives remain trapped between the promising pilot and the operational scale that never arrives.
McKinsey's most recent report on the state of AI confirms this with uncomfortable precision: adoption has spread, but scaling challenges persist, and the strongest correlation with real impact lies not in technological investment but in the redesign of workflows. Stated in economic terms: companies are paying for installation when they should be paying for transformation.
Outcome-based contracting is not a trend. It is the structural response to an incentive architecture problem that traditional models are incapable of resolving.
The Problem Is Not the Vendor, It Is the Logic of the Contract
Time and materials contracts, along with fixed-price agreements, were born to manage software delivery in contexts where deliverables were definable, timelines predictable, and value relatively linear in relation to effort. AI breaks all three conditions.
An AI system that automates incident management in infrastructure does not deliver a module. It delivers a reduction in resolution time, a drop in operational costs, a reduced dependence on on-call personnel, and eventually a reorganisation of the operations team. None of those outcomes appear on an invoice for hours. And none of them can be attributed with precision to a specific project milestone.
The result is predictable: the vendor charges for what it can measure, which is hours. The client pays for something it expected but which the contract never formally promised. When the ROI does not materialise, no one is technically responsible because the contract never required it.
There are three structural failures in this logic. The first is the absence of any correlation between the input and the value generated: spending more on consulting or on licences does not necessarily produce greater impact. The second is the lack of accountability mechanisms, because without a contractually defined outcome, the vendor has no incentive to pursue it. The third, and most frequently overlooked, is the total cost of ownership that traditional contracts render invisible: the management of organisational change, the team's AI literacy, the reconversion of processes, and the costs that disappear when the solution works well — such as the personnel or the software that the AI replaces. All of that remains off the balance sheet, even though it determines whether the investment was profitable.
The Logic of an Outcome-Oriented Contract
An outcome-based contract is not simply one in which the vendor earns a bonus if things go well. Its architecture is more precise and more demanding for both parties.
The starting point is the collaborative definition of the indicators that matter — not technical ones, but business ones: reduction in operational costs, an increase in the first-contact resolution rate with the client, a decrease in cycle time across the supply chain. On the basis of those indicators, verified baselines are established, with an agreed measurement methodology, and the attribution logic is constructed: what portion of the outcome can be reasonably connected to the AI solution and under what conditions.
Payment is structured in layers. A fixed base covers the vendor's minimum operating costs. A variable component is activated when results surpass defined thresholds. In the most sophisticated implementations, variance bands are established — what some call tolerance corridors — within which the vendor absorbs downside risk but also captures upside value.
This design changes the power dynamic in the commercial relationship. The vendor ceases to be a task executor and becomes a partner with exposure to the outcome. That shift in position is not rhetorical: it has consequences for how teams are allocated, how quickly a model performance problem is responded to, and how much continued investment the vendor is willing to make in the account.
For this to work, the vendor must possess capabilities that traditional models never demanded. It needs consultants who understand the client's business before discussing technology. It needs engineers who build while the scope is being defined, not afterwards. And it needs the infrastructure to operate the model in production continuously, including governance of inference costs and monitoring of model performance degradation over time.
The Scaling Error That Repeats Itself Most Often
There is a pattern of failure in AI adoption that recurs with sufficient consistency to be considered structural: organisations do not know where to place their focus and oscillate between two equally costly extremes.
Some bet on problems that are too narrowly scoped. They build an agent to automate vendor spend management without considering that the real problem lies across the entire procurement chain. The result is a solution that functions within its silo and cannot scale because it was not designed to connect with the processes that give it context.
Other organisations attempt to optimise everything at the same time and without stages. They seek to transform operations at scale without having demonstrated the value model in a contained segment first. The result is a project that consumes resources for years, generates progress reports, and produces no observable changes in the indicators that matter to the board.
What connects both extremes is the absence of an operating model before the technology is selected. Organisations that manage to scale AI in a sustained manner work with two simultaneous processes: process redesign and data and technology architecture. Not in sequence, but in parallel. And what keeps those two processes aligned is change management, organisational strategy, and product management as a permanent discipline.
This is the most compelling argument in favour of outcome-based contracting: it forces that clarity to exist before the contract is signed. A vendor that accepts being measured by the result needs to understand the process the client wants to improve. That pre-contractual conversation holds more strategic value than many subsequent months of consulting.
When the Right Incentive Builds the Right Partner
Outcome-based contracting reorders who captures value in an AI implementation and how. But it also reveals something about vendors that very few organisations analyse before signing.
A vendor operating under this logic must absorb risk. To absorb risk, it needs conviction in its own delivery capacity. That conviction cannot be merely commercial: it must be backed by technical architecture, by a history of execution, and by internal governance that allows it to manage model quality in production over months or years — not only at the moment of launch.
Few vendors possess that capacity today. And that scarcity has implications for buyers: the market of vendors genuinely committed to outcomes is smaller than it appears if one reads only sales literature. Filtering who can actually operate under this model and who is simply announcing it as a commercial differentiator requires asking precisely the questions that outcome-based contracting forces both parties to answer before signing.
From the perspective of value distribution, this model also possesses a virtue that traditional contracts do not: it makes visible what previously remained off the balance sheet. The costs of organisational change, the investment in training, the systems that become redundant, the personnel that are reassigned — all of that becomes part of the shared value analysis between client and vendor. That visibility does not guarantee equity, but it does eliminate the possibility that the vendor's success and the client's success operate in parallel universes.
When incentives are aligned around the outcome, the centre of gravity of the commercial relationship shifts from cost management to the maximisation of return. That difference is not semantic. It is what determines whether enterprise AI produces verifiable impact or simply produces projects.
