The Procurement AI Readiness–Realisation Matrix: How to Decide Whether AI Is Ready to Scale

A procurement team pilots an AI contract-review tool. The early results look convincing. Summaries are produced more quickly, users report less administrative work and the supplier is pressing for a wider rollout.

The CPO is then asked the question that sits behind almost every procurement AI programme:

Are we ready to scale it?

A conventional business case may compare licence cost with estimated hours saved. A maturity questionnaire may ask whether the organisation has an AI strategy, executive sponsorship and access to usable data. The pilot report may record enthusiastic feedback and several successful demonstrations.

None of those answers, on its own, resolves the decision.

The tool may be producing useful results within one controlled team while the wider procurement function still has fragmented contract repositories, inconsistent clause standards, unclear human-review rules and no reliable way to monitor corrections or exceptions. Another organisation may have invested heavily in data, governance and architecture but deliberately limited deployment until the right use cases and controls are in place.

Those two organisations should not receive the same diagnosis. Nor should the second automatically be judged less advanced because it has fewer live use cases.

The Procurement AI Readiness–Realisation Matrix is designed to expose that difference. It separates two questions that are too often collapsed:

• Readiness: Does the procurement function have the organisational foundations required to deploy and scale AI repeatedly and responsibly?
• Realisation: Are adopted AI use cases producing measurable procurement outcomes?

KOR’s central argument is that readiness and realised value are related, but independent. Procurement can be well prepared before significant value appears. It can also produce value from selected use cases while remaining unready for wider deployment.

That distinction matters because scale decisions fail when leaders mistake local success for organisational capability—or mistake disciplined foundation-building for a lack of progress.

KOR proposed framework: The Readiness–Realisation Matrix is KOR’s synthesis of procurement AI maturity research, enterprise-readiness models and responsible-AI governance approaches. It is a practical decision framework, not an industry standard or statistically validated benchmark.

A procurement AI readiness matrix is a decision framework that compares the organisational capability required to deploy AI responsibly with the value already being produced in live procurement work.

KOR’s model uses two independent axes because those conditions do not always develop at the same rate. A function may have strong data, governance and operating foundations but limited live value. Another may achieve useful results in a bounded pilot while remaining unprepared for wider deployment.

The matrix is therefore not a replacement for a maturity model. It answers a different question: given the relationship between current readiness and current realisation, what should procurement do next?

Procurement leaders have strong incentives to demonstrate visible progress. Pilots, licences, workshops and use-case pipelines are easy to count. They create tangible evidence that a function is responding to the AI agenda.

But visible activity can exist around the edge of an unchanged operating model.

The Hackett Group reported in its 2025 Procurement Key Issues Study that approximately 49% of procurement teams had piloted generative AI use cases, while only 4% reported large-scale deployment. Its 2026 research described rapidly increasing deployment alongside the need for operating-model, governance and talent redesign.

Research by GEP and the University of Virginia’s Darden School similarly identified a gap between experimentation and enterprise scale, arguing that operational discipline—not access to technology alone—separates organisations that move beyond pilots. The Supply Chain AI Readiness Report places particular emphasis on foundations, operating discipline and organisational capability.

Pilots are still necessary. They help teams test feasibility, risk, user response and potential value before committing to wider investment. The mistake is allowing a pilot to answer a question it was not designed to answer.

A pilot may establish that:

• a model can perform a task under defined conditions;
• users see potential value;
• a selected data set is adequate for a limited test;
• a technical integration is possible;
• a supplier can demonstrate useful functionality.

It does not automatically establish that:

• the relevant data is reliable across the function;
• the process is sufficiently standardised across categories or regions;
• controls will operate at greater volume;
• users outside the pilot team will adopt the workflow;
• supplier and model risks are understood throughout the contract term;
• benefits will survive the full cost and complexity of scale.

The same applies to software ownership. Purchasing an AI-enabled procurement platform proves that a capability has been acquired. It does not prove that the organisation can operate it well.

A conventional maturity curve implies a single direction of travel. In practice, procurement functions can be highly active without being well prepared, or well prepared before they have produced significant live value.

The Readiness–Realisation Matrix therefore uses two independent axes.

Readiness: the foundations for repeatable scale

Readiness asks whether the function can select, govern, integrate, adopt, measure and improve AI without creating disproportionate operational, commercial or regulatory risk.

It includes the condition of:

