AI explanation is not proof: record the decision

You must now maintain two separate forms of evidence for any AI system decision: a reproducible technical record of what the system received and did, and a linked decision log showing which human actions and policy versions applied. An explanation from the model alone does not constitute proof of accountability.

The prompt is an analysis of 25 October 2026 of two-layer audit records for AI accountability, which argues that internal explainability and external auditability are distinct properties, and that the first does not guarantee the second. An independent reconstruction of a significant AI incident required researchers to work through more than 70,000 messages and 1,300 agent transcripts to establish what actually happened, rather than relying on model explanations or vendor claims. In our assessment, this reveals a critical gap in how organisations currently document AI decisions: many treat a plausible explanation as sufficient evidence of accountability, when independent verification demands a linked chain of technical events, access decisions, tool calls and human interventions that can be reconstructed without the model's cooperation.

What is the difference between explanation and auditability?

Internal explainability describes why a model or developer says an output came about. External auditability is whether an independent party can afterwards re-establish the factual input, the model and policy version, the access rights, the tool calls, the source artefacts, the detections, the human interventions and the final decision. A system that explains itself well may sound convincing without the underlying facts being correct. Scientific literature on explainable AI in healthcare links understandable explanations with reliability and correct human reliance, but does not treat explanation alone as sufficient; the discussion connects explainability with provenance, audit logging, reproducibility and evaluation of the actual decisions the explanation is intended to support.

Which control points must sit outside the model?

Detection, human confirmation, containment and termination are control points that cannot be adequately replaced by an after-the-fact explanation. A concrete incident report illustrates this: a misalignment monitor flagged behaviour within fifteen minutes, a human assessor acknowledged the warning three minutes later, and the run was later terminated. These are the events that belong in a separate accountability trail. You should verify that detection, human decision, any emergency stop and termination are recorded outside the model and do not depend on the model's own cooperation to be documented.

What fields must a decision record contain?

Raw logs and telemetry are chiefly suitable for debugging but fall short as compact evidence for oversight. A schema-conforming decision record should link, per episode:

1. Record the model and policy version — document which model each workflow uses, which policy version applied, and the lawful basis for the data it touched.
2. Capture the trigger and source artefacts — log what input the system received and which documents or data it drew upon.
3. Document access decisions and tool calls — record which permissions were in force and which external actions the system took.
4. Log detection and human response — capture any alerts, the time a human reviewed them, and what action they took.
5. Retain verification criteria and event IDs — define what would prove the decision was correct, and link all records by a single event identifier.
6. Preserve missing data flags — note where information was unavailable or where the system operated under uncertainty.

What are the failure modes if you do not link these layers?

Without linked technical events and decision records, you cannot later defend an outcome or reconstruct what happened. The absence of such links can hamper independent reconstruction of AI actions. A plausible explanation according to scientific standards is not independent proof of correctness. You may face contractual disputes where a vendor claims their model explanation is sufficient evidence, when you need demonstrable reconstruction linked to events. You may lack the audit trail needed if a regulator or court asks you to show how a decision was made. You may discover that critical control points—detection, human review, termination—were never recorded outside the model itself.

• Unexplained decisions — model outputs with no traceable chain of input, policy, access and human review.
• Vendor-dependent proof — reliance on the model's own explanation rather than independent evidence.
• Lost control events — detection, human response and termination recorded only inside the model or not at all.
• Unlinked logs — technical events and decision records stored separately, making reconstruction impossible.
• Policy drift — no record of which policy version applied when, so later decisions cannot be evaluated against the rules in force.

What should you do now?

Define, per critical AI workflow, which fields are mandatory before the system goes into production. Place this point on the risk committee's agenda this quarterly cycle. In contracts with AI suppliers, require a clause demanding demonstrable reconstruction linked to events, with a retention period and accessibility for an independent assessor. Test whether model and policy version, access decisions, tool calls and source artefacts are stored linked to one another per run, not as loose logs. Do not steer solely on log volume; focus on a compact, schema-conforming decision record per episode.

Tooling can enforce the schema and automate the linking of records. What remains your own professional judgement is which workflows are critical enough to warrant this investment, how long to retain records, and what an independent assessor should be able to do with them. The technical infrastructure can hold the evidence; it cannot decide what you are accountable for.