Free tools Windows power users keep installed
One-click scans. No signup required.
An AI decision record is useful only if it can show what information was available when an agent acted, how the decision was configured, and what happened afterward. Allard Buijze, Axoniq’s founder and CTO, argues that many operational systems retain current state or actions without preserving enough history to answer those questions. His proposed approach is an architectural recommendation, not a universal standard; the EU AI Act’s logging duty has a narrower, defined scope.
What should an AI decision record contain?
Buijze’s framework separates a traceable decision into three parts. Keeping them together helps an organization investigate a consequential action later, rather than relying on a present-day explanation detached from the original circumstances.
As an Amazon Associate I earn from qualifying purchases.
- The input state: the information the agent could access at decision time, preserved in that historical state.
- The decision context: the conclusion and the model, prompt, policy, and tools involved.
- The resulting effects: the actions taken downstream because of the decision.
This is Buijze’s argument for a fuller decision record, not a consensus definition of explainability. An explanation of a conclusion can still be incomplete if the original inputs cannot be recovered or the resulting actions cannot be linked back to it.
Why a database pointer may not be enough
A log entry that points to a customer profile or other database record may appear to preserve the decision’s context. But if that record is later edited, the pointer may resolve to new values—not the values the agent saw. Buijze recommends recording the relevant values themselves or referencing an immutable version, so a later investigator can reconstruct the historical input.
The record should also connect decisions to effects in both directions. Correlation and causation identifiers can help follow a decision forward to resulting actions, or start with an effect and trace backward to the decision that caused it.
What makes the record dependable?
Buijze proposes several design properties to test. They are useful engineering criteria, but the article does not report independent performance testing or comparative product results.
- Append-only and tamper-evident: preserve an auditable history rather than silently replacing earlier entries.
- Transactional coupling: avoid a split history in which an action succeeds but its record fails, or the reverse. Test failures that occur between the action and the record write.
- Historical inputs: verify that the record can recover the values actually available at decision time, not merely the current contents of referenced records.
- Explicit causal links: make it possible to trace decisions to their effects and effects back to their causes.
- Appropriate retention: keep records for the period in which questions about the decision may arise.
- Domain readability: make entries understandable to the people who will need to assess them, not only to the system that generated them.
- Replay through corrected logic: preserve enough information to examine what a revised decision process would do with the original case. Replay is an investigative aid, not proof that a later result was the result originally produced.
Event sourcing or a companion log?
Buijze describes two possible architectures and cautions against applying event sourcing everywhere. The choice is whether the event history is the authoritative source of state or a supplemental record alongside existing systems. Neither approach is universally superior; the right fit depends on how the organization needs to recover inputs, link effects, and maintain the record.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Design question | Event sourcing | Companion log |
|---|---|---|
| Is the event history authoritative? | Yes: the event sequence is the state. | No: the existing system remains the source of truth; the log supplements it. |
| How are actions and records coupled? | The event sequence underpins state, so the design must preserve a consistent history. | The log sits beside the existing system; the integration must prevent action and record histories from diverging. |
| Can historical inputs be reconstructed? | Only if the recorded events preserve the needed historical values or versions. | Only if the log captures those values or immutable references; a mutable pointer alone may be insufficient. |
| Can effects be traced to a decision? | Requires explicit causal links in the event history. | Requires explicit causal links between the log and downstream actions. |
| What must be planned? | Retention, domain readability, and replay through corrected logic still need deliberate design. | The same properties matter, along with the reliability of writing the log alongside the authoritative system. |
What Article 12 of the EU AI Act requires—and what it does not
Article 12(1) of the EU AI Act states: “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.” Article 12(2) describes relevant logging purposes: identifying risk situations or substantial modifications, facilitating post-market monitoring, and monitoring operation under Article 26(5). The consolidated regulation on EUR-Lex is identified as updated 27 July 2026: EU AI Act, Article 12.
This provision applies to high-risk AI systems, not every AI system or agent. It requires technical capacity for automatic event recording and logs relevant to specified purposes. It should not be described as requiring every organization to preserve every prompt, a complete reasoning trace, every input snapshot, and all downstream business effects. Those broader elements are part of Buijze’s architecture argument, not the full text of Article 12. The Act also specifies additional minimum logging details for the remote biometric identification systems identified in Annex III point 1(a).
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Where to start when introducing decision records
Buijze recommends beginning with consequential decisions already delegated to agents, then prioritizing them by who may later ask about them and when. This is implementation advice from the author, not a process prescribed by the regulator. A practical assessment can turn that advice into concrete questions:
- Identify delegated decisions: list actions an agent can take and the systems or people affected.
- Rank the need for an answer: consider who could question each decision and how long afterward that question might arise.
- Trace one real decision end to end: check whether you can recover its historical inputs, decision context, and downstream effects.
- Test the failure boundary: simulate the action succeeding while the log write fails, and the reverse. Establish how the system detects and resolves divergent histories.
- Choose the record’s role: decide whether an event sequence should become authoritative or whether a reliable companion log is a better fit for existing systems.
The exact-title article is a first-person, vendor-associated opinion piece, not an independent study. Buijze writes, “For fifteen years, being able to explain your systems was a quiet virtue that few people asked about.” The statement reflects his perspective; the article does not quantify the prevalence or cost of untraceable AI decisions.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
