EU AI Act - capability crosswalk
If your AI program needs to evidence Article 12 record-keeping, Article 14 human oversight, or Article 73 serious-incident reconstruction, here is how the obligation maps to the AGLedger record, the Signed Statement chain, and the audit-export surface.
The crosswalk below is a capability mapping, not a compliance certificate. AGLedger provides the evidence pattern; your program provides the policy, the methodology, and the decisions.
Last updated: 2026-06-10 · API v1.2.0 · Article references reviewed against Regulation (EU) 2024/1689 (OJ L, 12 July 2024) and the Digital Omnibus provisional agreement of 7 May 2026
Where enforcement stands
The AI Act entered into force on 1 August 2024. Prohibitions and AI-literacy duties have applied since 2 February 2025, and general-purpose AI obligations since 2 August 2025. Under the Digital Omnibus agreed by the Parliament and Council on 7 May 2026 (pending formal adoption), the high-risk obligations this page maps - including Article 12 record-keeping - are expected to apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for high-risk AI embedded in regulated products. The records you will need in 2027 have to start accumulating before 2027.
If your AI program needs to evidence Article 12 record-keeping, the crosswalk below applies. The same evidence pattern - signed records, hash-chained, append-only - also supports non-AI automated work under SOX, GLBA, HIPAA, and other control families that require tamper-evident audit trails for RPA, CI pipelines, and microservice handoffs. AGLedger is software you self-host; the regulations are AI-framed, the underlying evidence pattern is not.
Article-by-article mapping
| Article | Requires | AGLedger provides | You own |
|---|---|---|---|
| Art. 6 + Annex III | Classification rules for high-risk AI systems | Field to record the classification (high, limited, minimal) and Annex III domain tag per record, applied consistently across the chain | The classification decision and methodology |
| Art. 9 | Risk management system | Signed, timestamped records of risk assessments, mitigation decisions, and tolerance-check results — evidence the process ran, when, and with what outcome | The risk management system itself: identification, evaluation, and the mitigation measures |
| Art. 12 | Record-keeping (event logging) | Append-only audit vault — every state change, attestation, and tolerance check result recorded automatically, Ed25519-signed and hash-chained; external anchoring writes signed checkpoints to write-once storage (S3 Object Lock) so the log’s integrity holds even against the operator running it | Determining which events are in scope |
| Art. 13 | Transparency and provision of information to deployers | Full chain exportable and machine-readable (JSON, CSV, NDJSON), so deployers can see what the system intended and did | The instructions for use, and deciding what to disclose and to whom |
| Art. 14 | Human oversight | Structured record of the designated overseer — name, role, authority scope, designation date — plus the signed Gate verdict when a human renders a decision | Designating the overseer and defining their authority |
| Art. 15 | Accuracy, robustness and cybersecurity | Tolerance bands enforce numeric bounds on record criteria; deviations are recorded as signed events | Defining the tolerance thresholds and acceptance criteria |
| Art. 17 | Quality management system | Cross-record compliance attestation records, linked to audit chain | The quality management system and policies, and the Art. 11/Annex IV technical documentation it references |
| Art. 18 | Documentation keeping | Audit export formatted for regulatory submission and third-party audit — signed, so a decade-old export still verifies | The documentation content and narrative, and the 10-year retention policy |
| Art. 19 | Automatically generated logs — retention of at least six months | Append-only retention — nothing in the vault is deleted or overwritten, so the six-month floor is exceeded by default; anchored checkpoints in write-once storage carry their own object-lock retention window (default ~7 years, configurable); offline-verifiable export at any point in the window | The retention schedule, and the lawful-basis and erasure analysis under GDPR |
| Art. 20 | Corrective actions and duty of information | Dispute resolution (3-tier), remediation states, revision workflow — each transition a signed record | Deciding what corrective action to take, and the notifications |
| Art. 26 | Deployer obligations — including Art. 26(6) log retention | 4 attestation record types (workplace notification, affected persons, input data quality, FRIA) plus the same retained, tamper-evident log store on the deployer side | Performing the attestation — we record it, you do it — and the deployer’s retention schedule |
| Art. 27 | Fundamental rights impact assessment | Structured record per assessment with risk level, domain, mitigation measures | Conducting the assessment itself |
| Art. 49 | Registration | EU AI Act domain classification across 8 Annex III categories, kept consistent between your filing and your operational records | The registration filing |
| Art. 72 | Post-market monitoring by providers | A continuous, signed record stream of production behaviour — intents, actions, outcomes, verdicts — as a data source the monitoring plan can rely on without questioning its integrity | The monitoring plan, the analysis, and the conclusions |
| Art. 73 | Reporting of serious incidents | The audit vault contains timestamped, hash-chained records of every agent action, record, completion, and verdict — export a complete incident reconstruction from a single signed source rather than correlating across multiple unsigned systems | Incident determination, authority notification, and the filing obligation |
These obligations exist because automated work needs structurally durable evidence. Whether or not your jurisdiction enforces them on schedule, the engineering requirement is real today. AGLedger provides the evidence pattern; your compliance program provides the policy and process around it.
Record-keeping under the Act also intersects data-protection law: Article 12 logs and Article 18 retained documentation are themselves records to which GDPR residency and international-transfer analysis applies. Self-hosting keeps that analysis short - the logs live in your PostgreSQL, in the jurisdiction you choose, with no processor relationship and no transfer introduced by the evidence layer. Data sovereignty is a property of the deployment model, not a clause to negotiate.