NIST AI Risk Management Framework

The NIST AI Risk Management Framework, commonly called the AI RMF, provides a structured approach to managing risks that AI systems can create for individuals, groups, organizations, society, and ecosystems. It applies to traditional machine learning and generative AI across design, development, deployment, operation, and retirement. Its purpose is to support trustworthy AI through organizational practices and technical controls, rather than certify that a model or cloud service is safe.

The framework has four core functions. GOVERN establishes policies, accountability, organizational culture, and oversight, and operates across the other functions. MAP establishes the system’s purpose, deployment context, stakeholders, dependencies, and potential impacts. MEASURE uses suitable quantitative and qualitative methods to assess identified risks and evaluate trustworthiness. MANAGE prioritizes risks, selects responses, allocates resources, and tracks whether controls remain effective. These functions are iterative and connected, not a mandatory sequence completed once before deployment.

For risk classification, start with the use case rather than the model’s brand, size, or hosting location. Record who could be harmed, how severe the harm could be, the likelihood and uncertainty of that harm, the scale of exposure, and whether affected people can challenge or reverse a decision. Consider sensitive data, vulnerable populations, autonomy, and legal obligations. An organization might define internal low-, moderate-, and high-risk categories, but these are its own governance choices: the AI RMF does not impose universal numbered tiers or the legal risk categories used by the EU AI Act.

Classification should determine the depth of governance. A system that drafts internal meeting summaries may need access controls, confidentiality checks, and user verification. A system that recommends whether applicants receive loans warrants stronger oversight because errors or discrimination can materially affect people. Appropriate requirements could include independent validation, subgroup performance testing, documented explanations, human review, appeal procedures, and formal acceptance of residual risk. Legal and compliance teams must separately determine which jurisdictional and sector-specific requirements apply; a low internal risk rating cannot waive a legal obligation.

In a cloud implementation, maintain an AI system inventory and connect each system to its business owner, technical owner, intended use, data sources, model version, risk assessment, and approval record. Use deployment pipelines to require evidence appropriate to the assigned risk level before production release. Evidence might include data provenance, evaluation results, security testing, documented limitations, rollback procedures, and approval by an accountable decision-maker. Managed cloud services can supply evaluation, access control, logging, and monitoring capabilities, but the customer remains responsible for its use-case assessment and governance decisions.

Measurement should address the framework’s trustworthiness characteristics: validity and reliability; safety; security and resilience; accountability and transparency; explainability and interpretability; privacy enhancement; and fairness with harmful bias managed. For a retrieval-augmented assistant, assess unsupported answers, unauthorized information disclosure, prompt injection, and performance for relevant user groups. Define acceptable thresholds, test representative and adversarial cases, and document uncertainty. A single accuracy score cannot establish that these different risks are adequately controlled.

Operational risk management continues after release. Monitor relevant performance and safety signals, investigate incidents, and reassess when data, models, prompts, retrieval sources, user populations, or permitted actions change. A summarization assistant that gains permission to send emails or execute transactions needs a new assessment because its potential consequences have changed. Define escalation paths, incident response procedures, and criteria for restricting or retiring a system.

Controls introduce trade-offs. Human review adds cost and latency, detailed logs can expose sensitive information, and fairness measures may require difficult choices between competing objectives. Document these decisions, limit evidence collection to what is necessary, and assign ownership for residual risk. Framework alignment is neither a compliance certificate nor proof that all risks have been eliminated; it is a repeatable way to make, justify, and revisit risk-informed decisions.