Every control in the NIST AI Risk Management Framework, broken down: what it requires, why it matters, how to meet it, and the evidence your auditor will ask for.
NIST AI 100-1 (AI RMF 1.0) is a voluntary framework, but it has become the reference point U.S. customers, auditors and regulators use to judge whether an AI program is credible. Its Core is organized into four functions. GOVERN runs through all of them, and MAP, MEASURE and MANAGE repeat across each AI system's lifecycle.
Cultivate a culture of AI risk management
6 categories · 19 subcategories → MPContext is recognized and risks related to context are identified
5 categories · 18 subcategories → MSIdentified risks are assessed, analyzed, or tracked
4 categories · 22 subcategories → MGRisks are prioritized and acted upon based on projected impact
4 categories · 13 subcategories →NIST calls them subcategories, and they describe outcomes, not prescriptive controls. You choose how to achieve each one. That flexibility is useful, but it also means an assessor will ask for evidence that the outcome is actually met.
Pair this guide with NIST AI 600-1, the Generative AI Profile. It maps 12 GenAI-specific risks, including confabulation, information security, data privacy and harmful content, onto these same subcategories with suggested actions.
Not every system needs every outcome at full depth. Tier your AI systems (GOVERN 1.3) and apply the heaviest treatment to high-impact ones. A marketing copy tool and a clinical triage model should not get the same review.
Cultivate a culture of AI risk management
GOVERN is cross-cutting: it sets the policies, accountability, culture and supply-chain rules that make the other three functions possible. Without it, MAP, MEASURE and MANAGE become one-off exercises nobody owns.
Policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks are in place, transparent, and implemented effectively.
NIST outcomeLegal and regulatory requirements involving AI are understood, managed, and documented.
AI is now regulated from several directions at once: the EU AI Act, U.S. state laws (Colorado, NYC Local Law 144, California), sector rules such as HIPAA and FDA guidance for software as a medical device, and privacy laws that already cover automated decision-making. You cannot manage a risk you have not identified, and "we didn't know" is not a defense regulators accept.
NIST outcomeThe characteristics of trustworthy AI are integrated into organizational policies, processes, procedures, and practices.
NIST defines trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. If these only appear in a values statement, engineering teams will optimize for speed and accuracy alone. Writing them into policy makes them requirements.
NIST outcomeProcesses, procedures, and practices are in place to determine the needed level of risk management activities based on the organization's risk tolerance.
A marketing copy assistant and a model that triages patients do not deserve the same scrutiny. Without a tiering method, teams either drown low-risk tools in paperwork or let high-risk systems through with too little review. Both outcomes undermine the program.
NIST outcomeThe risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities.
If risk decisions happen in hallway conversations, nobody can audit them, repeat them or learn from them. A documented process means that when a customer, auditor or regulator asks why a system was approved, the answer is a record and not someone's recollection.
NIST outcomeOngoing monitoring and periodic review of the risk management process and its outcomes are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review.
Models drift, regulations change, vendors swap model versions without notice and new attack techniques appear every month. A risk assessment from last year describes a system that may no longer exist. Scheduled review is how the program stays accurate.
NIST outcomeMechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.
The inventory is the foundation of the whole program. Most organizations underestimate their AI footprint by a wide margin once they count SaaS features with embedded AI, browser extensions, copilots and shadow use of public chatbots. Every other control depends on knowing what exists.
NIST outcomeProcesses and procedures are in place for decommissioning and phasing out AI systems safely and in a manner that does not increase risks or decrease the organization's trustworthiness.
Retired models leave behind training data, embeddings, fine-tuned weights, API keys and downstream integrations that still expect output. Switching one off carelessly can break dependent processes, orphan sensitive data or leave an exposed endpoint running for years.
Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks.
NIST outcomeRoles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization.
AI risk falls between security, privacy, legal, data science and product, and each group tends to assume another one owns it. Clear roles stop gaps and duplicated work, and they tell people who to escalate to when a model misbehaves.
NIST outcomeThe organization's personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements.
Most AI incidents begin with a well-meaning person: a developer pasting secrets into a chatbot, an analyst trusting a hallucinated citation, a manager relying on a biased screening tool. Policies only work when the people who must follow them understand them.
NIST outcomeExecutive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment.
AI risk is business risk, covering liability, reputation and regulatory exposure. If decisions sit only with engineers, high-impact tradeoffs get made without the authority or context they need. Regulators and boards increasingly expect a named executive to be accountable.
Workforce diversity, equity, inclusion, and accessibility processes are prioritized in the mapping, measuring, and managing of AI risks throughout the lifecycle.
NIST outcomeDecision-making related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversity of demographics, disciplines, experience, expertise, and backgrounds).
Blind spots are the main source of AI harm. A team made up only of ML engineers will miss clinical, legal, accessibility or cultural failure modes that a nurse, lawyer, accessibility specialist or member of the affected community would see right away. Range of perspective is a risk-detection control.
NIST outcomePolicies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.
"Human in the loop" means nothing unless you define who the human is, what they review, what authority they have and how much time they get. Without that, oversight turns into rubber-stamping. This is also a direct requirement for high-risk systems under the EU AI Act (Article 14).
Organizational teams are committed to a culture that considers and communicates AI risk.
NIST outcomeOrganizational policies and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimize potential negative impacts.
Pressure to ship AI features is intense. If raising a concern feels career-limiting, problems surface only after they hurt someone. A culture where challenging an AI design is expected catches issues while they are still cheap to fix.
NIST outcomeOrganizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate, and use, and they communicate about the impacts more broadly.
Knowledge that stays in one team's heads leaves when they do. Documented impacts let downstream teams, customers and auditors understand what a system can and cannot do, and they are the raw material for model cards, transparency notices and regulatory filings.
NIST outcomeOrganizational practices are in place to enable AI testing, identification of incidents, and information sharing.
AI fails in new ways: jailbreaks, prompt injection, data poisoning, harmful outputs and silent accuracy decay. Teams need permission, tools and channels to test for these and to report what they find, both inside the company and with the wider community.
Processes are in place for robust engagement with relevant AI actors.
NIST outcomeOrganizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks.
The people affected by an AI system, such as patients, applicants, customers or citizens, often notice harms the builders never anticipated. Without a channel for their feedback, you learn about problems from journalists, lawsuits or regulators.
NIST outcomeMechanisms are established to enable the team that developed or deployed AI systems to regularly incorporate adjudicated feedback from relevant AI actors into system design and implementation.
Collecting feedback that never changes anything is worse than not collecting it, because it erodes trust. This outcome closes the loop: valid feedback becomes backlog items, retraining data or design changes.
Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues.
NIST outcomePolicies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third-party's intellectual property or other rights.
Most organizations consume AI rather than build it: foundation model APIs, SaaS features, open-weight models and licensed datasets. Each one brings risks you inherit, including data use for training, unclear licensing, copyright exposure, model changes and vendor security posture.
NIST outcomeContingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk.
Model providers have outages, deprecate versions, change safety filters and suffer breaches. If a critical workflow depends on one external model with no fallback, the vendor's bad day becomes yours.
Context is recognized and risks related to context are identified
MAP establishes the context for each AI system: what it is for, who it affects, what it depends on and what could go wrong. Its output feeds MEASURE and MANAGE. Skip it, and you end up measuring the wrong things very precisely.
Context is established and understood.
NIST outcomeIntended purposes, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented. Considerations include: the specific set or types of users along with their expectations; potential positive and negative impacts of system uses to individuals, communities, organizations, society, and the planet; assumptions and related limitations about AI system purposes, uses, and risks across the development or product AI lifecycle; and related TEVV and system metrics.
Most AI risk depends on context. The same model can be harmless in one setting and dangerous in another. A precise statement of intended use is what lets you spot misuse, scope testing and defend design decisions.
NIST outcomeInterdisciplinary AI actors, competencies, skills, and capacities for establishing context reflect demographic diversity and broad domain and user experience expertise, and their participation is documented. Opportunities for interdisciplinary collaboration are prioritized.
Context-setting done only by builders reflects only the builders' view. Domain experts and representative users surface the real-world conditions, edge cases and harms that determine whether a system is safe to deploy.
NIST outcomeThe organization's mission and relevant goals for AI technology are understood and documented.
AI projects that are not tied to a mission tend to drift toward whatever is technically interesting. Anchoring each system to organizational goals makes it possible to judge whether its risks are worth taking.
NIST outcomeThe business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated.
Every AI risk decision is a cost-benefit tradeoff. If you cannot say what value the system delivers, you cannot decide whether a risk is acceptable. Systems that were already deployed often outlive the business case that justified them.
NIST outcomeOrganizational risk tolerances are determined and documented.
Without explicit tolerances, "acceptable" is decided case by case and inconsistently. Documented tolerances, such as a maximum error rate, maximum disparity between groups or acceptable downtime, turn subjective debates into measurable criteria.
NIST outcomeSystem requirements (e.g., "the system shall respect the privacy of its users") are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks.
Trustworthiness has to be designed in. Requirements such as privacy, explainability and human override are far cheaper to build at the start than to retrofit once a model is in production.
Categorization of the AI system is performed.
NIST outcomeThe specific tasks and methods used to implement the tasks that the AI system will support are defined (e.g., classifiers, generative models, recommenders).
Different AI techniques fail differently. Classifiers produce false positives, generative models hallucinate and can be prompt-injected, recommenders create feedback loops, and agents take unintended actions. Knowing the method tells you which risks and tests apply.
NIST outcomeInformation about the AI system's knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making decisions and taking subsequent actions.
Users over-trust AI output, especially fluent generative output. Documenting what the system does not know, such as its training cutoff, out-of-distribution inputs and unsupported languages, helps people decide when to rely on it and when to check.
NIST outcomeScientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation.
Weak data and weak experimental design produce models that look good on paper and fail in production. Construct validity, meaning whether you are measuring what you think you are measuring, is where many AI systems quietly go wrong.
AI capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks are understood.
NIST outcomePotential benefits of intended AI system functionality and performance are examined and documented.
Risk management is not risk avoidance. Documenting benefits concretely, and against a baseline, lets you weigh them honestly against costs instead of letting hype or fear decide.
NIST outcomePotential costs, including non-monetary costs, which result from expected or realized AI errors or system functionality and trustworthiness – as connected to organizational risk tolerance – are examined and documented.
Every model makes mistakes. What matters is what a mistake costs and who pays for it. A wrongly denied claim, a missed diagnosis or a defamatory output costs far more than the compute bill, and many of those costs are not financial.
NIST outcomeTargeted application scope is specified and documented based on the system's capability, established context, and AI system categorization.
Scope creep is one of the most common sources of AI harm: a tool validated for one population or task gets quietly used for another. A written scope sets the boundary for validation and for acceptable use.
NIST outcomeProcesses for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and certifications – are defined, assessed, and documented.
Human oversight only works if the human is competent. An operator who does not understand a system's failure modes cannot catch them and will defer to the machine.
NIST outcomeProcesses for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function.
This puts the oversight policy from GOVERN 3.2 into practice for a specific system. It ensures each deployed system has a defined way for humans to monitor, intervene and override it, and that this mechanism has been tested.
Risks and benefits are mapped for all components of the AI system including third-party software and data.
NIST outcomeApproaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third party's intellectual property or other rights.
An AI system is a supply chain: base model, fine-tuning data, embeddings, vector database, plugins, orchestration libraries and APIs. A poisoned dataset, a malicious model file or an unlicensed corpus anywhere in that chain becomes your problem.
NIST outcomeInternal risk controls for components of the AI system, including third-party AI technologies, are identified and documented.
Once component risks are known, each needs a matching control. Documenting the controls shows coverage and exposes components that are trusted by default.
Impacts to individuals, groups, communities, organizations, and society are characterized.
NIST outcomeLikelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented.
This is where impacts become ratable risks. Using evidence such as public incident databases and similar deployments, rather than intuition, makes the ratings defensible and comparable across systems.
NIST outcomePractices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented.
Impacts change after deployment and some only appear at scale. Ongoing engagement with users and affected groups, backed by named people and a budget, is how unanticipated impacts get detected.
Identified risks are assessed, analyzed, or tracked
MEASURE uses quantitative and qualitative methods (testing, evaluation, verification and validation, or TEVV) to analyze the risks MAP identified. It produces the evidence that trustworthiness claims are true, and keeps checking them in production.
Appropriate methods and metrics are identified and applied.
NIST outcomeApproaches and metrics for measurement of AI risks enumerated during the MAP function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not – or cannot – be measured are properly documented.
You cannot measure everything, so measure what matters most first. Documenting what you are not measuring is just as important: an unmeasured risk that is acknowledged is manageable, while one that is ignored is a hidden liability.
NIST outcomeAppropriateness of AI metrics and effectiveness of existing controls are regularly assessed and updated, including reports of errors and potential impacts on affected communities.
Metrics go stale. A benchmark the model now saturates, or an aggregate accuracy figure that hides subgroup failures, gives false comfort. Controls lose effectiveness too as attackers adapt.
NIST outcomeInternal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance.
Builders are the worst-placed people to find their own blind spots. Independence is a basic assurance principle in financial audit and security testing, and it applies to AI evaluation as well.
AI systems are evaluated for trustworthy characteristics.
NIST outcomeTest sets, metrics, and details about the tools used during TEVV are documented.
An evaluation result is only as credible as its method. If you cannot say which data, metrics and tools produced a number, nobody can reproduce, compare or trust it.
NIST outcomeEvaluations involving human subjects meet applicable requirements (including human subject protection) and are representative of the relevant population.
User studies, A/B tests and annotation work involve real people. They need consent and privacy protection, and the evaluation population must match the deployment population or the results will not hold up.
NIST outcomeAI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented.
Lab performance rarely survives contact with production. Real inputs are messier and more varied and include adversarial users. Testing must reflect deployment reality to mean anything.
NIST outcomeThe functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.
Data drift, concept drift, upstream model updates and changing user behavior all degrade AI systems silently. Without monitoring, you find out from customers.
NIST outcomeThe AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented.
Validity asks whether the system does what it claims. Reliability asks whether it does so consistently. Both must be shown with evidence before deployment, and the limits of that evidence must be stated plainly.
NIST outcomeThe AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and it can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics reflect system reliability and robustness, real-time monitoring, and response times for AI system failures.
Failure is certain at some point. What matters is how the system fails. A system that confidently answers outside its competence is dangerous, while one that abstains or escalates is safe. This matters most in healthcare, physical systems and agentic AI that takes actions.
NIST outcomeAI system security and resilience – as identified in the MAP function – are evaluated and documented.
AI adds attack surface that traditional security testing misses: prompt injection (direct and indirect), data poisoning, model extraction, membership inference, insecure tool use by agents and sensitive data disclosure. Attackers are actively exploiting these.
NIST outcomeRisks associated with transparency and accountability – as identified in the MAP function – are examined and documented.
If people cannot tell they are dealing with AI, or cannot find out who is responsible for an outcome, they cannot contest it, and you cannot defend it. Transparency obligations are also among the most common AI regulatory requirements, including chatbot disclosure and deepfake labeling.
NIST outcomeThe AI model is explained, validated, and documented, and AI system output is interpreted within its context – as identified in the MAP function – to inform responsible use and governance.
Explainability lets operators catch errors, lets affected people understand decisions and lets developers debug. It is increasingly required by law for consequential decisions, for example adverse-action notices in credit and the EU AI Act's transparency provisions.
NIST outcomePrivacy risk of the AI system – as identified in the MAP function – is examined and documented.
AI systems memorize training data, infer sensitive attributes, combine data in new ways and can leak personal information through outputs. Privacy law (GDPR, HIPAA, CCPA) applies fully to AI, and the fines are real.
NIST outcomeFairness and bias – as identified in the MAP function – are evaluated and results are documented.
AI can encode and amplify historical discrimination at scale. Biased outcomes in hiring, lending, housing, healthcare and insurance create legal liability under anti-discrimination law and laws such as NYC Local Law 144 and the Colorado AI Act, as well as serious reputational harm.
NIST outcomeEnvironmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed and documented.
Training and serving large models consumes significant energy and water. Stakeholders, ESG reporting frameworks and some regulations, including documentation duties for general-purpose AI under the EU AI Act, increasingly expect this footprint to be measured.
NIST outcomeEffectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented.
This is the meta-control: is your testing actually catching problems? If production incidents keep happening that evaluation should have caught, the evaluation program needs fixing.
Mechanisms for tracking identified AI risks over time are in place.
NIST outcomeApproaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts.
The risk picture at launch is incomplete. New risks appear through use: novel jailbreaks, unexpected user behavior, emergent capabilities after a model upgrade. Someone has to be watching for them.
NIST outcomeRisk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available.
Some of the most important AI risks, such as long-term societal effects, subtle manipulation or harm from agent autonomy, have no mature metrics. Lack of a metric does not mean lack of a risk.
NIST outcomeFeedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics.
People affected by AI decisions need recourse, and their reports are a valuable source of detection. Appeal mechanisms are also a legal requirement in many contexts, including GDPR Article 22 and several U.S. state AI laws.
Feedback about efficacy of measurement is gathered and assessed.
NIST outcomeMeasurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented.
Generic benchmarks say little about whether a system is safe for your patients, customers or use case. Domain experts know what "good" looks like in context and which errors matter most.
NIST outcomeMeasurement results regarding AI system trustworthiness in deployment context(s) and across the AI lifecycle are informed by input from domain experts and relevant AI actors to validate whether the system is performing consistently as intended. Results are documented.
Numbers need interpretation. A 95% accuracy figure may be excellent or unacceptable depending on context, and only domain experts can tell which. Their review confirms the system works as intended in practice.
NIST outcomeMeasurable performance improvements or declines based on consultations with relevant AI actors, including affected communities, and field data about context-relevant risks and trustworthiness characteristics are identified and documented.
Trend data shows whether your risk treatments are working and whether the system is getting better or worse. It is also what you show auditors and boards to demonstrate that the program is effective.
Risks are prioritized and acted upon based on projected impact
MANAGE turns the findings from MAP and MEASURE into decisions and action: whether to deploy, which risks to treat, how to respond when things go wrong and how to keep improving. This is where governance produces outcomes.
AI risks based on assessments and other analytical output from the MAP and MEASURE functions are prioritized, responded to, and managed.
NIST outcomeA determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.
Every AI program needs a real decision point where "no" is a possible answer. Without one, sunk-cost momentum carries flawed systems into production.
NIST outcomeTreatment of documented AI risks is prioritized based on impact, likelihood, and available resources or methods.
Resources are finite. Prioritizing by impact and likelihood keeps effort on the risks that could do the most damage instead of the ones that are easiest to fix.
NIST outcomeResponses to the AI risks deemed high priority, as identified by the MAP function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting.
Every significant risk needs a deliberate response, even if that response is to accept it. Documented treatment plans make sure high risks are not just recorded and forgotten.
NIST outcomeNegative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented.
Whatever risk remains after treatment passes to customers and users. They deserve to know about it, and documenting it protects you when known limitations later cause problems. The EU AI Act requires providers of high-risk systems to communicate residual risks to deployers.
Strategies to maximize AI benefits and minimize negative impacts are planned, prepared, implemented, documented, and informed by input from relevant AI actors.
NIST outcomeResources required to manage AI risks are taken into account – along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts.
Sometimes the best risk control is not using AI at all. If the cost of managing a system's risks exceeds its value, or a rules-based approach works just as well, that option has to be on the table.
NIST outcomeMechanisms are in place and applied to sustain the value of deployed AI systems.
AI systems degrade without maintenance. Value at launch is not value forever. Retraining, prompt tuning, data refreshes and dependency updates are what keep the system worth its risk.
NIST outcomeProcedures are followed to respond to and recover from a previously unknown risk when it is identified.
Some risks will only show up in production. A new jailbreak technique or an unexpected failure mode needs a defined response path, or teams will improvise under pressure.
NIST outcomeMechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.
You need a kill switch, and someone with the authority and knowledge to use it. When an AI system starts causing harm, every hour of delay increases the damage. This matters most for autonomous agents that can take actions.
AI risks and benefits from third-party entities are managed.
NIST outcomeAI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.
Vendor due diligence at purchase (GOVERN 6.1) is not enough. Vendors change models, terms, sub-processors and security posture after you sign. Ongoing monitoring catches those changes.
NIST outcomePre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance.
Foundation and open-weight models carry inherited risks such as training-data bias, embedded vulnerabilities, backdoors and license changes, and new problems with them are discovered all the time. Fine-tuning does not remove these risks.
Risk treatments, including response and recovery, and communication plans for the identified and measured AI risks are documented and monitored regularly.
NIST outcomePost-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.
This outcome brings post-deployment operations together into one plan per system. It is the operational runbook that shows the system is governed in production and not just at launch.
NIST outcomeMeasurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors.
Risk management should make systems better over time, not just keep them from getting worse. Building measurable improvement goals into each release cycle shows the program is effective and keeps stakeholders engaged.
NIST outcomeIncidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.
How you handle AI incidents determines whether trust survives them. Transparent communication with affected users, customers and regulators is increasingly mandatory. The EU AI Act requires providers of high-risk systems to report serious incidents, and existing breach-notification laws apply when personal data is involved.
Building to the AI RMF gets you most of the way to ISO/IEC 42001 certification and EU AI Act readiness. This is the high-level mapping we use with clients.
| AI RMF function | ISO/IEC 42001 | EU AI Act (high-risk) |
|---|---|---|
| GOVERN | Cl. 5 Leadership · Cl. 7 Support · Annex A policies, roles & supplier controls | Art. 4 AI literacy · Art. 17 Quality management system |
| MAP | Cl. 4 Context · Cl. 6.1 Risk & AI system impact assessment | Art. 6 Classification · Art. 9 Risk management · Art. 27 Fundamental rights impact assessment |
| MEASURE | Cl. 9 Performance evaluation | Art. 10 Data governance · Art. 15 Accuracy, robustness & cybersecurity |
| MANAGE | Cl. 8 Operation · Cl. 10 Improvement | Art. 14 Human oversight · Art. 72 Post-market monitoring · Art. 73 Serious incident reporting |
72 outcomes is a lot. This is the order we use to give clients something they can show a customer or auditor within one quarter.
Inventory every AI system (GV 1.6), publish an AI policy (GV 1.2), name owners (GV 2.1) and define risk tiers (GV 1.3).
Run MAP on your high-tier systems: intended use, impacts, risk tolerances and an AI-BOM. Review AI vendors and contracts (GV 6.1, MP 4.1).
Red-team and evaluate (MS 2.7, MS 2.11), turn on production monitoring (MS 2.4), formalize go/no-go (MG 1.1) and an AI incident playbook (MG 4.3).