When an AI triage system is questioned, who has the records?

The incident

On 30 November 2023, a patient arrived at a hospital emergency department with a severe headache, fever and breathing difficulties ^[1]. The hospital used an AI-assisted system called Core-MG to allocate beds. According to the incident report on the AI Incident Database, the system allegedly gave the patient a low-priority score. The patient was sent to a general ward. Hours later, their condition worsened and they were transferred to intensive care, where they died the same day.

The incident is still being investigated. What is known is that the family and medical staff have questioned whether the AI system contributed to the delay in intensive care, and whether human oversight was adequate ^[1].

It is the kind of case that will happen again, somewhere, and when it does the question will be the same: what did the system do, and can anyone prove it?

What the AI Act requires

Emergency triage counts as high-risk AI under Annex III of the AI Act ^[4]. From 2 December 2027, systems like Core-MG must meet the high-risk requirements, and one of them is automatic logging.

Article 12 says high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[2]. The logs are meant to make the system traceable: for spotting risks, for monitoring after market release and for the user's oversight.

The article lists what to log, such as the period each version of the system was in use, its operation and any human decisions that might have affected it. It does not say how to protect the logs. It just asks for them to exist.

That gap matters, because logs kept by the same people who could change them are easy to challenge. Think of it like this: a flight recorder is sealed in a box that survives a crash. A log file on a server the airline controls is more like a diary. Someone will ask whether the diary stayed the same.

Who keeps the logs, and for how long

Under Article 19, the provider must keep the automatically generated logs it has control over for at least six months, unless another law requires more ^[3]. Under Article 26.6, the user must do the same with the logs it controls ^[3].

Six months is a floor. In healthcare, records are often kept for years. The point is that both the provider and the user have a duty to keep logs, and to keep them in a way that makes them useful later.

Article 26 also says users must monitor the system's performance and report serious incidents to the provider and to market surveillance authorities ^[3]. A serious incident is one that causes death or serious damage to health, property or the environment, or a serious and irreversible disruption of critical infrastructure ^[5].

When such a report is made, the logs become evidence. The question is whether they can be trusted.

The evidence question

In the Core-MG case, the questions are: what priority did the system assign, when did a human see it, and did anyone override it? If the system had been logging under Article 12, the log would contain that information. But a year later, when an investigation or a lawsuit starts, how does the hospital show that the log is what was written on the day?

A log its own IT department can edit, even with good intentions, is not hard to dispute. Access controls and monitoring are the foundation, but they do not answer the question: if someone with administrator rights changed a line, would it show?

That is where a digital witness fits. It does not replace logging. It makes logs hold up.

How a digital witness works here

Say a hospital runs a high-risk AI system for triage. Each time the system assigns a priority, the decision is written to a log: the patient reference, the model version, the inputs, the score and the time. A human reviews it and either accepts or overrides the decision. That decision, too, goes into the log.

Here, the thing to seal is each decision record as it is written. The system sends a fingerprint of the record to WitniumChain, not the record itself, and gets a witness ID back. The content never leaves the hospital's systems. The fingerprint is sealed on a chain where any later change would show, even one made by the hospital.

Months later, when a family or a supervisor asks what the system did on 30 November, the hospital can share the log record and the witness ID. Anyone can calculate the fingerprint again and check it against the sealed one. If it matches, nothing has changed since the day it was sealed. Change a single character and it will not match.

Who checks: auditors, supervisors, the family's legal representatives and, if it comes to it, a court.

What it shows: that the record is exactly what was written at that time.

What it doesn't do: it does not show that the decision was medically correct, that human oversight was adequate or that the log is complete. Those are separate questions. What it does is take the authenticity question off the table.

How it would work

1. The AI writes a decision record to the log.
2. A fingerprint of the record is sealed with WitniumChain through the REST API, the SDK or the MCP server.
3. Later, anyone you share the record with can check that it has not changed.

The first 2,000 witnesses a month are free.

What this means for you

If you provide or use high-risk AI in healthcare, here are the questions to ask now:

• Does your system log the information Article 12 requires, and does it do so automatically?
• If a decision is questioned a year from now, can you show what the system did on that day, and which version was running?
• Who in your organisation can access and edit the logs, and would a change show?
• If a serious incident happens, can you produce the logs a supervisor or a court will ask for, in a form that holds up?

The law asks for the logs. Whether they hold up as evidence is a separate matter, and it is worth deciding early.

What to watch

The high-risk requirements for Annex III systems, including automatic logging, apply from 2 December 2027 ^[4]. Providers and users have just over a year to get ready.

For AI in products covered by Annex I, such as medical devices, the high-risk requirements apply from 2 August 2028 ^[6].

If you are building or using AI in emergency triage, bed allocation or similar systems, the time to sort out logging is before the rules apply, not after an incident.