Frameworks · Standards and guidance

qodiqa and the NIST AI RMF

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports the NIST AI RMF, and where it does not.

Guidance
NIST
AI RMF 1.0, January 2023. Voluntary.
Verified 2026-11-01

Read the official text Back to all frameworks

Overview

What it is

Issuer: NIST
Type: Guidance
Status: AI RMF 1.0, published January 2023; voluntary
Official text: nvlpubs.nist.gov

NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0). The AI RMF is a voluntary framework from the US National Institute of Standards and Technology for managing risks of AI systems. Its Core has four functions, Govern, Map, Measure and Manage, each divided into categories and numbered subcategories such as MEASURE 2.4.

Who it applies to. Any organisation that designs, develops, deploys or uses AI systems. It is voluntary and not specific to a sector or country, and it is not something a body certifies.

Where it meets qodiqa

The parts of the NIST AI RMF where the evidence matters.

Risk management

Policy changes follow a governed path and every decision records its reason, which supports a documented risk process.

Human oversight

Revocation, kill switch and bound approvals are mechanisms that can be assessed and documented.

Accountability

Signed receipts and an offline verifier let a third party check what was recorded.

Record-keeping and logging

A hash-chained audit trail supports monitoring and after-the-fact analysis.

Robustness and security

Fail-closed enforcement and separate key domains are concrete security properties you can evaluate.

Traceability

A request hash ties each decision to one exact request, which supports tracking risks in deployment (MEASURE 3.1).

Mapping

What qodiqa provides, and what stays with you.

Requirement or control	What qodiqa provides	What stays with you
`GOVERN 1.4` The risk management process and its outcomes are established through transparent policies, procedures and other controls.	Tenant policies are written down, changed through draft, review, approve and publish, and each enforced decision records the policy outcome and reason.	Your risk priorities, the policies themselves, and who is accountable for them.
`GOVERN 2.1` Roles, responsibilities and lines of communication for mapping, measuring and managing AI risks are documented.	Role-based operator access separates who may change policy, approve changes and read evidence, and each change is recorded.	Defining and staffing your organisation’s roles.
`MAP 3.5` Processes for human oversight are defined, assessed and documented.	Consent revocation, a global kill switch and human approvals bound to an exact tool action give oversight processes something to act on, and they are recorded.	Defining who oversees what, and assessing whether that oversight works.
`MEASURE 2.4` The functionality and behaviour of the AI system and its components are monitored when in production.	Allowed and blocked counts by reason, latency and alert rules for the gateway, with an export schema for security tooling.	Monitoring the model’s own quality, drift and outputs.
`MEASURE 2.7` AI system security and resilience are evaluated and documented.	A threat model, key-management and audit-anchoring documents, and a test-vector set that independent code can run.	Your own security evaluation of the whole system, and penetration testing.
`MEASURE 2.8` Risks associated with transparency and accountability are examined and documented.	Signed receipts and a Merkle transparency log let a third party check that a decision was recorded, offline.	Whether the recorded decision was the right one: a receipt proves it was recorded, not that it was correct.
`MEASURE 3.1` Approaches are in place to regularly identify and track existing, unanticipated and emergent AI risks in deployed contexts.	A durable record of every enforced request and its reason supports trend analysis of blocks and anomalies.	Choosing which risks to track, and tracking risks the gateway cannot see.
`MANAGE 2.4` Mechanisms are in place to supersede, disengage or deactivate AI systems that perform inconsistently with intended use.	A global kill switch with an audited operator, reason and time, and per-consent revocation.	The decision to disengage a system, and what replaces it.
`MANAGE 4.1` Post-deployment monitoring plans are implemented, including appeal and override, incident response and change management.	Incident-response and runbook documents, alert runbooks and an audit trail for reconstructing events.	The plan itself, user feedback channels and appeals to people.

Cross-check: the Regulatory Alignment Matrix, section 5

How it fits

What the NIST AI RMF asks, and what qodiqa produces.

GOVERN 1.4 (Transparent policies) is supported by Governed policy changes (Draft, review, publish).
MEASURE 2.4 (Monitor in production) is supported by Metrics and alerts (Reasons and counts).
MANAGE 2.4 (Disengage a system) is supported by Kill switch and revocation (Audited operator and reason).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

Consent artifact Signed with Ed25519, bound to one request, single use.
INTENT entry The audit entry written before the provider call.
Receipt A signed decision record that checks offline.
Audit export Hash-chained entries with a Merkle inclusion proof.
Anchor proof A signed checkpoint pinned outside the gateway.

Verify offline, from a clone of qodiqa-verify

node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of the NIST AI RMF. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets the NIST AI RMF is a decision for you and your advisers.

What qodiqa does not address:

Your risk priorities, tolerances and organisational governance.
Mapping the context, impacts and intended use of the AI system.
Model-level measurement: quality, bias, drift and explainability.
Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023 accessed 2026-11-01
qodiqa specification: Regulatory Alignment Matrix (QODIQA-RAM-2026-001) accessed 2026-11-01
qodiqa-gateway: enforcement flow accessed 2026-11-01
qodiqa-gateway: limitations accessed 2026-11-01

Next steps

See the evidence for yourself.

Read the spec section Run a simulation Quickstart