An AI system that has to keep records.
Article 12 requires high-risk AI systems to allow the automatic recording of events (logs) over their lifetime, so their operation can be traced and reviewed. It is the traceability backbone of the high-risk regime: it is what lets you reconstruct what a system did, supports post-market monitoring, and underpins an investigation. And it is code, an event is logged because something in the system logs it.
The shapes the same control failure takes.
Record-keeping weakens when a change reduces what a high-risk AI system records about its own operation. The recurring shapes:
Inference logging is removed
The call that records each decision (the inputs, the output, the model version) is deleted in a cleanup, so the system stops producing the trace Art. 12 expects.
Key fields are dropped from the record
Logging stays but stops capturing what is needed to reconstruct a decision (which version ran, what it was given), so the record exists but is not traceable.
A new high-risk path ships unlogged
A new model, route, or decision path is added with no event logging, leaving part of the system's operation unrecorded.
Logging stops covering the system's operation
The automatic logging is narrowed so it no longer captures events across the system's operation, leaving gaps in the traceability Art. 12 is meant to enable.
Log integrity is weakened
The event log becomes editable or is moved somewhere it can be changed, undermining its value as a faithful record.
Inference logging removed to cut cost.
A high-risk scoring model logs every decision it makes. The volume is expensive, so a change drops the logging call. The model keeps scoring; it just stops keeping any record of what it decided or on what input.
const result = await model.score(application)- await events.record({ model: model.version, input: application.id, result }) return resultThis removes the record of what the high-risk system decided and on what input. Art. 12 (record-keeping) expects automatic logging of the system's events over its lifetime, so its operation can be traced. If the cost is the issue, reduce what is logged or its retention tier, but keep a traceable record rather than removing it. Whether a system is high-risk and in scope is for your own assessment.
Record-keeping is checked as traceability.
Conformity for a high-risk system looks for the technical documentation and the logging that make its operation traceable: can you show what the system did, on what input, with which version, across its lifetime. A change that removed or hollowed out that logging is the gap behind that traceability, and it is visible in the diff to the inference or event-logging path.
A review, not a conformity assessment.
heygrc flags changes that touch Art. 12 and cites the article so the fix happens in the pull request. It does not classify your system's risk tier or run your conformity assessment. It catches the moment a high-risk system stops recording its operation, at the diff. heygrc is in early access.