The AI Business Case Is Already Here. The Real Question Is Where It Still Makes Sense.

Procurement, supply chain and contract management have moved past the question of whether artificial intelligence belongs in the function. The use cases are already live, and they are significant. I see organisations drawing up contracts with AI-assisted drafting tools that pull from clause libraries and precedents in seconds. I see price analytics engines scanning thousands of supplier quotes, market indices and commodity curves to surface anomalies a human team would take weeks to catch. I see repository-driven portfolio overviews that finally give contract managers a single, searchable view of thousands of agreements, with obligations, renewals and risks tagged and tracked automatically.

And there is more. Supplier risk scoring that reads news, filings and shipment data in real time. Demand forecasting that adjusts sourcing plans as conditions change. Automated extraction of terms from PDFs and scans, turning a paper archive into structured data. Clause comparison across negotiated versions. Renewal calendars that actually work. Audit trails built as work happens rather than reconstructed after the fact. None of this is hypothetical. It is running in real organisations today, and the results are real.

So the conversation has shifted. It is no longer about proof of concept. It is about where to put the next investment, how far to scale, and which process to reinvent next. That is a healthy place to be. But it is also the moment where a less obvious question starts to matter more than the one everyone is asking.

The resource question nobody booked for

AI is not an unlimited resource. That is a sentence worth sitting with, because the prevailing narrative suggests the opposite. We talk about AI as if it were cloud computing in 2012, a seemingly unending elastic pool you tap into and pay for by the sip. The reality is messier. Every inference has a footprint. Training and running large models consumes water for cooling, energy for compute, and physical hardware that itself depends on scarce materials and concentrated supply chains. The compute layer is not infinite, and the cost curve that looked linear a year ago is bending in directions finance teams did not model.

For a procurement or contract management leader, this changes the framing. You are not just choosing an architecture. You are choosing where to spend a finite and increasingly expensive resource. The question is not "what can we AI?" but "where does AI earn its keep?" Because in many cases it does, clearly. In others, the value is marginal and the cost is not. A model that drafts a high-stakes contract clause saves hours of expert time and reduces error. A model that summarises a routine internal memo saves two minutes and introduces risk. Both are "AI in the workflow." Only one of them justifies its own existence.

This is the shift I see coming in business case thinking. The first wave of AI adoption was driven by possibility and fear of missing out. The next wave will be driven by economics and constraint. Organisations will need to think clearly about where AI brings the most value, and accept that it does not need to be deployed on everything. There is a lot of value on the table. There is not enough value, or enough resource, to put it everywhere.

Architecture is half the question. Value is the other half.

A lot of the current debate is about architecture: which models, which orchestration layer, which agent framework, build versus buy, on-prem versus cloud. These are important decisions. But they are downstream of the decision that matters more, which is where in your operation AI actually earns a return. You can build the most elegant agentic architecture in the world and still spend six figures a month automating work that did not need automating.

The value lens is different. It starts from the portfolio of problems you have, ranks them by the cost of the problem and the realistic gain from AI, and only then asks which architecture fits. It treats AI investment the way any serious capital investment is treated: with a hypothesis, a cost, a risk, and a measure. The technology choice follows the business case, not the other way around.

This is where it gets interesting for our field. Procurement, supply chain and contract management are full of high-volume, high-stakes, data-heavy work. That is exactly where AI pays off. But they are also full of judgement, relationship, context and precedent. That is exactly where AI pays off only if it is scoped carefully. The business case is not uniform across the function. It is lumpy. The skill is finding the lumps.

The rise of the business AI architect

This is going to create a role I believe most organisations do not yet have and most are not yet hiring for: the business AI architect.

Note the first word. This is not a technologist role, and that is the point. The business AI architect is not the person who tunes models or builds the agent pipeline. It is the person who looks at the entire portfolio of possible AI initiatives and decides, with evidence, which ones deserve resource and in what order. They understand the portfolio. They understand prioritisation. They understand the business. And, critically, they get finance. They can read a cost model, stress-test a business case, and tell the difference between a saving and a saving that disappears once you account for compute, licence, integration, change management and risk.