• strategy and operating ownership;
• data and interoperability;
• technology and orchestration;
• governance and human oversight;
• use-case and process design;
• people, skills, adoption and trust;
• supplier and third-party AI control;
• value measurement and scale economics.

Readiness is not theoretical perfection. An organisation does not need every data problem solved or every process globally standardised before it can proceed. It does, however, need sufficient capability for the scope and risk of the intended deployment—and a credible way to manage what remains unresolved.

Realisation: adopted use cases producing measurable outcomes

Realisation asks whether AI is operating in practice and improving procurement outcomes.

Relevant outcomes may include:

• reduced cycle time;
• lower process cost;
• capacity released for higher-value commercial work;
• improved compliance;
• reduced leakage;
• earlier identification of contractual or supplier risk;
• improved decision quality;
• better stakeholder or supplier experience.

Realisation requires more than output generation. A system may produce technically impressive analysis that users do not trust, cannot incorporate into the workflow or must extensively rework. A use case may save time in one task while leaving the end-to-end process unchanged.

The benefit should therefore be:

1. Adopted by the intended users.
2. Observable in the relevant process.
3. Measured against a credible baseline.
4. Sustainable after implementation support is withdrawn.
5. Economically credible once integration, data, change, governance and administration costs are included.

Canonical internal filename: procurement_ai_readiness_matrix_diagram.png

Alt text: The KOR Procurement AI Readiness–Realisation Matrix plotting organisational readiness against measurable AI value across Foundation Building, Embedded Value, Unprepared Experimentation and Controlled Scaling.

The two axes create four positions:

• Unprepared Experimentation
• Foundation Building
• Controlled Scaling
• Embedded Value

They are not four mandatory steps in a linear journey. They describe the relationship between current organisational preparedness and current realised value. A function can move between them as its portfolio, controls and business conditions change.

Unprepared Experimentation combines lower organisational readiness with limited realised value.

The organisation may appear highly active. Multiple pilots are running, individual employees use general-purpose tools and procurement platforms are introducing AI-enabled functions. Yet the activity remains disconnected from a coherent operating model.

What it looks like

Typical characteristics include:

• use cases emerge opportunistically rather than from a prioritised portfolio;
• ownership is dispersed across procurement, technology and suppliers;
• teams use different tools and methods without common approval or monitoring;
• data preparation depends on manual work and local knowledge;
• human review is expected but not defined;
• users receive generic training rather than process-specific guidance;
• supplier data practices, model providers and update mechanisms are not fully understood;
• benefits are expressed through anecdotes, demonstrations or estimated hours saved;
• unsuccessful pilots continue because stopping them would be interpreted as programme failure.

The principal risk

The main risk is false confidence. The organisation has enough activity to create a persuasive progress narrative, but not enough evidence to support wider deployment.

Scaling in this position can magnify existing weaknesses. An informal workaround used by five experienced category managers may become an operational failure when applied across hundreds of users, multiple jurisdictions or higher-risk decisions.

The appropriate leadership decision

The response is not necessarily to stop all experimentation. It is to make experimentation deliberate.

CPOs should:

• create an inventory of current use cases, tools and embedded supplier functionality;
• define accountable owners;
• distinguish prohibited, experimental and approved uses;
• select a smaller portfolio of decision-useful pilots;
• establish baselines, human-review rules, risk boundaries and stop criteria;
• resolve the most material data and supplier issues;
• gather evidence that can support the next decision.

The objective is to move from activity to learning.

Foundation Building combines stronger organisational readiness with limited realised value.

This position is often undervalued because it may produce fewer stories of immediate success. The function is strengthening data, governance, architecture, skills and ownership before expanding deployment.

What it looks like

Typical characteristics include:

• executive intent is connected to defined procurement outcomes;
• use cases are prioritised against value, feasibility, risk and organisational capacity;
• accountable owners and decision rights are established;
• data constraints and remediation priorities are understood;
• approved experimentation environments and review standards exist;
• supplier-assurance and contracting requirements are being developed;
• affected roles and workflows are being redesigned;
• baselines and success measures are agreed before deployment;
• pilots are selective and designed to test critical assumptions.

The principal risk

The risk is preparation without learning. Organisations can over-engineer enterprise foundations, waiting for perfect data or a complete technology architecture before testing a real use case.

That approach delays value and can produce controls designed without enough understanding of how the technology behaves in practice.

