Making data work across boundaries: The next challenge for policing

The future of policing depends on more than changing force structures or investing in AI. It depends on making data work across boundaries.

Policing is being asked to change at pace. The Home Office's white paper, From local to national: a new model for policing, sets out one of the most significant reforms to policing in decades: fewer and larger regional forces, a new National Police Service, stronger national standards, greater use of technology and data, and a more coordinated approach to tackling serious and organised crime.

Data sits at the heart of those plans. The white paper notes that more than 90% of crime is now estimated to have a digital element, while data is fragmented across 43 forces and recorded in different formats. It proposes a new National Data Integration and Exploitation Service (NDIES), mandated national data standards, and a single decision-maker for key national datasets.

The timetable is ambitious. The Police National Computer is due to be switched off during 2026/2027, replaced by the Law Enforcement Data Service (LEDS), and NDIES is expected to have commenced delivery by the end of the same year.

That makes data architecture more than a technology decision. It is a reform decision.

The problem isn't a lack of data

Policing already holds enormous amounts of valuable information. The Home Office white paper describes the landscape it sits in as a "patchwork quilt" of different systems, standards, and processes with each force making many of its own decisions about technology and data.

For investigators, the consequences are practical. A county line’s investigation may involve intelligence held by several forces alongside national datasets. Investigators may not know whether another force or a national dataset holds anything relevant at all, so time is spent on requests and enquiries for information that does not exist. Where the information does exist, finding it can mean searching multiple systems, requesting it from other organisations, or working with data that has been recorded differently elsewhere.

The challenge, then, is not simply to collect more data, but to make existing policing data more accessible, consistent, and useful.

Centralising or connecting

The white paper describes NDIES as a centralised approach to data integration and exploitation. But national integration does not have to mean putting every dataset in one place.

The instinctive response to "integrate data nationally" is to bring everything together in a central platform. That creates dependencies. If force structures change, data may need to be migrated. If new capabilities arrive, new integrations may be needed. As the central environment grows, so does everything that depends on it. And every change to its architecture, security, governance, or suppliers has knock-on effects for each force and capability built on top of it. That slows innovation; when capabilities are tied to the platform that holds the data, a new tool has to wait for the platform to change, and improving one capability risks disrupting another.

There is a historical basis to be cautious. The NHS National Programme for IT was dismantled in 2011 with forecast costs of £9.8 billion and benefits worth only half of what had been spent. Members of Parliament found it had struggled to persuade NHS trusts to take systems procured nationally and called for a balance between standardisation and local ownership. FiReControl, which set out to replace 46 local fire control rooms with nine regional centres, was terminated with at least £469 million wasted after a national system was imposed without the support of local fire and rescue services.⁴ The lesson is not that national programmes cannot work but that a national system imposed without the support of those who run services locally is very hard to deliver.

A different model is to connect data while it stays in the environments where it is created and governed. This is the thinking behind a data mesh: Data is treated as a set of reusable products with clear ownership, standards, and access controls, and authorised capabilities consume them through common interfaces without the data having to move. Because capabilities are decoupled from the data, they can be built, tested, and replaced without changing the data underneath or each other. A capability tender becomes a contest over the application rather than the data engineering behind it, so smaller and more innovative firms can compete alongside the large integrators. More competition drives faster innovation and better value for the taxpayer.

That lets national access and local accountability coexist. An analyst might see patterns and trends, an investigator might see case-level information where authorised, and a public-facing service might only see aggregated data. The principle is straightforward: Make information available to those who need it without making everything available to everyone.

It also suits the reform itself. As forces move towards fewer, larger organisations, a connected model lets structures change while the underlying data stays locally governed, rather than turning every merger into a data migration.

Keeping choice open

Decoupling only lasts if the interfaces between data and capabilities stay open. The opposite is a single supplier that builds everything from the data layer to the applications on top. However capable that platform is, nothing changes without the supplier's involvement, and every new requirement, restructure, or renewal is negotiated from a position of dependency. Policing should not carry that risk. Open interfaces, common standards, and non-proprietary formats keep the choice with policing. As long as those interfaces stay consistent, the technology behind them can evolve or be replaced without disrupting the capabilities that rely on them, and applications and suppliers can change without starting again.

What a connected model gives policing

Our white paper sets out this architecture without reference to any product. Elastic already provides the foundation to build it; it’s what we call an Elastic data service: the data a force or national body owns with the search analytics, and AI agents built on it exposed through common and secure interfaces.

• Control stays with the data owner: Each force or national body runs its own Elastic data services and decides who can see what, down to individual records and fields. Every access can be audited. Accountability stays where legislation assigns it and where the public expects it to be.

Control stays with the data owner: Each force or national body runs its own Elastic data services and decides who can see what, down to individual records and fields. Every access can be audited. Accountability stays where legislation assigns it and where the public expects it to be.

• National reach without a national copy: Investigation tools, analytics, and AI agents draw on the Elastic data services they need, and each one receives only what the task requires. That same county lines investigation can use intelligence held by different forces without anyone building a new central store.

