Why AI Procurement Is Shifting from Software Buying to Capability Buying

ROI & Cost Optimisation

19 April 2026 | By Ashley Marshall

The old procurement question was 'which software should we buy?' The new one is 'which capabilities do we need, and what is the cheapest way to acquire them?' That distinction is quietly reshaping enterprise technology budgets.

The Old Procurement Model Is Breaking

For most of the past three decades, enterprise technology procurement followed a fairly predictable logic: identify a business problem, find a software vendor who has solved it, negotiate a per-seat licence, and roll it out. The software was static. The pricing was predictable. The procurement team knew what they were buying.

That model is under serious pressure. Not because software has become less important, but because AI has fundamentally changed what 'software' can do and how its value should be measured. When a tool can draft contracts, analyse financial data, route customer queries, and generate code, the question of 'how many seats do we need?' stops making sense. The value is no longer tied to the number of human users sitting behind it.

The shift is already showing up in procurement data. According to Tussell's UK Public Sector AI Procurement Tracker, published in March 2026, 54% more AI contracts were awarded by UK government bodies in 2025 compared to 2024, with total contract value reaching £1.17 billion - a 102% jump year on year. But the composition of those contracts is changing too. Earlier years were dominated by large infrastructure deals and compute contracts. The newer wave reflects a more granular, capability-specific approach: skills uplift, data governance, AI-assisted decision tools, workflow automation. Public sector buyers are starting to procure outcomes, not licences.

Private sector enterprise is following the same trajectory, even if the language is different. What is emerging is a procurement mindset that asks: what specific business capability do I need? How do I acquire it reliably and measurably? And what does it actually cost me per unit of value delivered, rather than per user logged in?

This is not a marginal adjustment. It represents a structural shift in how technology value is conceptualised, measured, and contracted for. Procurement teams that treat AI like they treat Microsoft Office are going to make expensive mistakes.

What Capability Buying Actually Means

Capability buying is not a new concept. Defence procurement has used it for decades: you do not procure 'a fighter jet software system', you procure air superiority capability, and the platform is just the vehicle. What is new is that this logic now applies to commercial enterprise AI, and most procurement frameworks have not been updated to reflect it.

In practice, capability buying means shifting your procurement conversations from product features to business outcomes. Instead of asking 'does this AI tool have a natural language interface?', you ask 'what reduction in average contract review time can this tool reliably deliver in our environment, and how will we measure it?' Instead of negotiating per-user pricing, you negotiate against a performance baseline: cost per resolved query, cost per document processed, reduction in error rate on a defined workflow.

This matters in practice because AI tools are not all equal. Two vendors may both claim to offer AI-powered contract analysis. But if one is a pre-trained model with no domain adaptation and the other is a fine-tuned system trained on your industry's document formats, the capability delivered is entirely different - even if the licence cost is similar. Capability buying forces that distinction into the open.

It also changes what your internal stakeholders should be evaluating. The question for a finance team is not 'does this tool integrate with our ERP?' It is 'what is the realistic throughput improvement, and does that justify the total cost including integration, change management, and ongoing governance?' Microsoft's own pricing evolution illustrates this pressure from the buyer side: as reported in April 2026, enterprise customers are actively questioning why they should pay per-user for Copilot in Microsoft 365 when AI can automate tasks that previously required additional human licences. Organisations are now modelling whether fewer users with AI augmentation can deliver the same or better outcomes than a larger headcount on traditional tooling.

That question - fewer users, better outcomes - is the defining commercial logic of capability buying. It is not anti-technology. It is a more rigorous form of technology investment, and it favours organisations that can measure what AI actually delivers.

Why the Old Software Buying Framework Fails for AI

The traditional enterprise software procurement process was built around a set of assumptions that no longer hold. It assumed that software was a fixed product with a defined feature set, that value scaled linearly with users, that the procurement decision was primarily a buying event rather than an ongoing performance management relationship, and that the vendor's job ended at deployment.

AI breaks every one of those assumptions. AI models drift over time as the data they were trained on becomes less representative of current conditions. A model trained to identify fraud patterns in 2023 may perform significantly worse by 2026 if the patterns have changed. A customer service AI tuned on historical queries may degrade as product lines evolve. This is not a bug - it is an inherent property of AI systems. But it means the procurement decision is not a single event; it requires ongoing evaluation against agreed performance criteria.

The scale of shadow AI activity inside enterprises reveals just how badly existing procurement frameworks have fallen behind. Research published by Retool in April 2026 found that 60% of enterprise builders had created tools, workflows, or automations outside of IT oversight in the past twelve months, with 25% reporting doing so frequently. Crucially, two thirds of survey respondents were senior managers and above - not junior staff looking to cut corners, but experienced leaders who found that the existing procurement cycle could not keep pace with the speed at which AI could solve their problems.

