skip to main content
iatroX JournalClinical AI

The Evidence Problem After an AI Error: How Do You Establish What Happened?

Featured image for The Evidence Problem After an AI Error: How Do You Establish What Happened?

You establish what happened by preserving the relevant workflow evidence, not merely saving the final AI answer. The investigation may need the original information, product version, retrieved sources, edits, approvals and external actions. That evidence should be collected through authorised organisational processes, with a clear purpose and access controls, rather than copied into personal accounts.

This article is dated 10 October 2026 and proposes an evidence-preservation approach for healthcare organisations in England. It is not legal advice about a particular claim. GMC record standards and ICO storage-limitation guidance provide different parts of the context: accurate clinical records and justified retention must be considered together.

The final note may hide the event you need to explain

Consider a fictional specialist clinic. An AI-generated letter includes an incorrect statement about whether a test has been completed. The clinician corrects the sentence in the record, but a referral was already prepared from the earlier draft.

The current record now looks reasonable. It does not, alone, show what the receiving service saw, whether the patient received a different version or why the original statement appeared. An investigation confined to the latest note could miss both the origin and the downstream consequences of the error.

The immediate task is to identify the disputed claim and its path. Was it present in the input? Was it inferred during summarisation? Did a later template introduce it? Did the reviewer amend it before or after transmission? Those are separate possibilities requiring different evidence.

Preserve a chain of events rather than a pile of screenshots

A useful evidence map links information to its status and time. It should distinguish a patient statement, a retrieved reference, a model-generated interpretation, a clinician amendment and an action recorded by another system.

Evidence categoryQuestion it can help answerImportant limitation
Original inputWhat information was actually available?It may itself be incomplete or incorrect
Product and configurationWhich function and settings were in use?A brand name alone is insufficient
Retrieved materialWhich source passage supported the claim?A current webpage may differ from the passage used
Generated outputWhat did the system present?It does not establish what the user understood
Edits and approvalsWhat changed, and when?An approval event is not proof of adequate review
External receipts and recordsWhat was sent, stored or accepted?A technical receipt may not prove clinical completion

This is a proposed investigation structure. It is not a requirement to retain every data category indefinitely or to create information that the system never recorded.

Model identity is useful but does not guarantee reproducibility

Knowing the foundation model can help, but the complete product may also depend on prompts, retrieval indexes, templates, integration settings and local data. An output can change when any of those changes, even if the visible model name remains the same.

A later rerun may therefore be informative without reproducing the historical event. It should be labelled as a new test, with its date and configuration, rather than presented as a reconstruction of what certainly happened. An apparently corrected answer does not prove that the original report was mistaken.

For a proposed supplier contract, ask which version identifiers, change records and relevant logs can be made available during an investigation. Establish whether the organisation can obtain them promptly, in an intelligible form and within the agreed information-governance arrangements. Do not wait until a dispute to discover that the necessary evidence is inaccessible.

Preserve context without preserving everything

The investigation needs enough information to distinguish causes and assess consequences. It does not automatically need unrelated patient histories, every recording from a clinic or unrestricted access to staff accounts.

Define the incident, affected time window, relevant functions and information required. A targeted preservation instruction can then be issued through the appropriate legal, clinical and information-governance teams. Where a legal hold or other retention obligation applies, it should be documented and reconciled with the organisation's normal deletion process.

The ICO's storage-limitation guidance, checked on 10 October 2026, does not impose one retention period for all personal data. That flexibility is not permission to keep everything just in case. The organisation should be able to explain the purpose of the retained evidence, who can access it and when the need will be reviewed.

Do not let preservation become a second incident

A clinician who emails screenshots to a personal account may believe they are protecting the investigation. They may instead create an uncontrolled copy of sensitive information. A supplier support ticket can create a similar problem when it receives more of the patient record than needed.

Use the approved incident route and ask for an authorised preservation process. Record what was observed in a factual way, including what remains uncertain. Avoid editing the original account to make it fit a later explanation, and avoid using a chatbot to rewrite confidential incident material without an approved basis.

If the incident may include a personal-data breach, ICO breach guidance supplies a separate assessment and reporting framework. A clinical safety incident, a data breach and a complaint may overlap, but they are not interchangeable categories.

Investigate the reviewer and the environment fairly

A log showing that a clinician approved a draft does not reveal the whole review process. What information was displayed? Was the relevant source accessible? Were warnings visible? Had the output changed between review and transmission? Could the clinician reasonably identify the defect from the material available?

These questions should not be used to dismiss individual responsibility. They help distinguish it from organisational and product factors. The same fairness applies to the supplier: an error inherited from an incorrect source record is different from an unsupported inference, although both may still require a system response.

An effective investigation should seek the explanation best supported by the evidence, not the explanation most convenient for the organisation. Where the record is incomplete, say so. Absence of a log should not become proof that an event did not occur.

Turn the findings into testable changes

A proposed final account should separate the established event, likely contributing factors, remaining uncertainty and corrective actions. Each action needs an owner and a way of checking whether it addresses the identified problem.

For the fictional clinic, correcting the current note is only one step. The service must establish whether earlier material reached another recipient and whether that recipient's decisions need review. A revised interface or template should then be tested against the failure mechanism, not merely accepted because the wording now looks better.

A source-linked learning tool can help clinicians explore a general knowledge gap identified by the incident. It should not become an unofficial evidence locker. For an iatroX learning exercise, separate the clinical concept from the incident evidence: use a fictional example, keep the investigation material in its authorised system and do not confuse educational reflection with historical reconstruction.

Frequently asked questions

Is saving the AI answer enough to investigate an error?

Often not; the input, configuration, sources, edits and downstream actions may be essential. Preserve only the relevant evidence through authorised processes.

Does rerunning the same question reproduce the original event?

Not necessarily. A rerun may use different sources, settings or software behaviour and should be described as a new test rather than definitive historical evidence.

Should clinicians retain patient screenshots personally in case of a claim?

They should use approved organisational and advisory routes instead of creating uncontrolled personal copies. Necessary preservation can be arranged with appropriate access, purpose and retention controls.

Check general clinical evidence without uploading an incident record →

More from the Journal