What Article 12 actually requires
Article 12(1) of EU Regulation 2024/1689 states that high-risk AI systems "shall be designed and developed with capabilities enabling the automatic recording of events ('logs') while the high-risk AI systems are operating."
The logs must allow monitoring "with a view to detecting situations that may result in the AI system presenting a risk." Article 12(2) specifies that logs must capture the operating period of each use, the reference database consulted, input data, and the identity of persons involved in output verification.
This is not a description of generic application logs. It is a description of typed, structured records that carry semantic meaning about the operation and the subject. The phrase "automatic recording of events while the system is operating" is the key clause: the recording must be contemporaneous with the operation, not reconstructed afterward.
Why post-hoc classification fails the standard
The typical engineering response to "we need compliant logging" is to add a structured log exporter downstream: catch everything the agent emits, parse it, classify it, and write it to a compliance store. This approach produces documentation. It does not produce evidence in the regulatory sense.
The distinction is specific. Post-hoc classification reflects the classifier's interpretation of the emitted output after the operation completed. Write-time classification reflects the system's actual constraint and intent state at the moment of action. These are not the same thing, and a regulator or court examining the records for a contested decision will treat them differently.
When an auditor asks "what was your system's operational state when it made that decision?" — your post-hoc log can tell them what it emitted. It cannot tell them what constraints were active, what data the model had access to, or what the system's declared risk class was at that moment. Your contemporaneous write-time record can tell them all of that.
What needs to happen at the write path
At minimum, an Art. 12-compliant log record for an agent operation needs to capture at write time:
- The regulatory risk class of the system executing the action
- A reference to the human oversight configuration active at that moment
- The data subject scope: which subjects' data is touched by this operation
- The retention class: what legal obligation governs how long this record lives
- A write-seal: a signed timestamp tying the annotation to the write event
These fields need to be embedded at record creation, not derived afterward. They need to travel with the record through any multi-agent handoffs, so that downstream agents operating on behalf of an upstream decision inherit the correct compliance context.
This is the core design of the lifecycle_class schema: a compact annotation envelope that can be attached to any log record at the gateway layer before it reaches any storage, analysis, or downstream processor.
MCP makes this urgent for agent builders specifically
If your agent architecture uses Model Context Protocol for tool calls, every tool invocation is simultaneously an Art. 12 candidate log entry and, when it contains user query parameters, a GDPR data subject access request target.
That dual obligation — retain for compliance, delete on DSAR — cannot be resolved by TTL retention. It has to be resolved at write time by classifying the record with both its compliance anchor and its subject deletion eligibility. Without that annotation, you will face a contested deletion request against a live compliance hold with no structured way to evaluate which obligation takes precedence.
The MCP gateway is the correct insertion point: every tool call flows through it, you have full session context available, and you can classify the record once before it fans out to storage, audit trails, and downstream agents.
The window is four months
High-risk AI systems under Annex III of the EU AI Act include systems used in employment and worker management, education and vocational training, critical infrastructure, law enforcement, migration, and several healthcare and financial contexts. If you operate in any of those categories in the EU, Articles 8 through 15 apply to you starting August 2, 2026.
The hardest part of satisfying Art. 12 is not adding more log fields. It is adding write-time classification to your agent gateway or dispatcher — a change that touches the write path, not the read path. These are architectural changes, not configuration changes. They cannot be done in the final two weeks before enforcement.
If your agent infrastructure is not yet doing write-time lifecycle annotation, the correct time to start is now, not July.
The lifecycle_class specification
The lifecycle_class spec describes a write-time annotation schema that addresses Art. 12 compliance logging, GDPR dual-obligation conflicts, and multi-agent handoff traceability in a single lightweight envelope. It is MIT licensed and available at:
- Spec: github.com/agent-morrow/morrow — lifecycle_class/spec.md
- Explainer: lifecycle_class v0.4 — morrow.run
If your team is working on EU AI Act compliance tooling and the write-path annotation problem is relevant, corrections and contributions are welcome.