The Procurement AI Adoption Model: How to Measure Culture, Trust and Behaviour Change

A procurement function completes an AI training programme. Licences are issued to category managers, sourcing teams and procurement operations. Senior leaders report strong participation and describe the rollout as an important step in modernising the function.

Three months later, adoption is uneven.

A small group of category managers uses the approved assistant daily for supplier research and strategy drafting. Other users have returned to spreadsheets, search engines and manual review. Some employees use personal AI accounts because the approved tool is slower or cannot reach the information they need. Contract specialists duplicate machine-generated analysis manually because nobody has defined what must be checked. Procurement operations has access to new automation but still runs the old approval and exception process around it.

Has procurement adopted AI?

It has enabled AI. It has created activity. Those are not the same as sustained adoption.

KOR’s central argument is:

AI adoption in procurement occurs when approved, useful and appropriately challenged AI becomes part of repeatable sourcing, category, contract, supplier and operational workflows. It cannot be inferred from training, licences or prompt volume.

This article applies the KOR Enterprise AI Adoption Model to procurement. The enterprise model establishes nine common adoption capabilities. The procurement application examines how those capabilities appear in a function where evidence quality, supplier confidentiality, commercial judgement, category variation and third-party technology all matter.

The question for the CPO is not:

How many people are using AI?

It is:

Where has AI become controlled procurement work, and what must change before the behaviour can scale?

Framework boundary: The Procurement AI Adoption Model is a KOR proposed synthesis. It is not an industry standard, employee assessment or claim that every procurement role should use AI in the same way.

AI adoption in procurement is the sustained use of approved AI within category management, sourcing, contracts, supplier risk and procurement operations, supported by role clarity, calibrated trust, appropriate review, workflow redesign and measurable outcomes.

Procurement is often treated as one function. In practice, it contains different professional and operating subcultures.

Category management

Category managers work with incomplete market information, commercial judgement and stakeholder influence. AI can accelerate research, structure strategy and identify patterns, but adoption depends on source quality, category relevance and whether the user can distinguish analysis from plausible synthesis.

Strategic sourcing

Sourcing teams operate through formal processes, supplier interaction, evaluation criteria and negotiation. AI may support requirements, event design, bid analysis and negotiation preparation. Adoption must preserve fairness, confidentiality, evidence and accountable evaluation.

Contracting and commercial management

Contract teams may use AI to summarise clauses, compare positions and identify obligations. Adoption depends on document quality, clause standards, legal review boundaries, retained evidence and the consequences of missed or misclassified risk.

Supplier risk, ESG and performance

AI can organise large volumes of supplier information and detect signals across external and internal data. The risks include weak provenance, stale sources, hidden scoring logic and overconfidence in generated risk narratives.

Procurement operations and procure-to-pay

AI may support intake, guided buying, classification, invoice handling, query resolution and exception management. Adoption is shaped by master data, process standardisation, system integration and whether the tool removes work or simply adds another layer.

Procurement leadership

Leaders use AI for decision support, portfolio visibility and communication. Their behaviour sets permission and expectations for the function, but it can also create pressure to present rapid progress before evidence exists.

These groups should share enterprise controls. They should not receive identical examples, training, review rules or adoption measures.

Procurement resistance is often treated as an attitude problem.

Employees may be described as cautious, traditional or insufficiently innovative. The response is then more communication, training and champions.

That diagnosis is incomplete where the approved capability:

• sits outside the workflow;
• cannot reach reliable procurement data;
• produces outputs that require full manual recreation;
• creates additional review without changing workload;
• lacks category-specific knowledge;
• cannot explain or cite its sources;
• requires users to remain accountable without clear decision rights;
• is less useful than the unauthorised alternative.

In those conditions, avoidance can be rational.

The UK Government’s 2026 AI Adoption Research found that lack of an identified need and limited AI skills were common barriers, while organisations also asked for tried-and-tested use cases and clearer support. The procurement lesson is straightforward: a useful, role-relevant proposition is more likely to be adopted than a generic capability accompanied by repeated encouragement.

Gartner’s procurement research has also identified change management as a constraint on procurement AI adoption. KOR’s position goes further: change management must be visible in process, management, incentives and evidence—not treated as a communications stream beside the technology project.

