The Procurement AI Maturity Model: Five Stages from Experimentation to Controlled Scale

A procurement function has twelve AI pilots, three enterprise software platforms with embedded AI, a steering committee and hundreds of employees who have completed introductory training. How mature is it? The answer may still be: not very. The pilots may be disconnected from the operating model. The software may be available but lightly used. The steering committee may approve policy without seeing operational evidence. Training completion may say little about whether people can challenge outputs, protect sensitive data or incorporate AI into procurement workflows. Reported benefits may be estimates rather than measured changes in cycle time, compliance, risk or commercial outcomes. This is the central weakness in many AI maturity assessments. They reward visible activity and average together capabilities that should not be interchangeable. A function can score highly for executive sponsorship and technology while remaining weak in data quality, human oversight, adoption or supplier assurance. The resulting average looks credible, but it may conceal the precise constraint that makes wider deployment unsafe or uneconomic. KOR’s Procurement AI Maturity Model takes a different approach. It defines five stages of organisational development, but progression is controlled by hard gates. Pilot volume, tool ownership or policy maturity cannot compensate for a critical weakness in the foundations required for the next stage. The purpose of the model is not to award procurement a flattering label. It is to answer a more useful question:

What can this function credibly do next, and what evidence must exist before it progresses?

AI maturity is often used as an umbrella term for several different conditions. For a meaningful assessment, they need to be separated.

A procurement function can be active without being ready, ready without yet producing substantial value, or successful in one use case without having mature function-wide capability. The separate KOR Procurement AI Readiness–Realisation Matrix plots preparedness against realised value. The maturity model addresses the longitudinal question: how reliably can the organisation repeat, govern and improve what it is doing?

KOR reviewed procurement-specific AI maturity and readiness models, broader enterprise frameworks, responsible-AI guidance and supplier-assurance approaches. The recurring foundations were clear. Credible models assess strategy, data, technology, governance, processes, people and value. The stronger procurement-oriented models also examine integration with source-to-pay workflows and the operational consequences of deployment. The gaps were equally consistent:

• culture and adoption are frequently acknowledged but weakly measured;
• self-assessment is rarely qualified by evidence confidence;
• supplier and third-party AI controls are often separated from operating-model maturity;
• benefits may be accepted without baseline or finance-grade verification;
• high scores in technology or strategy can conceal serious weaknesses elsewhere;
• public models often reveal little about weighting, calibration or stage thresholds.

KOR’s model is a proposed synthesis of that research. It is not claimed to be an industry standard or statistically validated benchmark. Its contribution is the combination of:

1. five procurement-specific maturity stages;
2. eight connected capability dimensions;
3. hard gates between stages;
4. evidence-confidence ratings;
5. explicit scale, redesign and stop decisions.

This reflects a broader shift in AI governance away from one-off policy creation towards lifecycle management. The NIST AI Risk Management Framework organises risk management around Govern, Map, Measure and Manage. ISO/IEC 42001 defines requirements for establishing, implementing, maintaining and continually improving an AI management system. The UK Government’s AI Management Essentials similarly focuses on organisational practices, records and third-party information rather than technology ownership alone. KOR applies that management-system logic specifically to procurement.

Most maturity assessments are built around a questionnaire. Respondents score statements such as “we have an AI strategy”, “our data is accessible” or “our people are trained”. The scores are weighted and averaged into a stage. That is efficient, but it creates four forms of inflation.

Activity inflation

Pilots, licences, prompts and training sessions are counted as evidence of organisational capability. The Hackett Group reported that 49% of procurement teams piloted generative AI in 2024, while only 4% had reached large-scale deployment. Its 2026 procurement research reported that deployment had nearly doubled year on year, yet only 12% of respondents described large-scale implementation. The direction of travel is clear, but the continuing gap between activity and scale is equally important. SOURCE: The Hackett Group 2025 research and 2026 Procurement Key Issues. Pilot activity should therefore generate evidence, not maturity points by itself.

Policy inflation

A policy exists, so governance is marked as established. Operational governance requires more: approved use cases, clear accountability, review standards, logs, escalation, incident handling and evidence that controls operate in practice. A document can be mature while the underlying behaviour remains inconsistent.

