MICKAI
Article · 11 July 2026

What Should a Police Force Require From an On-Premise AI System?

A police AI must run on force-owned hardware behind a verified air gap, with attested identity and a sealed audit log that survives court.

What Should a Police Force Require From an On-Premise AI System?
Author
Micky Irons
Published
11 July 2026
Follow Micky Irons
LinkedInX
sovereign ailaw enforcementon-premise aiair gapaudit log

A police force should require an on-premise AI system that runs entirely on hardware the force owns and controls, behind a verified air gap, with hardware-attested identity for every user and a cryptographically sealed audit log that can be proven intact in front of a court. The single reason is evidential. Case data classified OFFICIAL-SENSITIVE or above, and the chain of custody around it, cannot depend on a third party who can be compelled to disclose it or who cannot prove what the system did.

In 2026 a force cannot pour live investigation data into a public cloud AI service such as ChatGPT, Claude or Gemini, because those services are built to send data out to a shared provider estate. What a force needs instead is a system whose sovereignty is checkable, not promised. Mickai is a Sovereign Intelligence Operating System, a SIOS, built to run offline on operator-owned hardware with every action cryptographically sealed.

What does on-premise actually have to mean for police case data?

On-premise means more than a rack in the building. For policing it means the model, the inference, the vector store and the logs all sit on hardware the force owns, inside its own estate, with no runtime dependency on an outside network. A hosted model in a vendor cloud, even a dedicated tenant, still leaves the force trusting an outside party with OFFICIAL-SENSITIVE material. If the force pulls its external connection, the system must keep working at full capability.

What Should a Police Force Require From an On-Premise AI System?, illustration 1

How do you prove the air gap is real?

A claimed air gap is worthless; a verified air gap is checkable. Require a zero-egress inbound perimeter: the system accepts data through controlled, logged channels and makes no outbound calls, so there is nothing to exfiltrate through. If the system phones home for licensing, telemetry or updates, it is not air gapped. Updates should arrive as signed offline bundles the force inspects before applying them.

What Should a Police Force Require From an On-Premise AI System?, illustration 2

What must survive a disclosure challenge in court?

Evidence is only useful if its handling survives challenge. Every query, every document ingested, every model output and every human action must be written to an append-only audit ledger that cannot be edited after the fact. The entries should be signed with post-quantum algorithms, FIPS 204 for signatures and FIPS 203 for key encapsulation, so a signature made today cannot be forged by a future quantum adversary and repudiated years later at trial. Chain of custody then becomes arithmetic: each record links to the one before it, and any deletion or reordering breaks the chain visibly.

What Should a Police Force Require From an On-Premise AI System?, illustration 3

Who is allowed to run a query, and how is that proven?

Access control by password is not enough for classified work. Require hardware-attested identity: each operator authenticates with a device-bound credential that is cryptographically tied to the same ledger that records the action. The record then answers who, on which machine, at what time, saw or asked what. Role separation should be enforced by the system, not by policy alone, so an analyst cannot silently widen their own access.

What Should a Police Force Require From an On-Premise AI System?, illustration 4

Which rules make this necessary?

The UK Government Security Classifications require OFFICIAL-SENSITIVE and SECRET material to be handled on approved, controlled systems. The Data Protection Act 2018 Part 3 governs law enforcement processing and demands logging and accountability. Disclosure duties under the Criminal Procedure and Investigations Act 1996 mean the workings of any system touching evidence can be examined. The US CLOUD Act means a US-headquartered public cloud can be compelled to produce data regardless of where it physically sits, which makes it a poor custodian of another nation's case data. On AI specifically, the EU AI Act high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. DORA, NIS2 and ISO/IEC 42001 push the same direction on resilience and governance.

What can an independent auditor actually check?

An auditor should be handed the system and allowed to run concrete tests, not read a brochure. In practice we expect them to check:

  • The pull-the-cable test: disconnect all external links and confirm full function offline.
  • The zero-egress test: monitor the segment and confirm no outbound traffic across a full session.
  • The ledger continuity test: attempt to alter or delete one record and confirm the chain breaks and the tampering is detectable.
  • The attestation test: present a query from an unattested device and confirm it is refused and logged.
  • The signature test: verify a sample of ledger entries against the published post-quantum public keys.

Why can a public cloud AI service not do this?

Public cloud AI services are built to send data to a shared provider estate, behind an interface the customer cannot inspect. For general office work that is reasonable; for classified case data it is disqualifying. The force cannot verify an air gap because there is none, cannot prove the log is sealed because it does not hold the keys, and cannot answer a disclosure request about model behaviour it does not control. The point is architectural, not an accusation. Where a single answer could carry evidential weight, require cross-model consensus: more than one sovereign model answers independently, and disagreement is surfaced rather than hidden and written to the record. The methods behind this architecture sit within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending, never granted or patented.

An on-premise AI system for policing is only fit for purpose if a defence lawyer, an auditor and a judge can each verify what it did without having to trust the vendor.

Frequently asked questions

Can a police force use ChatGPT or Claude for classified case data?

No. Public cloud AI services send data to a shared provider estate and cannot offer a verified air gap or a sealed audit log the force controls. Under the US CLOUD Act a US-headquartered provider can be compelled to disclose data wherever it is stored. Classified and OFFICIAL-SENSITIVE material needs an on-premise sovereign system running on force-owned hardware.

What is a verified air gap in an AI system?

A verified air gap is one an auditor can prove, not one the vendor asserts. It means a zero-egress inbound perimeter with no outbound calls, tested by monitoring the network segment across a full session and confirming zero outbound packets. If the system phones home for licensing, telemetry or updates, the air gap is not real.

How does an on-premise AI system prove chain of custody?

It writes every ingestion, query, output and human action to an append-only ledger where each record is cryptographically linked to the previous one. Signing the entries with post-quantum algorithms such as FIPS 204 means any edit, deletion or reordering breaks the chain in a way that is detectable years later, so the record survives a disclosure challenge at trial.

Is the EU AI Act deadline for high-risk police AI still August 2026?

No. The Annex III high-risk obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat this as extra time to build the controls properly, not as a reason to delay them.

What standards should a sovereign police AI system meet?

Look for alignment with ISO/IEC 42001 for AI management, FIPS 204 and FIPS 203 for post-quantum signing and key exchange, the Data Protection Act 2018 Part 3 for law enforcement processing, and the UK Government Security Classifications for handling OFFICIAL-SENSITIVE and above. Operational resilience regimes such as DORA and NIS2 reinforce the same requirements.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/sovereign-ai-for-police-and-law-enforcement-classified-case-data. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles