WARRANTAutomatic logs over the lifetime of the system.
The load-bearing verb is technically allow. The system must permit recording. The practical effect: the absence of logs is not, by itself, a defence. You cannot claim the system was incapable.
Warrant records per agent decision. Each entry in actions[*] carries exactly four fields — action_id, actor, action, subject — because the schema sets additionalProperties: false on every action; the submitted timestamps, inputs and outputs stay in the trace and are not carried into the package. The package is a record mapped to the Article 12 obligations, independently verifiable offline without contacting Warrant. Article 12 is a logging-capability duty and fixes no retention period; the period comes from Article 19(1) for the provider and Article 26(6) for the deployer. The full record set an agent must keep — Article 12 read next to NYDFS § 500.6(a)(2) and SR 26-2 — is set out in records an AI agent must keep for a regulator.
The four recording capabilities.
Article 12(2) lists the events whose recording the system must enable. Each sub-clause is paraphrased and indexed below, with what the warrant-v1 evidence package actually carries against it. For the line-by-line reading, see EU AI Act Article 12, line by line.
agent_id and regulated_entity, both root fields of the submitted trace, plus trace_metadata.timestamp on the package, which records when the decision was sealed at attestation rather than when it was taken. warrant-v1 has no signed decision-time field and no model-version field, so the record is addressable by agent and by seal time but not by model version.
Article 19(1) layers a retention floor on top of these capabilities: the provider must keep the Article 12(1) logs, to the extent they are under its control, "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law". Six months is the floor, not the target — the period has to be appropriate to the intended purpose, and sectoral law routinely requires longer. The retention question in full — the Article 19(1) floor, the Article 26(6) deployer side, and where sectoral law extends both — is answered at how long must Article 12 logs be kept?
The deployer must interpret the output.
Article 13(3)(b)(ii) requires that the instructions for use accompanying the system disclose the characteristics, capabilities, and limitations of performance of the high-risk AI system, including its intended purpose. Warrant captures this binding per decision.
authorizations[*] per action (within_purpose, preconditions_met, justification). The justification is Warrant's assessment of the action, not the agent's own words: a firm's reasoning travels in the free-form trace[*].outputs it submits and warrant-v1 does not re-emit it.
agent_id and regulated_entity, both root fields of the submitted trace, identify the agent and the firm. warrant-v1 has no field for characteristics, capabilities or limitations of performance, so that element is not evidenced and the row in obligations.<action_id>[] carries compliance="gap".
authorizations[*].human_oversight_appropriate is Warrant's per-action assessment of whether human oversight was appropriate. It is not a record that a human was present or intervened, and warrant-v1 has no field that carries one: a human_review_recorded flag a firm puts in the free-form trace[*].outputs it submits is not re-emitted in the signed package. The record marks oversight "uncertain" when threshold-bypass is the only oversight evidence.
Oversight effectiveness, deployer-side retention.
Article 14 is a provider obligation, not a deployer one: high-risk AI systems must be designed and developed so that they "can be effectively overseen by natural persons during the period in which they are in use" (Article 14(1)). The matching duty on the deployer sits in Article 26(2), which requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. In warrant-v1 an authorizations[*] row carries the four oversight axes (within_purpose, preconditions_met, human_oversight_appropriate, reversible) for every action. There is no authorization_envelope root in the schema. The row was designed against Article 14 § 4, which is the paragraph that specifies what the system must enable the assigned overseers to do — and human_oversight_appropriate is Warrant's per-action assessment of whether oversight was appropriate, not a record that an assigned overseer was present or intervened. warrant-v1 has no field that carries one. Full Article 14 deeper mapping (oversight effectiveness review, escalation logs) ships v0.5, 2026 Q3.
Article 26(6) deployer-side log retention — logs kept for a period appropriate to the intended purpose, of at least six months, to the extent the logs are under the deployer's control — is operationally satisfied today by the Warrant Cloud receipt store and the customer's own retention policy.
When does the EU AI Act apply to high-risk AI systems?
Application of Article 12 to Annex III high-risk systems is deferred from 2 August 2026 to 2 December 2027 by the Digital Omnibus, which the European Parliament adopted at plenary on 16 June 2026 (Regulation (EU) 2026/1744, OJ L 2026/1744, 24 July 2026). Under Article 113 of Regulation (EU) 2024/1689 as enacted the date was 2 August 2026; the Omnibus replaces that with the fixed 2 December 2027 date. Counsel sitting in front of an unmapped agent today is sitting in front of an application date measured against a EUR 15 million ceiling. The European Commission AI Office — the body through which Article 64(1) charges the Commission with developing Union expertise and capabilities in the field of AI — has used the window between the Regulation's entry into force on 1 August 2024 and full application to publish guidance. Warrant's inference, not a regulator position: we expect that guidance to be read into early supervisory practice. No authority has said so, and we have not verified an enforcement action that does it.
The Commission's general-purpose AI code of practice — published 10 July 2025 and confirmed by the Commission and the AI Board as an adequate voluntary tool, as at the Commission's code page read on 6 August 2026 — sets the supervisory tone for the broader regime. Warrant's own reading of the Article 12(1) wording, not a published regulator position: a logging path that depends on a developer remembering to call a log function does not satisfy automatic recording, because Article 12(1) requires the system itself to "technically allow for the automatic recording of events". Retention is a separate duty and Article 12 fixes no period for it: Article 19(1) requires the provider to keep the Article 12(1) logs under its control for a period appropriate to the intended purpose of at least six months, and Article 26(6) places the parallel duty on the deployer. A policy that rotates the application log every thirty days falls below that floor. National competent authorities are being designated under Article 70, which required Member States to make contact information publicly available by 2 August 2025. No harmonised technical standard for Article 12 logging exists yet — prEN 18229-1 and ISO/IEC 24970 are both still in the standards pipeline; the state of play is at is there a standard for Article 12 logging?
The two vectors below are Warrant's inference from the Annex III categories and from existing privacy supervision. They are not a published enforcement priority, and we have not verified one. First, Annex III(5)(b) credit-scoring agents — AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, already inside the GDPR Article 22 perimeter and inside Article 12 from 2 December 2027 — would be the early candidates if supervisors follow decision volume and existing privacy casework. Second, Annex III(4)(a) recruitment and selection agents, already exposed on the privacy side, move from privacy-only to AI-Act-plus-privacy on 2 December 2027 (deferred from 2 August 2026 to 2 December 2027 by the Digital Omnibus; Regulation (EU) 2026/1744, OJ 24 July 2026). The deferred date binds the same Annex IV deliverable as the original one did.
Annex III determination, step by step.
Six clauses to walk in order. Each branch returns either an attached obligation or a documented exit. The order is Warrant's reading of the Annex III text, not a published examination procedure.
agent_id and regulated_entity in the submitted trace identify the agent and the firm, and authorizations[*].justification carries Warrant's per-action reasoning, but warrant-v1 has no field for characteristics, capabilities or limitations of performance, so the row in obligations.<action_id>[] carries compliance="gap". Article 11 technical documentation is lodged separately at conformity assessment.
Per-obligation field map.
The mapping below carries every Article 12 and Article 13 obligation Warrant attaches to. Each row names the sub-clause cite, the regulator-language obligation, and what the warrant-v1 evidence package actually carries against it. The published schema, api/spec/warrant-v1-evidence.schema.json, sets additionalProperties: false at its root and on every action, so the field list is closed. A package carries no risk-assessment object and so no deviation, drift or modification field; no oversight object and so no reviewer identity, review outcome or intervention record; no policy version; no model version; and none of the four biometric particulars Article 26(6) reaches — period of use, reference database, match query and verification subject. The rows below name the fields that do exist and state plainly where there is none. Warrant's reading, not a published examination procedure: this is the table we would put in front of a national competent authority, and the gaps are on it deliberately. What makes the package itself audit-ready — per-action, obligation-named, independently verifiable — is set out in audit-ready evidence for an AI agent.
agent_id and regulated_entity, both root fields of the submitted trace, plus trace_metadata.timestamp on the package, which records when the decision was sealed at attestation rather than when it was taken. warrant-v1 has no signed decision-time field and no model-version field, so an AI Office or national competent authority query resolves by agent and by seal time, not by model version.
authorizations[*] per action (within_purpose, preconditions_met, justification, human_oversight_appropriate, reversible). The justification is Warrant's assessment of the action, not the agent's own words: a firm's reasoning travels in the free-form trace[*].outputs it submits and warrant-v1 does not re-emit it.
regulated_entity, a root field of the submitted trace, names the entity. warrant-v1 has no field for a provider's contact details, so that limb is not evidenced in the package.
agent_id and regulated_entity, both root fields of the submitted trace, identify the agent and the firm. warrant-v1 has no field for characteristics, capabilities or limitations of performance, so that element is not evidenced and the row in obligations.<action_id>[] carries compliance="gap".
authorizations[*].human_oversight_appropriate is Warrant's per-action assessment of whether human oversight was appropriate. It is not a record that a human was present or intervened, and warrant-v1 has no field that carries one: a human_review_recorded flag a firm puts in the free-form trace[*].outputs it submits is not re-emitted in the signed package. The record marks oversight "uncertain" when threshold-bypass is the only oversight evidence.
Questions a compliance officer asks first.
Primary citations.
EUR-Lex carries the canonical Regulation (EU) 2024/1689 at CELEX:32024R1689. Article 12 anchor: record-keeping. Article 13 anchor: transparency to deployers. The European Commission overview is at digital-strategy.ec.europa.eu.