Can You Re-Run an AI Decision and Get the Same Result for an Audit?

Yes, but only if the system was built for it. A public cloud AI service cannot reproduce a past decision, because the model version and the routing behind the endpoint change without notice, so the exact conditions that produced the decision no longer exist. A reproducible decision needs four things held together: a pinned model version, the recorded inputs, a fixed seed where sampling is used, and a sealed record of the exact build. Mickai is a Sovereign Intelligence Operating System (a SIOS) built to do this. It runs offline on operator-owned hardware and cryptographically seals every action, so a decision made months ago can be reloaded and re-run against the same model, the same inputs and the same code.

Reproducibility has moved from a nice-to-have to a direct examiner question in 2026. Model-risk teams, DORA supervisors and internal audit no longer accept a plausible explanation of why a system decided something; they want to see the decision made again. An operator who cannot reproduce a past output has no defensible answer, and a hosted endpoint that silently updates its model cannot give one.

Why can a public cloud AI service not reproduce a past decision?

A hosted endpoint is a moving target. The provider updates the model, reweights routing between variants, and changes safety filters on its own schedule. None of that is versioned for the caller. The response a public cloud service returned in January may not exist in July, because the model that produced it has been replaced. There is no snapshot to reload. Under the US CLOUD Act the underlying data and logs also sit outside your control. Asked to run the exact decision again, a cloud service honestly cannot, because the state that produced it is gone.

What makes an AI decision reproducible?

Reproducibility is the discipline of removing every source of variation. Four inputs must be captured and frozen at the moment of the decision:

• The model version, pinned by content hash, not by a floating label that can be reassigned.
• The full input context: the prompt, retrieved documents, tool outputs and system configuration.
• The sampling parameters, including a fixed seed and temperature where any randomness is used.
• The exact build: the inference code, runtime and settings that turned those inputs into an output.

Capture all four and the decision becomes a function that can be called again. Miss one and the result drifts. Determinism is not bolted on afterwards; it is a property of an architecture that records the whole state before it answers.

How does deterministic inference actually work?

Because Mickai runs on operator-owned hardware, the operator controls every variable. The model weights are stored locally and pinned by hash, so the version cannot change underneath you. The inputs are recorded as they enter the system. Where sampling is enabled, the seed is fixed and logged. The build is versioned and sealed alongside the output. To re-run a decision, the operator loads the pinned model, replays the recorded inputs through the sealed build, and compares the new output to the original. We are honest about the limit: bit-for-bit identical output also depends on the numerical behaviour of the hardware, so where a residual difference arises from parallel computation it is bounded, documented and tested. For the highest-assurance cases we also apply cross-model consensus, running the same inputs through more than one sovereign model so an examiner sees agreement, not a single unverifiable answer.

“A decision an operator cannot reproduce is not an auditable decision, and no amount of after-the-fact explanation closes that gap.”

What can an auditor or model-risk examiner check?

An examiner does not want a narrative; they want to verify. With a sealed record they can pull the exact model hash used on the day, confirm it matches the build then in production, replay the recorded inputs, and watch the output regenerate. They can check the cryptographic signature on the ledger entry to confirm the record has not been altered since. They can inspect the hardware-attested identity to confirm which node and operator produced it. This is a named, repeatable test: load the pinned state, replay the inputs, verify the signature, compare the result. It either reproduces or it does not, checkable by a third party.

How is the record kept tamper-evident?

A reproducible decision is only as trustworthy as the record around it. Every action in Mickai is written to an append-only audit ledger and signed. The signatures use the post-quantum digital signature standards: FIPS 204 (ML-DSA) as the primary standard, with FIPS 205 (SLH-DSA) available for long-lived records. An entry therefore cannot be back-dated or edited without breaking the signature. Identity is hardware-attested and bound into the same chain, so a decision is tied to a specific attested node. The perimeter is zero-egress and inbound-only, so nothing leaves the operator estate to a third party who could rewrite history. Verification works offline, so an examiner can confirm a record years later without depending on any vendor still being online.

Which rules make reproducibility necessary?

Several regimes now assume a decision can be re-run. DORA, in force since January 2025, holds financial entities accountable for the behaviour of their systems and their providers. NIS2 extends duties of the same character to essential and important entities. GDPR gives individuals rights over automated decisions, requiring an operator to explain and stand behind a specific output. ISO/IEC 42001 sets the management-system expectation for AI governance. The EU AI Act sharpens this: 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 to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. The obligation to reproduce and evidence a decision is arriving, and the architecture that satisfies it must be in place before the questions start.

Frequently asked questions

Can a public cloud AI answer be reproduced months later for an audit?

Not reliably. Public cloud AI services update their models and routing without versioning it for the caller, so the exact conditions that produced an earlier answer usually no longer exist. There is no snapshot to reload. Reproducibility requires pinned local model versions and a sealed record, which a hosted endpoint does not give you.

What is deterministic inference?

Deterministic inference means fixing every variable that can change an AI output so the same inputs produce the same result. That covers the pinned model version, the recorded inputs, a fixed seed where sampling is used, and the exact build. Where a small residual comes from parallel hardware, it is bounded and documented rather than ignored.

Do fixed seeds alone make a decision reproducible?

No. A seed only controls the sampling step. Without also pinning the model version, recording the full input context and sealing the build, the same seed can still produce a different result because something upstream has changed. Reproducibility needs all four controls captured together at the moment of the decision.

How does an examiner verify the record has not been altered?

Each ledger entry is signed with post-quantum digital signatures under FIPS 204, with FIPS 205 for long-lived records. Any edit or back-dating breaks the signature, so an examiner can verify integrity by checking the signature offline. Identity is hardware-attested and bound into the same chain, tying the decision to a specific node.

Does running AI offline reduce audit quality?

The opposite. Running offline on operator-owned hardware means the operator controls the model, the inputs and the build, so the state that produced a decision can be preserved and reloaded. A zero-egress perimeter keeps records inside the estate, and offline verification lets an examiner confirm a decision years later without depending on any external service.