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 designed to detect and respond to cybersecurity events, per the Second Amendment text effective 1 November 2023. |
| Federal Reserve | SR 26-2 § II n.3 (supersedes SR 11-7 and SR 21-8) |
Documented model risk management for models in scope — but footnote 3 puts generative and agentic AI models outside the guidance, so an agent's record answers to general risk management and governance practice, not to a clause. |
| FCA | Consumer Duty, PS22/9 Principle 12 | Evidence of good outcomes and avoided foreseeable harm for retail customers. |
| RBI | FREE-AI committee report (not adopted · not binding) |
Responsible-and-ethical-enablement record across the AI's lifecycle — a forward-looking mapping, never presented as a statutory obligation. |
| MAS | FEAT principles | Fairness, Ethics, Accountability, Transparency evidence for the decision. |
| India DPDP Act 2023 | Data Fiduciary obligations (substantive duties not yet in force) |
Accountability of the Data Fiduciary to the Data Principal for the personal data touched — mapped ahead of commencement, not enforced today. |
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. Extracted from the agent's execution trace into actions[*]: an action_id, the actor, the action taken, and the subject it touched. Those four properties are the whole row. The inputs, outputs, timestamps and step numbers are read during extraction and are not carried into the signed record, and no pointer back into the source trace is retained. A reader holding the record cannot address a row to a position in the trace; matching a row to its origin means holding the trace alongside the package. What the row does carry is grounded in the trace rather than asserted later.
The authorization row. Per action, an authorizations[*] row keyed to the same action_id records whether the action was within_purpose, whether preconditions_met, whether human_oversight_appropriate — Warrant's assessment of whether the oversight present was appropriate to the action, not a record of a human intervening — whether the action was reversible, a confidence, 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 row also defines refusal and refusal_reason, and the honest statement about them is narrower than it looks. Where the pipeline declines an action, the request returns a refusal response and no package is built at all: nothing is signed, and there is no signed refused package to read those two properties out of. A refusal is an answer the caller receives, not an artefact a regulator later verifies. Equally, each authorizations[*] row names the action_id it was written for, but no check before signing requires the authorization keys to match the action ids exactly, to be unique, or to be complete — a reader who needs that guarantee compares the sets.
The obligation map. obligations is an object keyed by action_id; each row under a key — read as obligations.<action_id>[] — carries the sub-clause id, a compliance verdict, a confidence, and an evidence string that quotes or paraphrases the action's own text. What the row does not carry: the verbatim regulator text and the canonical source URL are not signed fields. The PDF may render citation text from Warrant's local corpus so the page reads, and that rendered text is display output, not signed data — what is signed is the clause id, resolved by the reader against the corpus digest recorded in trace_metadata.
The clause mapping is Warrant's, not a granularity the statute fixes. actions[*] is the unit Warrant records against EU AI Act Article 12(1); Article 12 requires that relevant events be capable of being logged and does not say the unit is the action rather than the session, so per-action granularity is an implementation choice. The authorizations[*] row is what an operation-level audit trail of the kind NYDFS § 500.6(a)(2) requires is built from — a reading Warrant offers, not one the package asserts: the obligation corpus carries no § 500.6 table, so a package reports NYDFS Part 500 as classified and in scope, not evaluated, and no obligations.<action_id>[].id resolves to that clause. authorizations[*].human_oversight_appropriate carries Warrant's per-action assessment of oversight, read against EU AI Act Article 14. The mapping is the field-to-clause binding that lets a regulator read the record against the statute, for the clauses the corpus actually carries.
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 / OCC / FDIC SR 26-2 (17 April 2026) · supersedes 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.