This person sits between the technical teams and the executive sponsor and does the one thing both sides struggle to do alone: connect the technology to the economics of the business. They are not anti-AI. They are pro-value. Their job is to make sure the organisation does not blunder into a programme that looks impressive in a demo and weak on a profit and loss statement.

Combine that with the growing burden of security, privacy and dependency, and you can see why this role is more than a prioritisation exercise. Every agent you deploy is a new surface area. It reads data, it writes data, it calls other systems, it makes decisions at speed. Security teams know this. Privacy teams know this. But the dependency angle is newer and it matters especially in our field. If your contract intelligence depends on a model provider, on a cloud, on an integration, on a data pipeline, then your contract intelligence has dependencies. Dependencies have failure modes. Failure modes have business consequences. The business AI architect is the person who maps those dependencies before they map themselves, at the worst moment, in a live incident.

So where, when, at what cost, and under what conditions. These four questions are the ones being overlooked in the current hype. The hype answers the first one loudly, with "everywhere," and skips the rest. A mature organisation answers all four, in order, before it commits.

Start with the future, not the tool

This is why my advice to leaders right now is to resist the pull of the AI programme as a starting point. Do not begin by standing up an AI initiative. Begin by getting clear on where you are going.

Start with a clear vision of your target operating model for the future. What does the function look like in three years? What work is human, what work is machine, what work is a careful mix? What capabilities do you need, what do you already have, and what will you retire? Then look at your risk of the future: the exposure you will carry as you digitise judgement and depend on external intelligence. Then look at your dependencies of the future: the providers, platforms, data flows and skills you will rely on, and what happens when one of them wobbles.

Only then do you start your AI programme. By that point, AI is not a leap of faith. It is a means of getting to a target you have already defined. The programme has a shape because the strategy has a shape. Investment follows intent.

I know this sounds slower than the alternative. The alternative is faster, until it isn't. The organisations that blunder into AI usually do so by starting with the tool and working backwards to a justification. They end up with a portfolio of experiments, none of which quite connect, all of which cost money, few of which have a clear line to a business outcome. Six months in, they have demos and no model. The slower path, the one that starts with the operating model, produces a programme that compounds.

Even in contract management: fix the process first

I want to land this on my home turf, because contract management is where I see the temptation most clearly.

Contract management is a field that has lived for years with the consequences of automating before fixing. We have all seen the contract repositories that digitised the chaos rather than ending it: thousands of contracts scanned in, metadata that nobody trusts, clauses nobody can find, obligations nobody tracks. The system was modern. The process underneath was not. Automation scaled the problem instead of solving it.

AI makes that mistake more expensive, and faster. If you deploy AI on top of a broken contract process, you get a faster broken process. You get drafts built on inconsistent templates. You get risk alerts based on metadata that was wrong to begin with. You get summaries of contracts that no one ever managed properly. The AI does not know your process is broken. It just learns it, scales it, and charges you for the privilege.

So the order of operations is the same as it has always been in this field, and it is the order the broader AI debate is rediscovering. Fix your process first. Fix your strategy first. Then automate. Not the other way around.

Fix the process: the lifecycle, the ownership, the handovers, the data, the definitions. Make the work legible before you make it intelligent. Fix the strategy: what you are managing contracts for, what value you expect, what risks you will not accept. Then, and only then, bring in the AI, scoped to the places where it earns its keep, governed by someone who understands the portfolio and the economics, and deployed against a target operating model you have already designed.

The shift that matters

The use cases are real. The value is real. I am not an AI sceptic. I am a business case believer, and right now the business case for AI in procurement, supply chain and contract management is strong in specific places and weak in others. The leaders who will win are not the ones who adopt the most. They are the ones who adopt with the clearest idea of where the value is, what it costs, and what they are willing to depend on to get it.

That requires a new discipline and, I would argue, a new role. It requires starting with the future you want, not the tool you have. And it requires the humility, even in a hyped market, to say that not everything needs AI, and that the things that do need it need to be earned.

AI is eating resources. Let it eat the right ones.

By Arjen Van Berkum

Keywords: AI, Economics, Leadership

Follow Us On

Become a Contributor Newsletter Signup