National reach without a national copy: Investigation tools, analytics, and AI agents draw on the Elastic data services they need, and each one receives only what the task requires. That same county lines investigation can use intelligence held by different forces without anyone building a new central store.

• Build once, deliver everywhere: A national capability, such as an intelligence service, can be designed once and delivered to every force, rather than reinvented 43+ times. Unlike a central system, the data does not move. Every force gets the same capability and technology; can search locally, regionally, or nationally as the task needs; and still keeps ownership and control of its own data.

Build once, deliver everywhere: A national capability, such as an intelligence service, can be designed once and delivered to every force, rather than reinvented 43+ times. Unlike a central system, the data does not move. Every force gets the same capability and technology; can search locally, regionally, or nationally as the task needs; and still keeps ownership and control of its own data.

• It runs where the data needs to be: Whether data is in the cloud, on-premises, or fully air-gapped, sensitive data can stay in the environment its owner chooses.

It runs where the data needs to be: Whether data is in the cloud, on-premises, or fully air-gapped, sensitive data can stay in the environment its owner chooses.

AI needs the foundation first

The UK government has committed £115 million over three years to support the adoption of AI and automation in policing, including a new National Centre for AI in Policing, known as Police.AI. The white paper is clear that fragmented infrastructure, ageing systems, manual processes, and poor data quality stand in the way. If every new AI capability needs its own data preparation and pipeline, scaling innovation will stay slow.

A connected foundation changes that starting point and it puts expertise to work. No one knows a data product better than the people who own and look after it. With Elastic, they can turn that knowledge into AI agents and automated workflows, built once and made available to anyone authorised to use them, across policing. An Elastic data service exposes those agents in the same way it exposes data, so new capabilities can use them just as easily. Those agents work with the same search and analytics as people, so they can answer where and when, not just what. The white paper's own examples of better analytics include hotspots and crime patterns.¹ They can search the content itself, not just the metadata recorded about it, across documents, images, audio, and video. And they work within the same access controls, so an agent sees no more than the person it works for.

Great context also makes AI cheaper and faster to run. Agents that start from well-prepared data, rather than rediscovering it on every question, need fewer steps. That is the role Elastic plays: the context layer between policing's data and its AI. In Elastic's published tests, preparing context in advance cut the input the AI model had to process by about 58%, and response times by about 40% for support case investigations with no statistically significant loss of factual accuracy. In another example with the same model and data, the number of steps an agent took fell from 33 to 9, and the time to answer from 213 to 64 seconds.

Organisations keep the choice of AI model, including models they host themselves for sovereign or air-gapped use. That makes it easier for local innovations to be tested nationally and, where they work, rolled out at scale, as intended by the Home Office white paper.

3 principles for the next phase

As the white paper moves from policy into implementation, three principles could help keep the architecture flexible:

• Build the data foundation separately from the applications: The integration layer should support today's capabilities without becoming a constraint on tomorrow's.

Build the data foundation separately from the applications: The integration layer should support today's capabilities without becoming a constraint on tomorrow's.

• Make openness the default: National standards should create consistency, while open interfaces and formats allow existing systems to connect and new technologies to be introduced without wholesale replacement.

Make openness the default: National standards should create consistency, while open interfaces and formats allow existing systems to connect and new technologies to be introduced without wholesale replacement.

• Connect by default and centralise where there is a reason to do so: Some datasets and capabilities will naturally need national ownership or centralisation, but this should be an operational and policy choice rather than the automatic answer to every integration problem.

Connect by default and centralise where there is a reason to do so: Some datasets and capabilities will naturally need national ownership or centralisation, but this should be an operational and policy choice rather than the automatic answer to every integration problem.

A connected foundation for policing

Elastic supports policing worldwide. With Elastic as the data foundation, each organisation can run its own data services and still contribute to a national capability without centralising its data.

To talk it through, contact our public sector team.

Sources

• GOV.UK, “From local to national: a new model for policing,” March 2026.

, “,” March 2026.

• , “Government response to phase 1 of the Southport Inquiry,” July 2026.

, “,” July 2026.

• House of Commons Committee of Public Accounts, “The dismantled National Programme for IT in the NHS,” July 2013.

House of Commons Committee of Public Accounts, “The dismantled National Programme for IT in the NHS,” July 2013.

• National Audit Office, “The failure of the FiReControl project,” July 2011.

National Audit Office, “The failure of the FiReControl project,” July 2011.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

In this blog post, we may have used or referred to third party generative AI tools, which are owned and operated by their respective owners. Elastic does not have any control over the third party tools and we have no responsibility or liability for their content, operation or use, nor for any loss or damage that may arise from your use of such tools. Please exercise caution when using AI tools with personal, sensitive or confidential information. Any data you submit may be used for AI training or other purposes. There is no guarantee that information you provide will be kept secure or confidential. You should familiarize yourself with the privacy practices and terms of use of any generative AI tools prior to use.

Elastic, Elasticsearch, and associated marks are trademarks, logos or registered trademarks of elasticsearch B.V. in the United States and other countries. All other company and product names are trademarks, logos or registered trademarks of their respective owners.