When 60% of people are going around the official process, that is not a compliance failure. It is a demand signal. It tells you that the process was not designed for a world where building a working AI-powered tool takes days, not months. The same Retool data found that 35% of teams have already replaced at least one SaaS tool with a custom-built alternative, and 78% plan to build more custom tooling in 2026. The 'buy or build' calculus has shifted fundamentally, and it is shifting precisely because AI has driven the cost and time of building toward zero.

UK procurement teams operating under the Procurement Act 2023 - which came into force in February 2024 for public sector bodies - now have more flexibility to evaluate bids on the basis of 'most advantageous tender' rather than lowest price. This is an opportunity to build capability-based evaluation criteria into formal procurement processes. Most public sector AI buyers have not yet taken full advantage of this flexibility.

The Governance Gap: What Nobody Wants to Talk About

Here is the counterargument that comes up every time capability buying is discussed: 'We cannot evaluate AI on outcomes because we do not have the governance infrastructure to measure them.' And that is often true. But it is not an argument for keeping the old procurement model. It is an argument for fixing the governance infrastructure.

The governance gap is real. Deloitte's 2026 State of AI in the Enterprise survey of over 3,200 senior leaders found that data privacy and security ranked as the top AI concern at 73%, with governance capabilities cited by 46% as a significant barrier. More tellingly, 35% of organisations surveyed had no AI productivity metrics in place at all. If you cannot measure what your AI is delivering, you cannot procure more of it intelligently, negotiate renewals effectively, or make credible business cases for further investment.

This is where capability buying and governance become interdependent rather than competing priorities. You cannot buy capability without defining what capability means. And to define it, you need the measurement infrastructure: clear baselines before deployment, agreed key performance indicators tied to business outcomes, ownership of those metrics inside the business (not just in IT), and a review cadence that happens at least quarterly for any material AI deployment.

In practice for UK organisations, this also intersects with the ICO's guidance on AI and data protection, the DSIT AI Safety Institute's ongoing work on AI assurance, and for regulated sectors, the specific requirements from the FCA, PRA, or NHS England depending on your context. These are not obstacles to capability buying - they are the framework within which capability must be defined and validated. An AI system that delivers impressive throughput metrics but fails a data protection audit has not delivered the capability you needed.

The organisations that are getting AI procurement right are treating governance as a design input, not an afterthought. They define what 'good' looks like in terms of both performance and compliance before they go to market. They build contract clauses that reflect ongoing performance obligations - including model refresh schedules, data handling commitments, and remediation timelines when performance drops below agreed thresholds. This is materially different from buying a software licence and hoping the vendor fixes bugs in the next release.

What Capability Buying Looks Like in Practice

Capability buying is not a theoretical framework. It requires concrete changes to how procurement teams structure evaluations, write contracts, and manage vendor relationships post-deployment.

Start with the baseline. Before any AI procurement process opens, the business should have a documented baseline for the process or function the AI is intended to improve. If you are buying an AI-powered contract review tool, what is your current average review time per contract, what is your error rate, and what is your fully-loaded cost per contract reviewed (including staff time)? Without this, you cannot evaluate whether any vendor's claims are credible, and you cannot measure ROI after deployment. This seems obvious, but in practice it is the step most organisations skip.

Reframe your evaluation criteria. Replace feature checklists with capability statements. Instead of 'does the tool support bulk document upload?', ask 'what is the vendor's committed processing throughput for documents matching our typical format and length, and what SLA applies if throughput falls below that level?' Instead of 'does the tool have an API?', ask 'how will the tool perform when integrated with our existing systems, and what is the measured latency in a production-equivalent environment?'

Build performance obligations into the contract. This is the single biggest change capability buying requires in legal terms. AI contracts need to include: defined performance benchmarks with measurement methodologies, obligations on the vendor to maintain or improve performance over the contract term (not just at point of deployment), model refresh or retraining schedules where relevant, clear data handling and model training provisions, and remediation pathways if performance degrades. The IBM 2025 Cost of Data Breach Report found that AI-associated breaches cost organisations more than $650,000 per incident. Contracts that are vague on data handling are a commercial and legal liability.

Create a post-deployment review cadence. Procurement does not end at go-live. For any AI capability with significant operational impact, schedule quarterly reviews that measure actual performance against the baseline and contracted benchmarks. Use these reviews to drive vendor accountability - and to build the internal evidence base that justifies expanding, renewing, or replacing the capability.

What this means in practice for smaller organisations is that you do not need a dedicated AI procurement team. You need two things: someone in the business who owns the baseline and the metrics, and a procurement or legal advisor who understands how to translate capability requirements into contractual obligations. These are learnable skills, and the investment in getting them right saves significant money at renewal.

The Procurement Question Every Board Should Be Asking

There is a version of this conversation happening in boardrooms across the UK right now, and it usually sounds like: 'We have approved X for AI tools this year. Are we getting value?' The honest answer in most organisations is: they do not know. They have purchased licences. They have done rollouts. They may even have adoption metrics. But they do not have a clear line from AI spend to business outcome.