The appropriate leadership decision

Foundation Building should combine disciplined preparation with bounded experimentation.

CPOs should:

• identify use cases that test the most important dependencies at manageable risk;
• avoid broad deployment before ownership and review expectations are clear;
• link foundation work to an explicit use-case roadmap;
• establish stage-exit evidence rather than open-ended transformation activity;
• recognise that fewer pilots can represent stronger progress when they are better governed and more informative.

A procurement function in Foundation Building may be better positioned for sustainable scale than a more visibly active peer.

Controlled Scaling combines meaningful realised value from selected use cases with uneven function-wide readiness.

This position requires careful interpretation because it sits in the higher-realisation, lower-enterprise-readiness area of the matrix. It does not mean the live use cases themselves are uncontrolled. It means they are succeeding within defined boundaries while wider organisational foundations remain inconsistent.

What it looks like

Typical characteristics include:

• one or more use cases operate successfully in live workflows;
• intended users have adopted the tools and outcomes are measured;
• human review, escalation and monitoring operate within the use-case boundary;
• experienced teams compensate for wider data or process weaknesses;
• local integrations or manual support make the workflow viable;
• shared enterprise capabilities are not yet consistent across categories, regions or systems;
• supplier assurance is adequate for the selected deployment but not standardised across the portfolio;
• leaders face pressure to replicate success faster than common foundations can support.

The principal risk

The risk is over-generalisation.

A successful contract-review use case in one jurisdiction does not prove readiness across every contract type, language or legal regime. A sourcing assistant adopted by one digitally confident team does not establish that the wider function has the same skills, data or managerial support.

Local success may depend on conditions that disappear at scale:

• exceptional subject-matter experts;
• manual data cleansing;
• intensive programme support;
• a cooperative stakeholder group;
• narrow document populations;
• low transaction volume;
• supplier concessions negotiated for the pilot.

The appropriate leadership decision

The correct response is selective expansion, not automatic enterprise rollout.

CPOs should:

• document which conditions made the use case successful;
• distinguish use-case readiness from function-wide readiness;
• preserve existing controls during expansion;
• test replication across a deliberately different population;
• resolve shared data, identity, architecture and adoption constraints;
• define where scale should stop until further evidence is available;
• avoid weakening human review merely to achieve greater volume.

Controlled Scaling is a legitimate and potentially valuable position. It becomes dangerous only when bounded success is used to imply universal readiness.

Embedded Value combines stronger organisational readiness with sustained, measurable outcomes.

AI has moved beyond isolated projects and become part of repeatable procurement operations. The organisation can govern, monitor and improve multiple use cases through a coherent operating model.

What it looks like

Typical characteristics include:

• use cases are integrated into defined procurement workflows;
• data, identity and technical controls support repeatable operation;
• human and system decision rights are explicit;
• adoption is sustained across intended user groups;
• performance, exceptions and incidents are monitored;
• value is measured against baselines and reviewed with finance where appropriate;
• supplier models, subprocessors and material changes are monitored through the contract lifecycle;
• the use-case portfolio is actively prioritised, redesigned and retired;
• lessons from failures and corrections inform governance and process design.

The principal risk

The risk is control drift and complacency.

Embedded use creates dependence. Models change, suppliers alter their technology stacks, data quality shifts and users develop new workarounds. A control that was appropriate at launch may become insufficient as the use case expands or the underlying model changes.

Maturity is not an endpoint of maximum automation. It is the capability to keep the system effective, proportionate and aligned with procurement outcomes.

The appropriate leadership decision

CPOs should:

• maintain active portfolio governance;
• compare realised value with continuing cost and risk;
• review model, supplier and data changes;
• retire use cases that no longer justify their operating burden;
• preserve human judgement in complex commercial decisions;
• reassess readiness when entering new processes, regions or risk categories.

The matrix position should not be based on a single broad impression. KOR assesses readiness across eight connected capabilities.

A weakness in one capability may constrain the scale decision. The purpose is not to produce the most flattering average score. It is to identify the dependencies that determine what the organisation can responsibly do next.

This capability examines whether AI activity is connected to procurement strategy and supported by clear ownership, decision rights and operating capacity.

What to assess

• connection between use cases and procurement outcomes;
• executive sponsorship and operational ownership;
• decision rights across procurement, technology, legal, security, data and finance;
• prioritisation of the use-case portfolio;
• lifecycle ownership after implementation;
• capacity to support change, administration and ongoing review.