Technology inflation

A procurement suite introduces advanced AI functions, so the organisation assumes its maturity has increased. Supplier capability and organisational capability are not the same. The function must still integrate the tool, govern access, redesign work, support users, monitor outcomes and manage changes to the supplier’s models and subprocessors.

Benefit inflation

Users report time savings, so value is considered proven. Mature value measurement requires a baseline, actual adoption, quality and risk outcomes, full operating cost and a credible route from released time to economic or operational benefit. A model that averages these inflated scores can place a function at Controlled Scaling even when it has not demonstrated the conditions required for production operation.

A hard gate is a minimum condition that must be met before the next maturity stage can be claimed. It prevents a high score in one area from cancelling out a material weakness in another. For example:

• sophisticated technology cannot compensate for absent human-review controls;
• executive sponsorship cannot compensate for unreliable data;
• high user enthusiasm cannot compensate for unauthorised tools or sensitive-data exposure;
• a strong pilot result cannot compensate for missing production ownership;
• estimated benefit cannot compensate for a lack of baseline or sustained adoption;
• internal controls cannot compensate for weak assurance over third-party AI.

This does not mean every dimension must be perfect. The gate should be proportionate to the risk and scope of the intended deployment. A low-risk research assistant and an autonomous supplier-selection agent should not face identical requirements. The principle is simpler:

The model contains five stages:

1. Reactive or Unready
2. Foundation Building
3. Managed Experimentation
4. Controlled Scaling
5. Orchestrated or Adaptive Procurement AI

At Stage 1, AI use is fragmented, informal or largely supplier-led. Activity may exist, but the procurement function has no coherent way to see, prioritise or govern it.

What it looks like

Common characteristics include:

• employees use general-purpose AI tools independently;
• AI functionality appears through existing software without a common assessment process;
• there is no complete inventory of tools, pilots or supplier-enabled AI;
• data ownership and permissions are unclear;
• use-case approval depends on local judgement;
• human review is assumed rather than designed;
• training is generic, optional or absent;
• suppliers provide limited clarity on models, data flows and material changes;
• benefits are based on demonstrations or anecdotes;
• ownership ends when a pilot or implementation project closes.

This is not necessarily an organisation with no AI. It may be an organisation with significant AI activity but little organisational control.

Typical procurement examples

• A category manager uses a public assistant to summarise confidential supplier information.
• A contract platform enables generative summaries, but legal and procurement have not agreed how outputs should be reviewed.
• A supplier-risk tool introduces machine-generated alerts, while users do not understand the source data or confidence level.
• Different regions purchase overlapping AI tools without a common architecture or supplier-assurance standard.

Leadership priority

The immediate priority is visibility and minimum control, not rapid expansion. The CPO should establish:

• a basic inventory of AI use, tools and embedded supplier functionality;
• named executive and operational ownership;
• initial rules for data, security and acceptable use;
• a route for approving experiments;
• visibility of the most material third-party dependencies;
• a defined programme of foundation work.

Hard gate to Stage 2

A function should not claim Foundation Building until it can evidence:

• accountable sponsorship and operational ownership;
• a sufficiently complete inventory of current AI use;
• initial risk, data and acceptable-use rules;
• a defined assessment scope and priority business problems;
• a route for reporting inappropriate use or incidents;
• agreement that pilot volume is not the maturity measure.

The evidence may still be substantiated rather than fully verified, but it must exist beyond verbal assertion.

At Stage 2, the organisation is deliberately strengthening the prerequisites for controlled experimentation. It may run fewer pilots than a visibly active Stage 1 organisation, yet be better positioned for sustainable progress.

What it looks like

Common characteristics include:

• procurement outcomes and candidate use cases are being prioritised;
• accountable owners and decision rights are defined;
• data quality, access and integration constraints are documented;
• governance principles and approval routes are being established;
• approved experimentation environments are identified;
• role-based capability needs are understood;
• supplier due-diligence questions and contract requirements are being developed;
• baselines are designed before significant deployment;
• change and adoption are considered in the use-case design.

The function is moving from curiosity to intentional capability-building.

The main risk: foundation work without learning

