The NIST AI Risk Management Framework and ISO/IEC 42001 are serious, well-designed documents. If you read them carefully, you will find a comprehensive account of what can go wrong with AI systems and a principled vocabulary for talking about risk, accountability, and governance.
What you will not find is a set of technical controls that enforce the framework at runtime.
That gap – between a governance document and a governance *control* – is the most important unsolved problem in enterprise AI risk management. Both NIST AI RMF and ISO/IEC 42001 are explicit that governance measures must be implemented and verifiable, not merely documented. Organizations that conflate having a framework with implementing controls are producing compliance theater.
What the frameworks actually require
The NIST AI Risk Management Framework organizes risk management around four core functions: Govern, Map, Measure, and Manage. The Govern function requires accountability structures, maintained AI risk policies, and informed teams. The Manage function requires that risk responses be implemented *and monitored* – not just identified.
ISO/IEC 42001 is a management system standard – the AI equivalent of ISO 27001 for information security. It requires a documented scope, risk assessment processes, objectives, and performance evaluation. Certification requires demonstrated implementation, not just policy documentation.
Both frameworks share one requirement that is easy to state and hard to meet: evidence of operation. NIST AI RMF’s Measure function requires quantifiable metrics and monitoring. ISO/IEC 42001’s performance evaluation clause requires that organizations monitor, measure, analyze, and evaluate their AI management system. Neither accepts “we have a policy” as a substitute for “we can show the policy is working.”
The translation problem
Most organizations approach framework compliance as a documentation exercise. They map existing policies to framework categories, identify gaps, write new policies to fill them, and present the completed mapping as compliance. This is useful – documented policies are better than none – but it misses the point.
A policy stating “AI agents must operate within least-privilege access bounds” does not constrain a single agent action. A policy stating “agent outputs must be logged” does not produce a single log entry. The frameworks require that policies be *implemented*: that a technical mechanism enforces the constraint and produces evidence.
Mapping controls to enforcement mechanisms
Consider representative NIST AI RMF and ISO/IEC 42001 requirements translated into enforcement-layer terms:
NIST GOVERN 1.1 – Policies and procedures are established for AI risk management:
A versioned policy bundle documenting what each agent is permitted to do, compiled from named principles and version-controlled. The active version is recorded with every enforcement decision.
NIST MANAGE 2.2 – Mechanisms for detecting and responding to AI failures are established:
A fail-closed architecture that blocks actions when policy evaluation is indeterminate, an escalation path for out-of-scope requests, and an evidence ledger recording anomalies.
NIST MEASURE 2.5 – AI system metrics and effectiveness measures are deployed:
SARIF-formatted findings from every enforcement decision, with trend analysis across sessions. Policy violation frequency, escalation volumes, repeated-failure detection.
ISO 42001 Clause 8 – Operation: AI system lifecycle processes are planned and controlled:
Runtime enforcement intercepting agent actions before execution, applying documented policy, and recording each decision. The lifecycle of every agent action is controlled, not described.
ISO 42001 Clause 9 – Performance evaluation:
An append-only audit ledger providing quantitative data on enforcement rates, violation frequencies, escalation volumes, and remediation outcomes.
How Ethosure operationalizes both frameworks
Ethosure’s enforcement core – the open-source `coding-ethos` project – was built on the principle that governance must be operational before it is auditable.
The policy bundle satisfies the documented-policy requirement: a single versioned JSON artifact compiled from named engineering principles, repo policy, and hook configuration. It is the policy record for NIST GOVERN and the documented procedure for ISO 42001 Clause 8.
The CEL-based deterministic enforcement engine satisfies the implementation requirement: every agent action is evaluated against the active policy bundle before execution. The decision is binding, not advisory. This gives the documented policy operational force.
The append-only evidence ledger – JSONL events with SARIF findings, linked to policy provisions – satisfies the measurement and audit requirements of both frameworks. When ISO 42001 Clause 9 calls for performance evaluation data, the ledger provides it. When NIST Measure requires quantifiable metrics, the ledger produces them.
The framework mapping is explicit: Ethosure links each evidence record to relevant NIST AI RMF and ISO/IEC 42001 control identifiers, so a compliance review can move directly from a control requirement to the evidence that satisfies it.
The practical implication
Organizations that have completed a NIST AI RMF or ISO/IEC 42001 mapping exercise and believe they have addressed their framework obligations should ask one question: can you produce evidence that the controls in the mapping are actually running?
If the answer requires assembling documentation rather than querying a system, the framework has not been operationalized – it has been documented. Regulators are examining exactly that gap. The EU AI Act, OSFI AGILE, and emerging AI governance frameworks all share the evidence-of-operation requirement that NIST and ISO articulate. The compliance posture that will survive scrutiny is one where the framework lives in the enforcement layer, not the document management system.