Questions to ask

• What specific commercial or operational problem is the use case intended to solve?
• Who can approve, pause or stop it?
• Who owns the process and outcome after the implementation team leaves?
• How are use cases prioritised against value, feasibility, risk and organisational capacity?
• What existing work will change or stop if the use case succeeds?

Strong evidence

• documented ownership and decision rights;
• a prioritised portfolio with explicit assumptions;
• stage gates and stop criteria;
• governance forums that make recorded decisions;
• resourcing for production operation, not only implementation.

Warning signs

• a long use-case list with no sequencing;
• sponsorship without accountable operational ownership;
• technology teams owning business outcomes by default;
• pilots continuing because nobody has authority to stop them;
• AI activity disconnected from procurement strategy.

Implication for scale

Without clear ownership and portfolio discipline, expansion creates fragmented accountability. The organisation may be able to run experiments, but it cannot reliably manage a scaled portfolio.

AI readiness depends less on whether an organisation possesses data than on whether the required data is usable, accessible, traceable and suitable for the intended decision.

What to assess

• data quality, ownership and lineage;
• taxonomy consistency;
• access, permissions and retention;
• unstructured documents and communications;
• integration across source-to-pay, ERP, contract, supplier and analytics systems;
• manual preparation required before data becomes usable.

Questions to ask

• Which data sources are required, and who owns them?
• How complete and current are they for the intended scope?
• Can an output be traced back to its source?
• Are contracts, specifications and supplier records stored consistently?
• What manual cleansing or reconciliation supports the pilot?
• Will that effort remain viable at greater volume?

Strong evidence

• named data owners;
• quality measures and remediation plans;
• documented lineage and access controls;
• tested integrations;
• reliable document repositories and metadata;
• monitoring of data failures and exceptions.

Warning signs

• a successful pilot depends on a hand-curated data set;
• users repeatedly upload local spreadsheets or documents;
• permissions are broader than the process requires;
• outputs cannot be traced to current source information;
• regions use incompatible taxonomies or clause standards.

Implication for scale

AI can tolerate some data imperfection, but scale requires predictable access, ownership and quality. Manual work hidden inside a pilot often becomes the largest barrier to replication.

A procurement function may own several capable tools and still lack a coherent technical environment for AI.

What to assess

• fit with the existing procurement architecture;
• APIs and integration options;
• identity and access management;
• approved experimentation and production environments;
• logging, monitoring and administration;
• model and version management;
• portability, resilience and supplier dependency.

Questions to ask

• Does the tool operate inside the workflow or require repeated copying between systems?
• Can access be controlled by role, data and use case?
• Are outputs and model changes logged?
• Who administers the system after implementation?
• How will the organisation respond if the supplier changes model provider, functionality or price?
• Can the use case be monitored at the required level of detail?

Strong evidence

• architecture and integration documentation;
• tested access controls;
• production monitoring and support arrangements;
• traceable configuration and model changes;
• clear administration ownership;
• resilience and exit considerations.

Warning signs

• teams buy or configure tools independently;
• important outputs move through email or unmanaged documents;
• the pilot uses elevated permissions that cannot be retained;
• nobody owns monitoring or incident response;
• the business case excludes integration and administration.

Implication for scale

A collection of individually useful tools can create more work and risk than value. Readiness requires enough orchestration to make outputs traceable and workflows repeatable.

Governance is credible only when it operates inside the workflow. A high-level policy does not establish how a buyer, category manager or contract professional should review a specific AI-assisted output.

NIST’s AI Risk Management Framework organises AI risk activity around Govern, Map, Measure and Manage. ISO/IEC 42001 similarly treats AI governance as a management-system capability rather than a one-off policy exercise.

What to assess

• use-case approval and risk classification;
• privacy, security and legal review;
• human-review and escalation rules;
• logging, auditability and incident management;
• accountability for decisions and errors;
• proportionality of controls to the use-case risk.

Questions to ask

• What decision is the AI supporting or influencing?
• What happens when its output is wrong?
• Which outputs require mandatory human review?
• What evidence must a reviewer consider?
• Are corrections and incidents recorded and used to improve the system?
• Can the organisation explain how an output informed a procurement decision?

Strong evidence

