Can councils run AI on resident and social care records without adding a cloud data processor?

Yes. A council can run AI over resident and adult social care records without adding a cloud data processor, as long as the system runs entirely on hardware the council owns and controls, with no records leaving the building. The reason is straightforward: if no third party ever receives or processes the records, there is no processor to name in your Article 28 contracts or your Record of Processing Activities. Mickai is a Sovereign Intelligence Operating System, a SIOS, built to work exactly this way: offline, on operator-owned hardware, with every action cryptographically sealed.

This matters in 2026 because almost all AI offered to local government is a hosted service. Even when the vendor promises a UK data centre, the records still leave council premises and a new sub-processor joins the chain. Adult social care records are special category data under UK GDPR, and councils carry Cyber Assessment Framework duties. A UK postcode on a data centre answers neither point.

Why does a UK data centre not settle the question?

Data location and data control are different questions. A UK data centre keeps the records in the country, but the hosting company still receives them, which makes it a processor. Under UK GDPR that triggers an Article 28 contract, due diligence, and an entry in your Record of Processing Activities. It can also bring sub-processors you have to track.

Ownership of the hardware matters more than the postcode. A service operated by a company headquartered overseas can be reachable under laws such as the US CLOUD Act, whatever the data centre address. Residency reduces one risk. It does not remove the processor, the contract, or the foreign-reach question.

How does AI run on council hardware without adding a processor?

The system is installed on machines the council already owns and runs inside its own perimeter. Sovereign models run locally, so the records are read and reasoned over in place. Nothing is sent to an external service for inference, which means no external party processes the data and no processor is added.

Four mechanisms make this dependable. A zero-egress inbound perimeter lets work come in while nothing leaves. Identity is hardware-attested and bound to the audit chain, so every action is tied to a known device and operator. The audit ledger is signed with post-quantum digital signatures. Cross-model consensus runs a decision past more than one model before it is trusted, which reduces single-model error on sensitive care work. This architecture is covered by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending.

“A council keeps control of social care data by keeping it in the building, because a processor you never add is one you never have to contract, assure or trust.”

Which rule makes this necessary?

Several duties point the same way. Adult social care records are special category data under Article 9 of the UK GDPR, so they carry the highest bar for lawful basis and safeguards. Article 28 governs any processor, and Article 30 requires you to record every one. The Data Security and Protection Toolkit sets the annual assurance standard for organisations handling health and social care data.

Councils also work to the Cyber Assessment Framework. Adding a cloud processor for AI widens the surface you must assess and assure. Keeping inference on owned hardware removes that surface rather than defending it.

What can an auditor check?

An auditor can verify the record without trusting a vendor's dashboard. Every action is written to a sealed audit ledger, and the ledger verifies offline, with no call to an external service. The signatures use the current post-quantum standards: FIPS 204, the ML-DSA signature scheme, is the primary seal, with FIPS 205, the SLH-DSA scheme, available as a second. These are signature standards, so the ledger is both tamper-evident and verifiable years later.

There is a plain test an auditor can run. Disconnect the machine from the network. If the AI still reads the records and the audit trail still verifies, the data never depended on leaving the building. A hosted service fails that test.

How does this map to the Cyber Assessment Framework?

The Cyber Assessment Framework asks you to manage security risk, protect against attack, detect events, and minimise impact. A design with no egress path and no third-party processor supports all four. There is no outbound route for records to be exfiltrated, no external assurance chain to maintain, and a signed ledger that makes detection and investigation concrete. The assurance story becomes shorter because the architecture removes risk instead of mitigating it.

Where does the EU AI Act timeline leave councils?

A UK council is not directly in scope, but many treat the EU AI Act as a baseline and align to ISO/IEC 42001 for AI management. The current position is worth stating precisely. The high-risk Annex III obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moving to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that as a build window, not a reprieve. Councils that put social care AI on sovereign, auditable foundations now will not be rebuilding under deadline later.

Frequently asked questions

Does a UK data centre count as keeping social care data in the building?

No. A UK data centre keeps the data in the country, which is a residency question, not a control question. The hosting company still receives the records, so it is a processor you must contract with under Article 28 and list in your Record of Processing Activities. Keeping data in the building means it never leaves your own hardware.

Is running AI on council hardware compatible with the Data Security and Protection Toolkit?

Yes, and it tends to simplify the assurance. The Data Security and Protection Toolkit asks you to show how health and social care data is protected. When inference happens on owned hardware with no egress, there is no external processor to assess and no outbound data flow to justify, so several toolkit questions are answered by the architecture itself.

Can a US-owned cloud service be trusted with special category records?

It depends on your risk appetite, but the US CLOUD Act means a US-headquartered provider can face lawful demands for data regardless of where the data centre sits. For special category social care records, many councils treat that reachability as an unacceptable residual risk. On-premises processing on council-owned hardware removes the exposure rather than contracting around it.

What is the difference between a data controller and a data processor here?

The council is the controller: it decides why and how residents' records are used. A processor is any third party that handles the data on the council's behalf, such as a cloud AI host. Every processor needs an Article 28 contract and a Record of Processing Activities entry. Run the AI on your own hardware and no processor exists, so neither obligation is created.

Does keeping AI in the building reduce model quality?

Not in the way people assume. Sovereign models run locally, and cross-model consensus checks a result against more than one model before it is trusted, which raises reliability on sensitive care decisions. Quality comes from the models and the checks around them, not from sending data to a public cloud service.