Six things procurement teams need before any AI tool

Key takeaways 

AI in procurement only works if you use it with purpose and intent. Before rolling out any AI tool, check six things:  

• is your catalogue and supplier data actually clean;  

• does your team take data quality seriously enough to trust what the tool surfaces; 

• who gets access and at what level;  

• is the rollout planned and piloted, not switched on all at once;  

• has legal, privacy, security and IT signed off; and  

• have you modelled what it will cost against what it will actually change.  

If you skip these, AI adoption will move fast in the wrong direction. If you get them right, it gives your team extra time back. 

AI in procurement only works if you use it with purpose and intent  

Let’s say your procurement team's stand-up is running long. The sourcing lead is trying to close out three supplier negotiations before the end of this quarter. The category manager has a backlog of purchase requests that keeps growing every week.  

The team is managing more work than ever. They need to assess suppliers, collect new data, and everyone is taking on more tasks than their job description lists. And adding headcount won't be part of the plan anytime soon. The budget for that was cut last quarter. 

This is not a unique case. Our 2026 report found that an indirect procurement team manages 250+ suppliers and spends 5,618 hours a year just to keep the process running.  ESG reporting alone adds another 20% to their existing workload — while budgets and headcount tend to remain flat.  

A colleague suggests using an approved enterprise AI tool to classify anonymised request summaries before a buyer reviews them. Their instinct isn’t wrong. They are trying to solve a real problem, fast, which is where AI can genuinely help.  

It's also exactly the moment where AI adoption can go sideways – not because the team lacks skill or judgement, but because these decisions are often made in a moment of rush, one tool suggestion at a time, without anyone stepping back to ask whether the team is ready for it. 

Jumping straight into working with a new AI tool or adding a point solution isn't the same as adopting AI with purpose. The teams who actually see the benefits of AI aren’t the ones who are the quickest to adopt new tools, but the ones that treat it as part of an integrated procurement strategy. 

Now, look at how to add AI into the procurement process, one decision at a time. 

Is your catalogue data clean and up to date? 

Let's say the team brings in an AI tool to help with spend analysis. The tool can surface patterns across thousands of line items faster than anyone on the team could scan them by hand. But it doesn't get the final say.  

Every flagged anomaly, every "this looks like overspend", still lands in front of a person who checks it before anything changes. Human oversight should be proportionate to the risk. Low-risk insights may not need manual approval, but any consequential decision should have a human decision-maker. 

That's not a workaround or a limitation to tolerate — it's the whole point. AI can prioritise anomalies and patterns; a category manager validates material findings before taking action. 

Which raises the question: Attention to what, exactly?  

For AI use cases that depend on catalogue or supplier data, establish ownership, assess quality and freshness, and test representative samples before the tool influences decisions.  

You need to make sure the data is reviewed by a human. That review usually turns up the same handful of things: categories that made sense three years ago and haven't been changed since; duplicate entries for the same item under two supplier names; pricing nobody's revisited since before the last renegotiation; and SKUs that nobody remembers approving. 

Each of these needs the same fix, and it's a simple one: someone goes through and cleans it up.  

• Consolidate categories back into something that reflects how the business actually buys today.  

• Merge duplicates.  

• Check pricing against what was actually negotiated.  

Keep in mind that data quality is not a one-off clean-up exercise. It needs owners, rules, exception handling and regular review. 

Catalogues change. Suppliers may add new items, variants or pack sizes outside the originally negotiated scope. If these become orderable without review, they can create spend leakage or make negotiated coverage less visible. The key is expecting this, not being caught off guard by it, and building in a regular habit of going back and clearing out what shouldn't be there. 

Does your team treat data quality and visibility seriously? 

How teams approach data quality is worth a closer look, because the numbers suggest most don't treat it as seriously as they should. A recent Hackett Group report found that only 37% of procurement leaders cited deep, real-time data and insight visibility as a critical trend.  

It's a sign that most teams still don't see it as a priority at all, which is exactly what makes AI adoption risky. If two-thirds of procurement leaders aren't prioritising visibility into their own data, most AI tools are about to run on catalogue data nobody's checked in a while. 

That matters because of what happens next: if you feed AI a mess, it doesn't hand back a mess — it produces confidently wrong outputs, which cost more time to catch and fix than doing the cleanup up front would have. Automation built on inconsistent product data, duplicate suppliers, or an ungoverned catalogue doesn't remove that risk. It compounds it, faster and at a scale no one on the team would have created by hand — and now someone has to notice the output is wrong before they can even start fixing it. 

Some procurement teams don't have the internal bandwidth to review every category line by line — and for those teams, bringing in outside expertise to benchmark categories against the market and flag anomalies is a perfectly reasonable move. 