• risk-based approval records;
• documented review and escalation standards;
• operational logs and incident processes;
• observed control testing;
• accountability that remains clear across human and supplier roles.

Warning signs

• reliance on an AI policy without operating controls;
• “human in the loop” is stated but not defined;
• reviewers approve outputs without time, evidence or capability;
• incidents are handled informally;
• every use case receives the same controls regardless of risk.

Implication for scale

A policy cannot absorb the risk created by greater volume, wider access or more consequential decisions. Governance must be designed for the actual process.

Technical performance does not guarantee process value. Scaling an unreformed workflow can automate waste or simply move the bottleneck elsewhere.

What to assess

• quality of problem definition;
• value, feasibility and risk prioritisation;
• end-to-end process redesign;
• testing and success criteria;
• distinction between experiment, production and scale;
• lifecycle management and retirement.

Questions to ask

• Is AI addressing a defined bottleneck or merely adding functionality?
• Which steps, approvals or hand-offs will change?
• Has the process been redesigned around the new capability?
• What would cause the organisation to stop the use case?
• Does improvement in one task translate into an end-to-end benefit?

Strong evidence

• current and future process maps;
• measurable success and stop criteria;
• clearly bounded tests;
• removal of duplicate activity;
• production ownership and review cycles;
• evidence that the use case solves the intended problem.

Warning signs

• AI is layered onto an inefficient process;
• users complete both the old and new workflow;
• pilot success is defined as output quality alone;
• nobody measures downstream rework or delay;
• every experiment is assumed to progress.

Implication for scale

The process—not the tool—is the unit that ultimately creates value. A quicker document or analysis is useful only if it improves the wider commercial outcome.

A technically ready organisation can remain behaviourally unready. Adoption is not a communications workstream added after deployment; it is part of the scale decision.

What to assess

• role-specific capability;
• use of approved tools;
• confidence in reviewing outputs;
• calibrated trust;
• managerial reinforcement;
• psychological safety to challenge and report failure;
• role, workload and incentive redesign;
• sustained adoption over time.

Questions to ask

• Can users explain where the tool is reliable and where it is not?
• Are intended users applying it inside the target workflow?
• Do managers model the required behaviour?
• Can employees report mistakes or poor performance safely?
• Has time released been redirected towards higher-value work?
• Does adoption continue after launch support ends?

Strong evidence

• observed capability assessments;
• sustained approved-tool usage;
• correction and escalation behaviour;
• manager coaching and operational review;
• redesigned roles and measures;
• longitudinal adoption data.

Warning signs

• training attendance is the principal adoption measure;
• usage depends on a few enthusiasts;
• employees accept outputs blindly or duplicate everything manually;
• shadow AI remains widespread;
• managers promote AI but continue to reward the old process.

Implication for scale

Without changed behaviour, projected benefits remain theoretical. Weak adoption can also push employees towards unmanaged workarounds, increasing both cost and risk.

Procurement has two roles in the AI transition: it is a user of AI and a buyer of AI-enabled products and services. Those roles should not be governed separately.

The UK Government’s AI Management Essentials encourages organisations to maintain records of the AI systems they use and obtain relevant documentation from third-party providers. The ICO’s AI audit framework also emphasises due diligence and contractual controls when procuring AI-enabled services.

What to assess

• supplier and model-provider transparency;
• data usage, retention and location;
• subprocessors and dependencies;
• model updates and material-change notification;
• performance, audit and assurance evidence;
• intellectual-property and liability allocation;
• exit, continuity and ongoing monitoring.

Questions to ask

• Which models and subprocessors support the service?
• How is customer data used and retained?
• What changes can the supplier make without consent or notification?
• What performance and assurance evidence is available?
• Can outputs and incidents be investigated?
• What happens if the model, provider or commercial terms change materially?

Strong evidence

• proportionate AI due diligence;
• documented data and model flows;
• contractual notification and audit rights;
• performance and incident obligations;
• active monitoring after award;
• credible exit and continuity planning.

Warning signs

• reliance on standard software terms;
• the supplier cannot explain its model or subprocessor chain;
• due diligence ends at contract signature;
• material model changes do not trigger review;
• internal employee use is governed more rigorously than purchased AI.

Implication for scale

Third-party capability can change during the contract term. Procurement readiness must include the ability to select, contract with and monitor AI suppliers—not merely govern internal use.

