If it can't be audited, it doesn't go to production

The external auditor asks a simple question: why was this supplier payment posted on the 28th and not the 30th? Nobody in the company knows. The payment reconciliation agent proposed it, someone approved it, but there's no trace of which data the decision was based on or which rule the agent applied. The honest answer is “we don't know”, and in an audit that answer is expensive.

The scene is a composite. What it describes isn't an AI problem in particular, but a problem with any system that makes decisions without leaving a record. If an agent processes cases at scale or acts quickly, reconstructing each material decision becomes harder without records designed for it.

What traceability means

A system is traceable when it can reconstruct the decisions that matter. For a figure: which metric was queried, which version of its definition, and which sources and transformations were used. For an action: what triggered it, what data the agent used, what it proposed and, if approval was required, who gave it and when. Where a case requires individual records, that capability must be designed and limited by data permissions and privacy.

Lineage: from the figure to the row

Data lineage documents how a figure depends on datasets and transformations. When an agent answers how much overdue receivables total, it should be able to show the query, the definition of “overdue” and the sources used. If the use case and permissions allow it, a detail view can show the invoices behind the total. Lineage alone does not always provide that breakdown: keys must be retained and the query designed for it.

A figure without a verifiable definition, source or version is hard to defend.

Regulation points the same way

It isn't just good practice. Article 12 of the European Union's Artificial Intelligence Act, adopted in 2024, requires systems classified as high-risk to allow automatic recording of events during operation. The obligation depends on the system's classification and context of use; it does not apply to every business agent. Even outside that scope, keeping evidence helps investigate errors and answer audit questions.

What to record

• Relevant queries: query identifier or category, metric version and a reference to the result; redact or avoid free-text queries and sensitive data.
• Every tool call: which one, under which identity and with what result, redacting sensitive parameters.
• Proposals with business impact, with references to supporting evidence and detail proportionate to risk.
• Human control decisions: who approved, rejected or edited, and when, where that step exists.
• The version of the model, the instructions and the rules in force at that moment.

The last point is the most often forgotten. If the rule or the model changes tomorrow, you need to know which version each of yesterday's decisions was made with.

Designing it from day one

Designing records from the start makes it easier to investigate failures and compare versions. It isn't free: it takes storage, permissions, sensitive-data redaction and a retention policy. In agent infrastructure, connectors, tools and approvals should share operation identifiers so the path can be reconstructed without copying every step's data indiscriminately.

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.