WARRANTThe definition, self-contained.
A per-action evidence record is a record that states, for each action an AI agent took, which regulatory obligation governed that action and whether the action satisfied it. It is independently verifiable without contacting the vendor. It is the unit of the evidence layer: one consequential agent action in, one record out.
The phrase carries three claims, each load-bearing. Per-action: the record is scoped to a single action the agent took, not to a session, not to a system lifetime, not to a day. Evidence: the record exists to be read by an outside party who was not present, retained against the regulator clock rather than the engineer's debugging window. Record mapped to a specific obligation: each record names the exact clause it was evaluated against, for example EU AI Act Article 12(1), and states whether the action met it.
A running log over a system lifetime and a discrete record per action both technically allow for the recording of events. The difference is what a regulator can do with each. A log says the system kept records. A per-action evidence record says: on this action, this clause applied, and here is whether it was met. The first answers a question about the system. The second answers a question about the action. Where the EU AI Act leaves the granularity undrawn is the subject of Article 12 and agentic per-action records.
What it is not.
The most common error is to confuse the per-action evidence record with the log it is built from. They sit at different layers, answer to different readers, and survive for different lengths of time. The four-layer split is worked through in the four-layer evidence stack; the short version is the table below.
| Property | Observability log / trace | Per-action evidence record |
|---|---|---|
| Reader | The on-call engineer | The auditor, the regulator, a court |
| Question | What happened, and is the system healthy? | Which obligation governed this action, and was it met? |
| Timeframe | Now to last 7 to 30 days | Years, against the regulator clock |
| Granularity | Spans, metrics, sampled events | One record per consequential action |
| Verifiable by an outsider | No, you must trust the vendor's store | Yes, independently, without contacting the vendor |
An observability platform produces no record an outside party can independently check. It rotates events out before the regulator clock starts, and it samples high-volume traces. A per-action evidence record is built downstream of the trace, retained against the obligation's horizon, and constructed so any party can confirm it has not changed since the action, without contacting the vendor.
What it proves, and to whom.
A per-action evidence record makes four claims an outside reader can check. Each is a property a sceptical auditor can test, not a marketing line.
The reader differs by setting. The deployer of the high-risk agent reads it first, because the deployer carries the obligations and signs their name to what the agent does; that responsibility is set out in the Article 26 deployer obligations. The auditor reads it during a post-incident review. The regulator reads it in place of the firm's telemetry when an inquiry opens. Because it is independently verifiable without contacting the vendor, a court or a notified body can read it with no dependency on the vendor being online or honest.
Which regulations require it.
No regime uses the phrase "per-action evidence record". Each writes the same underlying demand in its own register: produce, retain, and stand behind a record of what the AI did, mapped to the obligation that governed it. The general anchor is the EU AI Act:
Article 12 sets the obligation; Annex III sets which systems are in scope, including the Annex III §5(b) creditworthiness use case that pulls a lending agent into high-risk. The same demand recurs across regimes. One agent action evaluated against many regimes at once is the subject of one agent, many jurisdictions. The per-clause mapping, in brief:
| Regime | Anchor clause | What the record must show per action |
|---|---|---|
| EU AI Act | Art. 12(1) + Annex III + Annex IV | Lifetime event record for the high-risk use case; technical documentation of the action. |
| NYDFS Part 500 | § 500.6(a)(2) | Audit trail to detect and respond to Cybersecurity Events for a Covered Entity. |
| Federal Reserve | SR 11-7 (carried by SR 26-2) | Documented model risk management for any model whose output materially affects the institution. |
| FCA | Consumer Duty, PS22/9 Principle 12 | Evidence of good outcomes and avoided foreseeable harm for retail customers. |
| RBI | FREE-AI framework | Responsible-and-ethical-enablement record across the AI's lifecycle. |
| MAS | FEAT principles | Fairness, Ethics, Accountability, Transparency evidence for the decision. |
| India DPDP Act 2023 | Data Fiduciary obligations | Lifetime accountability of the Data Fiduciary to the Data Principal for the personal data touched. |
The clauses differ in scope and framing, and they do not all collapse into one another; where they diverge, an honest record holds the difference explicit rather than pretending the strictest covers all. What they share is the unit: the record of a single action, mapped to the clause that governed it. That shared unit is what a per-action evidence record names.
The fields it carries, made explicit.
A per-action evidence record is structured, not prose. Three groups of fields make it readable by a machine for matching and by an auditor for judgement. The shape below is the citable evidence shape, the same one a regulator can field-match without parsing display text.
The action. Drawn from the agent's execution trace as trace.actions[*]: the actor, the action taken, the subject it touched, the inputs it weighed, the outputs it produced, the timestamp. This is what happened, grounded in the trace rather than asserted later.
The authorization envelope. Per action, an authorization_envelope records whether the action was within_purpose, whether preconditions_met, whether human_oversight_appropriate, whether the action was reversible, and a justification grounded in the trace. This is the structured assessment of whether the action was permitted to be taken, in the form an auditor can read row by row.
The obligation map. For each action, the specific sub-clause it was evaluated against, the verbatim regulator text, the canonical source URL, and a compliance status. A field maps to a clause: trace.actions[*] satisfies EU AI Act Article 12(1) for the action; the full authorization_envelope satisfies NYDFS § 500.6(a)(2); authorization_envelope.human_oversight_appropriate carries the EU AI Act Article 14 human-oversight finding. The mapping is the field-to-clause binding that lets a regulator read the record against the statute.
The record is constructed so the same bytes can be checked by a third party, with no call to the vendor, and so the finding can be reproduced from the trace it was built on. The structure is the evidence; the structure is what a regulator field-matches against the clause.
The deliverable layer, not the runtime layer.
A per-action evidence record lives downstream of the agent. The agent runs; it emits an execution trace; the record is built from that trace after the action, mapped to the obligation, and assembled into a deliverable a regulator reads. It is not a guardrail that stops a bad action in the millisecond before it happens. It is the artefact that proves, months or years later, what the agent did and whether it was within its obligations.
This is the line between runtime and evidence. A runtime guard prevents harm and produces a decision the engineer sees. A per-action evidence record proves past behaviour and produces a finding the regulator reads. A firm needs both, but they are different products with different readers, and the record is the one a regulator asks for when an inquiry opens. The split is set out in full in the four-layer evidence stack.
Because it is the deliverable layer, the per-action evidence record is the thing a deployer can put in front of a regulator in place of telemetry. The telemetry answers a question the regulator did not ask. The per-action evidence record answers the one she did: on this action, which obligation governed it, and was it met. That is the record a regulator reads.
Adjacent terms, defined.
Questions a compliance officer asks first.
Read the source directly.
- Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
- EU AI Act Article 12 record-keeping · annotated text
- 23 NYCRR Part 500 · § 500.6 audit trail · NYDFS
- Federal Reserve SR 26-2 · carry-forward of SR 11-7
- FCA PS22/9 · Consumer Duty Policy Statement
- India Digital Personal Data Protection Act 2023
- The four-layer evidence stack · where the record sits
- Article 12 and agentic per-action records · the open granularity question
- One agent, many jurisdictions · the same record across regimes
- Article 26 deployer obligations · who orders the record
Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. A definition of a category term, with verbatim regulator excerpts sourced from the canonical URLs above. Not legal advice. The verbatim quotation of Article 12(1) reflects the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.