Explainable AI for Boards and Regulators
Every high-stakes decision signed and traceable to its inputs and authority, so a board or regulator can verify exactly what happened and why
When an artificial intelligence system makes a decision that moves money, denies a claim, flags a person, or reshapes a supply chain, someone eventually has to answer for it. Not in the abstract, but in a room: a board committee, a regulator, an auditor, a court. The question they ask is deceptively simple. What happened, and why? For most of the current generation of AI, the honest answer is a shrug dressed up as a probability score.
We built Mickai, our Sovereign Intelligence Operating System, so that this question always has a complete answer. Explainability for us is not a dashboard that renders a plausible story after the fact. It is a lineage: every high-stakes decision signed, timestamped, and traceable to the exact inputs, the brain that acted, and the human authority that permitted it. A board or a regulator can verify precisely what happened and why, and they can do it without taking anyone's word for it.
The gap between a good answer and a defensible one
Most AI explainability today is post-hoc. A model produces an output, and a separate mechanism generates a narrative about why that output seemed reasonable. This is useful for engineers tuning a system. It is close to useless for a regulated institution, because the explanation is reconstructed, not recorded. Two auditors can be shown two different stories for the same event, and neither can be proven to be what actually drove the machine.
A defensible answer has a different shape. It is not a story generated on demand. It is a fact captured at the moment of action, cryptographically bound to the decision so it cannot drift, be edited, or be quietly regenerated to suit the room. Boards under the European Union Artificial Intelligence Act (EU AI Act), financial firms under the Digital Operational Resilience Act (DORA), and any organisation answerable under the General Data Protection Regulation (GDPR) increasingly need the second kind. We designed for the second kind from the first line of code.
Attesting the decision before it happens
At the centre of Mickai sits the Operation Attestation Record (OAR). Before any consequential action executes, the subsystem produces a signed record of what is about to occur: the operation, the brain proposing it, the inputs it drew on, the policy that applies, and the authority under which it may proceed. The signature comes first. The action comes second. Nothing of consequence runs unattested.
This ordering is the whole point. A log written after an action can be lost, altered, or contradicted by the action itself. An attestation written before the action, and required by the system as a precondition to acting, cannot be retrofitted to hide what really happened. When a regulator asks whether a control was in place at the moment of the decision, the OAR is the moment of the decision, sealed.
Lineage that reaches all the way back
An answer that stops at the output is not lineage. A supervisory reviewer does not only want to know that a loan was declined; they want to know which data fed that decision, which brain version reasoned over it, which policy governed it, and who was accountable for allowing the brain to act at all. Mickai threads every decision back through that full chain, so a single query resolves the entire story from outcome to origin.
Because each link is signed and the records are held in a tamper-evident, cryptographically-signed audit ledger, the chain cannot be broken in the middle without the break being visible. If an input changed, if a brain was swapped, if an authority was exceeded, the ledger shows it. This is what turns explainability from a courtesy into evidence. A board is not asking to be reassured. A board is asking to be able to prove, later, to someone harder to please.
Verification that does not depend on us
The weakest form of assurance is the kind that only works if you trust the vendor's servers. If verifying an audit trail requires calling back to the company that produced it, the audit trail is only as trustworthy as that company's continued goodwill and uptime. We reject that arrangement. Mickai signs its records with post-quantum signatures under the Federal Information Processing Standard 204 (FIPS 204) ML-DSA-65, and those signatures can be verified offline, by the customer, on hardware the customer controls.
That independence matters to a regulator more than any feature demonstration. It means an examiner can take the ledger, verify every signature without a live connection to us, and confirm the lineage stands on its own cryptographic merits. The public cloud giants, OpenAI, Microsoft, Amazon Web Services (AWS), Google and Oracle, are allies at a different layer of the stack, and they serve enormous needs superbly. What they cannot offer the regulated boundary is an audit trail that a supervisor can validate with no dependency on the provider at all. That is the ground we hold, on the customer's own terms.
Authority, revocation, and the high-stakes threshold
Explainability is incomplete without authority. It is not enough to know what a subsystem did; you must know it was permitted to do it. In Mickai, brains are revocable. A capability granted on Monday can be withdrawn on Tuesday, and the ledger records both the grant and the withdrawal. When a board asks whether a brain still had permission to act at a given hour, the answer is a signed fact, not an administrator's recollection.
For the highest-stakes actions, a single signature is not enough. We require multi-brain agreement combined with voice-biometric approval, so that consequential decisions carry the assent of more than one reasoning subsystem and a verified human. The record of that approval is bound into the lineage like everything else. When the decision is later examined, the reviewer sees not only what was decided but the full quorum that stood behind it.
Why this lives on hardware the customer owns
None of this holds if the data leaves the building. An audit trail that egresses to an external service inherits every jurisdictional, contractual, and confidentiality risk of that journey. Mickai runs on hardware the customer owns, air-gapped or on-premise, with zero data egress. The lineage, the ledger, and the verification all live inside the customer's own boundary, where sectors bound by the Health Insurance Portability and Accountability Act (HIPAA) or by International Traffic in Arms Regulations (ITAR) actually need them to live.
This is the difference between explainability as marketing and explainability as governance. A board does not want a persuasive interface. It wants a record it can defend, on infrastructure it controls, verifiable by people it chooses, against standards it is judged by. That is a substrate decision, and we made it deliberately. Our 104 filed UK patent applications, spanning about 2,340 claims and owned by Mickai LTD, describe these capabilities: attestation before action, offline post-quantum verification, revocable authority, and the signed lineage that ties them together.
The bottom line
For boards and regulators, explainable AI cannot mean a story told after the fact. It has to mean a chain of signed, timestamped, tamper-evident records that trace every high-stakes decision back to its inputs, its reasoning subsystem, and its human authority, verifiable offline and held on hardware the organisation controls. We built Mickai so that when the room asks what happened and why, the answer is already sealed, already provable, and already waiting. Accountability should not be reconstructed. It should be recorded.