EU AI Act, Articles 12 and 13

Maturity note. Hardware attestation graduated to a real, run-bound AMD SEV-SNP quote on 2026-07-17 on deployments with an attestation agent; runs on the hosted service still carry the hardware-attestation scaffold flag, because the hosted service runs without one. Three other scaffold flags remain on every run: the timing declarations, the zero-knowledge transcript, and its state-prover binding. Every audit bundle flags these with a scaffold field; the open-source verifier surfaces them in its report. See /concepts/scaffold-gaps/ for the full disclosure list and what activates each. Rows in the crosswalk below that depend on scaffold layers are flagged inline.

What Articles 12 and 13 actually say

Article 12 (record-keeping) is the provision closest to what Verdifax does. It requires that high-risk AI systems technically allow for the automatic recording of events ("logs") over the lifetime of the system. Under Article 12(2), the logging capabilities must enable the recording of events relevant for identifying situations that may present a risk or involve a substantial modification, for the post-market monitoring referred to in Article 72, and for the deployer's monitoring of the system's operation under Article 26(5). Article 16 makes the provider of the high-risk AI system responsible for meeting this requirement.

Article 13 (transparency) is a related, secondary obligation. It requires that high-risk AI systems be designed and developed so that:

• Their operation is sufficiently transparent to enable deployers to interpret outputs and use them appropriately.
• They are accompanied by instructions for use that include the system's intended purpose, capabilities, performance, and known limitations.

Article 13 binds the provider. Where relevant, Article 13(3)(f) requires the instructions for use to describe the mechanisms that allow deployers to properly collect, store and interpret the logs.

Articles 19 and 26(6) (log retention) require providers and deployers, respectively, to keep the automatically generated logs under their control for at least six months, subject to other Union or national law, in particular data protection law. Tamper-evidence is not itself an Article 12 requirement. It affects how much weight a reviewer can give a log that a provider or deployer keeps.

When these obligations apply

Regulation (EU) 2026/1744 amended the Act's timetable. The high-risk obligations, including Articles 12, 13, 19 and 26, apply from 2 December 2027 for high-risk AI systems listed in Annex III and from 2 August 2028 for high-risk AI systems covered by Annex I. [Pending review by counsel: dates confirmed against the Official Journal text]

Where Verdifax fits

Verdifax does not write the instructions for use. It does not interpret model output. Verdifax is not the provider or the deployer of your high-risk AI system, so the obligations in Articles 12, 13, 19 and 26(6) rest with you, not with Verdifax. Using Verdifax does not by itself establish compliance with any of them.

What Verdifax does provide is an integrity layer for the events your system chooses to send it: Verdifax produces sealed records of those events, with hashes published in a public transparency log. On records sealed from run 238 on, a second public-log entry binds a digest of every section of the record; from run 239 on, deleting that entry fails verification, so a reviewer can check that no section has changed since anchoring. On earlier leaf v5 records, the public-log entry binds the run's identity and its 33 pre-anchor values, which include the attested decision, the AIVP governance result, the payload hash, the actor and the scaffold flags; their descriptive sections (outcome summary, request substance, authorization and approval chain, real-world effects, system provenance) are sealed by hashes inside the bundle but are not bound to the public log, so they show the bundle is internally consistent, not that a party able to rewrite the whole bundle has not changed them. [Pending review by counsel: whether and how a provider can rely on Verdifax as part of meeting Article 12, including through a supplier agreement under Article 25(4).] The rows below show how that capability relates to Article 12 record-keeping:

For Article 13 (transparency), which is the provider's obligation, the generated audit-pack PDF renders the sealed record in a form an oversight body can read. A provider can draw on it when describing log handling in its instructions for use. It does not by itself meet Article 13.

Sample audit response

When a market surveillance authority asks a provider or deployer for evidence that a specific decision was made by its high-risk AI system, the response can include:

1. The original input (or its hash, if PII is at issue)
2. The Verdifax manifest hash for that decision
3. The run's sealed audit bundle, from GET /runs/{id}/artifacts
4. Optional: the generated PDF audit report from /runs/{id}/report.pdf, which includes the regulatory mapping section

The regulator runs the open-source verifier, verdifax-verify, over the bundle. Offline, it recomputes every section hash and the anchored public-log leaves from the bundle's own fields and confirms every section is bound to the bundle's manifest hash, which the regulator compares with item 2. The check places no trust in the operator's servers.

What this does not cover

• Annex IV technical documentation, Verdifax does not generate this. Your governance team writes it.
• Conformity assessment, this is the provider's procedure. Verdifax records are not a conformity assessment and do not give rise to a presumption of conformity.
• Log retention period (Articles 19 and 26(6)), the period is the provider's and deployer's decision. The hosted Verdifax service currently has no deletion jobs and keeps sealed records indefinitely.
• Risk management system (Article 9), separate obligation.
• Data governance (Article 10), Verdifax does not see training data.
• Human oversight (Article 14), Verdifax records what happened; it doesn't enforce who was reviewing.

Continue

• NIST AI RMF mapping
• ISO/IEC 42001 mapping
• HIPAA audit trail
• SOX § 404 IT controls
• Sample audit response