The Production Threshold: A UK Procurement Checklist for Scaling AI Beyond the Pilot

An AI pilot is a controlled experiment. It usually has a named owner, a limited user group and a vendor keen to see it succeed. Production is different. The tool becomes part of a process, the user base widens and the cost model starts to reflect real behaviour rather than test traffic. For UK buyers, the gap between the two is rarely a technical gap alone. It is a procurement gap, and it is best closed before scaling begins.

Why pilot economics mislead

Pilots are often priced to encourage adoption. A vendor may waive setup fees, include a generous allowance or provide extra support during the trial. Those concessions can make the business case look stronger than it will be at steady state. The problem is not that vendors are acting unreasonably. It is that pilot terms are designed for evaluation, not for the operational life of a business-critical system.

Buyers should therefore treat pilot pricing as evidence of intent, not as a forecast. The relevant question is not what the pilot cost, but what production will cost when usage rises, support shifts to a standard tier and the vendor's commercial team returns to its normal position.

Define the production threshold before the invoice does

Scaling should begin with an explicit definition of what production means for the organisation. That definition should cover user numbers, transaction volumes, integration points, data sensitivity and the business processes that will depend on the tool. It should also state which pilot assumptions must hold true before the service is allowed to move beyond the trial.

Without that threshold, production arrives by default. A team extends the pilot, more users are added and the tool quietly becomes part of daily operations. By the time procurement is asked to review the arrangement, the organisation has less leverage and less time.

Read the meter: usage, commitments and overage

AI services are frequently billed on consumption. Tokens, API calls, compute time, storage and model choice can all affect the monthly invoice. A pilot may use a narrow set of inputs and a single model. Production may involve longer prompts, more documents, additional languages or higher volumes at peak times.

Buyers should ask for a worked example based on realistic production volumes, not a headline price per user. They should also establish how overage is charged, whether unused commitments can be carried forward and what happens if usage falls below forecast. Cost controls such as budget alerts, per-team chargeback and hard caps should be agreed in advance. A monthly invoice that cannot be explained by usage is a governance problem, not merely a finance problem.

Model changes are procurement events

AI models are not static components. Vendors update them, retire older versions and change default settings. A model change can alter output quality, latency, cost and the validation work required by the buyer. For a business-critical process, that is a procurement event even if no new contract is signed.

Contracts should set out notice periods for material model changes, the availability of previous versions for a defined transition period and the buyer's right to test before switching. Where the service depends on a specific model, the buyer should understand whether that dependency is contractual or merely customary.

Data retention, training and the UK GDPR question

Production usually means more data, and more sensitive data. Buyers should confirm what is retained, for how long and for what purpose. They should establish whether inputs or outputs can be used to train models, whether that use can be disabled and how deletion requests are handled.

For UK organisations, data protection terms need to reflect UK GDPR obligations and the role of the Information Commissioner's Office. The contract should identify the parties' responsibilities, support data subject requests and set out breach notification arrangements. A pilot may have survived on a simplified privacy notice; production requires a documented position that survives scrutiny.

Support boundaries and escalation

Pilot support is often attentive because the vendor wants the project to succeed. Production support is governed by service levels, severity definitions and escalation paths. Buyers should test those boundaries before they need them.

Ask how incidents are classified, what response times apply and whether support is available during UK business hours or around the clock. Clarify whether model-related failures count as service incidents and how the vendor communicates degraded performance. Service credits may compensate for downtime, but they do not restore a broken process. The contract should also identify what happens when the vendor's own suppliers fail.

Training is not a launch-day slide

Scaling AI changes the nature of staff training. A pilot group can learn by experiment. A wider user base needs practical guidance on acceptable use, prompt discipline, data handling and the limits of the tool. Managers need to know how to interpret outputs and when to escalate a concern.

Training should be treated as part of the production readiness checklist, not as an afterthought. That means named owners, refresher material and a route for users to report unexpected or harmful outputs. Adoption metrics should be reviewed alongside cost and quality metrics, because low usage can hide a tool that is not trusted.

Exit criteria and contract terms

Every production arrangement should have an exit plan. Buyers should secure data export in a usable format, transition assistance for a defined period and clear termination rights for material breach or persistent underperformance. They should also check price review clauses, auto-renewal terms and any restrictions on benchmarking or sharing performance data.

Exit criteria should be agreed before scaling. These may include accuracy thresholds, cost per transaction, integration stability, user adoption and support response times. If the tool fails those tests, the organisation needs a contractual route to reduce scope or leave.

A practical checklist

Before scaling, UK buyers should confirm the following: a written definition of production; a usage forecast with overage terms; budget alerts and cost ownership; notice periods for model changes; data retention and training positions; UK GDPR responsibilities; support levels and escalation paths; a training plan with named owners; exit criteria; and data export and transition terms.

AI can move from pilot to production quickly. Procurement should not be the last function to notice. The production threshold is easier to manage when it is defined, priced and contracted before the tool becomes indispensable.