1. Role clarity
2. Practical capability
3. Approved use
4. Calibrated trust
5. Managerial reinforcement
6. Psychological safety and challenge
7. Incentives and performance measures
8. Workflow and role redesign
9. Sustained adoption

AI changes procurement tasks, but adoption becomes unstable when responsibility remains vague.

A category manager may receive AI-generated supplier analysis. A sourcing manager may receive a proposed evaluation summary. A contract specialist may receive machine-generated risk flags. A buyer may receive an automated recommendation about the correct channel or supplier.

In each case, the employee needs to know:

• what the system is doing;
• what remains their judgement;
• which evidence must be checked;
• what information may be entered;
• when another person must review;
• who can override or stop the process;
• who remains accountable for the commercial outcome.

What to assess

• Which uses are expected, optional, restricted or prohibited?
• Which tasks are assisted, partly automated or fully retained by people?
• What review is required for research, evaluation, contracting and supplier decisions?
• Are decision rights reflected in procedures and role profiles?
• Can users explain the human–AI boundary?

Strong evidence

• role-specific guidance;
• workflow maps;
• decision rights;
• review and escalation rules;
• examples of appropriate and inappropriate use;
• observed consistency across teams.

Generic prompt training is not procurement capability.

A user may know how to generate a polished answer while remaining unable to judge whether the source is reliable, the commercial logic is sound or the conclusion fits the category.

Procurement capability includes:

• framing the commercial problem;
• protecting supplier and organisational information;
• selecting the approved tool;
• verifying sources and calculations;
• recognising hallucination and unsupported confidence;
• understanding category and market context;
• testing outputs against contracts and policy;
• documenting significant use;
• knowing when AI is unsuitable;
• escalating errors and uncertainty.

Capability should be assessed in the workflow. Ask users to complete realistic sourcing, contract or supplier tasks and explain how they checked the result.

The safe route must also be the practical route.

Procurement employees handle confidential bids, pricing, contracts, supplier data, stakeholder information and commercially sensitive strategy. Unapproved use can create significant exposure.

But a prohibition-only approach fails where authorised tools cannot perform legitimate work.

What to assess

• Are approved tools available to the intended roles?
• Can they access the necessary procurement knowledge and data?
• Are permissions appropriate?
• Is the user clear about what information may be entered?
• Does the approved process retain evidence where required?
• Is there a credible route for experimental use?
• Are embedded AI features in procurement platforms inventoried and approved?

Shadow AI should be treated as both a control issue and a diagnostic signal. It may indicate weak awareness, but it may also reveal a gap in the approved proposition.

The objective is neither trust nor scepticism. It is trust proportionate to evidence and consequence.

Under-trust

Users recreate the work manually, ignore useful recommendations or maintain parallel records. The technology adds cost without changing the process.

Over-trust

Users accept supplier research, scores, summaries or contractual analysis because the output appears detailed and professional.

What users should understand

• what the system performs well;
• what data and sources it uses;
• where it is unreliable;
• what cannot be inferred from the output;
• what review is mandatory;
• how corrections are captured;
• how performance is monitored.

The 2025 University of Melbourne and KPMG global trust study found widespread use alongside inappropriate and complacent behaviour and inconsistent evaluation of outputs. Procurement adoption must therefore measure review quality, not only confidence or frequency.

CPO sponsorship creates permission. Procurement managers determine whether AI becomes normal work.

The adoption cascade is:

CPO intent → functional ownership → manager reinforcement → workflow expectation → observed behaviour → sustained norm

Managers influence adoption when they:

• use approved capabilities appropriately;
• allocate time for learning and redesign;
• set role-specific expectations;
• remove data, access and process barriers;
• respond constructively to disclosed errors;
• challenge unsupported outputs;
• recognise good judgement rather than activity;
• stop low-value use cases.

A manager who asks for AI-enabled output but still expects the old manual pack, the same timetable and full duplicate checking is not reinforcing adoption. They are adding work.

Responsible procurement adoption requires permission to question the tool, the process and the programme narrative.

Users should be able to report:

• unreliable supplier information;
• a contract analysis that misses material context;
• pressure to use a tool outside its approved scope;
• an unapproved tool used in good faith;
• a workflow that creates duplicate effort;
• a supplier feature introduced without adequate review;
• a claimed benefit that is not visible in the process.