Foundation Building can become an indefinite transformation programme. Teams wait for perfect data, a complete architecture or an enterprise-wide policy before testing a useful application. That is not the purpose of the stage. The organisation should use bounded experiments to test the assumptions behind its foundation work. A contract-intelligence pilot might reveal that document metadata matters less than clause standardisation. A sourcing assistant might expose workflow and stakeholder issues before integration becomes the primary constraint.

Leadership priority

The CPO should connect every foundation investment to a defined use-case portfolio. The objective is not to “become AI ready” in the abstract. It is to build the capabilities required for specific procurement outcomes while retaining the ability to adapt as evidence emerges.

Hard gate to Stage 3

A function should not claim Managed Experimentation until selected pilots have:

• a defined business problem and accountable owner;
• documented success, risk and stop criteria;
• an approved environment and data route;
• sufficient process and data understanding for the test;
• explicit human-review and escalation requirements;
• supplier and technical dependencies identified;
• a baseline and measurement plan;
• a role-based adoption and capability plan;
• a decision process for progression, redesign or termination.

A pilot without a stop criterion is activity, not managed experimentation.

At Stage 3, pilots are directed, bounded and designed to generate decision-quality evidence. The difference from Stage 1 is not simply the number or sophistication of experiments. It is the discipline with which they are selected, operated and evaluated.

What it looks like

Common characteristics include:

• experiments have defined users, data populations, workflows and risk boundaries;
• use cases are prioritised against value, feasibility, risk and organisational capacity;
• users receive role-specific training and review guidance;
• corrections, exceptions and failures are captured;
• technical and supplier dependencies are actively assessed;
• outcomes are compared with a baseline;
• governance decisions and material changes are recorded;
• unsuccessful use cases can stop without being reframed as success;
• learning feeds into data, process, contract and control design.

What good experimentation produces

A strong pilot does not merely answer “does the tool work?” It should establish:

• where it works and where it does not;
• the data and process conditions it requires;
• the level and type of human review needed;
• how users respond in practice;
• the corrections, exceptions and risks created;
• the full support and administration burden;
• the measurable outcome relative to the current process;
• what would need to change for replication.

Typical procurement example

A sourcing assistant generates market summaries and draft event documents for a defined category team. Usage is high and users report time savings. A mature experiment would also test:

• source reliability and citation quality;
• whether users verify market claims;
• whether stakeholder input and approvals become faster;
• the amount of rework required;
• whether the time released changes category outcomes;
• whether the workflow remains effective with less digitally confident users;
• whether supplier or market data can be used within approved terms.

Without that evidence, strong adoption may still coexist with weak end-to-end value.

Leadership priority

The CPO must make explicit decisions. Each pilot should progress, be redesigned, remain bounded or stop. The portfolio should not become a waiting room in which every experiment survives because the programme needs positive stories.

Hard gate to Stage 4

A use case should not move into Controlled Scaling until it can evidence:

• sustained use by the intended users;
• measurable operational improvement against baseline;
• acceptable quality, correction and risk performance;
• demonstrated human-review and escalation controls;
• adequate logging, monitoring and incident handling;
• supplier assurance and contractual controls proportionate to the risk;
• accountable production ownership and support;
• a credible full-cost case for expansion;
• no critical unresolved legal, security, data or adoption constraint;
• clear conditions defining the next scope and where scale should stop.

This is the most important gate in the model. It separates evidence-generating experimentation from live operational expansion.

At Stage 4, selected use cases are being expanded or replicated through governed operating processes. Scale is not interpreted as universal deployment. It is a controlled increase in scope, volume, users, categories, regions or decision significance.

What it looks like

Common characteristics include:

• AI is integrated into live procurement workflows rather than operating solely beside them;
• reusable controls and stage gates apply across multiple use cases;
• data, identity and architecture support repeatable operation;
• production ownership, administration and support are established;
• adoption is measured over time, not only at launch;
• benefits and full operating costs are reviewed;
• portfolio governance shifts resources towards stronger applications;
• weaker use cases can be redesigned or retired;
• regional, legal and process variations are managed explicitly;
• supplier and model changes trigger reassessment where necessary.

The main risk: over-generalising local success

