Audit-ready evidence for an AI agent

01 · WHAT AUDIT-READY MEANS

What audit-ready evidence actually is.

An autonomous agent in a high-risk deployment takes many consequential actions in a single run. When an auditor opens an inquiry in 2027 about an action from 2026, the question is never "show me uptime that day". The question is narrower: show me what the agent did at this moment, under what authorisation, against which obligation, and prove the record has not been edited since. Evidence is audit-ready when it can answer that question without the deployer scrambling to reconstruct behaviour after the fact.

That resolves into five requirements the evidence must satisfy. It is a per-action record. Each record names the governing obligation. Each record captures the authorisation. The record retains automatically for the period the law sets, and is independently verifiable. The rest of this note works each requirement against the EU AI Act text, so a deployer can read the spec against any candidate stack. The architecture behind these properties is set out in the four-layer evidence stack; this note is the requirements view a deployer holds a vendor to.

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Regulation (EU) 2024/1689 · Article 12(1) · 13 June 2024

Article 12(1) is the dated, penalty-backed obligation underneath all of this. The application date is 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028, subject to Article 2(13), for systems classified as high-risk under Article 6(1) and Annex I — Article 113, third paragraph, point (c) of Regulation (EU) 2024/1689 as replaced by Article 1(40)(b) of Regulation (EU) 2026/1744, in force 27 July 2026 (OJ 24 July 2026). The dates they displaced were two separate fixed dates, not one: 2 August 2026 for the Annex III limb and 2 August 2027 for the Annex I limb. Article 2(13), inserted by Article 1(3) of the same Regulation, permits the Annex I limb to be limited where sectoral Union law provides equivalent or higher protection. Non-compliance is reachable under Article 99(4) at up to EUR 15 million or 3 percent of global annual turnover.

What the sentence does not do is fix the shape of the record. It requires that relevant events be capable of being logged; it does not say the unit is the action rather than the session, and it does not set how long the logs are kept — that is Article 19(1). Per-action granularity is a design choice, not a statutory instruction. The five requirements below are what turn a bare logging obligation into evidence an auditor accepts.

02 · REQUIREMENT 1 · PER-ACTION

It is a record per action.

The first requirement is granularity. Article 12(1) requires recording of events over the lifetime of the system, but it does not say whether a record means one running log per system or a discrete record for each autonomous action. For a single-pass model the distinction is academic. For an agent that takes a chain of consequential actions in one run, it is the whole question. An auditor cannot grade an action the deployer can only show buried inside a system-wide log.

So audit-ready evidence makes each action an addressable record. The per-action unit is actions[*] in the evidence schema, carrying an action_id, the actor, the action, and the subject — those four properties and nothing more. The inputs, outputs and timestamps stay in the ingested execution trace: they are not carried into the signed record, and no pointer back into the trace is retained, so matching a row to its origin means holding the trace alongside the package. That is the smallest unit a regulator's question maps onto. Whether the draft classification Guidelines treat the agent or the step as the unit of assessment is still an open boundary, examined in the per-action records question; either way, evidence built per action survives both readings.

"An auditor's question is per action. The evidence has to be too."Warrant Compliance · 2026-06-04

03 · REQUIREMENT 2 · NAMES THE OBLIGATION

Each record names the governing obligation.

The second requirement is that the record cites the specific obligation it answers to, down to the sub-clause, not the regulation in the abstract. "EU AI Act compliant" is not evidence. "Article 12(2)(c), monitoring under Article 26(5)" is. An audit-ready record names the article, the paragraph, and the sub-paragraph, so an auditor traces the record to the canonical text rather than to the vendor's interpretation of it.

