On 2 August 2026 the record-keeping obligations of the EU Artificial Intelligence Act began to apply to high-risk systems. Article 12 requires that such a system technically allow for the automatic recording of events across its lifetime, and that it provide a level of traceability of its functioning appropriate to its intended purpose.1
For one category of system, the Act says precisely what that means. Where a high-risk system performs biometric identification, the logging must as a minimum capture the period of each use with start and end times, the reference database the data was checked against, the input data for which the search produced a match, and the identity of the people involved in verifying the results.2
That list is worth reading twice, because of what it includes. It does not merely require a record that an identification occurred. It requires a record of the material the system was working from at the moment it decided. Somebody drafting the Act understood that an identification cannot be reviewed unless a reviewer can see what was compared against what.
For every other high-risk system, the standard is that traceability should be appropriate to the intended purpose, and the Act offers no technical definition of appropriate. The regulation got specific exactly once, in the case where the determinative input is a photograph and therefore obvious.
I should say plainly that we build governance and agent infrastructure, and that this argument came out of trying to work out what our own systems should record. Some of what follows describes an obligation that is easier to state than to discharge.
The prompt is not the input
Consider what "input data" means for a system that assembles its own context.
A model receives a prompt. In almost any deployed system of consequence, that prompt was not written by a person and sent to a model. It was constructed at runtime: some instructions from a template, some passages retrieved from a corpus because they scored well against the query, some facts pulled from a memory store because the system had learned them in previous sessions, some records fetched from a database through a tool call, and somewhere in the middle the thing the person actually asked.
The output is determined by all of it. Two people asking an identical question a week apart will receive different answers, not because the model changed but because the assembled context did. The corpus was reindexed. A memory was written. A document was updated. A ranking function returned a different set.
Now ask what a compliant log records. In most systems: the request, the response, timestamps, a model identifier, token counts, latency, perhaps a policy decision and its outcome. All the things that are easy to capture because they cross a boundary somebody instrumented.
What it does not record is the assembled context, which is the only part that explains the answer. The log shows that the system was asked a question and gave a reply. It does not show what the system was working from when it did. An auditor reading that log six months later can establish that an interaction occurred and can read what was said. They cannot establish why, because the determinative input was built in memory, sent to a provider, and discarded.
The biometric provisions get this right. The rest of the regime leaves it to whatever "appropriate" turns out to mean, and the current answer, in most deployments, is that it means the request and the response.
What medicine learned first
Medicine ran this experiment across two decades and reached the answer the hard way, through litigation.
The clinical record exists partly to establish a state of knowledge. When care is assessed after the fact, the question is not only what a clinician did but what a reasonable clinician in possession of the same information would have done, which makes the information itself the thing that has to be reconstructed. This is why contemporaneous notes carry evidential weight that later reconstruction does not, and why a note written at the time is treated differently from one written afterwards.
The move to electronic records changed what could be reconstructed, and it took a while for anyone to notice how much. Audit trails in modern electronic health record systems capture not only what was entered but when a clinician opened a record, which screens they viewed, how long they spent on diagnostic data, and whether a value was typed by a person or integrated automatically from another system.3 That last distinction matters more than it sounds: a number that arrived from a pharmacy system carries a different weight in review than one somebody keyed in, and the record has to say which.
The harder problem arrived with clinical decision support. When a system checks a prescription against known interactions and raises an alert, the interesting questions afterwards are often about what did not happen. Did the alert fire? Did the clinician see it? Was it dismissed, and against what other information on the screen at that moment? Did the rule fail to fire because the underlying reference data had not been updated?
None of that is answerable from a log of the prescription. It is answerable only from a record of what the system presented and what it was working from, which is a different and considerably more expensive thing to keep. Health informatics arrived at the position that reconstructing a clinical decision requires reconstructing the information environment in which it was taken, and built the audit infrastructure accordingly.
When I was researching healthcare AI regulation at the start of this year, comparing how Texas, Europe, the FDA and the UK were each approaching the same problem, the thing that stayed with me was not any of the four frameworks. It was how much of the clinical record turns out to exist for a purpose nobody designed it for. It was built so the next clinician on shift would know what had happened. It became, without anyone setting out to build it, the mechanism by which a decision taken years earlier can be examined on its own terms rather than with the benefit of knowing how things turned out.
Software has no equivalent tradition, and it shows in what we instrument. We log what crosses a boundary, because a boundary is where the instrumentation goes, and we call the result an audit trail on the strength of it being written down and timestamped.
The field is now applying the same reasoning to retrieval-augmented clinical systems, and doing it early rather than after the first case. A framework published in 2026 in Frontiers in Artificial Intelligence sets out an auditable, source-verified architecture for clinical decision support built on retrieval, in which data provenance is carried through the pipeline so that a recommendation can be traced to the specific sources that produced it.4 The authors are treating provenance as a requirement of the architecture rather than an addition to it, on the reasoning that a clinical recommendation which cannot be traced to its evidence is not usable in clinical practice regardless of how good it is.
That is the standard the rest of the field has not yet adopted, and healthcare adopted it because the consequences of not having it are visible in court.
Ninety days
There is a specific failure mode that makes this more than a documentation preference, and it is the one that action logs are structurally unable to surface.
A retrieval system is built from a corpus. The corpus was accurate when it was indexed. Over the following months the underlying documents change: a policy is superseded, a price list is updated, a procedure is revised. The index does not necessarily notice. One industry analysis reports accuracy degradation within ninety days of deployment in around 73 per cent of organisations, attributed almost entirely to document staleness rather than to any change in the model.5
Consider what that failure looks like from the outside. The system is available. Latency is normal. Error rates are flat. The model has not changed. Every metric on the dashboard is green, because every metric on the dashboard measures the machinery rather than the material. The system is confidently returning answers grounded in a version of the world that stopped being true in the spring.
An action log cannot detect this and cannot help an investigator afterwards. It will faithfully record that a question was asked and answered, and the answer will look reasonable, because it was reasonable given what the system had. The only way to establish what went wrong is to know what the system was working from at the time, and to know when that material was last confirmed against its source.
This is the same distinction the freshness of a clinical reference database makes: the interaction checker that fails to fire because its reference data is eighteen months old produces no error, no alert and no log entry. It produces silence, which reads exactly like safety.
Four things worth recording
The Act does not define appropriate, and there is a reasonable argument that it should not, since what is proportionate for a recruitment screening tool differs from what is proportionate for a system managing critical infrastructure. But the biometric provisions establish the shape of the answer, and the shape generalises further than the category it was written for.
Four things would make a decision reconstructable, and none of them is exotic.
What was assembled. Not necessarily the full text of the context, for reasons of cost and confidentiality addressed below, but a record identifying which sources contributed to the answer and in what version. The biometric provision asks for the reference database and the input data that produced the match. The general form of that requirement is a record of what grounded the response.
When that material was last confirmed. A corpus has two dates that are usually conflated: when it was last built, and when its contents were last checked against the systems they came from. A system indexed last week from documents revised last year is current by one measure and stale by the one that matters.
Where the material came from. The distinction electronic health records draw between a value a person typed and a value that arrived from another system is the same distinction between a fact somebody wrote down deliberately and one a model inferred and stored. Both may be true. They warrant different confidence, and a record that flattens them has destroyed the information a reviewer needs.
What was excluded, and why. This one is missing from most designs and is the one an investigator will eventually want. If a system had access to a document and did not use it, because a ranking function scored it below a threshold or a policy suppressed it, that is frequently the more interesting fact. A system that silently omits is harder to review than one that records its omissions.
None of this requires new regulation. All of it is already implied by traceability of the functioning of the system appropriate to its intended purpose, once you accept that the functioning of a retrieval-augmented system includes the retrieval.
The storage objection
The immediate objection is storage, and it is a real one rather than an excuse. Retaining the full assembled context of every interaction means retaining a substantial multiple of the traffic itself, and doing so for a period long enough to be useful. For a system handling millions of interactions this is not a rounding error.
The objection is weaker than it first appears, because it argues against the most expensive possible implementation rather than against the requirement. A record identifying the sources that grounded a response, the version of each, and a digest over the assembled content is small, and it is sufficient for most of what a reviewer needs. It establishes what the system was working from without reproducing it. Where the material is still held, it can be reconstructed on demand. Where it is not, the record at least establishes what is missing, which is more than silence provides.
There is a second objection with more force. In some settings the assembled context contains material that should not be retained at all, and a record-keeping regime that requires storing it would create a confidentiality risk in the name of accountability. The answer there is the same one: a reference and a digest identify what was used without holding it. A regime that forces an organisation to choose between an audit trail and a data protection obligation has been designed badly, and the reference-and-digest form is what avoids the choice.
What the cost objection genuinely rules out is retaining everything forever by default. It does not rule out knowing what your system was working from.
Where this argument stops
Three limits, stated because the case is stronger without the parts it cannot support.
A record of what a system was working from does not establish that the answer was right. It establishes what the answer was based on, which is a smaller claim. Plenty of decisions are well grounded and wrong, and a provenance record makes that legible rather than preventing it.
Nor does it reach the model itself. Knowing which passages were in the context window says nothing about how the weights combined them, and no amount of record-keeping at the boundary solves interpretability. This article is about the material a system was given, which is a tractable problem, rather than about what it did with it, which is not.
And the volume question is unresolved in practice rather than in principle. The reference-and-digest form is cheap in the abstract, and I am not aware of published work establishing what it costs at the scale of a large deployment or what proportion of investigations it actually satisfies. That is an empirical question, it is answerable, and as far as I can tell nobody has published an answer.
What a regulator will ask for
There is a doctrine in litigation, expressed differently across jurisdictions, that where a party fails to preserve evidence it had a duty to keep, the court may infer that the missing evidence would not have helped them. The absence is not neutral. It is construed.
Organisations deploying high-risk AI systems in Europe are now under an obligation whose specificity varies by category and whose general form has been left to interpretation. The interpretation that will be tested is not the one in the compliance documentation. It is the one that emerges the first time a regulator or a claimant asks an organisation to explain a particular decision, and the organisation produces a log showing a question, an answer, a timestamp and a model version.
That will not be a compliance failure in any obvious sense. The system recorded events automatically across its lifetime, exactly as required. It simply recorded the wrong ones, because the events it was built to capture were the ones that crossed an interface somebody had already instrumented, and the material that determined the answer never crossed anything.
Medicine reached the position that reconstructing a decision means reconstructing what the decision-maker had in front of them, and it reached it by discovering what happens in the alternative. The clinical record is not a log of treatments given. It is an attempt, imperfect and much argued over, to preserve a state of knowledge so that somebody later can ask whether it was reasonable to act on it.
The question worth putting to any system now covered by Article 12 is not whether it is logging. Almost all of them are. It is whether anybody could reconstruct, from what is being kept, what the system knew at the moment it decided. If the honest answer is no, that is worth establishing before somebody else asks.
Footnotes
-
Regulation (EU) 2024/1689, Article 12 (Record-keeping). High-risk AI systems must technically allow for the automatic recording of events over the lifetime of the system, at a level of traceability of the functioning of the system appropriate to its intended purpose. The obligations for high-risk systems began to apply on 2 August 2026. Article 12 itself specifies no retention period; retention obligations fall on deployers under separate provisions, and secondary coverage frequently conflates the two. ↩
-
Regulation (EU) 2024/1689, Article 12(3), which applies to high-risk systems referred to in Annex III point 1(a). The minimum logging comprises the period of each use with start and end date and time, the reference database against which input data has been checked, the input data for which the search has led to a match, and the identification of the natural persons involved in the verification of the results. ↩
-
Electronic health record audit trails commonly capture record access, screen views, time spent on specific data, and the provenance of individual values, including whether a value was entered by a person or integrated automatically from another system. This capability has made audit trails significant evidence in clinical negligence proceedings, which is the mechanism by which the practice became standard rather than aspirational. ↩
-
"An auditable and source-verified framework for clinical AI decision support: integrating retrieval-augmented generation with data provenance," Frontiers in Artificial Intelligence, 2026. The framework carries provenance through the retrieval pipeline so that a recommendation can be traced to the specific sources that produced it. ↩
-
This figure comes from industry analysis rather than peer-reviewed research and should be read as practitioner reporting. The direction is consistent with what retrieval practitioners describe, and the specific proportion should be treated as indicative rather than measured. ↩