The obligations of the EU AI Act — Regulation (EU) 2024/1689 — describe properties a system must show while it runs, not documents to produce afterwards. Risk management (Art. 9), transparency (Art. 13), human oversight (Art. 14) and automatic record-keeping (Art. 12) are written as process requirements, yet each has a technical counterpart you can measure: a threshold, an endpoint, an immutable log, a response time. Treat compliance as paperwork and you end up with folders of evidence; treat it as architecture and you get a system that emits the evidence itself.

Problem

The Regulation entered into force on 1 August 2024 and applies in phases: the Art. 5 prohibitions from 2 February 2025, the obligations on general-purpose AI (GPAI) models from 2 August 2025, the high-risk obligations originally set for 2 August 2026 (Art. 113). That last deadline is weighed down by a Commission proposal of 19 November 2025, the Digital Omnibus on AI, which postpones the application of the high-risk obligations: 2 December 2027 for stand-alone Annex III systems, 2 August 2028 for those embedded in regulated products under Annex I. On that text Parliament and Council reached a provisional political agreement on 7 May 2026, and the confirming vote is expected in the June 2026 plenary. It remains a proposal in progress: until it appears in the Official Journal of the Union, the new dates do not bind, and those of the original Regulation remain the legal reference.

The knot, though, does not depend on the dates. Articles 9-15 of the AI Act say what a high-risk system must do, not how to demonstrate it repeatably. Art. 9 calls for a “continuous and iterative” risk-management system across the whole lifecycle; Art. 12 calls for automatic recording of events (“logs”) for traceability; Art. 14 calls for human-oversight measures “commensurate” with the risks. Three legal verbs, no metrics. Turning the requirement into a verifiable control falls to the operator, who today manages case by case, often with documents that describe an intention instead of measuring a behaviour.

Architecture

Every AI Act obligation can be rewritten as an observable property of the system. This does not reinterpret the law: it chooses the evidence that makes the obligation checkable.

  • Risk management (Art. 9) — property: the system exposes a risk threshold for each decision and refuses or flags it when exceeded. Measurable evidence: the share of decisions carrying a score and a rationale, and the abstention rate when confidence falls below threshold.
  • Accuracy, robustness, cybersecurity (Art. 15) — property: the system holds the accuracy metrics it declares and withstands adversarial input. Evidence: the values measured on a versioned validation set, and the mean time to notice a runtime manipulation.
  • Transparency (Art. 13) — property: for each response the system can return data sources, model version and confidence level. Evidence: the latency within which this explanation arrives over an API, not its presence in a manual.
  • Human oversight (Art. 14) — property: there is a real human intervention point, with a state and the authority to halt. Evidence: the time that passes between a flag and the ability to stop, and the record of who exercised the override.
  • Record-keeping (Art. 12) — property: every decision leaves an append-only record, traceable to input, model version and operator. Evidence: the verifiable integrity of the log (chained hashing, signature) and the hours it takes to extract a single case’s trace when an authority asks for it.

This rewrites compliance as a set of controls, each with an expected value, a measurement method and an acceptance threshold. It is not invented: it is the model that risk-management frameworks already use. The NIST AI RMF organises risk governance into the Govern, Map, Measure, Manage functions, and the Measure function exists precisely to quantify what the other three oversee. ISO/IEC 42001 defines a certifiable AI management system (AIMS), with controls and an auditable improvement cycle. Both give the structure within which the controls listed above become repeatable and verifiable by third parties.

Critical point

The gap that matters is the one between the legal requirement and the technical control that makes it verifiable; it is not the one between a compliant company and a non-compliant one. An organisation can have a flawlessly written human-oversight policy and no way to show, after the fact, who was able to halt the system and when. The policy is documentation; the signed audit log is architecture.

Three properties separate evidence that holds from evidence that only describes:

  1. Immutability. A compliance log that can be edited after the fact is not evidence. It needs append-only storage with verifiable integrity — hash-chained logs, or signing with cosign or equivalents — so that an authority can establish that the trace has not been rewritten.
  2. Traceability to a standard. An isolated control is worth little; a control mapped to an AI Act requirement and to a NIST AI RMF or ISO/IEC 42001 control is reused across audits and cuts duplication. The mapping is the index that ties the evidence to the obligation.
  3. Automated extraction. If producing the evidence for an authority takes weeks of manual work, the system is not governed: it is documented. The metric that matters is the hours it takes to generate the evidence package on request.

It is the same gap that the OISG vocabulary (Open, Intelligent, Secure, Governed) makes plain: regulatory standards set high-level obligations without saying which measurable properties a system must show to meet them. OISG proposes, for each pillar, measurable adequacy criteria — for the Governed pillar, for instance, the hours it takes to produce compliance evidence for a supervisory authority — and an explicit mapping to the EU AI Act, NIST AI RMF and ISO/IEC 42001. It is the layer that ties the article of the Regulation to the control that proves it.

Implications

For anyone designing high-risk systems the architectural approach has concrete operational consequences. The Art. 9 risk management becomes a runtime requirement — scoring and abstention — not a chapter in the Annex IV technical documentation. The Art. 12 logging becomes a storage design choice (append-only, signed) made at the outset, not an export reconstructed on the eve of an audit. The Art. 14 human oversight becomes a component with an observable state and an authority to halt that you can test.

The gain lies in audit cost: evidence collected once, mapped to NIST AI RMF and ISO/IEC 42001, is reused across frameworks and supervisory cycles. The same signed trace that demonstrates traceability under Art. 12 also serves ISO/IEC 42001 reporting and the security obligations that intertwine with NIS2 (Network and Information Security Directive 2) in regulated sectors.

The Italian context adds a layer. Law no. 132 of 23 September 2025 — published in Gazzetta Ufficiale no. 223 of 25 September 2025, in force from 10 October 2025 — sets the national framework and names AgID (Agenzia per l’Italia Digitale) and ACN (Agenzia per la Cybersicurezza Nazionale) as competent authorities: AgID for notification, assessment and accreditation, ACN for surveillance and inspection and sanctioning powers. The law contains delegations to the Government to be exercised within 12 and 24 months: the implementing decrees are in the process of adoption and will define part of the specific obligations. A system that emits automatic evidence does not mind which authority asks for it or in what form: the recipient changes, not the architecture.

Limits

The approach does not settle the open legal questions. Determining whether a system is high-risk under Art. 6 and Annex III remains a legal assessment that no metric replaces; verifiable architecture takes the classification as already made. Likewise, thresholds and validation sets must be defined on defensible grounds: a measurable control that is badly calibrated gives false assurance, not compliance.

The dates for high-risk application remain uncertain until the Digital Omnibus appears in the Official Journal of the Union, and the implementing decrees of Law 132/2025 may add specific obligations not yet known. None of these unknowns changes the operational conclusion: the technical controls — scoring, abstention, signed append-only logs, traced override, automated evidence extraction — are useful regardless of the exact date they become mandatory, because they are the measurable form of obligations the Regulation has already written into its text.

Cover image: The hemicycle of the European Parliament in Strasbourg: a large semicircular chamber with curved rows of desks and seats descending… — photo by David Iliff, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:European_Parliament_Strasbourg_Hemicycle_-_Diliff.jpg