Britain Is Using Procurement to Test the AI Scale-Up Gap

The British government has launched the first competitions under a £100 million research-and-development procurement scheme for artificial intelligence companies. The program is aimed at technologies that have moved beyond early research but still need a real operating environment, a demanding customer and evidence that the product can work outside the laboratory.

Four initial challenges give the scheme a deliberately broad test. Companies can propose AI for NHS productivity, open and secure capabilities for defense environments, more efficient public computing infrastructure, or tools for assessing and reducing the risks of AI agents. Successful firms will work with government departments to develop demonstrators before any decision on wider deployment.

This is more than a grant program with a public-sector theme. The government is presenting itself as an early customer. Contracts will range from £250,000 to £10 million, with most expected to fall between £1 million and £3 million. Applicants face no minimum turnover, net-asset or cash-reserve requirement; intellectual property remains with the supplier; and upfront payments may be available when cash flow would otherwise exclude a smaller company.

Those terms target a familiar scale-up problem. A young company may have a technically credible product but lack the reference customer, procurement history or balance sheet needed to win a conventional public contract. Government may want the capability but find that its standard purchasing process favors established suppliers. A research-and-development contract can create a controlled bridge between those positions.

A contract is useful when it buys evidence

The scheme will succeed only if each demonstrator is designed around a decision. A health project should not be judged by whether an interface works in a pilot ward. It should show whether staff time, clinical workflow, service quality and safety changed under realistic conditions. A defense integration project must preserve security, interoperability and operational control. An agent-risk tool needs to help a named decision-maker distinguish manageable risks from uses that should be restricted.

Compute efficiency is an especially revealing challenge. It joins the scheme to ARIA’s Scaling Inference Lab, an open testbed intended to bring new hardware and software into rack-level systems. Component-level gains can disappear once networking, memory, software compatibility, cooling and workload behavior are included. Procurement should therefore buy evidence at the system boundary: cost and energy per useful workload, reliability, integration effort and performance under actual user demand.

Clear baselines matter across all four challenges. Without them, a supplier can complete a technically impressive demonstration while the public customer remains unable to decide whether the result is better than the existing service. Evaluation needs to state what is being displaced, which risks must remain below defined thresholds and what evidence would justify the next stage.

Independent technical assessors can test novelty and research quality, but the operating department must define usefulness. That division matters: a high-scoring technology is not automatically a viable public service, and a cautious department should not be able to reject a successful trial without explaining which operational threshold was missed.

Startup-friendly entry does not remove delivery discipline

Removing turnover and reserve requirements broadens access, but it also shifts responsibility toward the design of milestones. Upfront payments may be necessary when a small company must hire people, secure computing capacity or adapt its product before delivery. Later payments should then follow verified technical and service outcomes rather than activity alone.

Intellectual-property ownership strengthens the commercial incentive because a supplier can reuse what it builds. The public customer still needs durable rights to operate the deployed service, transfer data, audit performance and avoid a demonstration that can continue only through an uncompetitive follow-on arrangement. Those conditions should be settled before the pilot creates dependency.

Portfolio governance will be equally important. The four challenges have different buyers, risk tolerances and routes to scale. A single success rate would conceal more than it reveals. The scheme should report how many contracts reached a working demonstrator, how many produced decision-grade evidence, how many moved into wider procurement and why others stopped.

The missing link is adoption after the trial

Public innovation programs often produce pilots without producing services. A demonstrator can meet its technical objectives and still stall because no department owns the next procurement, operational funding is absent, data access cannot be sustained or integration costs exceed the benefit.

Each contract therefore needs an adoption hypothesis from the beginning. It should identify the potential operational owner, the decision date, the budget route and the standards the product must meet to move beyond research and development. This does not promise a supplier a later contract. It ensures that positive evidence has somewhere to go.

The £100 million envelope can help British AI companies establish reference customers and test difficult capabilities. Its larger value will depend on whether government learns to purchase uncertainty without normalizing endless experimentation. The decisive metric is not the number of startups funded or demonstrations completed. It is the number of well-evidenced capabilities that either enter routine use through a fair procurement or stop for a clearly recorded reason.