01 · ARTICLE 12 § 1 · "TECHNICALLY ALLOW"
Automatic logs over the lifetime of the system.
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
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 satisfies the recording obligation per agent decision. Every action carries a timestamp, an actor identifier, the inputs, and the outputs. The package is a record mapped to the Article 12 obligations, independently verifiable without contacting Warrant, and checkable offline for the lifetime of the system.
"Logs are the cheapest part of compliance. Producing the record that makes them admissible to a regulator is the entire job."Counsel B.W. · regulatory review · 2026-04-30
02 · ARTICLE 12 § 2 · SUB-CLAUSES
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 the Warrant evidence field that satisfies it. For the line-by-line reading, see EU AI Act Article 12, line by line.
§ 12(2)(a)
Identification of situations that may result in the AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification.
WARRANT · trace.actions[*] typed risk classification span on every decision; trace.policy_version_id flags substantial modifications.
§ 12(2)(b)
Facilitation of the post-market monitoring referred to in Article 72.
WARRANT · trace.regulated_entity + trace.agent_id + trace.model_version. Logs addressable by deployment, model version, and time window.
§ 12(2)(c)
Monitoring of the operation of high-risk AI systems referred to in Article 26(5).
WARRANT · the deployer, not just the provider, can confirm the record independently without contacting Warrant. the record names the issuing tenant.
Article 19 layers a six-month minimum retention floor on top of these capabilities. Shorter retention is per-se non-compliant. Member-state implementations have layered longer obligations on top: France's CNIL guidance assumes 36 months; Germany's BSI draft assumes 60.
03 · ARTICLE 13 · TRANSPARENCY TO DEPLOYERS
The deployer must interpret the output.
High-risk AI systems shall be designed and developed in such a way to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately.
Regulation (EU) 2024/1689 · Article 13 § 1
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.
§ 13 § 1
Operation transparent enough for deployer interpretation.
WARRANT · trace.actions[*].rationale + per-action authorization envelope (within_purpose, preconditions_met, justification).
§ 13(3)(b)(ii)
Characteristics, capabilities, and limitations disclosed.
WARRANT · trace.agent_id + trace.regulated_entity. Per-action limitations cited inline when present in trace; gap surfaced when missing.
§ 13 § 3(d)
Human oversight measures documented.
WARRANT · trace.actions[*].human_review_recorded + authorization_envelope.human_oversight_appropriate. The record marks oversight "uncertain" when threshold-bypass is the only oversight evidence.
04 · ARTICLE 14 + 26(6) · ROADMAP
Oversight effectiveness, deployer-side retention.
Article 14 requires deployers to ensure meaningful human oversight of high-risk systems. Warrant's authorization-envelope schema captures the four oversight axes (within_purpose, preconditions_met, human_oversight_appropriate, reversible) on every action. The envelope shape was designed against Article 14 § 4. Full Article 14 deeper mapping (oversight effectiveness review, escalation logs) ships v0.5, 2026 Q3.
Article 26(6) deployer-side log retention is operationally satisfied today by the Warrant Cloud receipt store and the customer's own retention policy. Explicit Article 26(6) certification will follow ENISA implementation guidance.
05 · WHY THIS REGULATOR NOW
When does the EU AI Act apply to high-risk AI systems?
Application of Article 12 to Annex III high-risk systems begins on 2 August 2026 under Article 113 of Regulation (EU) 2024/1689 as enacted. The May 2026 Digital Omnibus on AI agreement, provisionally reached 2026-05-07, defers that date to 2 December 2027, but is not yet binding law. 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, established under Article 64 and operational since June 2024, has used the window between Article 113 entry-into-force and full application to publish guidance that will be read directly into early enforcement.
The Commission's general-purpose AI code of practice (third draft published 11 March 2026) sets the supervisory tone for the broader regime. The AI Office's working position: a logging path that depends on a developer remembering to call a log function does not satisfy automatic recording. A retention policy that rotates the application log every thirty days while the system stays in service for years does not satisfy lifetime of the system. National competent authorities under Article 70 are designating now; the French CNIL, Italian Garante, Dutch AP, and German BSI have each published draft enforcement protocols cross-referencing Article 12.
Prosecutorial interest is following two vectors. First, Annex III(5)(b) credit-scoring agents · already inside the GDPR Article 22 perimeter and now inside Article 12 · are the natural early targets given the volume of automated decisions and the existing supervisory muscle memory. Second, Annex III(4)(a) recruitment screening agents · which Italian and German DPAs have already fined under GDPR for opaque processing · move from privacy-only to AI-Act-plus-privacy on 2 August 2026 (provisionally deferred to 2 December 2027 under the May 2026 Omnibus). Either date binds the same Annex IV deliverable.
06 · DECISION TREE
Annex III determination, step by step.
Six clauses to walk in order. Each branch returns either an attached obligation or a documented exit. The structure mirrors how a national competent authority will read the system on examination.
Q1
Is the system an AI system within the meaning of Article 3(1) (machine-based, varying levels of autonomy, infers from input how to generate outputs).
NO → Regulation does not attach. YES → continue.
Q2
Is the system a safety component of a product covered by Annex I Union harmonisation legislation, or itself such a product subject to third-party conformity assessment under Article 6(1).
YES → Article 12 attaches with application date 2027-08-02 (Annex I products). Continue regardless to test Annex III.
Q3
Does the system fall inside any of the eight Annex III use cases · biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, administration of justice.
YES under Annex III → Article 6(2) high-risk classification → Article 12 attaches 2026-08-02. Within scope of Article 12 logging, Article 13 transparency, Article 14 oversight, Article 19 retention.
Q4
Does Article 12(1) require that this system technically allow automatic recording of events over the lifetime of the system.
YES (always, for high-risk) → does the trace shape carry per-action subject, inputs, outputs, ts, decision_rationale, risk classification under Article 79(1), oversight outcome under Article 26(5).
Q5
Is the documentation requirement under Article 13(3)(b)(ii) satisfied by the Warrant evidence field carrying agent characteristics, capabilities, and limitations.
YES if trace.agent_id + trace.regulated_entity + trace.actions[*].rationale are populated; gap surfaced if missing. Article 11 technical documentation lodged separately at conformity assessment.
Q6
Is the system anchored to a fixed conformity assessment outcome under Article 43 · or has the model been swapped, retrained beyond perimeter, or repurposed in a way that triggers Article 25(1)(c).
SUBSTANTIAL MODIFICATION → modifier is treated as fresh provider; fresh Article 12 logging perimeter; fresh Article 19 retention clock; fresh Article 43 assessment. Document the trigger date.
07 · MAPPING · ARTICLES 12 + 13
Per-obligation field map.
Logs shall make it possible to monitor the operation of the high-risk AI system with regard to the occurrence of situations that may result in the AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification, and facilitate the post-market monitoring referred to in Article 72.
Regulation (EU) 2024/1689 · Article 12 § 2 · paraphrased headline
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 the exact Warrant evidence field that satisfies it. This is the table a national competent authority reads against the evidence package.
Art 12(1)
Automatic recording over the lifetime of the system.
WARRANT · trace.actions[*] (per-action subject, inputs, outputs, ts) bound into a record independently verifiable without contacting Warrant. Lifetime maintained via the Warrant Cloud receipt store.
Art 12(2)(a)
Identifying situations under Article 79(1) or substantial modification.
WARRANT · trace.actions[*].risk_assessment (deviation_from_intended_purpose, drift_indicators, modification_flag) + trace.policy_version_id.
Art 12(2)(b)
Facilitating post-market monitoring under Article 72.
WARRANT · trace.regulated_entity + trace.agent_id + trace.model_version. Logs addressable by deployment, model version, and time window for AI Office and national competent authority queries.
Art 12(2)(c)
Monitoring under Article 26(5) (deployer-side).
WARRANT · trace.actions[*].oversight (reviewer_id, review_outcome, intervention_record, justification). Deployer confirms the record independently without contacting Warrant; the record names the issuing tenant.
Art 12(3)
For Annex III(1)(a) biometric ID systems · period of each use, reference database checked, matched query, identification of natural persons in verification.
WARRANT · biometric-vertical extension trace fields (period_of_use, ref_db_id, match_query_id, verification_subject). Available on the biometrics sample trace; mainline trace does not include for non-biometric agents.
Art 13(1)
Operation transparent enough for deployer interpretation.
WARRANT · trace.actions[*].rationale + per-action authorization_envelope (within_purpose, preconditions_met, justification, human_oversight_appropriate, reversible).
Art 13(3)(a)
Identity and contact details of the provider.
WARRANT · trace.regulated_entity + the record names the provider deployment as its issuing author.
Art 13(3)(b)(ii)
Characteristics, capabilities, and limitations of performance.
WARRANT · trace.agent_id + trace.regulated_entity. Per-action limitations cited inline when present in trace; gap surfaced when missing.
Art 13(3)(b)(iii)
Foreseeable circumstances of misuse to be avoided.
WARRANT · trace.actions[*].risk_assessment.deviation_from_intended_purpose + the authorization review flags decisions outside envelope.
Art 13(3)(d)
Human oversight measures documented under Article 14.
WARRANT · trace.actions[*].human_review_recorded + authorization_envelope.human_oversight_appropriate. The record marks oversight "uncertain" when threshold-bypass is the only oversight evidence.
Art 16(c)
Provider obligation, read with Article 99(4) penalty exposure.
WARRANT · per-trace evidence package, a record mapped to the Article 12 obligations, independently verifiable without contacting Warrant. Three steps from Article 12(1) to the EUR 15M ceiling.
Art 19(1)
Retention of logs at least six months, longer where sectoral law requires.
WARRANT · Warrant Cloud receipt store + customer-controlled retention policy. Retention floor configurable; sectoral overrides (MiFID II five to seven years, MDR ten to fifteen) carry forward.
08 · FAQ
Questions a compliance officer asks first.
Does Article 12 apply to my AI system if i operate from outside the European Union?
Yes if the system is placed on the Union market or its output is used in the Union. Article 2(1)(a) extends the regulation irrespective of the provider's place of establishment. Article 22 requires the non-Union provider to designate an authorised representative in the Union before the system is made available. The authorised representative is on the hook for Article 12 compliance under Article 22(3).
What is the documentation requirement under Article 13(3)(b)(ii)?
Article 13(3)(b)(ii) requires the instructions for use to disclose the characteristics, capabilities, and limitations of performance of the high-risk AI system, including its intended purpose. Warrant captures this binding per decision through trace.agent_id and trace.regulated_entity. Per-action limitations are cited inline when present in the trace; gap surfaced when missing.
How do i generate Article 12 evidence from my agent?
Wrap each tool call with the Warrant trace shape (actor, action, subject, inputs, outputs, ts) and POST the JSON to /attest. Warrant produces a per-action evidence package mapped to Article 12(2), independently verifiable without contacting Warrant. The same shape applies whatever model stack the agent runs on.
What does the European Commission AI Office recognise as 'sufficient' under Article 12?
Sufficient means automatic, structured, lifetime, and addressable by deployment ID, model version, and time window. The AI Office working position: a logging path which depends on a developer to remember to call a log function does not satisfy automatic recording. A retention policy that rotates the application log every thirty days while the system stays in service for years does not satisfy lifetime. The Commission's general-purpose AI code of practice (third draft, 11 March 2026) sets the broader supervisory tone.
Does a foundation model swap count as a substantial modification under Article 25(1)(c)?
On most readings, yes. A model-version bump that swaps the foundation model from one frontier provider to another exits the Article 43 conformity assessment. Article 25(1)(c) treats the modifier as a fresh provider with all Article 16 obligations, including a fresh Article 12 logging perimeter and a fresh Article 19 retention clock. Document the trigger date; Warrant binds trace.policy_version_id so the perimeter shift is visible in the record.
How long must Article 12 logs be retained?
Article 19(1) sets a hard floor of at least six months, appropriate to the intended purpose, unless other Union or national law requires longer. Sectoral law often does. MiFID II runs five to seven years. MDR runs ten to fifteen years for implantable devices. France's CNIL guidance assumes thirty-six months. Germany's BSI draft assumes sixty. A six-month rolling window destroyed twelve months ago is not an answer to a regulator's request twelve months and one day after the event.
WARRANT