A successful use case can depend on conditions that will not survive replication:

• an unusually experienced team;
• a carefully curated data set;
• intensive manual support;
• a narrow contract or supplier population;
• low transaction volume;
• a cooperative stakeholder group;
• pilot-specific supplier concessions;
• a jurisdiction with simpler legal requirements.

Controlled Scaling requires the organisation to identify which conditions are intrinsic to the solution and which are temporary supports.

Supplier AI becomes an operating capability

At this stage, supplier assurance cannot end at contract award. The ICO’s AI audit framework highlights contractual roles, data-processing terms, audit rights and the need to reconsider performance as systems and information change. The UK Government’s AI Management Essentials asks organisations to maintain AI-system records and obtain relevant documentation from third-party providers. For procurement, this means monitoring:

• model providers and subprocessors;
• data use, location and retention;
• material functionality or model changes;
• performance and incident obligations;
• assurance evidence;
• audit and investigation rights;
• intellectual-property and liability allocation;
• continuity and exit arrangements.

Leadership priority

The CPO should expand only where shared capabilities can support the new scope. The goal is to preserve the controls and evidence that made the initial use case successful while reducing dependence on exceptional local effort.

Hard gate to Stage 5

A function should not claim Orchestrated or Adaptive maturity until it can evidence:

• repeatable lifecycle management across multiple use cases;
• portfolio governance with active optimisation and retirement;
• reliable operational telemetry and outcome measurement;
• embedded changes to roles, workflows and decision rights;
• sustained adoption across intended populations;
• continuous monitoring of suppliers, models and material changes;
• organisational learning from incidents, corrections and performance variation;
• value sustained beyond initial programme support;
• the ability to adapt controls and processes as risk and technology change.

Stage 5 requires more than scale. It requires a system capable of learning and adjusting.

At Stage 5, AI is part of a governed, connected and continually improving procurement operating model. This is not a state of maximum automation. Nor does it mean that AI makes every decision. Mature organisations use automation selectively and retain human judgement where commercial complexity, accountability or uncertainty demands it.

What it looks like

Common characteristics include:

• multiple use cases operate through a coherent decision and data architecture;
• human and machine responsibilities are explicit and regularly reviewed;
• governance is proportionate to use-case risk and supported by operational evidence;
• performance, adoption, exceptions and incidents are visible across the portfolio;
• data, models, prompts, integrations and supplier dependencies are managed through their lifecycle;
• lessons from failures and corrections inform process and control design;
• underperforming applications are redesigned or retired;
• value is assessed at process and portfolio level;
• the organisation can absorb model, supplier and regulatory change without reverting to unmanaged local practices.

What adaptive maturity is not

It is not:

• an autonomous procurement function with no meaningful human involvement;
• a permanent label that no longer requires reassessment;
• a portfolio in which every process uses AI;
• evidence that every category or region has identical capability;
• immunity from model drift, supplier risk or control failure.

Maturity is demonstrated by the ability to respond effectively when those conditions change.

Leadership priority

The CPO’s focus shifts from deployment to portfolio optimisation and institutional resilience. Questions include:

• Which use cases still justify their cost and control burden?
• Where has performance or adoption declined?
• Which decisions require stronger human judgement?
• Which supplier changes alter the risk profile?
• Where can common capabilities reduce duplication?
• Which applications should stop?

A mature function does not protect every AI investment. It protects the quality of the operating model.

The five stages describe progression. The following eight capabilities explain what is progressing. Each should be assessed independently before an overall stage is assigned.

This capability covers outcomes, ownership, decision rights, portfolio governance and operational accountability. Evidence should answer:

• Which procurement outcomes is AI intended to improve?
• Who approves, owns, supports and can stop each use case?
• How are use cases prioritised against value, feasibility, risk and capacity?
• Who owns performance after implementation?
• How are procurement, technology, legal, security, data, finance and HR decisions coordinated?

Early-stage organisations rely on sponsorship and project structures. Later-stage organisations maintain a governed portfolio with accountable production owners and explicit lifecycle decisions. Warning sign: a long use-case list with no sequencing, ownership or capacity model.

This capability covers data quality, ownership, lineage, access, unstructured information and integration. Evidence should answer:

• Which data sources and documents are required?
• Who owns them and how is quality measured?
• Can outputs be traced to current sources?
• What manual cleansing supports the workflow?
• Are permissions appropriate to the use case?
• Can the solution operate across relevant ERP, source-to-pay, contract, supplier and analytics systems?

Later maturity is not defined by perfect data. It is defined by predictable ownership, monitored quality and a scalable way to manage known limitations. Warning sign: a successful pilot depends on manually curated information that cannot be reproduced at greater volume.

This capability covers architecture, integration, identity, approved environments, administration, monitoring and resilience. Evidence should answer:

• Does the capability operate inside the workflow or require repeated copying between systems?
• Can access be controlled by role and data?
• Are outputs, model versions and material changes logged?
• Who administers and supports the service?
• How dependent is the function on one supplier or model?
• Can the organisation investigate failures and exit if necessary?

Later maturity involves a coherent architecture and reusable controls, not simply more tools. Warning sign: teams purchase overlapping AI products independently and exchange outputs through unmanaged email or documents.

This capability covers risk classification, approval, privacy, security, human review, logging, escalation and incident management. Evidence should answer:

• What decision is the AI supporting or influencing?
• What is the impact of an incorrect output?
• Which outputs require mandatory review?
• What must the reviewer examine?
• Are corrections and incidents recorded?
• Can the organisation explain how AI contributed to a procurement decision?

Later maturity is demonstrated when governance operates inside the workflow and adapts to risk, rather than existing only as a policy layer. Warning sign: “human in the loop” is repeatedly stated but the reviewer’s responsibility, evidence and authority are undefined.

This capability covers problem definition, prioritisation, workflow redesign, testing, production transition and retirement. Evidence should answer:

• Is AI addressing a defined operational or commercial problem?
• What changes in the end-to-end process?
• Which approvals, hand-offs or duplicate tasks are removed?
• What would cause the use case to stop?
• Does improvement in one task translate into process-level value?

Later maturity requires the function to redesign work rather than layer AI onto an unchanged process. Warning sign: users complete both the old and new workflow, so apparent time savings create no end-to-end benefit.

This capability covers role-specific competence, approved use, managerial reinforcement, psychological safety and sustained behaviour change. Evidence should answer:

• Can users frame tasks and verify outputs appropriately?
• Are approved tools used within the intended workflow?
• Do managers model the expected behaviour?
• Can employees challenge outputs and report failure safely?
• Have roles, workload and incentives changed?
• Does adoption continue after launch support ends?

Later maturity is demonstrated through observed capability and sustained behaviour—not training completion alone. Warning sign: the programme reports high completion rates while approved-tool usage and workflow adoption remain low. The separate KOR Procurement AI Adoption Model develops this dimension in detail.

This capability covers supplier due diligence, model and data transparency, subprocessors, contractual rights, monitoring and exit. Evidence should answer:

• Which models and third parties support the service?
• How is organisational data used, retained and protected?
• What can the supplier change without notification or approval?
• What assurance and performance evidence is available?
• Can incidents and outputs be investigated?
• What audit, continuity and exit rights exist?

Later maturity requires third-party AI to be governed throughout the contract lifecycle, not only during selection. Warning sign: strong controls apply to internal use, while procurement accepts opaque AI functionality under standard supplier terms.

This capability covers baselines, adoption-adjusted benefit, quality, risk, full cost and portfolio economics. Evidence should answer:

• What was the process performance before implementation?
• Which outcome is expected to change?
• How much theoretical benefit is realised at actual adoption levels?
• Are data, integration, review, governance, support and administration included in cost?
• Does value persist as the use case expands?
• Who verifies the result?

Later maturity requires finance-credible and operationally sustained value, combined with the willingness to stop weak applications. Warning sign: prompts, active users or documents processed are presented as business value.

An overall stage is useful for executive communication, but it can conceal material variation. A procurement function may have:

• Stage 4 technology and integration;
• Stage 3 use-case management;
• Stage 2 supplier assurance;
• Stage 2 adoption;
• Stage 1 value evidence.