The mapping is concrete, and it is Warrant's mapping rather than a shape the Regulation prescribes: Article 12 names the events that must be capable of being logged, and leaves the unit open. On that reading the per-action record under actions[*] is what Warrant records against Article 12(1). The risk-situation events under Article 12(2)(a) map to classification.risk_tier with its risk_tier_justification, read against authorizations[*].within_purpose for deviation from the intended purpose; there is no per-action risk assessment in the schema. The human-oversight monitoring events under Article 12(2)(c) map to the single human_oversight_appropriate field on each authorisation row, with its justification, and resolve against Article 26(5). Article 12(2)(b) has no counterpart: a package is scoped to one trace, post-market monitoring under Article 72 runs across a population of them, and no field carries an outcome or a cross-trace roll-up. The line-by-line field-to-clause map is set out in Article 12, line by line.

12(1)

Automatic recording over the lifetime of the system. FIELD · actions[*] — action_id, actor, action, subject. No pointer back into the source trace is retained; the row is those four properties.

12(2)(a)

Identifying situations that may present a risk, under Article 79(1). FIELD · classification.risk_tier with risk_tier_justification, read against authorizations[*].within_purpose for deviation from intended purpose.

12(2)(c)

Monitoring of operation under Article 26(5). FIELD · authorizations[*].human_oversight_appropriate with justification — Warrant's assessment of whether the oversight present was appropriate, not a log of a human intervening. The row also defines refusal and refusal_reason, but a declined action returns a refusal response and no package is built, so those two are never read out of a signed package.

04 · REQUIREMENT 3 · CAPTURES AUTHORISATION

Each record captures the authorisation.

The third requirement is that the record does not just say what the agent did; it says whether the agent was allowed to do it. For each action the record carries the authorisation: whether the action sat within the system's intended purpose, expressed as within_purpose, and whether the oversight actually present was appropriate to the action, expressed as human_oversight_appropriate — each in an authorizations[*] row naming the same action_id. An action that fell outside the intended purpose, or that should have had a human in the loop and did not, is exactly what an auditor is looking for.

What that oversight field is, and is not, matters to a reader grading a stack. human_oversight_appropriate is a judgement recorded per action about whether the oversight in place suited the action's risk. It is not an operator-presence log and not proof anybody intervened: no field carries an operator identity, a competence or training record, or a recorded override event. A reader who needs to know that a named human reviewed a decision has to take that from the deployer's own governance record, not from this one.

This is where the record-keeping obligation meets the deployer's standing duties. A deployer that runs a high-risk agentic system carries the Article 26 obligations and signs its name to what leaves the building, including the human oversight measures under Article 26(2) and the monitoring under Article 26(5). The authorisation fields are what let a record demonstrate those duties were met for each action rather than asserted at the system level. The full deployer duty set is in the Article 26 deployer obligations, line by line.

within_purpose

Whether the action sat within the system's intended purpose. FIELD · the per-action gate that maps to deployer use within the intended purpose.

authorizations[*]

Whether the oversight present was appropriate to the action, as assessed per action, and whether the action stayed within the permitted envelope. FIELD · an assessment, not an operator-presence log; resolves against Article 26(2) oversight and Article 26(5) monitoring.

05 · REQUIREMENT 4 · RETAINS SIX MONTHS

It retains past the six-month floor.

The fourth requirement is retention, and it is the one a general-purpose telemetry stack quietly fails. Two duties are routinely run together here and they are not the same. Article 12(1) is about capability: the system must technically allow for the automatic recording of events over its lifetime. It is not a lifetime-retention duty. Article 19(1) is the retention duty on the provider: the Article 12(1) logs under its control must be kept for at least six months, appropriate to the intended purpose, unless other Union or national law requires longer. Article 26(6) is the same duty on the deployer, for the logs under the deployer's control — the limb that binds the reader holding a stack to this spec. Sectoral law frequently requires far longer. MiFID II Article 16(7) keeps the records it covers for five years, and up to seven where the competent authority requests it. Medical Device Regulation Article 10(8) runs at least ten years, at least fifteen for implantable devices.

6 months

ART 19(1) · 26(6) FLOOR

At least six months, appropriate to the intended purpose, unless other law requires longer. Article 19(1) for the provider, Article 26(6) for the deployer.