That gap is not just a measurement failure. It is a procurement failure. It means the organisation bought software when it should have bought capability, and now cannot tell the difference between a tool that is delivering and one that is sitting idle.

The board-level question that cuts through this is not 'what AI are we using?' It is 'what business capability has our AI spend created, and what did that capability cost us per unit of value delivered?' Framed that way, it becomes clear very quickly which AI investments have genuine ROI and which are vanity purchases dressed up as digital transformation.

The UK public sector is beginning to model this shift. The NHS England Federated Data Platform contract with Palantir, the DWP's GenAI Lighthouse Projects with IBM at £13.5 million, and the MOD's AI and Autonomous Systems Experimentation Hub with Kainos at £7.4 million - these are all, to varying degrees, structured around capability delivery rather than seat count. The fact that they are among the largest and most scrutinised AI contracts in UK government is not a coincidence. Outcome-based contracting attracts more rigorous evaluation, and more rigorous evaluation produces better procurement decisions.

For private sector organisations, the lesson is the same but the urgency is higher. Public sector bodies have the luxury of framework agreements and extended procurement timelines. Private sector businesses competing in markets where AI is driving cost and speed advantages for competitors cannot afford to spend two years on a procurement cycle and then another year discovering that the tool they bought does not actually deliver the capability they needed. Capability buying, done well, compresses that cycle because it forces clarity about what you need before you spend anything.

The shift from software buying to capability buying is not complete. Most procurement teams are still operating with tools, processes, and supplier relationships designed for a pre-AI world. But the organisations that make this transition first will hold a genuine commercial advantage: they will spend less, measure more accurately, and make better decisions about where AI actually moves the needle for their business.

Frequently Asked Questions

What is the difference between software buying and capability buying in AI procurement?

Software buying focuses on acquiring a product with defined features, typically priced per user or per licence. Capability buying focuses on acquiring a specific business outcome - a measurable improvement in throughput, cost, quality, or speed - and structures the contract around delivery of that outcome. The vendor relationship in capability buying is ongoing and performance-managed, not a one-off purchase event.

How do we define 'capability' for our AI evaluation criteria?

Start with the business process you are trying to improve and document the current baseline: time taken, error rate, fully-loaded cost per unit. Then define what 'improved' looks like in specific, measurable terms - for example, a 30% reduction in average contract review time with no increase in error rate. Your capability definition is the specific, measurable change you expect the AI to produce in that baseline.

Does capability buying work for off-the-shelf AI tools, or only for custom deployments?

It works for both. With off-the-shelf tools such as Microsoft Copilot or a third-party AI writing assistant, capability buying means demanding vendor evidence of real-world performance in environments similar to yours, rather than accepting feature demonstrations. For custom or fine-tuned deployments, it means structuring the contract around performance milestones rather than delivery of a code base.

How does the UK Procurement Act 2023 change AI buying for public sector organisations?

The Procurement Act 2023, which came into force in February 2024, allows public sector bodies to evaluate bids on the basis of 'most advantageous tender' rather than lowest price alone. This gives procurement teams legal cover to build capability-based criteria - including performance benchmarks, governance standards, and outcome metrics - into their formal evaluation frameworks. Most public sector AI buyers have not yet fully used this flexibility.

What happens if an AI vendor cannot meet the performance benchmarks we set?

This is exactly why capability-based contracts include remediation provisions. If a vendor cannot meet agreed benchmarks, the contract should specify: a defined timeline for the vendor to diagnose and resolve the shortfall, interim mitigation steps, and an exit or renegotiation right if performance is not restored within the agreed period. Without these provisions, you are locked into a non-performing tool with no contractual leverage.

Is shadow AI a sign that procurement is failing?

Yes, in most cases. When experienced senior managers regularly build AI tools outside official procurement channels, it signals that the formal process is too slow or too disconnected from real business needs to be useful. The response should be to redesign the procurement process, not to crack down on shadow activity. Faster, capability-focused procurement that delivers working tools in weeks rather than months removes the incentive for workarounds.

How should we handle AI model drift in procurement contracts?

Model drift - where an AI system's performance degrades as real-world conditions diverge from its training data - should be addressed explicitly in the contract. Include provisions for: regular vendor reporting on model performance metrics, a scheduled model review cadence (at minimum annually, quarterly for high-stakes applications), the vendor's obligation to retrain or update the model if performance falls below defined thresholds, and clarity on who bears the cost of retraining.

What is a realistic timeline to shift from software buying to capability buying in our organisation?

Most organisations can make meaningful progress within two procurement cycles - roughly 12 to 18 months. The first step is establishing baseline metrics for your three to five highest-priority AI use cases. The second is rewriting your standard AI evaluation template to include capability statements and performance SLAs. The third is piloting capability-based contracting on the next two or three AI purchases. Full transition across the portfolio typically takes two to three years.