Calling that function Stage 3 because the scores average together would miss the decision-relevant point. It is not ready to progress until the value, adoption and supplier-assurance gates are addressed. The assessment should therefore report:

1. the overall constrained stage;
2. the stage reached in each capability;
3. the specific hard gates preventing progression;
4. material variation by use case, region or process;
5. the confidence supported by available evidence.

A maturity stage can sound more precise than the underlying evidence allows. KOR therefore attaches one of three evidence-confidence levels:

Provisional

The conclusion is based mainly on surveys, interviews or management assertion. This is useful for orientation and identifying where deeper work is needed. It should not support major investment, benchmarking or a claim of verified maturity.

Substantiated

The conclusion is supported by relevant artefacts, such as:

• strategies and ownership records;
• policies and approval decisions;
• process maps;
• architecture and access controls;
• supplier contracts and assurance documents;
• training and role guidance;
• implementation and benefits plans.

Substantiated evidence demonstrates that capability has been designed or documented. It does not always prove that it operates consistently.

Verified

The conclusion is supported by operational, system or finance evidence, such as:

• workflow telemetry;
• approved-tool usage;
• logs, corrections and exceptions;
• incident and escalation records;
• measured process outcomes;
• observed control operation;
• finance-reviewed benefits and costs.

A function may provisionally appear to be at Stage 4 while verified evidence supports only Stage 2 or Stage 3. The separate KOR Evidence Confidence Model explains how to make that distinction.

Consider a multinational procurement function piloting AI-assisted contract review. The pilot is popular. Initial summaries are generated quickly, users report less administrative work and the supplier recommends expansion to five countries. The organisation might describe itself as being in Controlled Scaling. A maturity assessment finds:

• the pilot uses a curated English-language contract population;
• other regions store agreements across local repositories with inconsistent metadata;
• review quality depends on one experienced legal-operations specialist;
• higher-risk clause escalation is not yet documented;
• corrections and exceptions are handled manually and are not consistently logged;
• supplier terms do not provide sufficient clarity on material model changes;
• time savings are estimated, while downstream legal escalation and rework have no baseline;
• adoption outside the original team is unknown.

Stage assessment

The use case demonstrates some characteristics of Managed Experimentation. It has a defined application, active users and promising results. It has not passed the hard gate to Controlled Scaling because production review, evidence, supplier assurance, data repeatability and wider adoption remain unresolved.

Required progression evidence

Before expansion, the function should:

1. document review and escalation standards;
2. establish accuracy, correction, cycle-time and rework baselines;
3. test a deliberately different contract population;
4. define production ownership and support;
5. resolve supplier notification and assurance provisions;
6. improve repository and metadata conditions for the next scope;
7. assess capability and adoption in the receiving team;
8. agree explicit scale and stop criteria.

This is not a negative assessment. It converts enthusiasm into a credible route to progression.

High adoption without verified value

A sourcing assistant is used frequently and receives positive feedback. The function claims advanced maturity. However, users still obtain stakeholder input through fragmented email, approvals take the same time and the generated material requires extensive rework. Usage is real, but end-to-end value remains unverified. The maturity constraint is value and process redesign—not adoption.

Strong technology with weak supplier assurance

A supplier-risk platform uses advanced AI and integrates well with procurement systems. Alerts are embedded in supplier-management workflows. The supplier cannot provide adequate transparency over data sources, model changes or relevant subprocessors. Contractual audit and change-notification rights are weak. The maturity constraint is third-party assurance—not technology. These examples illustrate why the model does not allow strengths to average away the capability that controls the next decision.

1. Define the scope

State whether the assessment concerns:

• the whole procurement function;
• a region or business unit;
• a process such as sourcing or contracting;
• a platform;
• an individual use case.

Do not mix use-case and function-wide maturity without making the distinction explicit.

2. Gather perception data

Use surveys and interviews to understand leadership intent, operating experience, adoption barriers and capability differences. Treat those responses as evidence sources, not proof.

3. Examine operating artefacts

Review strategies, process maps, decisions, policies, architecture, data records, contracts, training, controls and benefits plans.

4. Review operational evidence

Where available, examine usage, workflow telemetry, logs, exceptions, incidents, performance, adoption, quality and financial outcomes.

5. Assess all eight capabilities

