What MANAGE 2.1 asks when an AI system goes live
MANAGE 2.1 asks whether the people, time and budget needed to manage an AI system's risks have been taken into account, and whether a viable non-AI system, approach or method was considered as a way to reduce how large or how likely the potential impacts are. The NIST AI RMF is voluntary, and there is no AI RMF certification. No assessor will issue a badge for this subcategory. What the organization gets is a set of decisions it must be able to show, to its own leadership, customers, or a regulator who points to the framework. The National Institute of Standards and Technology (NIST) publishes the framework in NIST AI 100-1, and that document is the place to read the subcategory wording itself. The difficulty is that both halves are easy to assert and hard to evidence. A team can say that risk management is resourced without naming a single person, a monitoring budget line, or a review calendar. Likewise, a team can say it considered simpler methods, such as a rules engine, a statistical model or a human review queue, and then ship the model without writing down why the alternative was rejected. Alternatives are usually weighed in meetings and never recorded, so when a system fails, nobody can show that the choice was deliberate. A practical starting point is a short decision record for each live system. It should name the risk management roles and their time allocation, list the non-AI alternatives that were evaluated, state the reason each was accepted or rejected, and identify which systems need extra resources because they are self-updating, trained without ground truth, or highly uncertain. Confirm internally who signs off on these records and how often they are revisited, because the Playbook treats resourcing and alternatives as continuing questions, not one-time paperwork.
Which AI systems and teams MANAGE 2.1 reaches first
MANAGE 2.1 asks organizations to account for the resources needed to manage AI risk and to weigh non-AI alternatives. The scoping choices below decide which systems get that treatment first and which teams must fund and staff it. Start with the systems whose failure would cost the most and whose behavior is hardest to predict.
High-risk systems
Start with systems whose errors would cause the greatest harm to people, operations or regulatory standing. The Playbook suggests planning resources for systems that are high risk, which makes the risk tier the first input to any resourcing decision. Check that the inventory from GOVERN 1 records a risk tier for every system, and that the tier drives staffing, monitoring frequency and review depth.
Self-updating systems
Systems that change their own behavior after deployment can drift away from the version that was tested. The Playbook suggests planning resources for self-updating systems, because each update can invalidate earlier evaluations. Ask who approves updates, how a rollback works, and how much monitoring capacity is reserved for the period after each change.
Systems trained without ground truth
Where no reliable ground truth exists, the organization cannot easily confirm whether outputs are correct. The Playbook names systems trained without ground truth as a category needing dedicated resources. Budget for human review panels, sampling, and fallback processes, and decide in advance whether a non-automated method is the safer option for the decisions these systems support.
Highly uncertain systems
Some systems produce outputs whose confidence is low or poorly calibrated, even when they perform well on average. The Playbook calls out highly uncertain systems for resource planning. Identify the decision thresholds where a person must take over, and record the non-AI method that would handle those cases if the model is unavailable or withdrawn.
Third-party AI
Purchased or hosted models and services bring risks that the buyer can measure only in part. Resourcing must cover vendor monitoring, contract review and exit planning, which links this work to GOVERN 6 and MANAGE 3. Ask vendors for change notices, evaluation evidence and their own contingency plans, and confirm what the contract lets you test or inspect.
Teams and their Playbook actor tags
MANAGE 2.1 is tagged to four AI actor categories: AI Deployment, Operation and Monitoring, AI Impact Assessment, and Governance and Oversight. Risk management staff set the resource need, operations staff run monitoring and fallbacks, impact assessors judge harm, and governance owners approve funding and non-AI alternatives. Name one accountable owner per category so that resource requests are decided rather than deferred.
How an assessor tests resourcing and alternatives
An assessor testing the resourcing half of MANAGE 2.1 asks whether the organization has actually provided the people, budget, tools and time needed to manage the risks of its AI systems, and whether those resources match the risk. Because the NIST AI RMF is voluntary and NIST does not validate any organization's approach, there is no pass mark. The reviewer instead reads the decisions and follows them into practice. They typically start from the AI inventory and risk register, select the systems with the highest-rated risks, and trace each one back to a named team, a funded budget line and a time allocation. Resourcing is judged against the Playbook's suggestions to staff risk management teams and to plan for systems that are high risk, self-updating, trained without ground truth or highly uncertain.
- Named owners: Each high-risk AI system has a named accountable owner and a named risk team, with roles documented in a RACI or equivalent.
- Funded budget lines: Budget approvals, cost centers or planning documents show money assigned to monitoring, testing and review, not only to building the system.
- Capacity evidence: Staffing plans, rotas or ticket-load reports show the team can actually perform the reviews scheduled.
- Tooling and access: Evidence that monitoring, evaluation and logging tools are provisioned and that staff have the skills or training to use them.
- Risk-based scaling: A written rule that links resource levels to risk tier, with at least one case where a higher-risk system received more resources.
Common finding: a budget line exists, but no owner can be named and the spend cannot be traced to any specific system. Confirm with the audit or assessment lead which evidence they will accept before you collect it.
The second half of the outcome asks whether the organization considered viable non-AI systems, approaches or methods that could reduce the size or likelihood of the impacts an AI system might cause. An assessor is not asking whether a rules-based or manual process is better in general. They are asking whether the consideration happened, was recorded, and fed into the decision to deploy, keep or scale the AI system. The Playbook suggests considering non-automated or semi-automated alternatives and cataloging past failed designs, so the reviewer looks for a written comparison, not a verbal remark. The test is a trace from the decision record back to a document that describes the alternatives considered and why they were accepted or rejected.
- Written alternatives analysis: A design or decision record that lists at least the realistic non-AI options and states the impact each one would have compared with the AI system.
- Decision linkage: Evidence that the analysis was an input to the go or no-go decision, such as an approval record referencing it.
- Failed design catalog: A searchable record of past designs, pilots or systems that were abandoned or rolled back, with reasons.
- Review trigger: A defined condition, such as a major model change or new incident category, that reopens the alternatives question.
- Sign-off: Approval by a named role with authority over the risk, recorded with a date.
Common finding: alternatives were discussed in a meeting, and the only record is a line in the minutes that says the team considered other options. Ask the reviewer whether minutes alone will satisfy them, and if not, plan the written analysis before the assessment window opens.
Assessors weigh evidence by how closely it ties to a real decision and how recently it was produced. A policy saying the organization resources AI risk is weaker than a dated budget approval for a named system, and both are weaker than a record showing the approval was conditional on the risk team's review. This tab sets out the evidence set that usually withstands review and the findings that appear most often, so you can check your own records before a customer, contract or regulator asks. Sampling is typical: the reviewer picks a handful of systems and checks each in detail, so a program that looks complete only in aggregate can still fail.
- Sample-based testing: Reviewers pick several AI systems across risk tiers and verify resourcing and alternatives for each one.
- Dated artifacts: Records should show creation and approval dates, and the sequence should make sense (alternatives considered before deployment).
- Consistency checks: Budget figures, staffing plans and risk register entries should agree with each other.
- Stale decisions: A review done at launch but never repeated after the system changed is a frequent finding.
- Gaps in ownership: Teams that run the system are often not the teams that hold the risk budget, which assessors flag.
Before assessment, confirm with your assessor, customer or regulator which artifacts they consider sufficient, since the framework itself does not define a required format.
Steps to resource AI risk work and document alternatives
This sequence turns MANAGE 2.1 into a resource plan that names who does the risk work, what capacity they have, and why each AI system needs automation or a simpler alternative. The output is a recorded decision that an assessor or internal reviewer can trace back to the system inventory.
Inventory systems that need resourcing
Start from the AI system inventory maintained under GOVERN 1 and list every system that needs risk management resources. Flag the systems the Playbook singles out for closer resourcing: those that are high risk, self-updating, trained without ground truth, or highly uncertain. Record the owner, the business purpose and the impact on people for each one. This step is done when every flagged system has a named owner and a short justification for its flag, and the list has been reviewed by the accountable executive.
Name the risk management team and its capacity
Assign the people who will carry out AI risk work for each flagged system, drawing on the roles documented under GOVERN 2. Record each person's responsibilities, the systems they cover and the share of their time the work requires. Include the AI actor categories the Playbook tags to MANAGE 2.1 (deployment, operation and monitoring, impact assessment, and governance and oversight) so that every category has an owner. The output is a roster that shows gaps where a system has no qualified reviewer or where one person covers too many systems.
Confirm the skills and tooling the team needs
Compare the skills the roster requires with the skills it has, such as model evaluation, security testing, privacy review and domain knowledge of the affected process. Record what the team must buy, train for or outsource, and ask any external provider to state its scope and deliverables in writing. Include the tooling needed to collect monitoring data and keep records. The output is a skills and tooling gap list with a named owner for each gap.
Assess non-automated or semi-automated alternatives
For each flagged system, ask whether a rules-based process, a human review step, a semi-automated workflow or a process without AI could meet the business need with less risk. Compare the likelihood and magnitude of the impacts under each option, using the MAP and MEASURE results already on file. Record the option considered, the reason it was accepted or rejected, and any residual risk. Write this as an illustrative comparison if you need a worked example, and keep the decision with the accountable owner. The output is a written alternatives assessment for each flagged system.
Catalog past failed designs
Collect prior AI or automated decision designs that were withdrawn, rolled back, or caused incidents, both inside the organization and from documented public failures relevant to the use case. For each one, record the cause, the impact, the control that would have prevented it and whether the current design repeats the same pattern. Feed the catalog into the alternatives assessment and the team's training material. The output is a dated catalog that the risk team reviews before each resourcing decision.
Record the resource plan and decision
Document the resource plan for each flagged system: the team, the time commitment, the tooling, the chosen approach (AI, semi-automated, or non-AI), the residual risks and the review trigger. Obtain sign-off from the accountable executive named under GOVERN 2 and file the decision with the system record. The output is a signed resource plan that links to the alternatives assessment and the failed design catalog, so an assessor can trace each decision to its evidence.
Set the review trigger and schedule the next review
Define the events that reopen the resource plan, such as a material change to the model, a new data source, a rise in incidents, or a change in the regulatory context. Confirm who monitors those triggers and how the decision is re-approved. Record the review schedule the organization sets for itself, since NIST does not prescribe one in the framework. The output is a trigger list and a review calendar kept alongside the resource plan.
Evidence that shows resourcing and alternatives were considered
MANAGE 2.1 is tested by what the organization wrote down before and during deployment, not by intent. The artifacts below connect resourcing decisions, non-AI alternatives and past failures to a named decision record that an assessor can trace. Keep each one dated, owned and reviewed on a fixed cadence so it still reflects the system in production.
Named resource plan
A resource plan lists who staffs risk management for each AI system, what time and tooling they receive, and which budget line pays for it. Name a single accountable owner per system and a backup. Check that the plan covers the Playbook's higher-risk cases: systems that self-update, were trained without ground truth, or carry high uncertainty. Update the plan whenever team membership, system scope or risk tier changes, and record the date of each change.
Alternative analysis record
For each AI use case, keep a short record of the non-automated or semi-automated options considered, such as rules-based processing, human review queues or existing statistical methods. Write down the reasoning for the choice made, including the risks that the alternative would carry. An assessor looks for a decision that can be reversed or questioned later. Revisit the record when the system's inputs, accuracy or regulatory context changes.
Catalog of past failed designs
Maintain a register of earlier designs, pilots or models that were abandoned, rolled back or judged unsafe, with the failure mode and the control that now prevents a repeat. This shows that lessons from prior failures shaped resourcing and design choices. Add entries from incident reviews and post-deployment monitoring, not only from the original build. Assign an owner to review the catalog before each new use case is approved.
Resourcing review minutes
Minutes from governance or risk committee meetings should record which resourcing and alternative decisions were examined, who attended, what was decided and which actions have due dates. Minutes are the link between the plan and the decision, so keep them signed or approved in the minutes' next meeting. Set a review cadence in writing and confirm it with your own governance policy, since the cadence is an organizational choice rather than a framework requirement.
Resource and capacity triggers
Define the conditions that force a resourcing review, such as a rising incident count, a model update, a new data source or a staffing gap in the risk team. Record each trigger, the threshold that activates it and the decision that followed. Triggers stop the plan from going stale between scheduled reviews. Test them during tabletop exercises and keep the exercise notes as evidence.
Ownership and sign-off trail
A sign-off trail records who approved each resource plan and alternative analysis, with dates and the version reviewed. Store approvals in the same system as the artifacts, so the chain from decision to owner is visible. Confirm with your own assessor which approval levels they expect for high-risk systems, because expectations vary by organization and sector.
What meeting MANAGE 2.1 costs in money and effort
This table breaks down the cost components of resourcing MANAGE 2.1, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate internal effort from outside spend. No figures are given because none are supplied for this topic; ask for them in the written scope.
| Cost component | One-time or recurring | What drives it |
|---|---|---|
| Risk management staff time | Recurring | Number of AI systems in scope, how often risk teams review them, and whether staff are dedicated or shared with other duties |
| Analysis of non-AI alternatives | One-time per system, repeated at major change | Number of candidate systems, depth of comparison against rules-based or human-run processes, and documentation of results |
| Resourcing for high-risk and self-updating systems | Recurring | Systems that are high risk, self-updating, trained without ground truth or highly uncertain need more monitoring and review time |
| Documentation upkeep | Recurring | Frequency of model, data or vendor changes, and how much of the record is generated automatically from existing tools |
| External review or independent assessment | One-time or periodic | Scope of the review, whether it is an internal reviewer or outside firm, and whether it covers all systems or a sample |
| Third-party dependence | Recurring | Number of vendor models, data sources and contracts, and the effort to obtain their documentation and monitor changes |
| Tooling and software licenses | Recurring, with possible one-time setup | Commercial license terms, seat counts and hosting. Self-hosted open-source tools can remove license fees, but setup, hardening and upkeep still carry cost |
| Implementation partner support | One-time or retainer | Written scope of work, number of systems, and whether the partner builds evidence templates or runs ongoing reviews |
Who resources the work, who prepares evidence, and who tests it
The organization owns the resource decision. NIST AI 100-1 places MANAGE 2.1 under the Manage function, and the Playbook links it to deployment, operation and monitoring, impact assessment, and governance and oversight. Those are accountable functions inside the organization, so leadership must decide how much staffing, budget, tooling and monitoring capacity a risky system receives, and whether a non-AI method could reduce the magnitude or likelihood of harm.
- Resource decision: Name the owner who approves staffing and budget for risk management of each AI system, and record the reasoning.
- Alternatives analysis: Document viable non-automated or semi-automated options, and why each was kept or rejected.
- Failure history: Keep a catalog of past failed designs and what changed as a result.
- Risk-based planning: Decide in advance what resourcing applies to systems that self-update, lack ground truth or carry high uncertainty.
- Sign-off: Retain approvals in governance records that an assessor can trace.
Before engaging any partner, confirm internally who holds these decisions and whether that person can say no to a deployment.
An implementation partner prepares the systems, tooling and evidence that the organization's decisions rely on. DeployOpen works this way: it plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For MANAGE 2.1, that can mean building the monitoring stack, workflow tooling and records that show resources were allocated and alternatives were weighed. The partner does not decide the resource level or choose the non-AI alternative, and it does not certify the result.
- Environment build: Stand up the platforms and monitoring the organization has chosen, inside its own infrastructure.
- Evidence capture: Configure logging and records so approvals, assignments and review dates are retained.
- Documentation: Write the procedures and runbooks that staff use to operate the controls.
- Compliance readiness: Prepare systems and evidence for assessment, then fix gaps the organization decides to close.
- Handover: Transfer ownership of the platform, credentials and records to the client's teams.
Ask any partner to state in writing which decisions it will prepare inputs for and which remain with the client.
An independent auditor, assessor or certification body tests the controls and reports on them. Because the NIST AI RMF has no certification or conformity assessment program, an organization cannot obtain an AI RMF certificate. Any assessment against the framework is a review arranged by the customer, contract or regulator, and the assessor's findings belong to that review. NIST states that it does not validate or endorse any organization's use of the framework, so claims of AI RMF certification should be treated with suspicion.
- Independence: The assessor must not have designed, built or operated the controls it tests.
- Testing: The assessor samples records, interviews staff and checks whether resource decisions and alternatives analyses are traceable.
- Reporting: Only the assessor issues the findings or report, and it states its scope and limits.
- Scope agreement: Confirm in writing which systems, dates and subcategories the review covers.
- Consulting limits: A firm that helps build the program may be barred from testing it under its own independence rules.
Confirm with the requesting customer or regulator which form of review it accepts before any work starts.
Common gaps that fail a MANAGE 2.1 review
Assessors reviewing MANAGE 2.1 look for evidence that resourcing and non-AI alternatives were decided deliberately and revisited as the system changed. The gaps below are the ones that most often leave that evidence missing, and each card ends with the check that closes it.
No documented resource decision
Teams often assume risk management is staffed without recording who owns it, how many hours it receives, or which tools it depends on. MANAGE 2.1 expects the resources needed to manage AI risks to be considered, so a reviewer will ask for the decision itself, not the org chart. Check that a dated record names owners, budget lines for monitoring and testing, and the approver who accepted the level of resourcing.
Alternatives assumed, not analyzed
A common statement is that AI was the only sensible option, with no comparison to rules-based logic, statistical models or manual review. Reviewers expect viable non-AI alternatives to be evaluated and the reasons for rejecting them written down. Confirm that each candidate alternative has a short analysis covering expected impact reduction, cost and the risks it would introduce.
Resourcing unchanged after self-updating
A system that began as a fixed model and later retrains, updates from live data or changes its behavior carries different risks, yet staffing and review cadence often stay the same. The Playbook suggests planning resources for systems that are self-updating, trained without ground truth or highly uncertain. Check whether the resourcing decision was reopened at each material change to the system's learning behavior.
Playbook suggestions treated as a checklist
Teams sometimes copy every Playbook suggestion into a tracker and mark items complete without judging whether they fit the system. NIST states that the Playbook is neither a checklist nor a set of steps, and the framework lets users choose which actions apply. Check that each suggestion used or set aside has a recorded rationale tied to the system's context and risk profile.
No catalog of past failed designs
Without a record of earlier designs that failed or were withdrawn, teams repeat the same approach and reviewers see no lessons carried forward. The Playbook suggests cataloging past failed designs as part of weighing alternatives. Confirm that the organization keeps a searchable log of rejected or retired approaches, with the reason each one failed, and that new proposals are checked against it.
Non-AI option not reviewed after launch
The alternatives analysis is often done once before go-live and never repeated, even when the system's risk changes or cheaper non-automated controls become available. MANAGE 2.1 concerns reducing the magnitude or likelihood of impacts over the life of the system, so the comparison should be periodic. Check that the analysis has a named owner, a review trigger and a dated record of the most recent review.
How much effort MANAGE 2.1 takes and what to outsource
Is there a certificate for meeting MANAGE 2.1 in NIST AI RMF?
No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST states that it does not validate or endorse any organization's use of the framework. MANAGE 2.1 is an outcome you can show evidence for, but nobody issues a MANAGE 2.1 certificate. If a customer or contract asks for proof, ask what they mean by it: usually they want documented resourcing decisions and a comparison of non-AI alternatives, which an internal review or an independent assessor's report can cover. Confirm the exact wording of any contractual requirement before you commit to an approach.
What drives the cost of MANAGE 2.1 work?
The main cost is staff time, and it rises with the number and risk of AI systems in scope. Costs fall into three groups: internal time for risk owners and engineers, external help for preparing evidence or running a comparison of non-AI alternatives, and any tooling you buy or host. Drivers include how many systems are self-updating, trained without ground truth or highly uncertain, since NIST's Playbook suggests planning more resources for those. Ask any partner for a fixed-scope quote that lists the systems covered, the deliverables and the evidence you will receive. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
How long does MANAGE 2.1 take to implement?
The timeline depends on how many AI systems you run, how much of their resourcing is already documented, and how quickly decision-makers can review the findings. No supplied source gives a duration for this work, so treat any figure from a vendor or consultant as an estimate to test against your own environment. Ask for a schedule that splits the work into inventory, resourcing review, alternatives analysis and sign-off, and ask which dependencies sit with your team, such as access to system owners and budget holders.
What does our team need to provide for MANAGE 2.1?
Your team owns the decisions. Someone must be accountable for AI risk resourcing, system owners must describe how each system behaves and what it is used for, and risk owners must decide whether a non-AI alternative is viable. Expect to provide the AI system inventory, existing risk registers, budget and staffing records, and access to the people who run each system. NIST's Playbook suggests resourcing risk management teams and cataloging past failed designs, so bring incident records and project post-mortems if you have them. Confirm which AI actor categories, such as deployment, operations, impact assessment and governance, map to roles in your organization.
Can we do MANAGE 2.1 in-house without outside help?
Yes, if you have people who understand both the AI systems and the risk process. The framework is voluntary and NIST does not require any particular party to perform the work. In-house teams usually handle the inventory and the decisions, while outside help is most useful for independent challenge of the alternatives analysis, for preparing evidence in a consistent format, or for a team that lacks the capacity. Be clear about who signs off each conclusion, because an outside partner prepares systems and evidence but does not issue audit reports or certifications. Independent auditors and assessors do that work.
What should a partner prepare for MANAGE 2.1?
A good partner prepares material that your team and any independent assessor can review. Ask for a written scope that names the AI systems covered, a resourcing assessment for each one, a catalog of non-AI alternatives considered with the reasons each was accepted or rejected, and records showing which risks the resourcing and alternatives address. Ask how the partner will document decisions and where the evidence will be stored. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications.
What can we outsource and what must stay internal for MANAGE 2.1?
Outsource preparation work and keep ownership internal. Work that partners commonly take on includes building the AI system inventory, drafting the resourcing analysis, cataloging alternatives and organizing evidence. Decisions about risk acceptance, resource allocation and the choice of a non-AI alternative must stay with accountable managers. Independent verification, where a customer or regulator requires it, comes from an independent assessor, not from the team that prepared the material. Write the split into the statement of work so each deliverable has a named owner.
Does the Playbook or a Generative AI Profile change MANAGE 2.1 effort?
They can add suggested actions, but they do not add a required checklist. The NIST AI RMF Playbook suggests actions for MANAGE 2.1, including resourcing risk management teams, considering non-automated or semi-automated alternatives, and planning resources for high-risk or self-updating systems. The Playbook is not a checklist, and its audit log shows the last content update in August 2023, with AIRC saying it will be updated after the AI RMF is revised. NIST AI 600-1, the Generative AI Profile, lists no suggested actions for MANAGE 2.1, so generative AI teams should use the core Playbook guidance and confirm with their own assessor how it applies.
How DeployOpen prepares MANAGE 2.1 evidence
DeployOpen's part in MANAGE 2.1 is to plan, implement and prepare the systems and evidence that show an organization has weighed the resources needed to manage AI risks and considered viable non-AI alternatives. The organization owns the decision. It decides whether a model-driven feature is justified for a given use, whether a rules engine, a semi-automated review queue or a human process would reduce the magnitude or likelihood of impact, and who signs off. DeployOpen works in the client's own cloud accounts, data centers or air-gapped networks under a fixed-scope written agreement that sets out the systems in scope, the deliverables and the timeline before work starts. DeployOpen does not issue assessments, attestations or certificates. Only an independent assessor or auditor can give a view on whether the outcome has been met, and NIST does not certify or endorse any organization's use of the AI RMF.
In practice, the written scope usually covers the resource record for each AI system (risk management staffing, tooling, review time and budget owner), a documented comparison of the AI approach against non-automated or semi-automated alternatives, and a register of past failed designs that the team has checked against the current proposal. For systems the organization marks as high risk, self-updating, trained without ground truth or highly uncertain, DeployOpen can configure the logging, access and change records that let the organization show those resource decisions over time. Confirm with the organization's own policy owners which of these artifacts they want kept, where they are stored, and which roles approve them.
Ongoing support is handled through a retainer rather than a one-time build. Retainers can cover upkeep of the evidence set as systems change, periodic review of resource allocations, updates to the non-AI alternative analysis when a system is retrained or its use expands, and preparation for an assessor's requests. A quote follows from the written scope: it reflects the number of systems, the depth of the alternatives analysis, the infrastructure involved and the expected upkeep. Ask for the quote to separate one-time preparation from recurring retainer work, and to state what the organization must provide, such as staff time for interviews and access to existing records.