7–30 days

DEFAULT TELEMETRY

A general-purpose observability tier rotates logs out well before the floor. Retention is automatic, not a plan.

The practical test is whether retention is a property of the evidence system or a retention plan bolted onto a telemetry tool. Audit-ready evidence retains automatically for the period the obligation sets — the Article 19(1) floor for a provider, the Article 26(6) floor for a deployer, or the longer sectoral period where one applies — and does not depend on someone remembering to extend a retention window before logs rotate. A record that was rotated out cannot be reconstructed after the fact, and a record reconstructed after the fact cannot be made audit-ready retroactively.

06 · REQUIREMENT 5 · VERIFIABLE

It is independently verifiable.

The fifth requirement is the one that separates a record from a claim. Audit-ready evidence is independently verifiable: an auditor can confirm the record is unchanged since the action on their own machine, without contacting the vendor and without trusting the vendor's storage. The property lives in the record itself and resolves against an external public reference the vendor does not operate. None of it depends on the vendor being honest, present, or even still in business.

The failure mode this requirement closes is the deposition question. A record held only in the vendor's database, presented as the vendor presents it today, has a known weakness: staff turnover, data migration, a deliberate edit by an insider. A regulator who asks "who attests this is unchanged?" gets one answer, the vendor, and that answer collapses on chain of custody. An independently verifiable record inverts the trust assumption: the auditor checks the record, not the vendor. An audit-ready record is one a court can trust without trusting the company that produced it.

Per-action evidence record · Warrant registerRECORD MAPPED TO A SPECIFIC EU AI ACT OBLIGATION · INDEPENDENTLY VERIFIABLE

→ /verify

07 · THE RECORD SHAPE

The record shape, read against the text.

Put the five requirements together and the shape of an audit-ready record is specific. It is a per-action unit — Warrant's choice of granularity, not one Article 12 prescribes. Each unit carries the field that names its obligation, the fields that capture its authorisation, and the events Article 12(2) calls relevant. The whole set is retained for at least six months — Article 19(1) where the provider holds the logs, Article 26(6) where the deployer does — longer where sectoral law says so. And the set is independently verifiable. A deployer can score any candidate evidence stack against this shape line by line.

per action

actions[*] is the addressable unit — action_id, actor, action, subject. Each authorizations[*] row names an action_id, and obligations is an object keyed by action_id, so a row is read as obligations.<action_id>[]. REQUIREMENT 1 · the record is per action, not a system-wide running log. What is NOT enforced: no check before signing requires those key sets to match the action ids exactly, to be unique, or to be complete. A reader who needs that guarantee should compare the sets themselves rather than assume the package did it.

obligation

Each action maps to a sub-clause the obligation corpus carries: Article 12 and its paragraphs, read with the Article 19(1) retention entry. REQUIREMENT 2 · a record mapped to a specific EU AI Act obligation, down to the sub-paragraph. What is NOT in the corpus: Article 26 has no entry, so the deployer's own duties under Article 26(5) and 26(6) are named on this page as law a deployer carries, not as clauses a package cites.

authorisation

authorizations[*] carries within_purpose, preconditions_met, human_oversight_appropriate, reversible and justification, each row naming the action_id it was written for. REQUIREMENT 3 · the authorisation for each action, resolving against Article 26(2) and 26(5).

retention

Retained automatically for the statutory period — at least six months under Article 19(1) for a provider and Article 26(6) for a deployer, longer where other law requires it. Article 12(1) is the logging-capability duty, not the retention duty. REQUIREMENT 4 · retention is a property of the system, not a plan that can lapse.

verify

Independently verifiable without contacting the vendor, against an external public reference. REQUIREMENT 5 · the auditor checks the record, not the company that produced it.

08 · FAQ

Questions a deployer asks first.

What makes evidence for an AI agent audit-ready under the EU AI Act?

