Context OS is one layer of a Governed AI stack.
Updated 31 October 2026
An auditor reviewing an AI agent does not start with the chat transcript. They ask what the agent saw, what it was allowed to do, who approved any exception, and whether the decision can be reproduced later. Ordinary logs usually answer only the first question. Decision traces are a separate design choice that answers the rest. This guide explains where the two differ, what each should contain and which fields to keep.
The four questions an auditor asks
These four questions are our framing for an audit review, not a list published by any regulator. They are useful because each one points to a different record, and most enterprises hold only some of them.
- What did the agent see? The inputs it received and their versions at the moment of the action.
- What was it allowed to do? The rule or policy that applied, and the result of checking the action against it.
- Who approved the exception? The named person or role, the time of approval, and the stated reason.
- Can the decision be reproduced? The stored output, and the versions of the model, prompt and policy in force.
What an ordinary log records
A conventional application log records events. A request was received, a record was read, a tool returned a response, an error occurred. Such logs are essential for debugging, security monitoring and incident response. They are often timestamped and retained centrally, which is valuable in its own right.
They rarely record why an action was permitted. That reasoning usually lives elsewhere: in a policy engine, a ticket or an approver's inbox. A log can show that a payment instruction was sent. It cannot, by itself, show that the instruction passed a limit check or that a manager accepted the exception behind it.
What a decision trace adds
A decision trace records how a particular decision was made. It groups the inputs, the policies evaluated, any exception granted and the approver under one decision identifier. Where a log captures a moment, a trace captures a case.
In practice, an auditor who receives a trace can check each step in order. They can confirm the inputs existed at the time, confirm the rule version was active, confirm the approver held the authority to approve, and confirm the outcome matches the record. A plain log supports only the first of those checks reliably.
The trace does not replace the audit trail a bank already keeps. The audit trail proves the sequence of events. The decision trace explains the authority behind each consequential step.
Logs versus decision traces
The table below describes the target state for a decision trace. Many systems will meet only some of these rows at first.
| Auditor question | Ordinary log | Decision trace |
|---|---|---|
| What happened? | Yes, as separate events | Yes, linked to one decision identifier |
| What context was used? | Often missing or partial | Versioned references to each input |
| Which policy applied? | Rarely recorded | Policy identifier, version and result |
| Who approved an exception? | Depends on the approval tool | Approver, role, time and reason |
| Can the decision be reconstructed? | Only by joining several sources by hand | Yes, provided inputs are stored or referenced |
What the EU AI Act asks, and what it does not
Article 12 of Regulation (EU) 2024/1689, the AI Act, requires that high-risk AI systems technically allow the automatic recording of events over their lifetime, to support traceability. In summary, Article 14 requires that high-risk systems can be overseen by people, including the ability to interrupt the system and an awareness of the risk of relying too heavily on its output. Both articles appear in the EUR-Lex text of the AI Act.
Neither article uses the term decision trace, and neither defines a log format. The Digital Omnibus on AI, Regulation (EU) 2026/1744, amends the Act, including some application dates, as shown in its EUR-Lex record. Check which dates apply to your system in the amended text, not in a summary.
The questions an auditor will ask, and the field that answers each
Use this list as a review sheet when you walk an auditor through an agent decision.
- Which agent version acted? The agent identifier, release version, model identifier, and the prompt and policy versions in force at the time.
- What did it know? Context references with source system, retrieval time, and a content hash or version number.
- Why was it allowed? The policy identifier, rule version and evaluation result, including each limit that was checked.
- Who said yes? The approver's identity and role, the approval time, and the stated reason for any exception.
- Can we show it again? The stored output the agent actually produced. Avoid relying on a fresh rerun to explain an old decision, because a rerun may not reproduce the original result.
The last point matters for design. A rerun of an agent is a new decision, made with the model, data and policy as they stand today. Store the output the agent produced at the time, with the inputs and versions it used, so the original decision can be shown exactly as it happened.
A checklist for your next audit
Run these five checks before the auditor arrives, not during the meeting. Each check maps to one of the four questions above, so a failed check tells you which record is missing and which team owns it.
- Confirm that every agent action carries one decision identifier across all the systems it touches.
- Check that each policy evaluation records its rule version and its result.
- Sample five exceptions and confirm each has a named approver, a time and a reason.
- Pick one past decision and reconstruct it from stored records alone, without asking the team to explain it.
- Write down what you cannot reconstruct, and close that gap before the audit date.
Who should own the gaps
Gaps in traces are usually found by the first test, and they are usually owned by no one. Assign each gap to a named team with a closure date. Common owners are the platform team for missing fields, the process owner for approvals recorded outside the system, and the risk function for policies without version control.
Report open gaps to the same committee that reviews other control gaps. Treating trace gaps as a separate, lesser issue delays the fixes that matter most.
Where this guide stops
We have not published measured audit outcomes for decision traces. The field list and checklist are our recommendations, based on the regulatory text above and on the questions auditors raise. In the primary sources we reviewed, no regulator defines decision traces, and the term is still developing. If you adopt it, record how your system meets each field, and test it against one real decision before you rely on it.
Frequently asked questions
Are decision traces the same as audit logs?
No. Audit logs record events, such as a request, a read or an error. Decision traces record the reasoning context of one decision: the inputs, the policies evaluated, any exception and its approver. Logs show what happened. Traces explain why it was allowed. Most regulated enterprises need both, linked by a shared identifier.
Does the EU AI Act require decision traces?
Not by that name. Article 12 requires high-risk systems to allow automatic logging of events over their lifetime for traceability. Whether a decision trace is needed depends on your system design, your risk classification and your auditor's expectations. Application dates were amended by Regulation (EU) 2026/1744, so check the amended text.
What should an AI agent log entry contain?
At minimum: agent and model versions, a timestamp, the user or system that invoked the agent, references to the inputs, tools called, the output, and any policy result. Store records in a form that resists later editing where possible. Add an approver field for exceptions. This is our recommended minimum, not a legal checklist.
Can an agent decision be replayed exactly?
Do not assume so. A rerun of an agent uses the model, data and policy as they stand at the time of the rerun. Store the output the agent produced originally, together with its inputs and versions, and use that stored record to explain the decision.
Related reading
- How decision traces build trust in AI agents
- How AI agent audit trails support bank compliance
- Which platforms give AI agents governed business context?
Sources
- Regulation (EU) 2024/1689 (AI Act), Articles 12 and 14. EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- Regulation (EU) 2026/1744 (Digital Omnibus on AI). EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
Disclosure: This article is published by XenonStack, which develops ElixirData, a platform that produces decision traces.
