The Setup: One Decision, In Scope

Our illustrative decision: an autonomous credit agent evaluates a €5,000 limit-increase request. Credit scoring sits in Annex III, so if this system is deployed in the EU, it is high-risk by classification — which activates the record-keeping, transparency and oversight obligations that apply to high-risk systems from December 2, 2027.

Before that date, teams could treat these articles as a documentation exercise. Now they are operational requirements: the system itself must produce the records. That is the difference this walk-through is about — not what the articles say, but what your pipeline must emit while the decision happens.

Station 1 — The Trace (Article 12: Record-Keeping)

Article 12 requires high-risk systems to be capable of automatically recording events, with logging that ensures a level of traceability appropriate to the system's purpose. The operative word is traceability of the decision — not request logging.

So the first thing the agent does is open a trace: the inputs it received, the evidence it consulted (as references, not paraphrases), the reasoning steps it took, and the options on the table. Each event is chained to the previous one in a tamper-evident hash chain, so any later modification of history is detectable. The chain is the quiet workhorse of everything downstream: it is what lets a third party later confirm the record is the record.

What an auditor sees at this station: a complete, append-only account of the decision as it unfolded — and a verification result confirming the chain is intact. Deep dive on the requirement: Article 12 logging requirements.

Station 2 — The Sealed Packet (Article 13: Transparency)

Article 13 requires the system's operation to be sufficiently transparent for deployers to interpret its output and use it appropriately. A stream of events is evidence, but it is not yet an interpretation surface — so when the agent reaches its conclusion, the trace is sealed into a decision packet.

The packet is the structured summary of the whole decision: the decision itself, the context, the deliberation with arguments for and against, the alternatives that were considered and why they were rejected, references to the evidence, the rationale, the expected impact, and the human-oversight status. It is signed at sealing, so it can be verified offline. We take the packet apart field by field in Inside the Signed Decision Packet.

Therefore: when a deployer asks "why did the agent recommend declining?", the answer is not a grep through logs — it is a bounded, readable object with the counterarguments included.

Station 3 — The Approval (Article 14: Human Oversight)

Our decision exceeds the deployer's threshold, so it lands in an approval queue instead of executing. A credit analyst reviews the packet — the arguments, not just the score — and approves with a note. That approval becomes an oversight event on the same trace.

Here is the part policy documents cannot do: proving the approver was human. In AIAgentree, human-judgment permissions are refused to machine API keys at creation — structurally enforced — so an approval event in the trail could only have been created by a person. The full argument is in Human Oversight You Can Prove, and the obligation itself in Article 14 human oversight.

Station 4 — The Decision Record (Article 86: The Explanation)

Months later, the affected customer exercises their Article 86 right to an explanation. One export call produces the Decision Record: a self-verifying PDF/A-3B document containing a human-readable account of the decision, the live tamper-evidence verification result, a signature block, and the signed machine packet embedded in the file. The regulatory narrative prose in the Record is currently a draft pending legal sign-off; the data, signatures and verification underneath are production.

The Record is what makes the explanation portable: it can be handed to the customer, their lawyer, or a regulator, and verified without logging into anything. The page-by-page walk-through covers it in depth.

Station 5 — The Evidence Package (What the Regulator Receives)

Now the audit request arrives: evidence for the credit agent, covering the last quarter. Instead of a war-room month, the response is a generated package — a ZIP organized into per-article folders:

"Isn't This Overkill for One Decision?"

For one decision, yes — that is precisely the point. The pipeline only works because no station involves a human doing paperwork: the trace is emitted by the SDK as the agent runs, sealing is one call, the approval is a queue the analyst already works in, and the Record and package are exports over data that already exists.

Compliance programs fail when the record is produced after the decision, by people, under deadline. They hold when the record is a by-product of the decision happening. That inversion — record as exhaust, not as homework — is the entire design argument, and it is why the two seconds at Station 1 matter more than the eight months after.

Diagnostic question: in your current stack, which of the five stations exist as running code today — and which exist as a document someone would have to write during an audit?

A Technique You Can Run This Week

Sources & Further Reading