Five properties together. The evidence is a per-action record, not a system-level summary. Each record names the specific EU AI Act obligation it answers to, down to the sub-clause. Each record captures the authorisation for that action: whether it sat within the system's intended purpose, and whether the oversight actually present was appropriate to the action — an assessment recorded per action, not proof that a human was present or intervened. The record is retained for an appropriate period with a floor of at least six months — Article 19(1) binds the provider, Article 26(6) the deployer, each for the logs under its own control; Article 12(1) is the separate duty to make the system technically capable of recording events over its lifetime, not a duty to hold every record for that lifetime. And the record is independently verifiable, meaning an auditor can confirm it is unchanged since the action without contacting the vendor.

Does audit-ready evidence have to be per action, or is one running log enough?

Article 12(1) of Regulation (EU) 2024/1689 requires automatic recording of events over the lifetime of the system but does not fix the granularity. For an autonomous agent that takes many consequential actions in one run, an auditor's question is per action: what did the agent do on this date, under what authorisation, against which obligation. A running log that cannot answer at the level of a single action leaves the deployer reconstructing behaviour after the fact. Audit-ready evidence is structured so each action is an addressable record.

Which obligation should an evidence record cite for an agent action?

The specific sub-clause the action answers to, not the regulation in the abstract. For record-keeping the citation is Article 12 read with the six-month retention floor — Article 19(1) where the provider holds the logs, Article 26(6) where the deployer does. For monitoring of human oversight in deployment it is Article 26(5). For the deployer's wider standing duties it is Article 26, whose retention limb is Article 26(6) and whose monitoring limb is Article 26(5). An audit-ready record names the article, paragraph, and sub-paragraph, so an auditor can trace the record back to the canonical text rather than to the vendor's interpretation.

How long must audit-ready evidence for an AI agent be retained?

Article 19(1) of the EU AI Act sets a floor of at least six months on the provider, appropriate to the intended purpose, unless other Union or national law requires longer; Article 26(6) sets the same floor on the deployer for the logs under its control. Sectoral law frequently requires longer: MiFID II Article 16(7) keeps the records it covers for five years, and up to seven where the competent authority requests it, and Medical Device Regulation Article 10(8) runs at least ten years, at least fifteen for implantable devices. A general-purpose telemetry stack that rotates logs out at seven to thirty days fails the six-month floor on its own. Audit-ready evidence retains automatically for the period the obligation sets rather than for the window the tool defaults to. Keep the two duties apart: Article 12(1) requires the technical capability to record events over the lifetime of the system, and Article 19(1) is what fixes how long those logs are then kept.

What does independently verifiable mean for AI agent evidence?

It means an auditor can confirm the record is unchanged since the action on their own machine, without contacting the vendor and without trusting the vendor's storage. The record carries the property within itself. The verification resolves against an external public reference the vendor does not operate, so the answer does not depend on the vendor being honest or even online. A record held only in the vendor's database, presented as the vendor presents it today, is not independently verifiable.

When do these requirements apply to a high-risk agentic system?

The application date is 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028, subject to Article 2(13), for systems classified as high-risk under Article 6(1) and Annex I. Both dates come from Article 113, third paragraph, point (c) as replaced by Article 1(40)(b) of Regulation (EU) 2026/1744 (the Digital Omnibus on AI), which is in force from 27 July 2026. The dates they displaced were two separate fixed dates, not one: 2 August 2026 for the Annex III limb and 2 August 2027 for the Annex I limb. Article 2(13), inserted by Article 1(3) of the same Regulation, permits the Annex I limb to be limited where sectoral Union law provides equivalent or higher protection. Non-compliance with the record-keeping obligation is reachable under Article 99(4) at up to EUR 15 million or 3 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. As at 24 July 2026, the date of the Official Journal publication.

09 · READ THE SOURCE

Read the source directly.

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text and the shape of audit-ready evidence. 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. Retention references are to Article 19(1) for providers and Article 26(6) for deployers; other deployer references are to Article 26.

How to produce audit-ready evidence for an autonomous AI agent.