Who gets to use the new tool and with what type of access? 

Let's say you decide to roll out the new AI feature. Someone still has to decide who can actually use it, and for what. One of the safer starting points is usually the tool your team already trusts.  

An AI feature in an existing platform may reduce identity and integration complexity. But even inside a trusted tool, someone still has to decide who gets what level of access — and that decision needs to be written down and signed off by the people it affects, not assumed or worked out informally after the fact. 

It's worth imagining what happens when that step gets skipped. Let’s say a newly hired employee is given AI-assisted ordering access with a spending range nobody thought to narrow. Within weeks, they've exceeded budget before anyone notices. Or someone ends up with admin access by accident rather than by design, and now they can change other people's permissions too, which turns one oversight into several. 

These scenarios are what happens when permissions are treated as a setup task instead of an ongoing responsibility. That's also why permissions can't just live in an IT ticket somewhere. They need to be part of how new employees are onboarded, so everyone understands from day one what they can do with the tool — and just as importantly, what they can't. 

Do you have a plan on how to roll it out to the wider organisation?  

Once stakeholders sign off the strategy, there's another decision that's just as easy to rush: when does each team get to use the new tool? Turning it on for everyone at once, on day one, isn't a safe way to add AI into your procurement process — it's a gamble, and it's usually the first thing to go wrong even when everything else was planned properly. 

A safe, gradual rollout is documented before it starts, not improvised once people are already using the tool. That usually means picking one of two paths and committing to it:  

One approach is to start with leadership and admins, who need to understand the full functionality before anyone else gets to use it, and let it cascade down from there. 

The other, for higher-risk use cases, is to begin with a controlled pilot using representative users and realistic data. You define success measures, monitoring, support and rollback criteria before expanding access. 

Either way, the order matters. The people who'll end up supporting and troubleshooting the tool need to understand how it works under the hood before the people who'll just be using it day to day get access. It's what keeps a rollout from turning into a string of individual support tickets the moment real usage starts. 

The common thread across both of these steps, sign-off and rollout: a plan, agreed on before you start, beats a decision made in the middle of the rush. 

Is it aligned with your existing policies? 

None of this is a decision procurement gets to make alone. Involve the relevant legal, privacy, security, IT, data and business owners early, and document the risk-based approval required for the specific use case. Legal and compliance check that the tool actually holds up against existing policy: how it handles data, what it's allowed to touch, where the risk sits if something goes wrong. IT is checking something a little different — less about policy, more about whether the thing is safe to plug in, how it fits into the systems already running, and what happens if it doesn't. 

Skipping this step doesn't save time, it just moves the delay to later, when it's harder to undo. A tool that's already been rolled out to twenty people is a much bigger problem to walk back than a tool that's still sitting in a shared drive waiting for sign-off. 

So the plan, before anything goes live, is simple to state and easy to skip under pressure: get the relevant stakeholders in the room, get their approval in writing, and only then move to rollout. 

Can you model the cost and value before you commit? 

An impressive demo is not yet a business case. Understanding what ROI in procurement actually looks like means building a simple cost estimate before committing to a new AI tool. 

The cost is not just the subscription fee; it may include integration, data preparation, security review, training, ongoing monitoring and the cost of switching off or replacing the tool later. 

Your team should also define the baseline you want to improve: hours spent on a process, cycle time, rework, maverick spend, supplier leakage or compliance effort. Then you can estimate what the tool could realistically change and test those assumptions in a controlled pilot. 

The aim is not to predict the return on investment to the nearest decimal. It is to make the assumptions visible, understand what must be true for the investment to pay off and avoid committing to a tool simply because its demo looked great.  

Six checks, one decision 

Now, back to your stand-up. The sourcing lead still has three negotiations to close, the category manager's backlog hasn't gotten any shorter, and ESG reporting isn't going anywhere. None of that changes. What changes is how the team gets to say yes to AI. 

"Let's use an approved tool to classify these requests" is a fine place to start a conversation. But before that idea goes anywhere, the team needs to know the catalogue and supplier data feeding the tool are actually clean, and that someone takes ownership for keeping them that way. They need to know who's allowed to do what with the tool, written down, not assumed. They need a rollout that's been planned and piloted, not switched on for everyone at once. They need legal, privacy, security, and IT to have looked at it and signed off. And they need an estimate of what it will cost. 

These steps might slow the adoption down, initially, but they make all the difference between adopting AI for the hype, and adopting AI with purpose — and whether it will make a stretched team's job harder, or give them some time back. 

The teams that get real value out of AI aren't the fastest. They're the ones who checked the data, wrote down the permissions, planned the rollout, got the sign-off, and did the math before they committed.