A successful demonstration is not a business case. A use case that works technically may become unattractive once the full conditions of scale are included.

What to assess

• baseline and outcome definition;
• adoption-adjusted benefit;
• quality, risk and compliance outcomes;
• full implementation and operating cost;
• finance credibility;
• scalability of the economic case;
• portfolio prioritisation and retirement.

Questions to ask

• What was the process performance before deployment?
• Which outcome should change, and by how much?
• How much of the theoretical benefit is realised at actual adoption levels?
• Are integration, data preparation, governance, review and administration included?
• Does the value persist when the use case expands?
• Who verifies savings or capacity claims?

Strong evidence

• pre-implementation baselines;
• measured process and quality outcomes;
• finance-reviewed assumptions;
• full-cost analysis;
• adoption-adjusted benefit;
• periodic portfolio review and retirement decisions.

Warning signs

• prompts, users or documents processed are reported as value;
• time savings are based on estimates from enthusiastic users;
• implementation support is excluded from cost;
• benefit is assumed to scale linearly;
• underperforming use cases remain active to protect the programme narrative.

Implication for scale

Realisation must be economic and operational, not merely functional. A use case should be scaled because it produces a better procurement outcome at an acceptable cost and level of risk.

The matrix should not be completed as a quick perception survey. A credible position requires a defined scope and triangulated evidence.

1. Define the unit of analysis

State whether the assessment concerns:

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

This matters because a use case can be ready while the wider function is not. Mixing those scopes produces misleading results.

2. Gather perception data

Surveys and interviews provide breadth and context. They help identify differences between leadership intent and operational experience.

They should not be treated as proof. Respondents use terms such as established, integrated and adopted differently.

3. Examine operating artefacts

Relevant evidence includes:

• strategies and portfolio decisions;
• ownership and approval records;
• process maps and review standards;
• architecture and access controls;
• data-quality records;
• supplier documentation and contracts;
• training and role guidance;
• baselines and benefits plans.

4. Review operational evidence

Where available, examine:

• system and workflow usage;
• logs, corrections and exceptions;
• incident records;
• process performance;
• quality and compliance measures;
• finance-credible outcomes;
• full operating costs.

5. Assess readiness by capability

Evaluate the eight capabilities, identify contradictions and apply hard constraints. Do not allow a strong technology score to conceal weak governance or adoption.

6. Assess realisation

Evaluate adopted outcomes against a baseline. Distinguish demonstration performance, pilot results and sustained production value.

7. Apply evidence confidence

KOR’s Evidence Confidence Model separates:

• Provisional findings, based mainly on self-report;
• Substantiated findings, supported by documents or artefacts;
• Verified findings, supported by operational, system or finance evidence.

A precise-looking score supported only by perception data should not drive a major scale decision.

8. Plot the position and preserve variation

The overall position is useful, but capability variation must remain visible.

A function may sit close to Foundation Building overall while one contract use case is already in Controlled Scaling. Another may report Embedded Value in a narrow platform but lack verified adoption across the intended population.

Those differences should be recorded rather than averaged away.

9. Convert the result into decisions

The assessment should specify:

• which use cases should scale;
• which should remain bounded;
• which require redesign;
• which should pause or stop;
• which dependencies must be resolved;
• who owns each action;
• what evidence is required for reassessment.

Consider a multinational procurement function using AI to summarise and identify risk in supplier contracts.

The pilot team reports a reduction in initial review time. Users are engaged and the system performs well on a selected group of English-language agreements.

A wider assessment finds that:

• the pilot uses a curated contract repository with reliable metadata;
• other regions store contracts across shared drives and local systems;
• the pilot team has an experienced legal operations specialist who reviews exceptions;
• human-review rules are not yet documented for wider users;
• the supplier provides adequate data protections for the pilot, but material model-change rights remain unresolved;
• measured time savings exist, but downstream legal escalation and correction rates have not been baselined;
• adoption outside the original team is unknown.

How the matrix interprets it

At the use-case level, the pilot may be approaching Controlled Scaling: measurable value exists within a bounded workflow and active oversight is in place.

At the function level, readiness may remain closer to Unprepared Experimentation or early Foundation Building, depending on the strength of common governance, data and ownership.

The decision

The appropriate decision is neither a full stop nor an enterprise rollout.

Procurement should:

1. preserve the current pilot controls;
2. document the human-review and escalation model;
3. establish baseline accuracy, correction and downstream cycle-time measures;
4. test a deliberately different contract population;
5. resolve supplier change and assurance provisions;
6. improve repository and metadata conditions for the next scope;
7. assess adoption and capability in the receiving team;
8. agree the evidence required before further expansion.

This is a more disciplined answer than declaring the pilot simply “successful” or “not scalable”. It identifies the boundary within which value is credible and the conditions required to widen it.

The Readiness–Realisation Matrix has deliberate limits.

It is not a universal benchmark

The model does not claim that every procurement function should occupy the same position or pursue the same level of automation. Appropriate readiness depends on strategy, risk, process complexity and organisational context.

It is not a replacement for use-case assessment

A strong function-level position does not make every proposed use case appropriate. Each application still requires value, feasibility, risk and supplier assessment.

It is not a maturity staircase

The quadrants are not mandatory sequential stages. A function can move from Controlled Scaling towards Embedded Value as common foundations strengthen. It can also move backwards if adoption declines, controls drift or a supplier changes materially.

It is a snapshot with an evidence date

Readiness and realisation change. Assessments should record scope, date, evidence confidence and known limitations. They should be revisited after significant deployment, organisational or supplier changes.

It does not remove judgement

The matrix structures leadership judgement. It does not replace it with a single automatic answer.

The Readiness–Realisation Matrix is one part of a connected assessment system.

• AI Readiness in Procurement: Why Pilots Do Not Mean You Are Ready to Scale explains why pilot activity, organisational readiness, maturity and realised value must be distinguished.
• The Procurement AI Maturity Model explains how capability becomes increasingly repeatable and governed over time.
• The Evidence Confidence Model assesses how strongly a readiness or maturity conclusion is supported.
• The Procurement AI Adoption Model examines culture, calibrated trust and behaviour change in operational terms.
• Procuring AI Safely develops the third-party due-diligence and contracting requirements.
• From AI Pilot to Measurable Value develops the baseline, benefits and scale-economics discipline.

Together, they answer four different questions:

1. Are we prepared, and are we producing value?
2. How consistently have we converted capability into repeatable ways of working?
3. How credible is the evidence behind that conclusion?
4. Will people use the capability responsibly and sustainably?

The central mistake in procurement AI is not experimentation. It is allowing experimentation to answer a question it was never designed to answer.

A pilot can show that a tool works under certain conditions. It cannot, by itself, establish that the procurement function can reproduce the result across different data, teams, processes and risk environments.

The Readiness–Realisation Matrix makes that distinction visible.

It recognises that disciplined foundation-building can represent genuine progress before significant value appears. It also recognises that selected use cases can produce meaningful outcomes before the wider function is ready for enterprise scale.

For CPOs, the practical question is therefore not simply, “Did the pilot work?”

It is:

What value has been realised, within what boundary, supported by what organisational capability and evidenced strongly enough to justify the next decision?

That is the question that turns an AI programme from a collection of promising activities into a controlled procurement capability.

---

What is the purpose of a procurement AI readiness matrix?

It helps procurement leaders separate organisational preparedness from measurable AI value. This prevents pilot activity or isolated benefits from being mistaken for enterprise-wide readiness.

What are the four positions in KOR’s Readiness–Realisation Matrix?

The four positions are Unprepared Experimentation, Foundation Building, Controlled Scaling and Embedded Value. Each describes a different relationship between readiness and realised value and therefore requires a different leadership response.

How is an AI readiness matrix different from an AI maturity model?

A maturity model describes how organisational capability develops through stages. The readiness matrix plots current preparedness against current value, so it can show that a function is well prepared before major benefits appear or that a bounded use case is producing value before the wider function is ready to scale.

What evidence is needed to place a procurement function on the matrix?

Leaders should combine stakeholder interviews with policies, process artefacts, system records, supplier evidence, usage data, operational outcomes and finance-reviewed benefits where relevant. The confidence placed in the position should reflect the quality of that evidence.

Does high realised value mean procurement is ready to scale AI?

No. High value in one controlled use case may coexist with weak function-wide data, governance, adoption or supplier controls. The organisation should scale only within the boundary supported by its evidence and capability.

How often should the matrix be reassessed?

It should be revisited after material changes such as a new model or supplier, expansion into another process or region, a significant incident, deterioration in outcomes or completion of major readiness work.