Why do promising AI pilots struggle to reach UK security teams?
A 28 September CETaS report examines public–private AI partnerships using 22 expert interviews and two focus groups. Its recommendations concern procurement and coordination, not proven operational gains.
The short version
- What happened
- Expert interviews identify organisational barriers, not a measured adoption rate.
- Who it affects
- Accountable procurement matters for staff and for people affected by security decisions.
- What remains unproven
- Targeted qualitative sampling is not representative of every supplier or agency.
Keep in mind
Targeted qualitative sampling is not representative of every supplier or agency.
Recommendations have not been tested as a causal intervention in this report.
Source analysis · 1 linked source. Primary analysed source date: 28 September 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
The evidence behind the recommendations
CETaS at The Alan Turing Institute published a study of UK national-security AI partnerships on 28 September 2026. Natasha Karner, Anna Knack, Mackenzie Jorgensen and Carolyn Ashurst draw on a literature review, targeted interviews with 22 government, industry and academic experts, and two focus groups. The report argues for stronger coordination, sustained funding and engagement with a wider range of suppliers, including smaller companies.
The authors propose an innovation centre to connect organisations and scale effective approaches. This is an institute policy research report, not an announced government programme or an experimental demonstration of better security outcomes. Its purposive expert sample can reveal barriers and mechanisms, but cannot establish what percentage of all suppliers encounter each problem. The focus-group count is not an additional count of independent organisations.[1]
Our analysis: a pilot needs an operational owner
The practical distinction is between proving that a tool can perform a task and establishing who will run it. Consider a system that helps an analyst sort a large set of public documents. A short demonstration may show useful retrieval. Routine use also requires a team responsible for source quality, access, error reports, software changes and continued funding. If those responsibilities remain unresolved, the demonstration can succeed while adoption stalls. This example illustrates an implementation question, not a finding about a specific classified project.
A buyer should be able to describe the operational problem without starting from a favourite model. Is the bottleneck the time spent locating records, checking translations or assessing conflicting accounts? Different problems require different tests and may not require a large generative model. A clear specification helps a smaller supplier show relevant capability without pretending to reproduce every feature of a frontier platform. It also gives procurement staff a basis for comparing proposals.
Faster adoption needs measurable safeguards
Our interpretation is that speed should be measured across the whole route into service. Reducing a purchasing delay is useful only if the system can subsequently be supported and checked. A time-limited pilot could publish non-sensitive measures such as review effort, false leads, reproducibility and the cost of switching suppliers. It should define what failure would stop expansion. The number of demonstrations held or partnerships announced would be a weak substitute for those operational measures.
People affected by security decisions have a stake even when they never use the software. An incorrect association in an analytical tool could consume investigators' time or draw attention to the wrong person. That possibility makes documented uncertainty and human accountability essential design questions. This article does not establish that any named system has caused such an outcome. It asks what evidence a public buyer should require before a pilot influences consequential decisions.
What would change the assessment
The proposed coordination approach would be more persuasive if subsequent projects disclosed milestones, costs and independently reviewed results where security permits. A new centre might remove duplicated work, but it could also add another layer of approval. Comparing the time and resources needed to move similar projects into supported service would help distinguish those possibilities. Suppliers should also have a clear account of why a project stopped, so public spending produces usable learning even when a technology is rejected.
The report concerns the UK, and its institutional recommendations should not be transplanted wholesale into another country's security system. Nevertheless, the questions about ownership, evaluation and long-term support are relevant to public AI procurement elsewhere. Our assessment would change if repeated operational trials showed both dependable benefits and manageable oversight costs. Until then, the report provides qualitative evidence about the conditions for collaboration, while the impact of the proposed reforms remains to be demonstrated.