Open Weight AI Models Need Procurement Evidence Before Deployment

Open-weight models are no longer a fringe technical option. The question for UK leaders is whether procurement evidence has caught up with the freedom to download and deploy them.

Open weight is a procurement decision, not a download decision

Open-weight AI models have become attractive because they promise more control. A business can run the model in its own environment, tune it for a specific workflow, inspect behaviour more closely and reduce dependence on a single hosted vendor. That is useful, especially for regulated UK organisations that need clearer answers about where data goes and who can access it. But the phrase open weight can also create a false sense of safety. The weights may be available, but that does not mean the training data is transparent, the licence is simple, the model is appropriate for every use case, or the operating burden disappears.

The practical starting point is to treat the model as a supplier and a software component at the same time. Procurement should ask for the same evidence it would expect from a platform vendor, then add AI-specific checks around evaluation, model behaviour and downstream safeguards. That means recording where the model came from, which version is being used, which licence applies, what benchmarks matter for the intended workflow, what safety tests have been run, and who owns patching or replacement when a stronger or safer model appears.

This matters because UK adoption is moving from experimentation into operational use. The Office for National Statistics found that AI use among UK businesses with 10 or more employees rose from around 12% in late 2023 to around 35% by June 2026. At the same time, the ONS found the average number of AI technologies used by adopting businesses rose only modestly, from around 1.4 to 1.6. That combination says a lot. More organisations are entering the AI market, but many are still shallow users. Open-weight models can help firms deepen adoption, but only if buying discipline improves alongside technical access.

ONS data shows AI use among UK businesses with 10 or more employees rose from around 12% in late 2023 to around 35% by June 2026.

The evidence pack should answer six questions before pilot approval

A good evidence pack should be short enough for a board sponsor to read and specific enough for engineering, legal and security teams to act on. It should not be a long-form vendor brochure. For an open-weight model, the pack should answer six practical questions. What exactly are we using? Where did it come from? What are we allowed to do with it? How did it perform against our tasks? How will it be operated safely? What happens when it fails, changes or becomes unsuitable?

The first question sounds simple, but it is often where weak procurement starts. A team should record the model name, provider, version, release source, hash or verified distribution route where available, licence, intended deployment environment and any modifications made internally. If a model is downloaded from a community mirror rather than the original provider, that should be treated as a supply chain risk. If weights are adapted, quantised or fine-tuned, the adapted artefact needs its own record. The business is no longer only buying a model. It is creating a maintained internal component.

The second and third questions are about rights and provenance. Open weight is not the same as open source. A model can be available for download while still carrying usage restrictions, competitive restrictions, attribution requirements, acceptable use conditions or uncertainty about training data. Legal sign-off should happen before the pilot becomes operational, not after a successful demo has created pressure to ship. The fourth question is evaluation. Generic benchmarks are useful context, but they do not prove the model works inside a claims process, support workflow, finance review or HR assistant. The pack should include task-level tests, refusal tests, hallucination checks and human review thresholds. That is what this means in practice: a buyer should be able to reject a technically impressive model because it cannot produce reliable, auditable outputs in the actual workflow.

Open weight is not the same as open source, and availability to download is not the same as permission to deploy.

UK security guidance already points in this direction

The UK policy direction is not telling businesses to avoid AI. It is telling them to manage AI as a lifecycle risk. The Code of Practice for the Cyber Security of AI says AI systems have distinct risks including data poisoning, model obfuscation and indirect prompt injection. It also sets out lifecycle phases such as secure design, secure development, secure deployment, secure maintenance and secure end of life. That language is important for open-weight models because the buyer may inherit more of the lifecycle than they would with a hosted managed service.

The NCSC guidelines for secure AI system development make the same point in operational terms. They ask providers and stakeholders to consider secure design, secure development, secure deployment, and secure operation and maintenance. They also stress that AI systems need to function as intended, remain available when needed and avoid exposing sensitive data to unauthorised parties. Those principles apply whether the model is proprietary, hosted, open weight, fine-tuned or embedded inside another product.

For procurement teams, the implication is straightforward. Security evidence should not stop at a supplier questionnaire. The business needs to know how the model will be isolated, monitored, updated and retired. It needs logging that captures model version, prompts, retrieved context, tool calls and output decisions where appropriate. It needs policy controls for data classes that cannot be sent to the model. It needs a route for reporting model failure that looks more like incident management than user feedback. The counterargument is that this slows down adoption. In reality, it speeds up the right kind of adoption because teams can reuse the evidence template across future model choices instead of rebuilding the argument for every pilot.

