Why procurement belongs in the AI conversation before the pilot scales

An AI tool rarely arrives with a clear announcement that the organisation is changing its operating model. More often, somebody starts using it to summarise documents, prepare meeting notes or draft responses. The demonstration is useful. Colleagues ask for access. Someone connects a shared folder.

Within weeks, a small experiment may be handling information and influencing work that its original approval never covered.

For UK organisations, the question is not simply whether procurement has purchased the right subscription. It is whether the business understands what it is trusting the supplier and the system to do.

Start with the decision, not the product

Before comparing suppliers, describe the proposed use in ordinary language.

What work will the tool support? What information will it receive? Will its output be checked before use? Can it take actions in other systems?

Consider a hypothetical housing association exploring an assistant for maintenance correspondence. Drafting a response for an employee to review is one use. Sending messages automatically or changing the priority of repairs introduces different consequences.

The same distinction applies to a professional services firm reviewing client documents or a local authority summarising internal papers. A supplier’s general description of an “AI assistant” does not resolve the boundaries of a particular deployment.

Procurement needs that operational context to ask useful commercial questions.

Treat the pilot as a bounded engagement

A pilot should have an owner, an agreed purpose and a decision date.

Record the permitted users, information sources, integrations and spending limits. Agree what evidence would justify continuing and what findings would require a change or a stop.

This can be proportionate. A short, well-maintained record is more useful than an elaborate approval pack that nobody consults.

The important point is that expansion requires a decision. Adding confidential documents, another department or an automated action should not happen merely because the software makes it convenient.

Procurement can help keep those boundaries visible when trial subscriptions renew or additional licences are requested.

Follow the information through the service

Ask what happens to information after it enters the tool.

Which providers process it? What is retained? Can inputs or outputs be used to improve models? What controls are available to administrators? How are access permissions and deletion handled?

The answers should relate to the actual service tier and configuration being proposed. A broad supplier statement may not explain the features your team intends to enable.

For a connected document assistant, existing access problems also matter. If shared folders contain information that too many employees can already see, connecting AI may make that information easier to discover.

Procurement should obtain relevant supplier evidence and involve privacy, security and technical colleagues. It should not be expected to make specialist judgements on their behalf.

Evaluate the work, including the checking

A successful demonstration is a starting point, not a business case.

For a reporting assistant, evaluate whether important qualifications, dependencies and risks survive the summary. For a drafting tool, examine misleading statements, unsuitable wording and the effort required to correct them.

Measure the whole task. A draft produced quickly may offer little benefit if employees spend longer checking it than they previously spent writing it.

Useful evaluation questions include:

• Does the output preserve material facts and uncertainty?
• Can reviewers trace important statements to their sources?
• How much checking and correction is required?
• Do people use the tool, or maintain a parallel workaround?
• Can the organisation restrict or stop its operation when needed?

Agree acceptable evidence before the team becomes committed to a rollout.

Connect assurances to operating responsibilities

Commercial terms and practical controls need to support each other.

An assurance about restricted access is useful only if the organisation knows how to configure, maintain and check that restriction. A promise of incident support needs a clear contact route and an internal owner who can act.

For a UK SME, several responsibilities may sit with one senior person. A larger enterprise or public body may divide them across commercial, technology, security and service teams. Either arrangement needs explicit ownership.

Supplier assurance does not remove the organisation’s responsibility for how it deploys and uses the service.

Plan for change and departure

Approval should not last indefinitely without review.

A model update, new integration or change in business purpose may alter the assessment. Establish who watches for those changes and who can authorise continued use.

Also ask how the organisation would leave. Can it retrieve useful records, documents and configurations? Can access be withdrawn? Is there a workable alternative if the service becomes unavailable?

These questions become harder once teams depend on the tool.

A practical next step

Before the next pilot expands, bring the business owner, procurement and relevant specialists together around a one-page brief:

• The task and intended benefit.
• Permitted information and access.
• Supplier evidence and unresolved questions.
• Evaluation criteria and review date.
• Named decision owner.
• Conditions for expanding, changing or stopping.

Early procurement involvement should help teams make informed progress. Its value is greatest while choices remain open.