Updated 12 May 2026 · Re-checked and republished 29 August 2026 · AgenticRail
EU AI Act, NIST AI RMF, ISO 42001: Three Frameworks, One Evidence Question
Three frameworks dominate AI governance in 2026: the EU AI Act (binding regulation, high-risk obligations from December 2027, and December 2028 for AI embedded in regulated products), NIST AI RMF 1.0 (voluntary US framework, widely adopted as enterprise baseline), and ISO/IEC 42001:2023 (international management system standard with certification path). Each specifies different obligations. All three converge on a requirement that agentic AI systems cannot meet with logging alone: evidence that oversight mechanisms were operational during deployment. A framework is an asserted safeguard — it says what must happen. What every framework leaves to the operator is proof that it did. This page compares the three factually, then maps what a pre-execution receipt chain can — and deliberately cannot — evidence for each. (The general version of that distinction — asserted, enforced, provable — is here.)
May 2026 — What's changed
→EU AI Act — high-risk enforcement December 2027 and August 2028. Stand-alone Annex III high-risk AI obligations apply from 2 December 2027; high-risk AI embedded in regulated products under Annex I from 2 August 2028. Both were deferred by the Digital Omnibus on AI, in force since 27 July 2026. Agentic systems in Annex III sectors must satisfy Articles 9, 11, 12, and 14 or face penalties up to €15M or 3% of global turnover.
→NIST — Critical Infrastructure Profile concept note (April 2026). NIST published a concept note for AI RMF Profile on Trustworthy AI in Critical Infrastructure, extending the core framework to energy, finance, healthcare, and transport operators. It follows the Generative AI Profile (NIST AI 600-1, July 2024). The direction is sector-specific, risk-tiered guidance — consistent with the EU AI Act's regulatory approach. The profile is in concept phase; a draft for public comment is expected later in 2026.
→ISO/IEC 42001 — Adoption accelerating. ISO/IEC 42001 is not legally required, and certification confers no status under the EU AI Act. What it does provide is a management system an auditor already knows how to test, which is why it is often adopted as a conformity-readiness position ahead of the December 2027 deadline rather than as a substitute for one.
Key takeaways
- EU AI Act is binding law — penalties up to €15M or 3% of turnover for high-risk breaches. High-risk AI deadlines: 2 December 2027 stand-alone (Annex III), 2 August 2028 embedded in regulated products (Annex I). Both deferred by the Digital Omnibus on AI, in force since 27 July 2026.
- NIST AI RMF is voluntary. No penalties, no deadline. Widely adopted as US enterprise baseline.
- ISO/IEC 42001 is voluntary with optional certification. Aligns with ISO 9001/27001 management system structures.
- All three require operational evidence of oversight — not just logs, but proof the controls ran before actions executed. This is why the deterministic vs probabilistic distinction matters at the regulatory level.
- One receipt chain produces evidence toward all three simultaneously. The evidence maps across frameworks; the obligations stay yours.
- MAS SAFR (July 2026) is a supervisory white paper, not a regulation — nothing to comply with. It earns a place here because it is the first of these documents to specify runtime components rather than organisational process, and because it raises the custody question the others leave alone: who holds the audit log.
The three frameworks at a glance
Binding regulation
EU AI Act
Regulation 2024/1689 · European Union
Risk-based regulation classifying AI systems from unacceptable risk (banned) to minimal risk. High-risk AI — including agentic systems in hiring, lending, healthcare, law enforcement, and critical infrastructure — faces mandatory conformity assessment, technical documentation, CE marking, EU database registration, human oversight, and logging. High-risk obligations apply from 2 December 2027 for stand-alone systems, and 2 August 2028 for high-risk AI embedded in regulated products under Annex I (deferred by the Digital Omnibus on AI, in force since 27 July 2026).
Full text →
Voluntary framework
NIST AI RMF 1.0
AI Risk Management Framework · NIST, USA
Voluntary framework organising AI risk management across four functions: Govern (policies, culture), Map (context, risk identification), Measure (analysis, assessment), Manage (prioritisation, treatment). Adopted as baseline by US federal agencies and widely used in enterprise risk programmes globally. No certification mechanism; no legal deadline.
NIST AI →
Certifiable standard
ISO/IEC 42001:2023
AI Management Systems · ISO/IEC JTC 1/SC 42
International standard for AI management systems, structured like ISO 9001 (quality) and ISO 27001 (information security). Specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. Certification available via accredited bodies. Annex A includes 38 controls covering AI system design, data, operations, and incident management.
ISO standard →
Side-by-side comparison
| Property |
EU AI Act |
NIST AI RMF 1.0 |
ISO/IEC 42001 |
| Legal force |
Binding regulation (EU) |
Voluntary guidance |
Voluntary; certification available |
| Deadline |
Dec 2027 (high-risk AI) |
None |
None (certification-led) |
| Scope |
All AI placed on EU market; risk-tiered |
Any organisation using or developing AI |
Any organisation developing or using AI |
| Penalties |
Up to €15M or 3% (high-risk); €35M or 7% (prohibited practices) |
None |
None (loss of certification) |
| Human oversight required |
Yes — Article 14 (mandatory) |
Yes — Manage 2.4 (recommended) |
Yes — Annex A controls (required for certification) |
| Logging / traceability |
Yes — Article 12 (mandatory) |
Yes — Measure 2.4 (recommended) |
Yes — Annex A.6.2.8 (control) |
| Technical documentation |
Yes — Article 11 + Annex IV (mandatory) |
Recommended (Map 5) |
Yes — Clause 8.4 (required for certification) |
| Incident reporting |
Yes — Article 73 (serious incidents) |
Recommended (Manage 4) |
Yes — Clause 10.1 |
| Conformity assessment |
Yes — third-party for most Annex III |
No |
Yes — independent certification |
| Agentic AI specific guidance |
Implicit via risk classification |
AI RMF Playbook (emerging) |
Not explicitly addressed |
How sequence enforcement maps to each framework
Sequence enforcement — evaluating each agent action against a defined policy before execution, issuing a cryptographic receipt on every authorised pass — is not specific to any one framework. It produces the class of evidence all three converge on: oversight points that are operational during deployment, logging that is tamper-evident, and proof that prerequisites were met before actions executed.
Framework requirement
Article 14: Human oversight measures — natural persons must be able to intervene or halt the system. Oversight must be effective (built into operation, not available as policy option).
What AgenticRail’s receipt chain evidences
AgenticRail does not satisfy Article 14 on its own — human oversight is an organisational measure, not a software feature. What AgenticRail adds is the evidence layer oversight needs: every step requires authorisation before executing, a DENY stops execution without relying on the model to comply, and every enforcement decision — the refusals as much as the permissions — leaves a signed receipt. A HALT is different and narrower: it is a refusal at the boundary before enforcement runs, so it produces no receipt and evidences nothing. Whether oversight was exercised well is a question about people; whether it structurally could and did occur becomes provable.
Framework requirement
Article 12(2)(a): logging capabilities must enable recording of events relevant for identifying situations in which the system may present a risk. Article 12 specifies purpose, not content — the period-of-use / reference-database / persons-involved minimum list is Article 12(3) and applies to remote biometric identification only.
What AgenticRail’s receipt chain evidences
Every AgenticRail gate decision produces an Ed25519-signed receipt in tamper-evident storage, recording: step, sequence ID, decision, timestamp, payload hash, action type, and chain linkage (
prev_receipt_hash). Sealed sequences are additionally copied to an
independently held archive. Tampering breaks the chain detectably. Pre-action record — not post-action log.
Framework requirement
Article 11: Technical documentation demonstrating system operates as intended, including design logic, testing results, and risk management measures.
What AgenticRail’s receipt chain evidences
AgenticRail’s report endpoint generates a verifiable record for any sequence ID: the receipt chain with raw Ed25519 signatures and their exact signed bytes (so
verification runs offline, in your own code), per-link hash-chain checks, and an independent-archive comparison for sealed sequences. It does not write your Article 11 documentation — it supplies the operational-evidence exhibits that documentation cites.
Framework requirement
Manage 2.4: Mechanisms are in place, and responsibilities assigned, to supersede, disengage, or deactivate AI systems that behave inconsistently with intended use.
What AgenticRail’s receipt chain evidences
AgenticRail is separate from the model, so the authority to stop it does not depend on the model complying. A sequence is scoped to the API key that opened it, and a revoked key is refused at the boundary from that point on — every subsequent step, without the agent's cooperation. Two limits worth stating: revocation is performed by AgenticRail rather than through a customer-facing control, and the step-order contract a deployer declares on each call is the part of policy they set themselves. Manage 2.4 asks for mechanisms and assigned responsibilities; the mechanism is real and the assignment is a deployment arrangement, not a product feature.
Framework requirement
Measure 2.4: The functionality and behaviour of the deployed AI system are monitored when in production.
What AgenticRail’s receipt chain evidences
AgenticRail’s gate statistics (total evaluations, ALLOW/DENY rates, sequence completions) are recorded in KV and exposed via the
dashboard. The receipt chain enables retrospective analysis of exactly which steps were blocked and why.
See the May 2026 updates section at the top for the NIST Critical Infrastructure Profile concept note and EU AI Act enforcement timeline.
Framework requirement
Clause 9.1: Monitoring, measurement, analysis, and evaluation — the organisation shall determine what needs to be monitored and measured and the methods for valid results.
What AgenticRail’s receipt chain evidences
AgenticRail gate decisions are the measurement points. Every ALLOW and DENY is recorded with full metadata. The AgenticRail receipt chain constitutes the continuous operational record that Clause 9.1 requires — produced automatically, not as a separate measurement exercise.
Framework requirement
Annex A, A.6.2.8: AI system recording of event logs — the organisation shall record event logs of AI system operation across the life cycle, at minimum while the system is in use.
What AgenticRail’s receipt chain evidences
AgenticRail’s receipt chain enables complete reconstruction of agent sequence behaviour: which steps ran, in what order, what the gate decided, at what time. The Ed25519 signatures make the reconstruction tamper-evident — any alteration is detectable.
A fourth document, different in kind: MAS SAFR
The three above are the established instruments — one binding, one voluntary, one certifiable. A fourth appeared in July 2026, and it belongs on this page for a different reason: not because it binds anyone, but because of what it describes.
Supervisory white paper
MAS SAFR
Safeguards for Agentic Finance at Runtime · Monetary Authority of Singapore, July 2026
Describes a runtime governance layer built from four components — Agent Identity, Controls Repository, Disposition Engine, Audit Log — which together evaluate an agent’s proposed action before it executes and record the decision. A white paper, not a regulation: it confers no status, and there is nothing to be compliant with.
Component mapping →
What makes it worth reading beside the other three is the level it operates at. The EU AI Act, NIST AI RMF and ISO/IEC 42001 all specify organisational process: who is accountable, what must be documented, which risks must be managed. SAFR specifies runtime components — the parts that sit in the execution path and act while the agent is running. It is the first of these four documents to describe the evidence layer itself rather than the obligations that layer exists to serve.
It also puts a question on the table that the other three leave alone: who holds the audit log. A log held by the same party whose agents it records is corroboration, not attestation, and SAFR states an independence requirement rather than leaving custody unexamined. The component mapping sets out where AgenticRail meets each of the four components — and the point at which the mapping stops.
Which framework applies to your agentic AI system?
Most organisations building agentic AI in 2026 will need to address at least two of these frameworks simultaneously:
- →EU market + high-risk sector: EU AI Act is mandatory. ISO/IEC 42001 certification provides a structured conformity path. NIST AI RMF aligns US operations.
- →US federal or regulated enterprise: NIST AI RMF is baseline. ISO/IEC 42001 provides certification. EU AI Act applies if EU market activity exists.
- →Global enterprise, any sector: ISO/IEC 42001 provides the management system foundation. EU AI Act applies to EU-facing deployments. NIST AI RMF fills voluntary gaps.
- →Agentic AI in any regulated context: All three frameworks require operational evidence that oversight mechanisms functioned during deployment. Sequence enforcement produces this evidence — one receipt chain, citable under all three.
- →Outside these jurisdictions (including Aotearoa NZ): none of the three binds directly — but local regulators ask the same underlying question: can you evidence that the safeguard ran? See the NZ health and NZ education briefs for that question on home ground.
The evidence layer is the same regardless of which framework you are working under. The receipt chain offered as Article 12 evidence is the same chain offered under ISO/IEC 42001 Annex A.6.2.8 and NIST AI RMF Measure 2.4 — build the evidence once, cite it three ways. The frameworks’ other obligations — risk management, documentation, and the oversight measures themselves — remain separate work that no receipt does for you.
Frequently asked questions
What is the difference between EU AI Act and NIST AI RMF?
The EU AI Act is binding EU law — mandatory for any AI placed on the EU market, with penalties up to €15M or 3% of global turnover for breaches of the high-risk obligations (Article 99(4) — the €35M / 7% tier is Article 99(3), for the prohibited practices in Article 5) and compliance deadlines of 2 December 2027 for stand-alone Annex III high-risk AI and 2 August 2028 for high-risk AI embedded in regulated products under Annex I. NIST AI RMF 1.0 is a voluntary US framework with no penalties or legal deadlines. It organises risk management across four functions (Govern, Map, Measure, Manage) and is widely adopted as an enterprise baseline, particularly in US federal contexts.
Is ISO 42001 required for EU AI Act compliance?
No — ISO/IEC 42001 certification is not legally required for EU AI Act compliance. However, it provides a structured management system that can support the technical documentation and risk management evidence required under Articles 9 and 11. Many operators pursuing EU AI Act conformity assessment use ISO/IEC 42001 as a governance foundation alongside their notified body review.
Does California SB 53 apply to my agentic AI system?
Almost certainly not, unless you train frontier models yourself. California SB 53, the Transparency in Frontier Artificial Intelligence Act, took effect on 1 January 2026 with further provisions from 1 January 2027. It binds frontier developers — developers of foundation models trained using more than 10^26 integer or floating-point operations, including compute used in later fine-tuning or material modification. A second and stricter tier, large frontier developers, applies where annual revenue including affiliates exceeded USD 500 million in the preceding year; those organisations must additionally maintain catastrophic-risk protocols and report critical safety incidents to California regulators. Deploying an agent built on somebody else's model does not make you a frontier developer, and neither does supplying a component used inside an agentic system. SB 53 regulates the people training the models, not the people running workflows on top of them — which is why it sits outside the three frameworks compared above rather than beside them.
What does EU AI Act Article 12 require for logging?
Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over the lifetime of the system, and Article 12(2) requires those logging capabilities to enable recording of events relevant for three purposes: identifying situations in which the system may present a risk under Article 79(1) or a substantial modification, facilitating post-market monitoring under Article 72, and monitoring operation under Article 26(5). For a non-biometric high-risk system that is the entire requirement — it specifies what the logs must be good for, not what they must contain, with no field list and no format. The concrete minimum content list widely quoted as Article 12 — period of use, reference database, matching input data, persons involved in verification — is Article 12(3), which opens "For high-risk AI systems referred to in point 1(a) of Annex III": remote biometric identification only. Retention is not in Article 12 either; it is Article 26(6) for deployers and Article 19 for providers. In practice, logs an AI system writes about itself are weak evidence for exactly this purpose — an independent, tamper-evident record is what post-market monitoring can actually rely on. AgenticRail produces that record: an Ed25519-signed receipt written by the gate before each step runs, for permits as much as refusals, chained so that any later alteration is detectable.
When does the EU AI Act apply to agentic AI?
High-risk obligations apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I. Both were deferred by the Digital Omnibus on AI, in force since 27 July 2026. Agentic AI systems operating in Annex III sectors — hiring, lending, healthcare triage, law enforcement, critical infrastructure — are classified as high-risk. These systems must satisfy Articles 9, 11, 12, and 14 by the deadline, including CE marking and EU database registration where required.
Can one approach satisfy EU AI Act, NIST, and ISO 42001 simultaneously?
One evidence layer can serve all three at once. All three frameworks ask for the same underlying capability: operational proof that oversight mechanisms functioned during deployment. Infrastructure-level sequence enforcement — gate-evaluating each agent action before execution and issuing a cryptographic receipt — produces a chain citable under EU AI Act Article 12, ISO/IEC 42001 Annex A.6.2.8, and NIST AI RMF Measure 2.4 simultaneously. What no single mechanism can do is satisfy any of these frameworks outright: risk management, technical documentation, and the oversight measures themselves remain organisational obligations. Evidence once; the obligations stay yours. AgenticRail is built as that layer: one enforcement gate, one signed receipt chain, three citations.
See it working
One receipt chain. Three frameworks’ evidence.
The receipt chain cited under EU AI Act Article 12 is the same chain cited under ISO/IEC 42001 Annex A.6.2.8 and NIST Measure 2.4. You can exercise both ends of it yourself, with no signup and no key.
The demo drives a real sequence through the live gate. Try to run a step out of order and watch it come back DENY with the rule that fired — the enforcement happens before the action, which is what makes the record evidence rather than a log.
The verifier takes any sequence ID and returns the receipt chain with raw Ed25519 signatures and the exact bytes that were signed, so you can check them in your own code against the published keys. It answers any HTTP client, and it never needs to contact us to be believed.