What should a local council require before using AI on citizen data?

A local council should require four things before any AI system touches citizen data. The system must run offline on hardware the council owns and controls. It must enforce a zero-egress perimeter, so no citizen record, prompt or embedding can leave the council estate. Every action must be written to a tamper-evident audit log that a data-protection regulator can verify without trusting the supplier, and each operator must hold a hardware-attested identity bound to that log. Under UK GDPR and the ICO accountability principle, a council must be able to prove what happened to citizen data, and it cannot prove what it cannot see.

This matters more in 2026 than it did two years ago. Public cloud AI services process prompts on infrastructure the council neither owns nor inspects, and much of that infrastructure sits under legal regimes such as the US CLOUD Act, which can compel disclosure regardless of where the data physically rests. A council holds housing records, benefits data, safeguarding files and electoral information. Once that data is sent to a third-party endpoint, the council has lost the ability to demonstrate control, and demonstrable control is the whole of its statutory duty.

Why can citizen data not leave the council estate?

Because a council is a data controller, not a data consumer. UK GDPR makes the controller accountable for every processing operation, including operations carried out by a processor on its behalf. When citizen data is sent to an external AI endpoint, the council becomes dependent on that provider's word about what was retained, logged or used for training, and a word is not evidence. The Information Commissioner's Office expects records that show, not assert, lawful processing. Data that has left the estate cannot produce those records. So the safe architecture is the one where the data never leaves: processing happens where the data already lives, behind the council's own perimeter.

How does offline, zero-egress AI actually work?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs on operator-owned hardware inside the council network, with no outbound connection to any model provider. Sovereign models run locally, so a prompt containing a resident name is answered on the council's own machines and is never transmitted. The perimeter is inbound-only: requests reach the system, but citizen data has no route out. There is no telemetry channel, no training callback and no silent sync. This is a design property, not a policy promise. A policy can be changed; an architecture with no egress path has nothing to change. These mechanisms, including hardware-attested identity bound to a sealed ledger and cross-model consensus that cross-checks an answer before it is acted on, sit within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending.

What can a data-protection auditor check?

An auditor should be able to verify four things without taking anyone's word:

• Locality: that inference ran on named hardware inside the council estate, evidenced by hardware-attested identity.
• Egress: that no citizen data left the perimeter, evidenced by the absence of any outbound data route.
• Provenance: who ran which action, on which record, at which time, evidenced by a signed audit entry.
• Integrity: that the log has not been altered after the fact, evidenced by a cryptographic chain.

In Mickai every action is sealed to a post-quantum signed audit ledger. Each entry is signed with FIPS 204 signatures and chained to the entry before it, so a deleted or edited record breaks the chain and the break is visible. The auditor checks the mathematics, not the supplier.

Which rules make this necessary?

Several, and they point the same way. UK GDPR requires accountability and data minimisation. The ICO expects provable records of processing. ISO/IEC 42001, the AI management-system standard, expects documented control over AI systems and their data. For councils touching regulated financial or critical-service functions, DORA, in force since January 2025, and NIS2 raise the bar on operational resilience and supplier concentration risk. None of these is satisfied by a screenshot. Each is satisfied by an independently verifiable record, which is exactly what an offline, sealed system produces.

“A council can only be accountable for citizen data it can still see, and it can only prove that accountability with a record no supplier can quietly rewrite.”

What about the EU AI Act deadline?

The timeline moved, and councils should read the move correctly. The high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028. The Article 50 transparency duties are largely unchanged. This is a build window, not a reprieve. The obligations that will arrive, logging, human oversight and traceability, are precisely the ones an offline sealed ledger already satisfies. A council that builds for verifiability now is ready early; a council that waits inherits a retrofit.

What should a council put in its procurement checklist?

Short, testable clauses beat long ones:

• Does it run fully offline on council-owned hardware, with a signed statement of no outbound data route?
• Can the council export the full audit log and verify its signatures itself?
• Is every operator action bound to an attested hardware identity?
• Are audit signatures post-quantum, using FIPS 204 and FIPS 205?
• Can the system operate with the network cable removed, and still log?

If a supplier cannot answer yes to the first two, the citizen data has already left the room.

Frequently asked questions

Can a council use a public cloud AI assistant on citizen data if it turns off training?

Turning off training reduces one risk but does not restore control. The prompt still leaves the council estate and travels to third-party infrastructure that may be reachable under laws such as the US CLOUD Act. The council still cannot produce an independent record of what happened to the data. For citizen data the safer position is processing that never leaves the perimeter.

What is a zero-egress perimeter?

It is a network design where requests can come in but citizen data has no route out. There is no telemetry, no model callback and no background sync. Because the egress path does not exist, there is nothing a misconfiguration or a future policy change can quietly open.

How does an auditor verify the AI log has not been tampered with?

Each entry in the audit ledger is signed and chained to the previous entry using post-quantum signatures under FIPS 204. Altering or deleting any record breaks the cryptographic chain, and the break is detectable by anyone holding the public key. The auditor verifies the signatures directly and does not need to trust the supplier.

Does offline AI mean the council needs its own hardware?

Yes, and that is the point. Sovereign processing runs on hardware the council owns and controls, inside its own network. This keeps citizen data on the estate and lets the council attest exactly where inference ran, which is what the accountability principle requires.

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

No. The Digital Omnibus deferred the Annex III high-risk obligations to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028, while Article 50 transparency duties are largely unchanged. The extra time is best used as a window to build verifiable systems, not a reason to delay.