prEN ISO/IEC 24970 at approval stage: logging and traceability evidence for Article 12
Category Standards
Published AIAssuranceLabs
The ISO project record for ISO/IEC FDIS 24970, AI system logging, shows the text at the final draft ballot in ISO/IEC JTC 1/SC 42, and the parallel European adoption is recorded in the standards data as prEN ISO/IEC 24970Approval. The document supplies the event model and record structure that Art. 12 leaves unspecified. A provider uses the final draft as the reference event set for a logging test and names it as a draft in the technical documentation; no presumption of conformity attaches, because no harmonised standard is cited in the Official Journal.
What the source says
The ISO project record that the standards entry cites lists the designation ISO/IEC FDIS 24970, the title "Artificial intelligence, AI system logging", the committee ISO/IEC JTC 1/SC 42 and the stage code 50.20, which the ISO stage table labels as the FDIS ballot initiated. The scope statement reads that the document "describes capabilities and requirements for event logging in artificial intelligence systems" and that it "is designed to be used with a risk management system". The standards entry for prEN ISO/IEC 24970Approval records what the document supplies to a test: common capabilities, requirements and an information model for logging events in AI systems, which give an Art. 12 logging test its reference event model and its field definitions.
The stage label "approval" in the standards data corresponds to the CEN Formal Vote and to the ISO FDIS ballot. The CEN BOSS page on the Formal Vote states that the stage covers the editing of a final draft European Standard (FprEN), a vote of the CEN members in an eight-week period with no extension, and ratification one month after a positive result is circulated. The CEN BOSS page on the Enquiry states that the earlier stage is a weighted vote of twelve weeks with comments, and that a text with technical changes after the Enquiry goes to the Formal Vote. Under the Vienna Agreement, a standard developed under ISO lead is voted in parallel at the DIS and FDIS stages, so both ballots run on the same text. A document at approval stage is therefore a final draft: the technical content is settled unless the vote fails, and the clause numbering may still move before publication.
The JTC 21 logging part prEN 18229-1Enquiry sits one stage earlier, at enquiry, where technical comments are still open. The standards page shows both stages from data and the citation status of every entry: none is cited in the Official Journal as of the anchor date
Verified on last full verification run, see the change log
, so Art. 40(1) of Regulation (EU) 2024/1689 attaches no presumption of conformity to either document.| Document | Body | Stage | What a test takes from it |
|---|---|---|---|
prEN ISO/IEC 24970Approval | ISO/IEC JTC 1/SC 42, parallel adoption by CEN-CENELEC JTC 21 | Approval: final draft, FDIS ballot and CEN Formal Vote | Reference event model, record structure, integrity and traceability clauses |
prEN 18229-1Enquiry | CEN-CENELEC JTC 21 | Enquiry: technical comments open | Expected event set, fields per event, retention requirements |
What changes for a provider or deployer
The obligation does not move with the ballot. Art. 12(1) requires a high-risk AI system to technically allow the automatic recording of events over its lifetime, and Art. 12(2) requires the events to give traceability appropriate to the intended purpose for the three purposes in points (a) to (c). The duty applies from the Annex III application date Deferred for a system classified under Art. 6(2) and from the Annex I date Deferred for a system under Art. 6(1). The article names no event list, no field and no retention period; the Art. 12 obligation page records that the minimum retention sits in Art. 19 and Art. 26(6). The event set and the traceability level come from hierarchy level 2, the two drafts above, read against the intended purpose in the instructions for use.
What changes is the stability of the reference. A final draft gives a test an event model whose technical content is settled, so an expected event set built from it survives publication unless the vote fails. PR-12-LOG v1.0 builds the expected event set from the reference event model in step 6, checks in step 12 that each catalogued event carries a time-zoned timestamp, an event type, a source identifier and a correlation identifier, tests continuity of the event set across an update in step 17, tests the integrity mechanism in steps 22 and 23, and reconstructs sampled decisions from the logs alone in step 30. Each of those steps cites the clause topic of prEN ISO/IEC 24970Approval without a clause number, because numbering can still move; the protocol page states that limitation and its revision rule. The outputs are the log completeness and continuity test report and the decision reconstruction record, delivered as the test report of the logging and human-oversight verification service within the limits stated at what we cannot do.
For the deployer, the information model gives a checklist for what the export under Art. 13(3)(f) carries. Art. 26(5) requires the deployer to monitor the operation of the system on the basis of the instructions for use, and Art. 26(6) requires the deployer to keep the logs under its control for the period that article sets. An export without the model version and the configuration in force does not let the deployer reconstruct a decision after a retrain, the first common finding on the Art. 12 obligation page. A draft is evidence for the method a provider chose, never a requirement: Art. 12 refers to no standard, and the technical documentation under Annex IV section 3 names the draft with its stage as the source of the event set.
What to do now
- Record the traceability rationale under Art. 12(2): the level the intended purpose needs and the event set that achieves it, as step 5 of PR-12-LOG v1.0 asks.
- Build the expected event set from the final draft and the enquiry draft, one row per event with purpose, trigger and fields, following the log completeness guide.
- Compare the log schema in Annex IV section 3 against that set, and check every event for the four record fields in step 12 of the protocol.
- Reconstruct a sample of decisions from the logs alone, provider side and deployer side, and classify each gap as missing event, missing field, unreadable format, broken linkage or retention loss.
- Watch the standards page for publication and for any citation in the Official Journal; the first changes the reference name in the technical documentation, the second changes what Art. 40(1) attaches.
Related pages
The obligation, protocol, guide, service and hubs this post rests on.
- Obligations
- Protocols
- ICP hubs
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.