Consider this example: the board asked for an AI governance program. Security came back wanting ISO/IEC 42001 certification. The data science group came back wanting NIST AI RMF. Six weeks later there are two slide decks, two owners, and zero written controls.
Here is the direct answer. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system [1]. The NIST AI Risk Management Framework organizes risk work across four functions, Govern, Map, Measure, and Manage [2], with the Generative AI Profile adding generative-specific risks and suggested actions inside those same functions [3]. They are not competing choices. ISO/IEC 42001 defines management-system requirements. AI RMF can help teams organize the risk work and evidence they map to those requirements.
The failure mode is predictable. Two owners produce two document trees, two evidence collections, and a control nobody can prove is operating, because the evidence lives in whichever tree the last reviewer happened to ask about. What follows is the alternative: a single control library, two mapping columns, and evidence artifacts produced by the delivery pipeline instead of assembled the month before an audit.
The Framework Argument Your Team Is Having Is the Wrong One
The argument sounds like a standards debate but it is actually an ownership debate. Nobody is fighting about whether human oversight matters. They are fighting about whose document the oversight control lives in, which is a question about budget, headcount, and who gets audited.
Start by separating two different jobs. The first job is proving a management system exists and keeps improving, which is what a certification body examines against ISO/IEC 42001 requirements [1]. The second job is analyzing what can go wrong with a specific retrieval-augmented assistant that reads customer contracts and drafts responses, which is what the AI RMF functions and the Generative AI Profile suggested actions are built for [2][3].
Set review frequencies according to risk, responsibilities, and changes to the system. AI RMF calls for ongoing monitoring and periodic review; model, prompt, and tool changes are useful triggers for another use-case review [2].
Treat them as one program with two reporting views so teams can reuse documentation. The control statement gets written once, in operator language. The framework references become metadata on that control, not separate documents with separate authors.
What Each Framework Actually Gives You
ISO/IEC 42001 gives you organization-wide AI management-system requirements, including risk management [1]. Defined AI management system scope. Assigned roles and responsibilities. Stated objectives. Internal audit cadence. Continual improvement [1]. If you have ever been through an ISO 27001 audit, the shape is familiar, and that familiarity is the point: your existing management-system muscle transfers.
NIST AI RMF provides a complementary structure for risk work. The four functions provide a place to put risk identification, measurement, and treatment work [2]. The Generative AI Profile organizes generative-specific risk categories and suggested actions across the same Govern, Map, Measure, and Manage structure [3], which means your evaluation artifacts and your governance reporting can cite the same evidence.
Regulation (EU) 2024/1689 adds a third layer where it applies. Obligations vary by risk classification and the regulation includes provisions addressing general-purpose AI models [4]. The practical consequence for your inventory is that each record must capture whether those obligations apply and the rationale behind that determination, not just a yes or no checkbox.
Use this working map to assign owners and evidence. Confirm the applicable ISO requirements when adding clause references to your control library.
| Governance Need | ISO/IEC 42001 Role | NIST AI RMF Role | Who Owns It | Evidence Location |
|---|---|---|---|---|
| AI system inventory | Management system scope and documented information [1] | Govern function system inventory [2] | AI governance lead | Inventory system of record, queryable |
| Use-case risk classification | Risk and impact assessment requirements [1] | Map categories plus GenAI Profile risk list [3] | Use-case accountable owner | Inventory record with rationale field |
| Pre-release evaluation | Performance evaluation and objectives [1] | Measure function [2][3] | Engineering lead | Evaluation job output attached to release |
| Human oversight design | Roles, responsibilities, operational controls [1] | Manage function treatment decisions [2] | Product owner plus risk | Design doc referenced in deployment manifest |
| Post-deployment monitoring | Monitoring, measurement, analysis [1] | Measure and Manage [2][3] | Platform operations | Dashboards and threshold alert config |
| Incident and near-miss handling | Nonconformity, corrective action, improvement [1] | Manage function response and recovery [2] | Incident commander on rotation | Ticket plus evaluation-set change record |
All three reference points converge on inventory, risk assessment, documentation, human oversight, and post-deployment monitoring. That overlap is exactly why one control library works and why two parallel programs are waste.
The Inventory Record That Gates Production Access
Make the inventory record a hard prerequisite for production access, enforced by the deployment pipeline. Not a reminder email. Not a quarterly nag from the governance channel. If the inventory ID is absent or incomplete, the deploy fails.
The required fields are unglamorous and they decide whether the rest of the program functions:
- Accountable owner, a named person with a calendar, not a team alias that resolves to nobody at 2am
- Business purpose, written in one sentence that a non-technical reviewer can evaluate
- Data categories and classification, including whether personal or regulated data is in scope
- Model and version, as the exact identifier the runtime resolves, not a family name
- Tools or APIs the system can invoke, enumerated per tool rather than summarized as "internal APIs"
- Deployment region and user population, which together drive most regulatory classification questions [4]
- Risk tier, with the rationale recorded alongside the verdict
Tool dependencies belong in the inventory because every tool a server exposes is an entry point that needs its own authorization decision, input validation, and audit trail. The Model Context Protocol specification documents how servers expose tools, resources, and prompts over a defined protocol [5], which makes those definitions inspectable artifacts you can diff instead of tribal knowledge buried in application code. When a new tool appears in a server manifest, that is a governance event.
The review trigger rule should be written once and applied everywhere: re-review on a fixed cadence and after any material change to model, prompt, tool set, or data source. Record this rule in your management-system process and map its evidence to the relevant AI RMF activities [1][2].
Measure inventory completeness against discovered usage, not against what teams volunteered. Shadow AI is not a people problem, it is a measurement problem: if your only input is self-registration, your inventory is a popularity contest among teams who read governance emails.
- Management system scope recorded
- Record the management-system scope before assigning its owners, controls, and evidence
- [1]
- Four functions give evidence a home
- Govern, Map, Measure, and Manage provide the structure that release decisions and incident reviews can both cite
- [2]
- Generative risks enumerated
- The GenAI Profile organizes generative-specific risks and suggested actions, which converts "assess AI risk" into reviewable work items
- [3]
- Obligations vary by classification
- Regulation (EU) 2024/1689 ties duties to risk class and addresses general-purpose AI models, so the inventory must store the classification rationale
- [4]
- Tool surface is inspectable
- MCP documents how servers expose tools, resources, and prompts, so each exposed tool can be reviewed as a named entry point
- [5]
Tier the Gates or Governance Becomes a Tax
Applying identical review depth to an internal meeting-notes assistant and a customer-facing credit explanation system can create review queues that do not reflect the stakes. Engineers do not route around governance because they dislike governance. They route around it because the queue is the same length regardless of stakes.
Write tier entry criteria as conditions. "High risk" needs a definition; "produces output visible to an external customer without a human in the loop" is a test. The following T1-T4 tiers are a proposed internal release policy. Determine EU AI Act classifications separately for each applicable use case [4].
| Tier | Trigger Conditions | Required Evidence | Human Oversight Design | Approval Path |
|---|---|---|---|---|
| T1 internal productivity | Employee-only, no customer impact, no write actions | Owner attestation plus standard logging | User reviews output before use | Self-service registration |
| T2 internal decision support | Informs employee decisions, read-only tools | Evaluation run on a versioned set [6] | Documented reviewer role | Engineering lead sign-off |
| T3 customer-facing output | External visibility, or write actions to systems of record | Scored evaluation plus guardrail config plus rollback plan | Named approver before release | Governance lead plus product owner |
| T4 regulated or at-scale personal data | Regulated decisions, or personal data at scale, or EU AI Act obligations apply [4] | Full T3 set plus classification rationale and monitoring thresholds | Documented intervention and override mechanism | Risk committee with recorded decision |
The lightweight path has to be genuinely lightweight. Self-service registration, standard guardrail configuration, logging enabled by default, owner attestation, cleared without a committee meeting. Give a team shipping an internal summarizer a clear registration and review path.
The high-impact path has to be genuinely rigorous. Documented evaluation results, a defined human-oversight mechanism, an incident and rollback plan, and a recorded approval before production. Use these artifacts to support the release decision, then map them to applicable management-system requirements and AI RMF activities [1][2].
Evidence Belongs in the Pipeline, Not the Spreadsheet
A compliance spreadsheet is a snapshot of someone's memory. Pipeline-attached artifacts are the actual state of the system at the moment of release. When an auditor asks whether the control operated, only one of those answers the question.
Attach the following to every deployment record:
- Evaluation job results and scores for the candidate configuration
- Guardrail configuration, by version, not by name
- Prompt version hash, so the exact text is recoverable
- Model identifier and version as resolved at deploy time
- Retrieval index or knowledge base version, because grounding changes when the corpus changes
- Approval record with approver identity and timestamp
Amazon Bedrock supports model and RAG evaluation jobs, including LLM-as-a-judge and human review [6]. If those jobs fit your metrics, retain their output and link it to your release record. If you are building the measurement layer from scratch, our write-up on agent release gates and evaluation harnesses covers what to score beyond demo accuracy.
Example deployment manifest: replace the identifiers with the exact versions used in your environment. Make the fields required by your release policy enforceable in the pipeline:
ai_deployment:
inventory_id: AIS-0147 # must exist and be complete
risk_tier: T3
model: model-id-and-version
prompt_version: sha256:9f2c41b8e7
knowledge_base_version: kb-contracts-2026-03-11
guardrail_version: gr-pii-redact-v7
evaluation_run: bedrock-eval/job-7731 # scored run, retained
human_oversight: "reviewer approves before customer send"
approver:
identity: e.vasquez@example.com
timestamp: 2026-03-14T16:22:09Z
rollback_plan: runbook/ais-0147-rollback.mdOne artifact set answers two questions. The evaluation run reference answers a NIST AI RMF Measure question about how performance was assessed [2][3]. The approver record and retained manifest answer an ISO/IEC 42001 question about documented information and operational control [1]. You produced the evidence once.
The Crosswalk Table That Replaces Two Documents
The central deliverable is a control library where each row is a control statement with four pieces of metadata: ISO/IEC 42001 clause reference, NIST AI RMF function and category, evidence artifact, and owner. That is the whole artifact. It replaces both document trees.
Representative rows look like this. AI system inventory maintenance, with evidence being the inventory export and its last-reviewed timestamps. Use-case risk classification with recorded rationale, with evidence being the rationale field itself. Pre-release evaluation, with evidence being the retained evaluation run [6]. Human oversight design, with evidence being the referenced design doc and the oversight field in the manifest. Post-deployment monitoring thresholds, with evidence being alert configuration. Incident and near-miss handling, with evidence being tickets plus the resulting change records.
The authoring discipline matters more than the format. Write the control once in operator language, then map it. The moment someone writes a control in framework vocabulary, a parallel document is born, because the next framework will need its own phrasing of the same requirement.
Maintenance mechanics are simple and non-negotiable. Version the control library. Record who changed what and why. Treat mapping changes as reviewable changes so internal audit can reconstruct the program state as of any date, which is what an audit of a management system actually tests [1].
When EU AI Act obligations apply, you add a third mapping column and nothing else changes [4]. That is the payoff of writing controls independent of framework vocabulary. Teams working through overlapping European regimes may also find our notes on meeting DORA, NIS2, the EU AI Act, and CRA on AWS useful for sequencing.
Incidents and Near Misses Feed the Evaluation Set
A closed incident that changes nothing in the evaluation suite means the same failure is still shippable next quarter. This is the loop most programs skip, and it is the loop that separates a governance program from a governance binder.
The mechanism is to treat the evaluation dataset as a governed asset that grows from production failures rather than a fixed benchmark picked at kickoff [3][6]. Every regression found in production becomes a permanent case, added under change control, with a reference back to the incident that produced it. The set gets harder over time, which is the correct direction.
Score process, not just outcome. Tool selection, argument correctness, retrieval grounding, and loop or retry behavior all deserve their own scores alongside final-answer quality [3][6]. A system that reaches the right answer by calling the wrong tool three times is a system with an unmeasured failure mode, and in agent architectures that failure mode is where blast radius lives.
Calibrate your judges. If you use LLM-as-a-judge scoring, sample human review of judged outputs and record disagreement rates [6]. Judge drift is silent by default: the measurement basis degrades while the dashboards stay green.
Close the loop with an output requirement. Every near-miss review produces one of four things: a new evaluation case, a guardrail change, a control amendment, or an explicitly recorded decision to accept the risk with a named accepter. That record is continual improvement evidence in ISO/IEC 42001 terms [1] and Manage function evidence in AI RMF terms [2]. For the organizational side of this, see how we structure AI agent operating models and the control surfaces in our agent governance solution.
Auditor Questions, Answered, and What to Do Next Week
Can one evidence record support both mappings? Yes, when its scope supports the relevant requirements and activities. Keep each applicable requirement and AI RMF activity beside the control and its evidence, and review the completeness of each mapping [1][2].
Do we need ISO/IEC 42001 certification to claim AI RMF alignment? No. They are independent. Certification is an assessment of your management system against the standard's requirements [1], while AI RMF is a voluntary framework you can map to without any certification body involved [2].
How do you show that a release control operated? Retained manifests can show whether the gate ran on each deployment. Runtime controls, such as monitoring and access enforcement, need their own logs and review records [2].
Where does EU AI Act classification live? In the inventory record, as a classification plus the rationale, because obligations vary by risk class and the regulation includes general-purpose AI model provisions [4]. Store the reasoning, not just the verdict.
Who signs off on high-impact releases? A named individual, recorded with identity and timestamp in the release record. Record the approval owner even when a committee participates, so reviewers can attribute and reconstruct the decision.
Your next working session
Export the current list of AI use cases from every source you have: cloud account tags, model invocation logs, expense reports for third-party AI tools, and self-registrations. Mark which ones have a named accountable owner. The unowned remainder is your first backlog.
Then track one metric starting this week: the percentage of production AI deployments whose release record contains a referenced evaluation run and a named approver. Use that percentage to locate releases whose evidence needs attention.
The framework argument your team is having was never about ISO/IEC 42001 versus NIST AI RMF. It was about who owns each control and where its evidence lives. Answer those two questions and both mappings fall out of the same library.
References
[1]ISO/IEC, "ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system," 2023. https://www.iso.org/standard/42001
[2]NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[3]NIST, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile," NIST AI 600-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
[4]Official Journal of the European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)," 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
[5]Model Context Protocol, "Specification," 2025. https://modelcontextprotocol.io/specification/2025-06-18
[6]Amazon Web Services, "Amazon Bedrock User Guide: Evaluation." https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html