The Article 12 compliance gap.

1. The legal obligation

Article 12 of the EU AI Act requires providers of high-risk AI systems to ensure that the system technically allows for the automatic recording of events over the lifetime of the system. The recorded events must be appropriate to the intended purpose of the system and must enable, at minimum, the identification of situations that may give rise to risks under Article 9, the facilitation of post-market monitoring under Article 72, and the monitoring of operation by deployers under Article 26.

Under the current official text the Article applies from 2 August 2026 in respect of high-risk AI systems within its scope. A 7 May 2026 provisional Council and Parliament agreement on the AI Omnibus would move the standalone high-risk application date to 2 December 2027 and the product-embedded high-risk application date to 2 August 2028 if formally adopted. The work to close the architectural gap, including the contribution described in this paper, continues regardless of which date applies. The obligation falls on providers placing high-risk AI systems on the EU market, irrespective of whether the provider is established in the EU. Non-compliance carries administrative fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99).

Article 12 specifies what must be logged. It does not specify how.

2. The interpretive gap

Article 12 is a results-based requirement. The Article specifies that logs must be capable of supporting the post-market and operational monitoring obligations elsewhere in the Regulation, but does not specify any of the following technical questions on which compliance will turn:

• The granularity at which logs must be recorded (per-system, per-session, per-inference, per-event)
• The integrity properties the logs must possess (tamper-evidence, non-repudiation, cryptographic binding to the recorded events)
• The verifiability of the logs by parties other than the provider (regulators, deployers, affected persons, third-party auditors)
• The retention period and the requirements for storage architecture
• The format and interoperability of the logs across providers, deployers, and supervisory authorities

In each of these dimensions, the Article requires something, but the specific technical requirements are left to be defined by harmonised standards, common specifications, or the providers themselves operating at risk of supervisory challenge.

3. The available standardised solutions

The relevant standards landscape includes the following published or in-development standards:

3.1. ISO/IEC 42001:2023, AI management systems

ISO/IEC 42001 specifies requirements for an AI management system, including governance, risk management, and lifecycle activities. The standard addresses the organisational and procedural dimensions of AI governance. It does not specify per-inference logging architecture, log integrity properties, or external verifiability of logs.

3.2. ISO/IEC 23894:2023, AI risk management

ISO/IEC 23894 provides guidance on AI risk management aligned with ISO 31000. The standard addresses the risk management activities required by Article 9 of the EU AI Act. It does not address the technical implementation of the logging requirement in Article 12.

3.3. The C2PA content provenance specification

The Coalition for Content Provenance and Authenticity (C2PA) publishes a specification for recording the origin and creation history of digital content, including AI-generated content. A C2PA manifest records information about the creating tool, the creating entity, and the editing history. It does not record whether a non-bypassable governance evaluation was applied to the output before delivery, nor does it record the specific governance parameters that the evaluation considered.

3.4. Trusted Execution Environment attestation

TEE-based attestation systems (Intel SGX, AMD SEV, ARM TrustZone, and cloud-based equivalents) certify the execution environment in which an AI system runs. Attestation reports confirm model identity, platform integrity, and code measurement. They do not certify the per-output governance decisions applied to specific inferences.

3.5. AI governance and monitoring platforms

Commercial AI governance platforms provide aggregate visibility of AI system activity, configuration management, and sampling-based audit. They do not, in general, issue per-inference externally-verifiable evidence of the governance evaluation applied to specific outputs.

4. Characterising the gap

The standardised solutions described above each address a portion of the AI governance and audit landscape. None of them, individually or in combination, satisfies the composite requirement that a regulator, deployer, or affected person would need to verify Article 12 compliance for a specific high-risk AI output:

Provide independently verifiable evidence that a specific AI output, identified by content, was subject to a non-bypassable governance evaluation against the risk parameters established under Article 9, and that the parameters of that evaluation are recoverable from the evidence without access to the provider's internal systems.

The gap is not a gap in policy or in regulatory intent. The Article 12 obligation is clear in what it asks for. The gap is in the available standardised technical means by which providers can demonstrate compliance and by which supervisory authorities can verify it.

5. The four required architectural properties

The published paper develops the gap analysis into a candidate evaluative framework: four architectural properties proposed as the minimum set required for any Article 12-compliant per-inference logging mechanism. A mechanism that satisfies fewer than the four cannot satisfy the obligation in full.

• Per-inference, every governed output produces an associated record; aggregate or sampled logs are insufficient
• Architecturally bound, the record cannot be generated except by the governance pipeline; an audit log generated independently of enforcement is not a governance certificate
• Externally verifiable, third parties can verify the record without access to the issuing system's internal infrastructure
• Fail-closed, no output is delivered without a retrievable, valid record

Section 4 of the published paper sets out these four properties in detail and Section 5 develops the architectural-binding requirement (the Integrity Clash applied to the audit-vs-enforcement boundary, generalising the formalisation in Nemecek et al., 2026) as the property that distinguishes a governance certificate from an audit log.

6. Relationship to the trust stack

The trust stack architecture developed by aiGUARD Systems Limited, comprising Synapse-ID™, aiGUARD™, and aiGEC™, addresses each of the four required properties. The aiGEC™ specification, in particular, is the candidate technical instantiation of all four architectural properties combined. The aiGUARD™ (Thames Sentinel™) architecture provides the non-bypassable governance enforcement to which aiGEC™ is architecturally bound.

The trust stack is one of several possible technical contributions to closing the Article 12 gap. The published paper characterises the gap and presents per-inference governance certification as a candidate mechanism, it does not advocate exclusively for the trust stack. Standards bodies, working groups, and harmonised standards processes will determine which technical contributions are adopted and on what terms. aiGUARD Systems Limited offers standards-essential claims under FRAND, see our licensing page for the binding undertaking.

7. Conclusion

Article 12 of the EU AI Act becomes applicable to high-risk AI systems on the timetable confirmed by the EU institutions through the AI Omnibus process. The available standardised technical solutions do not, individually or in combination, satisfy the composite verification requirement that supervisory authorities and deployers will reasonably expect. The gap is real, characterisable, and addressable.

It is in the interests of providers, deployers, supervisors, and ultimately of persons affected by high-risk AI systems that the gap be closed through harmonised technical standards rather than through ad hoc provider implementations. aiGUARD Systems Limited welcomes engagement with standards bodies, regulators, and industry partners on the work required to close this gap before the compliance deadline.