You may not be buying AI
Your suppliers may be bringing it anyway

An AI purchase without an AI purchase order

An organisation can introduce AI into a consequential workflow without ever approving an AI purchase.

A mid-sized organisation commissions a consultancy to analyse 40,000 customer complaints. The contract promises experienced analysts, a rapid turnaround and a set of recommendations. It says nothing about artificial intelligence.

The consultancy uses a large language model to summarise the complaints, group themes and draft the findings. A subcontractor provides the interface. The underlying model changes during the engagement. Human analysts review a sample rather than every output.

No one has necessarily behaved improperly. The supplier has found a faster way to perform the work. The buyer, however, has skipped decisions it would probably have made had the service been sold as an AI system: which data may enter the model, how conclusions will be checked, how errors can be reconstructed, which third parties are involved, and who is accountable if a recommendation is wrong.

That is the emerging procurement blind spot. AI is no longer confined to the item on the purchase order. It may sit inside the method used to deliver it.

The 2021 warning that grew more relevant

In summer 2021, before generative AI became an everyday business tool, Mona Sloane, Rumman Chowdhury, John C. Havens, Tomo Lazovich and Luis C. Rincon Alba published AI and Procurement: A Primer through New York University. The report focused on public procurement in the United States and organised the problem around six tension points: definitions, process, incentives, institutional structures, technology infrastructure and liabilities.¹

Its regulatory snapshot is now dated. Its structural diagnosis is not.

The primer argued that a supplier's design choices can encode policy judgements; that procurement can create long-lived infrastructure and path dependency; that some problems only become visible after deployment; and that responsibility can be distributed across a chain of contractors, models, data and supporting services. It also identified an awkward alignment of incentives: buyers and vendors can both prefer a technological answer that looks fast, efficient and contractable, while procurement staff may receive little organisational reward for slowing the process to redesign its controls.

The primer is now most interesting where it is most dated. It largely imagined an organisation buying an identifiable AI system. Generative AI has made it easier to import the same tensions without calling the transaction AI procurement at all.

Three ways AI crosses the procurement boundary

Supplier AI can enter through at least three routes.

Bid preparation. A supplier may use a model to draft or improve its tender, with possible consequences for accuracy, confidential information and the credibility of promised capability.

The product itself. An ordinary product may acquire AI features such as transcription, translation, classification, recommendation or automated support.

The delivery method. A consultancy, law firm, recruitment company, managed service, agency or outsourced operations provider may use AI internally to perform work that the buyer still understands as a conventional professional service.

These routes are not equally risky. A spelling suggestion in a bid is not equivalent to using a model to rank applicants, formulate legal advice or summarise sensitive case files. The useful boundary is materiality: can the AI use affect confidential data, consequential conclusions, service quality, rights, security, accountability or the ability to challenge a result?

The rules are beginning to notice the invisible service

UK public procurement guidance now states the problem directly. Procurement Policy Note 017, updated in February 2025, applies to central government departments and related in-scope bodies. It does not prohibit suppliers from using AI in tendering. Instead, it recommends proportionate disclosure, controls over confidential information and due diligence. More importantly, it warns that AI and machine learning are becoming increasingly prevalent in the delivery of services that are not presented as AI services, and suggests requiring suppliers to declare that use where it is likely to matter.²

The note gives a deliberately ordinary example: a video-conferencing service may include AI-based transcription or live translation. That feature changes questions about how meeting records are handled and whether the information may be used to train further models. The service is still video conferencing. Its data and governance surface has changed.

The United States Office of Management and Budget reached a similar conclusion in Memorandum M-25-22. Its full acquisition rules do not treat every incidental use of AI by a contractor as a deliberate AI acquisition. Yet the memorandum separately warns that vendors will increasingly use AI in contract performance where the government may not anticipate it, and tells agencies to decide when disclosure provisions are warranted.³

For AI systems and services that are deliberately acquired, the same memorandum points towards the controls that matter once AI is visible: data and model portability, information about subcontractors, ongoing testing and monitoring, notification of new AI features, and the ability to roll back or reconsider use when performance changes.

NIST's voluntary cross-sector Generative AI Profile broadens the signal beyond government. It describes generative AI value chains as combinations of third-party datasets, pre-trained models, APIs, plug-ins and services, and notes that failures can be difficult to attribute to one component. It recommends due diligence for embedded AI, clear contracts and evaluation rights, inventories of third parties, continuous monitoring, incident response and fallback planning.⁴