The UK AI cyber security code highlights risks such as data poisoning, model obfuscation and indirect prompt injection.

Cost control is only real when the operating model is visible

One reason open-weight models appeal to business leaders is cost. The pitch is simple: avoid per-token pricing, run models on owned or reserved infrastructure, route sensitive workloads locally and keep more leverage in supplier negotiations. That can be true, but it is incomplete. The cost of an open-weight deployment includes compute, engineering time, monitoring, patching, evaluation, security review, incident response and the opportunity cost of maintaining a model that may be overtaken quickly. A cheap model can become expensive if nobody owns the lifecycle.

DSIT's AI Adoption Research gives useful context here. It found that among AI adopters, 85% were using natural language processing and text generation, while agentic AI was the least adopted technology at 7%. It also found high costs, unclear regulation and ethical concerns were significant barriers for businesses that raised them. These findings fit what many UK leaders are seeing internally. Text generation is easy to try. Production-grade automation, model hosting and workflow ownership are much harder.

That is why the evidence pack should include unit economics before the pilot scales. The team should compare the open-weight option against a hosted model, a smaller model, a retrieval-only system and a human-in-the-loop process. The right metric is not only cost per token. It is cost per completed task, cost per accepted output, cost per escalation avoided and cost per audited decision. For some workflows, a hosted frontier model with strong vendor tooling may be cheaper overall. For others, a smaller open-weight model running inside a controlled environment may be the better long-term option. What this means in practice is that procurement should approve an operating model, not just a model name.

DSIT found natural language processing and text generation were used by 85% of AI adopters, while agentic AI was used by only 7%.

Assurance is becoming a market, so buyers should demand usable proof

The assurance market is maturing quickly because buyers need more than model cards and marketing pages. DSIT's mapping of the AI and software security services market reported that cyber attacks or breaches affected 43% of UK businesses in the past year, citing the Cyber Security Breaches Survey 2025. It also found that the 2026 sectoral study identified 111 AI security providers and 1,141 software security providers, up from 66 AI and 960 software security providers in a previous 2025 market analysis. That is a signal that AI assurance is becoming part of the buying landscape, not a niche afterthought.

The same DSIT mapping found 92% of AI security providers were aware of the AI Security Code of Practice and 86% were aware of the AI security global standard. Awareness does not guarantee quality, but it means UK buyers can start asking sharper questions. Does the provider test prompt injection? Does it assess model supply chain risk? Does it review retrieval data exposure? Does it test data leakage? Does it check operational monitoring? Does it produce evidence that can be read by non-technical risk owners?

For open-weight deployments, third-party assurance can be particularly helpful where internal teams lack specialist skills. But outsourcing the test is not the same as outsourcing accountability. The business still needs a named owner for accepting risk, a remediation log, and a decision record that explains why the model is suitable for the selected use case. The common misconception is that assurance is only useful for high-risk AI. In practice, assurance is useful whenever an AI output can influence money, access, customer experience, compliance posture or employee decisions. It gives the organisation a shared language for risk before the model becomes embedded in daily work.

DSIT's 2026 sectoral study identified 111 AI security providers and 1,141 software security providers.

The best buyers will maintain a model register

The strongest UK AI teams will not choose one model and freeze. They will maintain a model register that lets them swap, route and retire models with less disruption. The register should include every model used in production or controlled pilots, including hosted APIs, embedded SaaS models, open-weight models, fine-tunes, small local models and retrieval components that shape outputs. For each entry, the register should capture owner, purpose, data classes, supplier, version, licence, hosting location, evaluation summary, risk rating, monitoring method, review date and exit route.

This approach fits the reality of the market. Models change quickly, pricing changes, licence terms change, benchmark leadership changes and new vulnerabilities appear. A register gives leaders a way to see concentration risk. It shows whether customer support, sales enablement, compliance review and internal knowledge search all depend on one supplier. It also shows where open-weight models are being used because they are genuinely better for the workflow, and where they have been adopted because a technical team wanted more control without proving the business case.

The practical test is simple. If a regulator, board member, insurer or major customer asked which AI models touch sensitive workflows, could the business answer in one working day? If not, the organisation does not yet have operational control. Open-weight models can be a powerful part of a mature model portfolio, especially where data control, latency, customisation or supplier leverage matter. But they should enter through the front door, with evidence. The business case is strongest when the procurement pack, model register and operating controls all tell the same story: this model is not just impressive, it is owned, measured and replaceable.

If a board member asked which AI models touch sensitive workflows, the business should be able to answer in one working day.