Key findings

• Assess a specific system in a specific context, not AI in the abstract.

• Record benefits, affected people, foreseeable misuse, dependencies, and failure paths.

• Measure multiple trustworthiness characteristics and important data or user slices.

• Prioritize by impact, likelihood, detectability, and reversibility.

• Keep residual-risk acceptance and ongoing monitoring owned by named people.

Scope a real decision, not a framework exercise

Start with one proposed or operating workflow. Record its intended purpose, users, affected people, inputs, outputs, decisions, actions, connected systems, model and vendor dependencies, and operating environment. Define where the workflow begins and ends. A support drafting tool and an autonomous refund agent may share a model but have different impacts, permissions, and controls, so they require separate context.

State the release decision the assessment will support: experiment, limited pilot, production, scope expansion, or renewal. Identify legal and contractual requirements separately; NIST AI RMF is voluntary guidance, not a declaration of compliance. As of July 2026, NIST states that AI RMF 1.0 is being revised, so record the version used and check future updates rather than treating the assessment as permanent.

Govern: establish accountability and risk tolerance

Name an executive risk owner, business system owner, technical owner, and reviewers for privacy, security, legal, HR, or sector issues as applicable. Document policies, approval authority, escalation, incident response, staff competence, vendor responsibilities, and how affected-user feedback reaches the owner. Confirm that people have time and authority to perform their roles.

Set explicit risk tolerance. Examples include no autonomous account closure, no disclosure of restricted data, no production write without a traceable identity, and a maximum rate for defined material errors. Decide which conditions require pause or rollback. Governance is cross-cutting in the AI RMF: it should shape mapping, measurement, and management throughout the lifecycle rather than appear as a signature at the end.

Map: understand context, people, data, and dependencies

Map intended benefits and negative impacts to customers, employees, non-users, the business, and wider stakeholders. Include foreseeable misuse, over-reliance, denied access, unequal performance, privacy loss, manipulation, financial harm, safety effects, and reputational damage. Identify alternatives, including no automation and lower-agency designs. A technically accurate system can still be inappropriate in its social or business context.

Trace data provenance, quality, representativeness, permissions, retention, and transformations. List foundation models, retrieval sources, tools, APIs, libraries, hosting, human reviewers, and vendors as dependencies. Record assumptions and boundaries: language, geography, customer type, document format, volume, and excluded cases. Map how errors propagate and whether they are detectable and reversible before harm occurs.

• Minimum evidence: workflow diagram, data flow, stakeholder list, dependency inventory, impact scenarios, and assumptions.

• Key question: who can be affected even if they never directly use the system?

Measure: turn trustworthiness into tests

Choose measurements that match the mapped context. NIST identifies characteristics including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed. Not every characteristic has one numerical metric. Combine quantitative tests, qualitative review, control evidence, and scenario exercises.

Build a representative evaluation set with normal, difficult, rare, and adversarial cases. Test important slices such as language, customer segment, document source, or request type where relevant and lawful. Measure serious-error frequency separately from average quality. Test tool authorization, prompt injection, data leakage, outage handling, retries, cost limits, human review, and rollback. Document uncertainty, sample limitations, and who judged subjective outcomes.

Manage: prioritize and treat risk

Create a risk register with scenario, cause, affected party, existing controls, impact, likelihood, detectability, reversibility, owner, treatment, deadline, evidence, and residual risk. Use descriptive scales with examples so reviewers apply them consistently. A rare but catastrophic and hard-to-detect event may deserve more attention than a common cosmetic error.

Choose treatment explicitly: avoid the use, reduce scope or agency, add controls, transfer part through contract or insurance, accept residual risk, or stop. Control order matters. Removing a write tool is stronger than asking a model not to use it; deterministic validation is stronger than relying on a prompt; prevention is usually stronger than post-event detection. Record who accepts remaining risk and why.

Run a lean assessment workshop

Prepare the workflow and data diagrams, evaluation results, vendor evidence, incident history, and open decisions. In a 90-minute workshop, confirm scope and owners, walk the normal path and failure paths, challenge assumptions, score risks, assign treatment, and decide what evidence is still missing. Frontline users should participate because they know exceptions and workarounds that leadership and developers may not see.

The output can be concise: a one-page system profile, a risk register, an evidence index, and a decision record. Depth should scale with consequence and uncertainty. A low-risk internal summarizer may need a brief assessment. A system influencing employment, finance, health, safety, or access to services needs specialized review and more robust evidence.

Make the assessment continuous

Set review triggers for model or vendor changes, new data, new tools, permission expansion, new user groups, increased volume, incidents, material performance drift, and legal changes. Production telemetry and sampled human review should feed the risk register. Track whether controls work in practice, not only whether they exist in documentation.

Use a current-state and target-state profile to prioritize improvement. An SMB does not need to implement every Playbook suggestion. NIST describes the Playbook as voluntary and tailorable, not an ordered checklist. Select actions that address the system's important risks, keep evidence proportionate, and revisit the assessment as context and capability evolve.

Maintain an evidence index and decision record

Link every material control claim to inspectable evidence instead of treating the assessment narrative as proof. The index can reference evaluation datasets, test results, red-team scenarios, access reviews, data-flow diagrams, model and prompt versions, vendor documentation, reviewer training, incident exercises, monitoring dashboards, and rollback tests. Record the evidence owner, collection date, covered system version, limitations, and next review date. This makes gaps visible and prevents an old screenshot or expired vendor statement from supporting a current production decision.

Close each assessment with a signed decision record stating the approved scope, prohibited uses, residual risks, required controls, monitoring thresholds, review cadence, and conditions that trigger pause or reassessment. Separate evidence from judgment: test results describe observed performance, while an accountable owner decides whether remaining risk is acceptable for this context. When the model, data, tools, permissions, or affected population changes, compare the new state with the approved baseline and reopen only the affected risk decisions rather than repeating the exercise blindly.

Sources and methodology

This article synthesizes the primary sources below as of the publication date. Forecasts and recommendations are directional scenarios, not guarantees; they should be tested against your workflow, data, risk tolerance, and current vendor documentation.

National Institute of Standards and Technology: AI Risk Management Framework 1.0 (accessed 2026-07-30)

National Institute of Standards and Technology: NIST AI RMF Playbook (accessed 2026-07-30)

National Institute of Standards and Technology: Generative Artificial Intelligence Profile (accessed 2026-07-30)

National Institute of Standards and Technology: AI test, evaluation, validation and verification (accessed 2026-07-30)

National Institute of Standards and Technology: AI Risk Management Framework Roadmap (accessed 2026-07-30)