Practical perspectives
Is Your Procurement Data Ready for an AI Pilot?
A workflow-led data readiness check for procurement teams preparing an AI software pilot: records, quality, access, ownership and a safe first dataset.
On this page
A procurement AI pilot can fail before anyone evaluates the product: supplier records are duplicated, contract dates live in PDFs, purchase orders use inconsistent units, or the team cannot share the data the demonstration assumes.
“Clean all procurement data” is too large a starting point. Choose one workflow, identify the records it actually needs and make the gaps visible. This article offers a practical readiness check, not a requirement to build a perfect data warehouse before speaking with vendors.
1. Start with one decision and its input records
For a supplier quote comparison pilot, list the approved request, specifications, quote documents, supplier identifiers, price units, currency, delivery terms and award decision record. For contract obligation extraction, the relevant set is different: signed agreements, amendments, party names, effective dates and the process that uses the extracted obligations.
Draw a simple path from source system to user decision. Who owns each record? Where is the authoritative version? How does a correction get back into the source? A demonstration that uses a hand-built spreadsheet may still be useful, but should not be mistaken for proof that the live workflow is ready.
The UK guidelines for AI procurement ↗ advise buyers to assess data availability and governance before selecting an AI system. The amount of preparation depends on the job: a read-only document search and an automated supplier action need different data and controls.
2. Inventory the smallest useful dataset
Use a small set of real, appropriately redacted cases. Include ordinary records and the exceptions that make the current process difficult. Ask the process owner to explain what a correct output would show, including facts that cannot be inferred from the records.
| Input | Readiness question | If the answer is no |
|---|---|---|
| Supplier identity | Can quotes be tied to the correct supplier or legal entity? | Map duplicate names and keep unresolved identities out of automated actions. |
| Item and unit | Are quantities, pack sizes and units recorded consistently? | Create a conversion rule only where a source supports it; flag the rest. |
| Price and terms | Can currency, taxes, freight and payment terms be separated? | Show the missing components instead of ranking incomplete totals. |
| Dates | Are requested and offered delivery dates comparable? | Record the ambiguity and request clarification. |
| Decision history | Is the award rationale and approval accessible? | Use the pilot to test output quality, but do not claim a historic decision was reproduced. |
| System handoff | Can corrected results return to the approved sourcing record? | Record the manual step and its owner in the pilot cost. |
This worksheet is an example. A supplier-risk or spend-analysis pilot needs a different inventory. Keep only fields needed for the chosen question; extra sensitive data does not improve a trial simply because it is available.
3. Check quality where it changes the outcome
The Government Data Quality Framework ↗ separates completeness, uniqueness, consistency, timeliness, validity and accuracy. Apply those dimensions to decision-critical fields. A supplier record can be complete but wrong; a quote can be accurate at capture and stale by the time a buyer acts.
- Completeness: are the fields needed for the task present in each case?
- Uniqueness: do duplicate supplier or item records change the result?
- Consistency and validity: do units, currencies, dates and identifiers follow usable rules?
- Timeliness and accuracy: is the source current enough, and can a reviewer check it against the original record?
Document what the team corrected, what it excluded and what remains unknown. A pilot should show how the product behaves when a value is missing, not only after the dataset has been polished for a demo.
4. Agree access, sharing and correction boundaries
Before uploading supplier quotes, contracts, employee records or pricing, ask the appropriate internal owners what may be used in the trial. Decide whether to use synthetic, redacted or live data; who can view it; where it is processed; how long it remains; and how it can be deleted or exported. Record any limitations that prevent the trial from representing production.
Ask the vendor to show role permissions and the path for a human correction. If the tool drafts a supplier message or changes a record, identify the person who approves the action and the system that retains the final decision. A good answer should describe the current product and proposed configuration, not only a security slide.
The NIST AI Risk Management Framework ↗ links context, measurement and governance throughout an AI system’s use. In procurement terms, readiness includes the people and controls around the data, not just file format.
5. Choose a narrow go, repair or stop decision
A team is ready for a narrow pilot when it can provide representative cases, identify authoritative sources, permit the agreed data use, name reviewers and define what the output must contain. It may still have imperfect data. The pilot can measure how well the product flags those imperfections.
If a critical source is unavailable, an identity field cannot be trusted, or trial sharing is not approved, repair that dependency first or test a smaller, lower-risk slice. Record the gap rather than asking a vendor to work around it invisibly. After the readiness check, use the same cases in our real-workflow pilot method. To research possible products, browse the AI procurement software guide.
Keep the readiness worksheet beside the pilot result. It explains whether a weak outcome came from product behaviour, missing inputs, a configuration dependency or a process the team has not yet agreed.