Compensating Rollback: How Sovereign AI Safely Undoes a Wrong Action in a Regulated Workflow

The question a regulator actually asks

When an automated action goes wrong inside a bank, an insurer, or an NHS trust, the interesting question is never how clever the model was. It is what happened next. Who caught it, how fast, what was undone, what was left standing, and can you prove every step of that to a supervisor months later. Under PRA and FCA operational resilience rules, under DORA, and under the EU AI Act's expectations for high-risk systems, the burden sits with you to show that a wrong action is contained and correctable by design, not by luck.

Most AI systems have no honest answer here. They can generate an action. They cannot cleanly take it back. A cancelled database transaction is not the same as an underwriting decision that already priced a policy, a payment instruction that already left the building, or a customer message that already landed. Real workflows have side effects in the outside world, and the outside world does not roll back just because your transaction did.

This is why Mickai treats reversibility as a first-class architectural feature. We call the mechanism compensating rollback, and it is one of the reasons regulated businesses can run autonomous AI inside their own walls, on-prem or air-gapped, without holding their breath.

Rollback and compensation are not the same thing

A rollback undoes an uncommitted change inside a single system. Useful, but small. It only works while the action is still contained.

A compensating action is the discipline of reversing an effect that has already committed and already had consequences. If a booking was made, the compensation is a matching cancellation. If a payment was released, the compensation is a recall or an offsetting credit with a clear audit link back to the original. If a notice went out, the compensation is a correction sent to the same recipient with the error explicitly flagged. The point is not to pretend the first action never happened. The point is to return the business, the customer, and the record to a defensible state, and to make that return itself an auditable event.

Mickai builds every autonomous workflow as a sequence of steps that each carry their own compensating counterpart. A step is never allowed into production unless its reversal is defined. If you cannot say how an action is undone, the arbiter does not let it run.

How compensating rollback works inside the SIOS

Three parts of the Mickai architecture make this real rather than aspirational.

First, the deterministic arbiter. Mickai runs 50 brains under a single deterministic arbiter that sequences work and decides what commits. Because the arbiter is deterministic, the exact order of steps is known and replayable. When something has to be undone, the system knows precisely which steps ran, in which order, and therefore which compensations to fire and in which reverse order.

Second, the OAR, our tamper-evident audit record. Every action and every compensating action is written to the OAR and signed with ML-DSA-65, a post-quantum signature scheme. This matters twice over. It means the original mistake is on the record, and it means the correction is on the record too, cryptographically bound to the action it reverses. A supervisor does not have to trust a screenshot or a support ticket. They can verify the signed chain: action taken, error detected, compensation executed, state restored.

Third, hardware-bound identity and air-gapped RAG. The whole system runs on infrastructure the business owns, on-prem or air-gapped, so the audit trail and the rollback logic never leave the customer's control and never depend on a third party's goodwill. Reversibility you do not own is not reversibility you can rely on in front of a regulator.

Why this is a compliance feature, not just resilience

Engineers reach for rollback for uptime. Compliance officers should reach for it for evidence. That distinction is the whole argument of this piece.

Operational resilience regimes ask you to define impact tolerances and to show you can stay within them through severe but plausible disruption. An AI action that fires incorrectly is exactly such a disruption. Compensating rollback lets a Chief Risk Officer state, with proof, that the maximum time an erroneous automated action persists is bounded, and that its effects are reversed to a known state within that bound.

For a General Counsel or a Data Protection Officer, the same mechanism answers the harder questions. Under UK GDPR, an automated decision that should not have been made needs to be remediated and the remediation demonstrated. Compensating rollback produces that demonstration as a signed record rather than a promise. For a Chief Compliance Officer under FCA Consumer Duty, being able to show that a wrong outcome was detected and actively put right, not quietly overwritten, is the difference between a controlled incident and a reportable failing.

