MANAGE-2.2: Mechanisms are in place and applied to sustain the value of deployed AI systems.

MANAGE-2.2 focuses on what happens after deployment, where many AI governance programs get thin. You can pass a design review and still fail in production if accuracy decays, input data shifts, user behavior changes, or business requirements evolve. The requirement is short, but the operational implication is clear: you need mechanisms that keep deployed AI systems delivering their intended benefit, without drifting into unacceptable risk.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate “sustain the value” into a control objective you can test: (1) clear value definitions and success criteria, (2) monitoring and alerting tied to those criteria, (3) a controlled process for changes and retraining, (4) periodic governance reviews that decide to continue, constrain, or retire the system, and (5) retained evidence that those mechanisms are actually applied (NIST AI RMF Core). If you already operate IT services with SLOs, incident management, and change control, you can adapt that muscle to AI-specific failure modes.

Regulatory text

“Mechanisms are in place and applied to sustain the value of deployed AI systems.” (NIST AI RMF Core)

Operator meaning: you must (a) implement concrete operational mechanisms (monitoring, controls, reviews, and decision rights) and (b) show they run in practice for each deployed AI system. “Sustain value” is broader than model performance; it includes whether the system continues to meet business objectives, user needs, and risk tolerances as conditions change (NIST AI RMF Core).

Plain-English interpretation

A deployed AI system should not be “set and forget.” You need a production sustainment program that:

• Defines what “good” looks like (value, performance, and risk limits).
• Detects when reality deviates from expectations (drift, errors, harm signals, cost spikes, latency).
• Forces disciplined decisions (fix, roll back, retrain, restrict, or retire).
• Produces audit-ready evidence that these activities occur.

If you cannot demonstrate ongoing monitoring, change discipline, and periodic value confirmation, auditors will treat the system as unmanaged in production even if the initial deployment was approved.

Who it applies to

Entity scope: any organization developing or deploying AI systems (NIST AI RMF Core).
Operational scope: any AI system that is deployed and used for real decisions or customer/internal workflows, including:

• Customer-facing AI (recommendations, chat, underwriting support, fraud screening support).
• Internal AI (HR screening support, security analytics, finance forecasting).
• AI embedded in third-party products you operate or configure (model-as-a-service, SaaS features).

Teams implicated: product, engineering/ML, IT operations/SRE, data governance, security, privacy, legal/compliance, model risk management (if applicable), and third-party risk management.

What you actually need to do (step-by-step)

Use this sequence to operationalize MANAGE-2.2 quickly.

Step 1: Create a “deployed AI inventory” view

Build a list of deployed AI systems with enough detail to manage sustainment:

• System name, business owner, technical owner
• Use case and decision type (assistive vs automated action)
• Data inputs and sources (including third parties)
• Model version, release date, and hosting environment
• User population and downstream processes affected

Tip: if you already have an application inventory, add an “AI deployed” flag and required AI fields.

Step 2: Define “value” and success criteria per system

For each system, document:

• Business outcomes: what the system is supposed to improve (speed, quality, loss reduction, customer support resolution).
• Performance KPIs: accuracy/quality metrics appropriate to the use case (do not force one metric across all models).
• Risk KRIs: leading indicators of harm or non-compliance (complaint signals, override rates, anomalous segments, unsafe output rates, security abuse indicators).
• Minimum acceptable thresholds and action triggers: what causes investigation, throttling, rollback, or retraining.

Your control test becomes simple: can you show metrics, thresholds, owners, and recorded actions when thresholds were hit?

Step 3: Implement monitoring, alerting, and review routines

Put mechanisms in place that run continuously or on a recurring schedule:

• Data monitoring: schema changes, missingness, distribution shift, outlier rates, and input quality checks.
• Model monitoring: performance over time, latency, error rates, confidence distribution, calibration drift where relevant.
• Human feedback monitoring: user overrides, manual review outcomes, ticket trends, customer complaints relevant to AI behavior.
• Security monitoring: prompt injection attempts, unusual query patterns, data exfiltration signals for generative systems.

Operationalize with:

• Named dashboards (owner, location, access control)
• Alert rules tied to thresholds
• On-call/triage workflow and ticketing integration
• A standing monthly (or similar) review meeting for material systems

Step 4: Put AI changes under change control (including data and prompts)

Sustainment fails when teams change prompts, features, training data, or post-processing logic without governance. Require:

• A change request describing what changed and why (model version, prompt, policy rules, feature set, dataset, filtering)
• Risk assessment for the change (impacted users, impacted controls, new failure modes)
• Testing evidence (offline evaluation results, regression tests, red teaming results if applicable)
• Approval by the right owner(s)
• Backout/rollback plan

If your organization already has ITIL-style change management, extend it with AI-specific fields rather than creating a parallel process.

Step 5: Define incident management for AI-specific failures

Add AI incident categories and playbooks:

• Model degradation causing incorrect decisions
• Harmful/unsafe outputs for generative AI
• Data pipeline corruption
• Access control or data leakage related to the AI system
• Third-party model/service outage affecting decisioning

Make sure incidents produce:

• Root cause analysis that distinguishes data vs model vs process causes
• Corrective actions (retrain, change thresholds, add guardrails, restrict use)
• Lessons learned and control updates

Step 6: Periodically re-justify continued deployment (“value confirmation”)

Set a governance checkpoint where the business owner and risk/compliance confirm:

• The use case is still valid and approved
• Metrics show continued benefit
• Known risks remain within tolerance
• Controls still work (monitoring, access, change control)
• Third-party dependencies remain acceptable

Record the decision: continue, continue with constraints, pause, or retire.