Record the stage supported by evidence in each dimension. Identify variation by region, process and use case.

6. Apply the hard gates

Determine which minimum conditions are absent. Do not calculate the overall stage as a simple average.

7. Rate evidence confidence

State whether each material conclusion is provisional, substantiated or verified.

8. Define the constrained overall stage

The overall stage should reflect the capabilities that control the next significant deployment decision.

9. Build a stage-exit roadmap

A useful roadmap specifies:

• the hard gate to be passed;
• the action required;
• the accountable owner;
• the evidence that will demonstrate completion;
• the decision enabled when the gate is passed;
• the date or trigger for reassessment.

This is more useful than a generic list of improvement initiatives.

It is not an industry standard

The five stages and hard gates are KOR’s proposed synthesis. They should be refined through practical application and evidence.

It is not a competition to reach Stage 5

The appropriate target depends on procurement strategy, risk, complexity and investment economics. Some processes should remain human-led. Some use cases should remain bounded. Some should not use AI.

It does not assume one stage across the organisation

Different regions, categories, processes and applications may sit at different stages. The assessment should expose that variation.

It does not replace use-case approval

A mature function can still propose a poor, unsafe or uneconomic use case. Each application needs its own value, feasibility, risk and supplier assessment.

It is not permanent

Maturity can decline. Adoption falls, data changes, suppliers update models, controls drift and key personnel leave. The stage should be reassessed after material change.

It does not remove leadership judgement

The model structures judgement and demands evidence. It does not replace accountability with a score.

KOR’s model cluster separates four decisions that are commonly confused:

• The Procurement AI Readiness–Realisation Matrix asks whether foundations are strong and whether adopted value is being realised.
• The Procurement AI Maturity Model asks how repeatable, governed and adaptive the capability has become.
• The Evidence Confidence Model asks how strongly the conclusion is supported.
• The Procurement AI Adoption Model asks whether people are using AI responsibly and sustainably within redesigned work.

The published overview, AI Readiness in Procurement: Why Pilots Do Not Mean You Are Ready to Scale, explains the relationship between the models. Together, they prevent a procurement function from being classified through a single, flattering number.

The number of AI pilots a procurement function runs is visible. The operating capability behind them is harder to see. That capability is demonstrated when the organisation can:

• choose the right use cases;
• prepare and govern the relevant data;
• integrate AI into workable processes;
• define human and machine responsibilities;
• support sustained adoption;
• assure third-party suppliers;
• measure outcomes and full cost;
• learn from failure;
• stop applications that no longer justify themselves.

A credible maturity model should reward those conditions—not the appearance of technological progress. The practical question for a CPO is therefore not, “How much AI are we using?” It is:

Which stage can we evidence, which hard gate currently constrains us, and what decision will become responsible when we pass it?

That is the difference between an AI programme that accumulates activity and a procurement function that develops controlled, adaptive capability.

What is a procurement AI maturity model?

A procurement AI maturity model assesses how consistently a procurement function can select, govern, integrate, adopt, measure and improve AI. KOR’s model uses five stages and hard gates so pilots, licences or strong technology scores cannot conceal material weaknesses in data, governance, adoption, supplier control or value evidence.

What are the five stages of procurement AI maturity?

The five stages are Reactive or Unready, Foundation Building, Managed Experimentation, Controlled Scaling, and Orchestrated or Adaptive Procurement AI. Progress depends on evidence that the defining operating conditions of the next stage are in place.

How is AI maturity different from AI readiness?

Readiness asks whether procurement has the foundations required for an intended deployment. Maturity asks how consistently those foundations have become repeatable, governed and improving ways of working across use cases and over time.

How should procurement assess its AI maturity?

The assessment should combine surveys and interviews with policies, process artefacts, architecture, supplier documentation, system usage, logs, exceptions, outcome measures and full operating costs. Each stage finding should also state whether its evidence is Provisional, Substantiated or Verified.

Why does the model use hard gates?

Hard gates prevent strengths in one area from numerically cancelling out a critical weakness elsewhere. A function should not claim Controlled Scaling, for example, if it cannot evidence sustained adoption, production ownership, human-review controls or measurable outcomes.