AI Governance Platform, Or A Substrate That Governs Itself?

Governance belongs inside the substrate when you own the substrate. A platform bolted alongside a stack can only record what the stack chooses to report, while a governed substrate seals every consequential action into an append-only, hash-chained record in the same code path that performs the action. A separate AI governance platform is still the right answer for fleets of third-party models nobody controls, where observation from outside is the only lever. The difference is where the evidence is created, and evidence created at the point of action does not depend on a later stage choosing to forward it.

• A governance platform sits beside the stack and depends on what the stack emits.
• A governed substrate writes the record itself, in the same code path that performs the action.
• Separate governance is the right answer for fleets of third-party models nobody controls.
• Downstream telemetry can lose entries without anyone noticing. An edit breaks the hash chain, and the break shows to anyone verifying with the operator public key, so custody of the operator signing key is the thing to control.
• In Mickai, every consequential action is sealed into the Open Audit Record and signed with FIPS 204 ML-DSA.
• Anyone holding the operator public key can verify a Mickai record cold and offline.

What does a bolted-on AI governance platform actually see?

A governance platform integrates with an AI stack through logs, APIs and agents. It sees the inference calls the stack decides to emit, the prompts the stack decides to forward, and the outcomes the stack decides to summarise. That is a real capability, often the only one available. It is also, structurally, a report about the system rather than a property of it.

The gap shows up under pressure. A retry that never reached the logging path. A batch job that ran with export disabled. An operator who changed a threshold minutes before the collector started. None of these announce themselves. When the record is assembled downstream, absence looks exactly like nothing having happened.

When is a separate governance platform the right choice?

When you run a fleet of models you did not build, hosted by parties you do not control, external governance is the correct architecture. You cannot instrument what you cannot reach. A dedicated governance layer gives you one place to define policy, one inventory of what is in use, and one view across vendors whose internals are closed to you.

That case is common and legitimate. Arriving at AI through third-party endpoints is an ordinary starting point, and a governance platform is an honest response to it. Our argument is narrower: once the substrate is yours, paying an outside system to infer what happened inside it is a strange way to spend the control you already hold.

What changes when governance is part of the substrate?

In Mickai, governance is not a module that watches the system. It is the path every consequential action must travel. A capable model runs on hardware you own, fully offline over loopback only, with no outbound path by default, and consequential actions are staged for a human to approve or refuse.

Each sealed entry carries an index, a timestamp, the actor, the typed action, the target and a SHA-256 of its payload. Entries are chained, so editing one entry breaks every entry after it, and the break is detectable by anyone who verifies. That property is bounded by key custody: whoever holds the operator signing key could rewrite the chain and re-sign it. The chain is signed with FIPS 204 ML-DSA, the post-quantum signature standard. FIPS 203 ML-KEM is key encapsulation and never signs anything.

Identity follows the same rule. It is issued, not federated: each organisation holds its own signing key and ledger, seats grant or revoke studios individually, and licences bind to hardware. Nothing there asks an outside directory for permission, which is why the record stays complete when the network does not.

How do you prove a record was not edited after the fact?

Start by asking where the record is created. If a collector downstream of the work creates it, that collector is the weakest link, and its silence is indistinguishable from nothing having happened. If the same code path that performs the action creates it, the record and the action are one event.

Then ask who can verify it. A record only the vendor's console can read is a claim. The Open Audit Record is tamper-evident: hash-chained, signed, and verifiable cold and offline with the operator public key alone, which is why the operator signing key is the asset to guard. Deterministic engines produce every number, so identical inputs give identical results. An auditor need not trust a description of a calculation: they can rerun it and compare.

Does a governed substrate remove the need for a governance layer?

Not always, and we will not pretend otherwise. If part of your estate runs on external endpoints, that part still needs governing from outside, and a governance platform is the right instrument for it. Mixed estates are normal.

What changes is the shape of the problem. Work that moves onto a governed substrate stops needing to be observed, because it produces its own evidence as a by-product of running. The governance layer shrinks back to covering systems that will never let you inside them.

What should a buyer ask before choosing either approach?

Three questions separate the options quickly. Where is the record written, at the point of action or after it? Can that record be verified by a third party without the vendor present? And can a consequential action complete without a human in front of it?

The answers tell you whether you are buying evidence or buying reporting. Both have a place. Only one of them survives a hostile reading of the log.

Frequently asked questions

Do I need a separate AI governance platform if the models run on my own hardware?

If the whole estate runs on a substrate that seals its own record, a separate platform largely duplicates evidence you already hold. If part of the estate sits on third-party endpoints, keep external governance for that part. The dividing line is control, not scale.

Can someone edit the audit record after the fact?

The record is tamper-evident: it does not stop an edit, it makes an edit detectable. Entries are hash-chained and signed, so an alteration breaks verification from that point onward for anyone holding the operator public key. Checkpoints signed off the box and anti-rollback checks make truncation detectable too. The property rests on key custody, because whoever holds the operator signing key could rewrite and re-sign.

What intellectual property sits behind this?

Mickai LTD owns 104 filed UK patent applications carrying approximately 2,340 claims, working towards examination. The estate spans the architecture described here: audit, identity, entitlement and staged actions. Filed is not granted, and we say so plainly.

Can an external auditor verify a record without contacting Mickai?

Yes. Verification needs the record and the operator public key, and the organisation holds both. No connection to us, no licence check and no running system are required.

Where can I see this working?

Mickai runs a closed beta at mickai.co.uk/beta. Entry is selective and not every applicant is accepted, because each deployment binds to hardware the organisation owns. The most useful applications tell us which consequential action you would put behind the record first.