What an AI-assisted decision has to leave behind

A question you cannot currently answer

An assessor, a client, or a lawyer asks why a particular consignment was released without inspection in March.

The honest answer is that the risk model scored it low. The next question is the difficult one: what did the model see, and who decided that was good enough?

In most implementations there is nothing to answer with. The score was displayed, somebody acted on it, and the screen refreshed. The decision happened; the reasoning evaporated.

Why the record disappears by default

A human decision leaves residue almost accidentally. An email, a note in the margin, a name against an approval, someone who remembers the conversation.

A model-assisted decision leaves none of that unless it was designed to. The output is transient by nature — a number on a screen at a moment in time, generated from inputs that have since changed, by a model version that may since have been updated.

Nobody chose to lose it. It was never captured, because capturing it was not part of anybody's specification.

Five things worth keeping

None of this requires specialist tooling. It requires deciding, once, what gets written down.

• What the model was asked. The specific inputs at that moment. Not the data source in general — the values that produced this output.
• What it returned, including any confidence or score, and any explanation it offered.
• Which version produced it. A model updated in June did not make March's decision, and without the version you cannot reconstruct anything or defend it.
• Who acted, and whether they agreed. Acceptance and override should both be recorded, with a reason for the override. A system that records only the overrides teaches people not to override.
• What happened next. The outcome, linked back. Without it you have an audit trail but no way to learn whether the model is any good.

The override record is the one that matters

Most organisations, if they capture anything, capture the recommendation. The override is more valuable.

An override is a person with context judging that the model is wrong. Recorded consistently, overrides are the richest source of information you have about where the model's boundaries actually are — the edge cases nobody thought of at validation, the local knowledge the training data never held.

Recorded nowhere, the same override is made repeatedly by different people, each of whom assumes they are the first, and none of whom can demonstrate that the model has a systematic blind spot.

An override that leaves no trace is not a control. It is a workaround that happens to be correct.

What this looks like to an assessor

ISO 9001:2026 does not arrive with a clause that resolves any of this, and anyone promising otherwise is selling something. What it does is tighten the expectations around operational control, competence and accountability — and those apply regardless of whether a person or a model operates the control.

So the question an assessor asks is not do you use AI. It is the ordinary one they have always asked: show me how this control works, show me it was validated, show me it is monitored, show me who owns it.

If a model is part of the control and you cannot produce that, you do not have an AI problem. You have an unevidenced control, which is a finding with a long-established name.

One thing to do this quarter

Pick one decision where a model already has influence. Try to reconstruct a single instance from three months ago — inputs, output, version, who acted, what followed.

However far you get before the trail goes cold is the length of your current record. For most organisations it is about a day.