Step 7: Extend sustainment mechanisms to third parties

Deployed AI systems often rely on third parties for data, models, hosting, or monitoring. Add:

• Contract/SLA hooks for model/service changes and outage notifications
• Change notification requirements for third-party model updates
• Periodic attestations or evidence requests (where feasible)
• Exit/portability plan if a third party creates unacceptable operational risk

This is where third-party risk management connects directly to AI governance: if you cannot detect or control upstream changes, you cannot credibly sustain value.

Required evidence and artifacts to retain

Auditors will ask for proof that mechanisms are “in place and applied.” Retain artifacts that show operation over time:

Core governance artifacts

• Deployed AI inventory entry for each system
• Ownership matrix (business owner, technical owner, risk/compliance reviewer)
• Value definition and KPI/KRI specification with thresholds
• Approval record for initial deployment and subsequent material changes

Operational artifacts (the “applied” proof)

• Monitoring dashboards screenshots/exports and alert configurations
• Periodic monitoring reports with dates and reviewer sign-off
• Incident tickets and post-incident reviews tied to the AI system
• Change requests, approvals, test results, and release notes
• Meeting minutes or decision logs for periodic value confirmation reviews

Third-party artifacts (if applicable)

• Contracts/SOW sections addressing change notice, SLAs, and security obligations
• Third-party performance reports and outage communications
• Evidence of periodic third-party reviews tied to the AI system dependency

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you define ‘value’ for this model and who approves that definition.”
• “What metrics do you monitor, what are the thresholds, and what happens when thresholds are breached?”
• “Provide evidence of monitoring over a period and actions taken.”
• “How do you control prompt/model changes and retraining events?”
• “How do you ensure upstream third-party changes don’t silently degrade performance or increase risk?”
• “When was the last time you considered retiring or constraining the system?”

Hangup to anticipate: teams often have dashboards but no documented thresholds, no defined action triggers, and no record of decisions. That fails the “applied” part.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails MANAGE-2.2	Fix
Only tracking model accuracy offline	Production value can degrade due to data shift, UX changes, or downstream process changes	Add production monitoring and human feedback signals tied to real outcomes
No clear owner	No one is accountable for sustaining value	Assign a business owner and a technical owner; document decision rights
Ad hoc prompt/model edits	Drift and regressions go undetected	Put prompts, filters, and model versions under change control
“Annual review” with no operational telemetry	Reviews become paperwork	Require dashboards, alerts, incidents, and change history as review inputs
Ignoring third-party updates	Upstream changes break your assumptions	Contract for change notices; monitor externally provided model behavior and uptime

Enforcement context and risk implications

NIST AI RMF is a framework, not a law, and enforcement varies by the regulatory regime you operate under. The practical risk is governance defensibility: if an incident occurs and you cannot show you sustained value through monitoring, controlled change, and periodic review, your organization looks negligent in production operations (NIST AI RMF Core; NIST AI RMF program page). This also affects internal model risk oversight, customer trust, and board reporting, because “value” includes reliability, safety, and operational resilience.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Identify deployed AI systems and owners; build the deployed AI inventory.
• For top-risk systems, define value KPIs/KRIs, thresholds, and escalation paths.
• Stand up basic monitoring dashboards and alert routing for those systems.
• Document a lightweight AI change control addendum (model/prompt/data changes).

Days 31–60 (operationalize mechanisms)

• Integrate alerts into ticketing/on-call workflows; require triage notes.
• Implement periodic value confirmation reviews for the highest-impact systems.
• Add AI incident categories and post-incident review templates.
• Start collecting recurring evidence (reports, approvals, meeting minutes).

Days 61–90 (scale and audit-proof)

• Expand monitoring and reviews to remaining deployed systems based on risk tiering.
• Formalize third-party dependencies for each system and set evidence expectations.
• Run an internal “tabletop” on a drift or unsafe-output scenario and record corrective actions.
• Prepare an audit packet per system: inventory, metrics, monitoring history, change log, incidents, and review decisions.

Where Daydream fits: sustaining value is evidence-heavy. Daydream can centralize control mapping for MANAGE-2.2, assign control owners, and automate recurring evidence collection so you can show mechanisms are operating without chasing screenshots and emails.

Frequently Asked Questions

What counts as “mechanisms” under MANAGE-2.2?

Mechanisms are operational controls that keep a deployed AI system effective and within risk tolerance, such as monitoring, alerting, change control, incident management, and periodic governance reviews (NIST AI RMF Core).

Do we need to measure “value” in dollars?

No. You need a defined, approved value statement and measurable success criteria. Financial metrics can help, but operational outcomes, quality, and risk indicators are also valid if they tie back to the use case.

How do we handle systems embedded in third-party SaaS tools?

Treat them as deployed AI dependencies. Define what “good” looks like, monitor what you can (outcomes and errors), require change notifications contractually where possible, and keep evidence of periodic third-party reviews tied to that AI function.

What evidence is most persuasive to auditors?

Time-stamped artifacts that show mechanisms operating: monitoring reports, alerts with follow-up tickets, approved change records with testing, incident postmortems, and governance review decisions with rationale.

How do we decide which systems get the most sustainment effort?

Tier systems by impact and risk: decision criticality, user reach, reversibility, regulatory sensitivity, and third-party dependence. Apply deeper monitoring and more frequent reviews to the highest tiers.

We have monitoring, but no one looks at it. Are we compliant?

Probably not. MANAGE-2.2 requires mechanisms “in place and applied,” so you need evidence that people review signals, make decisions, and take corrective actions when thresholds are breached (NIST AI RMF Core).