The UK Government's AI Playbook adds the practical buying questions: understand the supplier's AI approach, consider vendor lock-in, integration, ongoing support, hidden costs, intellectual-property rights and acceptable liabilities.⁵

None of these public-sector documents creates a universal legal duty for every private organisation. Taken together, however, they are a clear management signal. Serious buyers are moving from a narrow question - What AI are we buying? - to a wider one: Where can AI enter this service, and what must remain under our control?

Disclosure is only the first control

A yes-or-no question about AI is too blunt. As AI features spread, almost every supplier may eventually have to answer yes. The useful question is not whether AI exists somewhere in the service. It is where it materially affects the work, the data, the judgement or the dependency.

A contract that only requires disclosure manages awareness, not control. Five further controls are needed.

1. See it. Map the tasks, models, providers, APIs, plug-ins and subprocessors involved. The buyer should know where AI influences delivery, not merely that the supplier has an AI policy.

2. Bound it. Define approved purposes and data boundaries. Specify whether organisational, customer or personal data may enter external systems, be retained, be used for training or be repurposed.

3. Test it. Require evidence that the service works in the buyer's context. Identify who validates outputs, what is sampled, which failure modes are measured and when a human must override or escalate.

4. Trace and change it. Preserve enough version, source, testing and incident information to reconstruct material outputs. Require notification when models, features, data sources or subcontractors change.

5. Leave it. Plan for rollback, manual fallback, continuity, portability, data return or deletion, transition support and termination. A dependency is not controlled if the buyer cannot exit it.

The easiest failure is mutual convenience

The 2021 primer's incentives section deserves particular attention. It observed that buyer and vendor incentives can converge around speed and a plausible technological solution, while procurement professionals may be rewarded for completing the transaction rather than redesigning the process around emerging risk.

The same pattern can appear beyond government. The supplier sees AI as an internal delivery method and may prefer not to complicate the sale. The buyer wants the service delivered quickly and may prefer not to turn an ordinary contract into an AI-governance exercise. Neither side needs to deceive the other. It is enough that nobody asks a question likely to slow the deal.¹

This is why the issue cannot be solved by inserting one disclosure clause and assuming the process will take care of itself. Someone must own the uncomfortable questions. Procurement, the service owner, legal, security, data, risk and relevant domain experts need a proportionate route for deciding when supplier AI use deserves deeper scrutiny.

Do not turn this into an AI paperwork exercise

The answer is not to demand an inventory of every autocomplete function used by every supplier. Over-control would create noise, delay ordinary work and encourage formulaic declarations that reveal little.

Deeper scrutiny is justified when one or more of the following is true:

the service handles sensitive, confidential, regulated or high-value information;

AI influences a recommendation, decision, advice product, classification or external communication;

human review is reduced, sampled, poorly defined or difficult to evidence;

the model, provider, data source or subcontractor can change without the buyer's approval;

an error would be difficult to detect, challenge, reverse or explain;

the service cannot continue, transfer or exit safely if the AI component fails or becomes unavailable.

This risk-based approach keeps the focus on consequences and dependencies rather than on the label attached to the technology.

The sensible next move

Organisations do not need to launch an enterprise-wide supplier questionnaire tomorrow. A smaller sequence is more useful.

Start with high-risk tenders and renewals. Apply the disclosure and control test where sensitive data, consequential outputs or difficult-to-reverse dependencies are present.

Update supplier due-diligence and change-control templates. Make AI use, model changes, subprocessors and data use visible at the points where contracts are already reviewed.

Ask service owners where AI is already entering delivery. The most important use may not sit in the technology budget or be described as an AI project.

The objective is not perfect visibility. It is enough visibility to decide which uses are acceptable, which require stronger evidence, and which dependencies the organisation is unwilling to inherit.

Govern the method, not only the product

Procurement once had a relatively simple boundary: identify the system being bought, evaluate it, select the supplier and write controls into the contract. AI is weakening that boundary because the capability can sit inside the supplier's method rather than the buyer's product description.

The answer is not to ban supplier AI. In many cases it will improve speed, capacity and service quality. The answer is to make material use visible enough to govern: what data is involved, what work the model performs, who checks it, how it changes, who is accountable and whether the buyer can continue or leave when something fails.

AI procurement is no longer confined to buying AI. It includes buying anything whose supplier may use AI to deliver it.

The useful question before the next tender or renewal is therefore not simply, “Are we buying AI?” It is: “Where can AI enter this service, and what will we still be able to see, test, challenge and change when it does?”