Police AI needs a disclosure run log

A summary is not an audit trail. If an AI tool tells an investigator that 40 messages matter, somebody must still be able to reconstruct which material was searched, what the tool excluded and why those 40 appeared.

On 14 July, the UK Home Office accepted recommendations to let technology assist criminal disclosure and announced PoliceAI pilots that will generate summaries of digital material. The scale explains the attraction: the department says some investigations contain the equivalent of more than 500,000 e-books and an average fraud case holds over four million documents. Successful tools are intended for wider deployment across police forces in 2027.

The same day’s government response supplies the more important requirement. AI use should be lawful, fair and proportionate, with human oversight, testing, assurance and recordkeeping. Those words need one operational object: a run log attached to every material review.

The reform changes the search, not the duty

Criminal disclosure in England and Wales is governed principally by the Criminal Procedure and Investigations Act 1996 and its code of practice. Prosecutors must disclose material that might reasonably undermine the prosecution case or assist the defence. Investigators and disclosure officers record, retain, examine and reveal relevant material so that the prosecutor can apply that test.

The reform does not hand that decision to a model. The government proposes updating the code to state that technology may help identify potentially relevant material, flag material that may meet the disclosure test and review large volumes. It also says technology is an aid to a compliant, “thinking” process, not a substitute for legal duties or professional judgment.

That boundary is easy to state and harder to preserve in software. A generated summary can look finished even when it rests on an incomplete export, an aggressive date filter or a model version that changed after testing. An investigator may review the prose without seeing the retrieval decisions underneath it.

The control should therefore sit between the machine output and the human decision. Before a summary enters a case file, its reviewer should be able to answer three questions:

• What exact material entered the run?
• What settings and tool version produced the result?
• What checks were performed before a person relied on it?

If any answer lives only in a vendor’s internal telemetry, the force does not yet hold a reviewable record.

Keep one record for each run

The Home Office has committed to a cross-agency protocol covering accountability, human oversight, testing, assurance, explainability and bias monitoring. A run log turns that future protocol into something a team can test now.

Run-log field	What it proves	Minimum useful entry
Material boundary	Which evidence could influence the output	Case ID, source systems, export time, item count and a corpus fingerprint
Tool state	Which system actually ran	Product, model and retrieval version, plus configuration
Review method	How material was selected or summarised	Query, filters, thresholds and any excluded file types
Output	What the tool returned	Result file, item references and error report
Check	How the result was challenged	Sample reviewed, misses found and exceptions raised
Accountability	Who accepted or rejected reliance	Operator, reviewer, decision, timestamp and reason

Source: Home Office, Modernising the Criminal Disclosure Regime, recommendations 1, 2 and 7. Last verified 2026-07-15.

The fingerprint need not be elaborate. A manifest listing the source files and their hashes is stronger than a screenshot saying “upload complete”. The purpose is to detect a changed corpus and to let another authorised reviewer reproduce the boundary of the search without duplicating sensitive material.

Configuration matters just as much. “Tool X was used” is not enough when a retrieval threshold, supported file list or language setting can alter which items surface. Store the small set of parameters that materially affects the result, not every infrastructure metric the service emits.

Test misses, not just polished summaries

Procurement demonstrations reward fluent output. Disclosure assurance must look for relevant material the tool failed to surface.

The independent review recommended common metrics for accuracy, security and value for money, alongside regular review of deployed tools. The government has accepted the objective and plans a forum involving law enforcement, prosecutors, defence representatives and the judiciary. This is a better frame than a single headline accuracy score.

A force or supplier should build a small test pack with known inclusions, known exclusions and difficult boundary cases. It should cover scanned documents, unusual file types, long message threads, multiple languages and material that points away from the working theory of the case. Run the same pack after a model, retrieval or configuration change.

For live work, sample from both sides of the result:

1. Review some items the tool ranked as relevant.
2. Review a random sample it did not surface.
3. Record false positives, false negatives and unreadable files.
4. Escalate when the miss pattern affects a live issue in the case.

The second sample is the load-bearing one. Checking only selected material measures whether the summaries sound plausible; it does not test whether the search overlooked something capable of assisting the defence.

Preserve challenge and rerun paths

The government’s proposed code change expressly preserves the defence’s ability to object to the approach used to identify or review material. That makes reproducibility part of procedural fairness, not a back-office convenience.

An objection may arrive months after the original run. By then, a cloud model may have changed, an account may have been closed or the source export may have been replaced. The team does not need to freeze an entire AI service forever, but it does need enough evidence to explain what happened and decide whether a controlled rerun is required.

Retention should therefore cover the run log, result, source manifest, validation outcome and material configuration. Access must follow the case’s existing security controls. Logs should not copy the contents of sensitive evidence into a less protected analytics system merely to make governance easier.

The supplier contract should also make the exit path explicit: exportable logs, notice of model changes, a record of processing failures and a way to identify which live cases used an affected version. Central procurement may reduce duplicated buying, as the review recommends, but it also increases the blast radius of a silent update.

Pilot the record before the model

PoliceAI’s pilot has a sensible opportunity. It can define the review record before forces scale the summarisation tool, then make log completeness a condition of deployment.

The smallest exercise uses an existing, lawfully accessible training corpus. Run one version of the tool, save the six fields above, have a second reviewer reproduce the material boundary and inspect a sample of omitted items. Change one setting and repeat. If the team cannot explain the difference between the two outputs from its own records, the pilot has found a governance gap before a live case depends on it.

AI can reduce the manual burden of sorting millions of files. It cannot make an unexplained search fair by writing a confident paragraph at the end. Before PoliceAI measures hours saved, it should prove that every saved hour still leaves a trail another person can follow.