The traces of a decision
An AI agent receives a request, consults a knowledge base, prepares a proposal, and hands it to an operator. In some cases, it opens a ticket, sends a message, or updates a record. Each step can leave a trace: the model in use, the instructions it received, the documents it retrieved, the tools it called, the time of the action, and the resulting output.
That reconstruction becomes necessary when an outcome calls for review. Anyone examining a rejection, an error, or an improper action has to follow the path from the original request to its consequence. The European Union's Artificial Intelligence Act requires high-risk AI systems to have technical capabilities for recording relevant events throughout their lifetime and to provide deployers with information that helps them interpret the output.1
Recording opens the work of review. Understanding a case requires a distinction between the event, its explanation, the causes that produced it, and the changes that can reduce its recurrence. A log describes a sequence. An explanation examines how that sequence produced an output. A causal analysis also examines source quality, system configuration, available authorisations, and the conditions in which people used the result. Prevention reaches completion when a change has been tested in subsequent work.
NIST distinguishes transparency, explainability, and interpretability.2 Transparency makes information about a system and its outputs available. Explainability concerns the process that produces an output. Interpretability connects that output to its intended purpose and context of use. Each activity requires different evidence and involves different people.
Consider a support request rejected by an application. The person reviewing the case needs access to the request itself and to the documents actually used. They need to trace the rule, threshold, or instruction that guided the proposal. They need to verify the action carried out, the identity under which it took place, and the authorisation that permitted it. They also need to see what happened to the request and to the person who submitted it.
These pieces of information rarely sit in the same place. A knowledge base keeps the sources. The application configuration keeps instructions and versions. The system that exposes a tool retains authorisations and completed requests. An operator records a confirmation, correction, or cancellation. A complaint can reveal a consequence that no operational indicator had shown.
Improvisation helps clarify why this chain requires attention. A musician acts in the present through technique, memory, practice, and listening to others. Every gesture draws on a repertoire and responds to the conditions of the moment. Craft, narrative, critique, and improvisation describe different ways of connecting experience, material, and audience.
An AI agent produces a sequence of actions within a repertoire defined by others. Instructions guide the model. Documents establish part of the material available to it. Tool interfaces set the actions it can take. Authorisations determine what the agent may consult, change, or send. Responsibility runs along this chain: from those who define the rules to those who approve the system's use, examine its outcomes, and intervene when a case requires correction.
Turning knowledge into data always involves selection. Every record preserves some distinctions, aggregates others, and leaves further elements aside. A report on completed cases may be arithmetically accurate while placing delays, messages, corrections, and additional work in the background. An answer generated by AI may appear complete while depending on a documentary base that lacks the decisive circumstance.
Attention to data therefore begins before the model. Those who design a system need to establish which decision its categories must support, which exceptions require separate recording, and which sources allow a conclusion to be challenged. Those who use the system need to recognise uncertainty, pause an action, and request a review. Those who receive the consequence need a route for reporting an error.
Here I find a punk stance useful: make a decision's wiring, rules, and responsibilities accessible. This stance rejects the prestige of opacity and asks for a simple test. Who can consult the data? Who wrote the instructions? Who authorises the tool? Who can stop the action? Who records and verifies the correction?
The same logic applies to security. Authorisations belong in the system that executes the action, within the user's context and with proportionate privileges. For high-impact operations, human confirmation creates a point at which the case can be examined again.3 The trace preserves the action's history; authorisation rules define the conditions that permit it.
Indiscriminate data collection would produce surveillance and confusion. Selection therefore needs a criterion: retain the information required to reconstruct a decision, discuss its consequences, correct a rule, and identify the person or role responsible for intervening. Privacy, access, and retention periods belong to the same design.
Let us return to the original request. A system response can accelerate the first examination. A decision becomes reliable when a competent person can follow the traces that produced it, test the available evidence, and change the rule that guided the action. This capacity for correction gives the record its value and makes the system governable.
Regulation (EU) 2024/1689, Articles 12 and 13, EUR-Lex. Article 12 governs the recording capabilities of high-risk AI systems; Article 13 requires a level of transparency that enables deployers to interpret and use output appropriately.↩
National Institute of Standards and Technology, AI Risks and Trustworthiness, sections 3.4 and 3.5. This reference supports the distinction between transparency, explainability, and interpretability.↩
OWASP, LLM06:2025 Excessive Agency. Its guidance recommends downstream authorisation, least privilege, and human approval for high-impact actions.↩