If employees believe that reporting an error will be treated as incompetence or resistance, the organisation will receive cleaner progress reports and weaker control.

Adoption stalls when the new workflow conflicts with the measures governing the old one.

Examples include:

• asking category managers to use AI while measuring only sourcing-event volume;
• adding verification without adjusting workload;
• encouraging experimentation while penalising stopped pilots;
• automating administration without changing role expectations;
• measuring log-ins and prompts rather than commercial outcomes;
• celebrating estimated hours saved without identifying released capacity.

Better measures include:

• approved use in relevant workflows;
• source and output verification;
• reduced cycle time across the whole process;
• fewer avoidable errors or exceptions;
• improved compliance or risk visibility;
• stakeholder experience;
• capacity released and redeployed;
• sustained use after launch support;
• measurable commercial or operational value.

A procurement use case has not been adopted if AI produces an output while the rest of the process remains unchanged.

Category strategy

Redesign may change how market evidence is collected, structured, challenged and updated. The category manager should spend less time assembling material and more time testing implications and engaging stakeholders.

Sourcing

Redesign may change requirement preparation, supplier questions, analysis and negotiation planning. Evaluation fairness and retained evidence must remain clear.

Contracts

Redesign may shift first-pass review, clause comparison and obligation extraction while preserving escalation for material legal and commercial judgement.

Supplier risk

Redesign may change signal collection and triage, with people focusing on material alerts, investigation and action.

Procurement operations

Redesign may remove manual routing and repetitive queries rather than generating another recommendation for a person to re-enter elsewhere.

The relevant question is:

Which step disappears, changes or becomes more valuable because AI is present?

Procurement adoption is cultural when appropriate behaviour persists under ordinary operating pressure.

Test whether it survives:

• the end of launch communications;
• reduced implementation support;
• busy sourcing and renewal periods;
• manager and champion changes;
• new employees joining;
• difficult categories and contracts;
• supplier or model updates;
• failures and exceptions;
• pressure to deliver quickly.

A use case dependent on one enthusiast is promising. It is not yet a function capability.

The enterprise context lenses still matter, but procurement needs its own application.

Category and market structure

AI may work well in information-rich indirect categories and less well where supplier markets are opaque, technical or relationship-dependent. Adoption should follow the use case and evidence, not a blanket function mandate.

Direct versus indirect procurement

Direct procurement may face product, quality, engineering and supply-continuity constraints that differ from professional services or corporate categories. The workflow, data and consequences should determine the control level.

Central versus regional teams

A global procurement function may have one policy but different languages, systems, supplier markets, regulatory conditions and decision rights. A successful central pilot does not establish regional usability.

Organisation size

Large functions can provide specialist support and integrated platforms but face legacy complexity and multiple operating models. Smaller functions may diffuse behaviour quickly but rely more heavily on informal judgement and vendor defaults.

Platform maturity

Embedded AI in Coupa, Ariba, Ivalua, Jaggaer, contract systems and supplier tools may arrive faster than the organisation’s approval and adoption process. Procurement should inventory the capability rather than waiting for employees to identify it.

1. Enabled but unchanged

Training and access exist, but the old workflow remains dominant.

Leadership response: diagnose usefulness, process fit and management expectations before buying more licences.

2. Active but uncontrolled

Use is widespread, including shadow tools, but review and evidence are inconsistent.

Leadership response: make the approved route usable, clarify boundaries and gather operational evidence.

3. Controlled but fragile

Selected teams use AI appropriately, but adoption depends on champions or implementation support.

Leadership response: broaden management ownership, redesign roles and test durability.

4. Embedded and evidenced

Approved use is sustained across relevant workflows, controls operate and outcomes are measured.

Leadership response: scale selectively, monitor change and continue improving the portfolio.

Provisional

• surveys and interviews;
• training attendance;
• management assertion;
• user sentiment;
• pilot anecdotes;
• estimated time savings.

Substantiated

• role guidance;
• approved use cases;
• workflow and review design;
• tool configuration;
• training aligned to roles;
• manager expectations;
• supplier documentation;
• issue and escalation records.