For a Head of Model Risk working to SS1/23, reversibility gives the model risk framework a containment layer: when a model output is later judged wrong, the effect it produced has a defined, evidenced path back. And for the Board or a non-executive director asking whether autonomous AI is safe to deploy at all, the honest engineering answer is that safety in a regulated setting is not the absence of mistakes. It is the guaranteed presence of correction. Compensating rollback is how that correction is guaranteed.

Where this lands across sectors

The pattern generalises. In reinsurance and in life and health insurance, a mispriced treaty or a wrongly bound risk is reversible with a signed offsetting entry rather than an awkward phone call. In wealth and asset servicing and among custodian banks, a settlement instruction that should not have gone can be recalled with the reversal itself on the audit chain. For building societies, credit unions, neobanks, and mortgage lenders, a lending decision made on stale data can be withdrawn and re-run with the whole sequence provable to the PRA. For digital-asset and crypto firms operating under intense scrutiny, the ability to show a bounded, signed correction to an on-chain-adjacent action is not a nicety, it is a licence condition in spirit.

Each of these is served by a purpose-built Mickai Studio, from Tyche for underwriting to Plutus for finance to Nomos for compliance, and every Studio inherits the same rollback discipline from the substrate. You do not bolt reversibility on per use case. It is in the floor.

The strategic picture

Mickai is built and LIVE, and we are building to scale. The moat under this is deliberate: 104 filed UK patent applications, roughly 2,340 claims, held by Mickai LTD, covering the arbiter, the signed audit record, and the reversibility mechanics described here. Filed, not granted, which gives us a priority date and a prior-art position while the category forms. As a dated third-party signal, in June 2026 Micky Irons was ranked number 4 on Crunchbase, with Mickai in the top one to two percent of companies globally. The sovereign AI market that this architecture serves is projected to grow from around USD 40 billion in 2025 to roughly USD 148 billion by 2032.

We see Mickai as an ally to the frontier labs, not a rival to them. The dual-buyer thesis is straightforward: regulated enterprises need to own and run AI inside their own walls, and the infrastructure that lets them do that safely is exactly the kind of category a hyperscaler would eventually want to own. Reversibility, provable and signed, is one of the load-bearing reasons.

Micky Irons, founder and CEO of Mickai.

FAQ

What is compensating rollback? It is a mechanism that reverses an AI action that has already committed and had real-world effects, by executing a defined counter-action and writing that correction to a signed audit record. It differs from a database rollback, which only undoes uncommitted changes inside one system.

How is it different from an ordinary undo? An undo assumes the action was contained. Compensating rollback assumes the action already reached the outside world, a payment sent, a policy priced, a notice delivered, and returns the business and the record to a defensible state with the reversal itself logged as an auditable event.

Why does a compliance officer care, not just an engineer? Because it produces evidence. Operational resilience, UK GDPR, and FCA Consumer Duty all ask you to show that a wrong outcome was contained and corrected within bounds. Compensating rollback turns that into a signed, verifiable chain rather than a verbal assurance.

Where does the audit record live? In the OAR, a tamper-evident record signed with the post-quantum scheme ML-DSA-65, running on infrastructure the customer owns, on-prem or air-gapped, so it never leaves their control.

Frequently asked questions

What is compensating rollback?

It is a mechanism that reverses an AI action that has already committed and had real-world effects, by executing a defined counter-action and writing that correction to a signed audit record. It differs from a database rollback, which only undoes uncommitted changes inside one system.

How is it different from an ordinary undo?

An undo assumes the action was contained. Compensating rollback assumes the action already reached the outside world, a payment sent, a policy priced, a notice delivered, and returns the business and the record to a defensible state with the reversal itself logged as an auditable event.

Why does a compliance officer care, not just an engineer?

Because it produces evidence. Operational resilience, UK GDPR, and FCA Consumer Duty all ask you to show that a wrong outcome was contained and corrected within bounds. Compensating rollback turns that into a signed, verifiable chain rather than a verbal assurance.

Where does the audit record live?

In the OAR, a tamper-evident record signed with the post-quantum scheme ML-DSA-65, running on infrastructure the customer owns, on-prem or air-gapped, so it never leaves their control.