I have spent a long time building the least glamorous part of an AI system: the record of what it did.
While most of the attention went to wrapping models, I was working on the thing every regulated buyer eventually asks for and almost no stack can produce. Not "is the model clever enough". That question is nearly always answered. The one that kills deployments is this:
Show me what the system did, on whose authority, over which documents, and prove that record has not been edited since.
I have watched pilots die on that question. Not on capability. On evidence.
Here is how we built the answer, and where its limits actually are.
The order matters more than the components
The instinct is to build the AI product, then bolt governance on. That order cannot work, because the evidence layer determines what the rest of the system is even allowed to do. If the model can already reach the network and act on its own initiative, no amount of downstream logging turns that into an auditable system. You are writing a description of events after the fact and asking people to trust the describer.
So we inverted it. The evidence and governance layer came first, and the model was placed inside it.
Practically, that means:
- A capable model runs on hardware the customer owns, over loopback only.
- No outbound network path is enabled by default.
- Consequential actions are not executed on the model's own initiative.
That last point is the one engineers tend to argue with, so let me be specific about it.
Staged actions, and refusals as first-class events
A consequential action is staged. It is proposed, held, and presented to a named person who approves or refuses it. Nothing happens until that decision exists.
The part people miss: a refusal is recorded as a first-class event, not discarded. If you throw away refusals, your audit trail quietly becomes a record of things that succeeded, which is a very different and much less useful artefact. When an auditor asks "did this system ever try to do X", a log of successes cannot answer. A log that includes what was proposed and declined can.
The record itself
Every consequential action is sealed into an append-only, hash-chained record. Each entry carries:
- its position in a total order
- a timestamp
- the acting identity
- a typed action
- the target
- a SHA-256 digest of the payload
Each entry commits to the hash of the entry before it. The chain is signed using FIPS 204 ML-DSA, the post-quantum digital signature standard.
The property that follows: alter one field anywhere in that history and the hashes stop lining up and the signature stops verifying. You cannot quietly edit entry 400 of 900 and leave the rest intact, because 401 committed to what 400 used to be.
Verification needs only the record and the operator public key. No API call. No vendor dashboard. No network. An auditor can sit in a room with the machine disconnected from everything and satisfy themselves about what happened.
Where this actually stops, said plainly
I would rather describe this accurately than oversell it, because the overselling is what gets found out in a technical review.
The record is tamper-evident, not tamper-proof. Nothing about a hash chain prevents someone with sufficient access from destroying the whole thing, or from writing a new valid chain from scratch. What it does is make alteration of history detectable rather than deniable.
And that property rests on one assumption: the operator keeps custody of the signing key. If the key is compromised, an attacker can forge a chain that verifies. Post-quantum signatures do not change that. Any system claiming that its audit log "cannot be altered" is either being loose with language or has not thought about key custody.
That is the honest boundary. Inside it, the guarantee is genuinely useful.
Identity is issued, not federated
Each organisation holds its own signing key and its own ledger. Entitlements are issued locally, and seats grant or revoke capabilities individually.
The consequence is architectural rather than cosmetic: no supplier sits in the trust path for identity, entitlement or the audit record. Verification does not require anything from us. That is deliberate, because a trust path that runs through the vendor is exactly what a sovereignty requirement is trying to eliminate.
What is actually shipping
Being concrete about state, because vapour is easy to write:
Mickai ships as an operating system with a studio for each area of work. Sixty-three are specified. Fourteen are production-ready today, forty-nine are in development. They run on fifty registered knowledge bases that retrieve over material the customer holds, without that material leaving the estate.
On the IP side, since people ask: Mickai LTD is the applicant on 104 filed UK patent applications carrying approximately 2,340 claims, filed at the UK IPO and working towards examination. They are filed and pending, not granted, and I will not describe them otherwise.
The beta
The design partner beta is open at mickai.co.uk/beta.
It is selective, and the page runs a hardware capability check in your browser before an application is accepted, because the deployment only works where the hardware does. If your organisation's binding constraint is that the data genuinely cannot leave your infrastructure, that is the case this was built for.
If you think the threat model above is wrong, or that the key-custody caveat undermines the whole approach, I would genuinely like to hear it. That argument is more useful to me than agreement.
More at mickai.co.uk.
Top comments (0)