Verified

• sustained approved usage;
• observed review behaviour;
• corrections and escalation;
• reduced shadow use;
• end-to-end process change;
• outcomes against baseline;
• capacity redeployment;
• finance-validated value where relevant.

Adoption and evidence confidence should be reported separately. A high adoption claim supported only by interviews should not justify enterprise scale.

Step 1: map use by role and workflow

Inventory general-purpose tools, platform features, local experiments and known shadow use across category, sourcing, contracts, risk and operations.

Step 2: define appropriate adoption

Specify what good use looks like for each workflow. Maximum use is not the objective.

Step 3: assess the nine capabilities

Use interviews and surveys for orientation, then examine operating evidence.

Step 4: compare leadership and user views

Differences between senior perception and frontline experience are diagnostically valuable.

Step 5: observe real work

Review how users research, check, transfer, correct and escalate outputs.

Step 6: identify the constraint

Distinguish skill, trust, access, data, workflow, management, incentive and governance problems.

Step 7: redesign the intervention

Choose role-specific training, product changes, process redesign, manager action or control improvement based on the constraint.

Step 8: establish outcome baselines

Measure time, quality, risk, compliance, stakeholder experience and total cost before claiming value.

Step 9: test durability

Reassess after support is reduced and difficult cases appear.

A procurement function pilots an assistant that produces supplier and market research for category strategies.

The pilot team reports major time savings and strong user satisfaction.

A broader adoption review finds:

• the most confident users are experienced category managers;
• source links are inconsistent;
• users apply different verification standards;
• some categories have strong public data while others do not;
• regional teams cannot access the same sources;
• managers still request the old research pack;
• estimated savings exclude checking and reformatting;
• no process exists for recording corrections.

The CPO does not approve an immediate global mandate.

The function redesigns the use case:

• category-specific source standards are defined;
• outputs must link to evidence;
• users receive role-based review guidance;
• regional access is tested;
• the strategy template is changed;
• duplicate research steps are removed where evidence supports it;
• corrections are logged;
• cycle time and quality are measured end to end;
• expansion is conditional on category and regional performance.

The capability moves from an impressive assistant to a procurement workflow.

Treating training as adoption

Training is an input. Adoption is sustained operating behaviour.

Blaming culture for poor product design

A tool that is harder than the workaround will not become normal through communication alone.

Using champions as permanent infrastructure

Champions can support discovery, but managers and process owners must own the operating model.

Measuring activity instead of outcomes

Prompts and log-ins do not prove process change or value.

Applying one standard across all categories

Use-case suitability, evidence and risk vary.

Ignoring embedded supplier AI

Procurement can adopt AI without deliberately buying a product labelled as AI.

Mandating use too early

Premature mandates create compliance theatre, duplicate work and hidden avoidance.

Preserving the old workflow

If every old step remains, the organisation has added technology rather than redesigned work.

The purpose of the Adoption Model is not to classify employees as innovative or resistant.

It is to determine:

• where approved behaviour exists;
• where usage is uncontrolled;
• whether trust is calibrated;
• whether managers reinforce the change;
• whether workflows have improved;
• whether adoption survives normal pressure;
• whether outcomes justify further scale.

The strongest adoption programme is not the one with the greatest activity.

It is the one that can show where AI has become useful, controlled and sustained procurement work.

What is AI adoption in procurement?

It is the sustained use of approved AI within procurement workflows, supported by role clarity, practical capability, calibrated trust, management, controls and measurable outcomes.

How is adoption different from procurement AI readiness?

Readiness assesses whether the function has the broader foundations to deploy AI. Adoption assesses whether people are using it appropriately and sustainably in actual work.

Is training enough?

No. Training must be accompanied by useful tools, workflow integration, management reinforcement, incentives, review rules and evidence.

Should AI use be mandatory in procurement?

Only where the use case, workflow, support, controls and value are sufficiently established. Premature mandates often produce hidden workarounds.

How should procurement leaders measure culture?

Measure approved behaviour, review quality, challenge, manager reinforcement, workflow change, sustained use and outcomes—not sentiment alone.

Does every procurement role need the same AI capability?

No. Category managers, sourcing professionals, contract specialists and operations teams require different examples, controls and depth of capability.