NIST AI RMF: the measure and manage instrumentation
This is the one framework here that nobody is legally obliged to follow, and the one organisations borrow from most often when several overlapping obligations have to be satisfied at once. It asks whether you govern, map, measure and manage AI risk. It does not tell you what to record.
- The instrument
- NIST AI RMF 1.0, with the Generative AI Profile (NIST AI 600-1)
- Status
- Voluntary; widely used as the governance spine for overlapping rules
- Who it applies to
- Organisations that want one governance structure across several AI obligations, including public-sector and regulated buyers.
Where AI-FW fits
AI-FW is the measure and manage instrumentation for the runtime AI path, and it supplies the data that govern and map consume. It is deliberately not a risk register: it produces measurements, enforcement evidence and the trend lines that show whether risk is being managed or merely discussed.
What stays with you
Read this list first. It is the boundary of what a product can do for you, and it is where the remaining work sits.
- The risk register and treatment plan, including residual-risk decisions
- Trustworthiness evaluation beyond runtime controls: red-teaming, evaluation datasets, fairness testing and human-factors work
- Governance artefacts: AI policy, roles, training and escalation paths
- Choosing risk tolerance and thresholds, which the product records rather than decides
- Stakeholder reporting and communication
What the framework asks, and what the product does
The obligations that touch the AI path, paired with the capability that answers each one. Everything else in this framework is organisational work, listed above.
Policies, roles and accountability for AI risk
Role-based access, every enforcement change audited to an actor, and attestations that name the accountable person
Competence, training and documented decisions
In-product documentation of controls and owners, plus an assessment history that acts as a record of governance decisions
Define and communicate risk tolerance
Approval, risk and quota thresholds are configuration, so what you decided tolerance to be is inspectable
Manage supply-chain and third-party risk
A model inventory enumerating every provider and endpoint, as the starting point for supplier assessment
Frame purpose, context and regulatory exposure
Per-model purpose configuration, with each model linked to the obligations it serves
Understand capabilities, tasks and deployment channels
Inventory of models, agents, and the applications and channels they serve, with attribution for each
Identify and prioritise risks and impacts
Risk profiles with scoring, violation categories and trend views, so prioritisation starts from observed behaviour
Use metrics that are meaningful for the risk
Latency, token, block, mask and category metrics per model, agent and user, available over time rather than as a point reading
Measure validity, reliability, safety, security and resilience
Guard effectiveness is testable at each assessment, and upstream failure telemetry shows how the path behaves under stress
Measure privacy exposure, explainability and harmful bias
Category detection across personal, payment, health and semantic classes surfaces what is exposed and flags semantic drift over time
Prioritise, treat and track risk over time
Assessment history with score trends, a gap list with severity and owner, and mitigation rules as documented treatment
Respond, recover and communicate
Incident signals, drift findings, audit continuity, and evidence packs suitable for communication to stakeholders
A rule pack to start from
The enforcement that makes the controls real. Severity runs 1 to 5, and a rule that is switched off reports as a gap, so these are meant to be live from day one.
The clearest safety signal in the profile
Privacy measurement and reduction at the boundary
Supply-chain governance, enforced
Security and resilience measurement
Information integrity, including confabulation signals
What the evidence pack contains
Per period, and without prompt or response content, which is what makes it safe to hand over.
- Control statuses by functionMapped to govern, map, measure and manage
- Metric availabilityBecause an empty panel reports as unknown rather than compliant
- Risk scoring configurationThe thresholds that encode your risk tolerance
- Mitigation rule stateTreatment that is actually running
- Drift historyManage signals across the period, not a single check
Customer responsibilities and sources
- Maintain the risk register and treatment plan, with owners and residual-risk decisions.
- Run evaluation and testing beyond the runtime path: red-teaming, evaluation datasets, fairness testing and human-factors work.
- Produce the governance artefacts: AI policy, roles, training and escalation paths.
- Decide risk tolerance and thresholds, which the product records rather than chooses.
- Report to stakeholders, boards and governing bodies.
Common questions
No, it is voluntary. It is also the framework most often used as the spine for others, because govern, map, measure and manage maps cleanly onto obligations that are mandatory elsewhere. If you are answering an EU AI Act or sector question, this is usually the scaffolding the answer gets built inside.
The runtime-visible ones: data privacy, information security, information integrity including confabulation, harmful bias and homogenisation, human-AI configuration, value-chain integration, intellectual-property exposure through egress, and dangerous content. The same controls cover most of them, because they all reduce to what enters the prompt, what leaves the model, and who is allowed to do it.
Most of it, honestly. The register, the tolerance decisions, the testing programme, the policy and the reporting are organisational work. The product contribution is measurement and enforcement evidence, which is the part that tends to be missing when an organisation has a framework but cannot show it operating.
Validate it yourself with our Technical Plan
Ask us to run this framework against your own environment: the rules that would be created, what the assessment reports, and what the evidence pack contains for a real period.
This page maps product capabilities to published expectations. It is not legal, audit or certification advice, and it creates no compliance representation. Applicability and sufficiency are judgements for your counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed; check the primary sources above, and the page itself, before relying on a date or a threshold.