MANAGE 4.1 post-deployment monitoring plans

What does NIST AI RMF MANAGE 4.1 require for post-deployment monitoring?

MANAGE 4.1 asks that post-deployment monitoring plans are implemented for an AI system already in use. It sits in MANAGE 4 (risk treatment, response, recovery and communication) of the Manage function in NIST AI 100-1, Table 4. The outcome covers more than watching uptime: the plan should capture and evaluate input from users and other AI actors, handle appeals and overrides, define decommissioning, and run incident response, recovery and change management. The risk it targets is what surfaces only in use: performance drift as data changes, harms that no pre-launch test anticipated, and errors that users work around without anyone recording them.

The difficulty is usually organizational. Monitoring is split across the teams that build, operate, and use the system, and no one may own the combined picture. Logging is often too thin to reconstruct a bad output, and many organizations have no defined path for retiring a model or tool once it is no longer fit for purpose. Before an assessment or customer review, confirm who owns the monitoring plan, which metrics trigger review, where user complaints and overrides are recorded, and what the decommissioning criteria are. Those answers are the evidence you will need to show.

NIST AI 100-1 is voluntary, and there is no AI RMF certification. No body will certify that a system meets MANAGE 4.1, so the outcome is judged through your own plan and records. An internal or independent reviewer will check whether the plan exists, whether it is being followed, and whether logs and review minutes show that findings led to action. The NIST AI RMF Playbook lists suggested actions for this subcategory, and it is a reference for building the plan, not a checklist to sign off against.

Which AI systems, data and third parties does the monitoring plan cover?

Before monitoring is built, the compliance lead needs to settle what counts as a deployed system, which generative and predictive models are in scope, and where third-party components and data flows sit. These decisions set the boundary of the post-deployment plan, and each card below changes how much monitoring work follows.

Systems in production versus pilots

MANAGE 4.1 is about systems that affect people after deployment, so the first scoping decision is which systems count as deployed. A pilot that reaches real users, real records or real decisions usually belongs in scope, even if it is labeled a trial. Check the AI inventory against production traffic and access logs, not only against project lists. Record the date each system moved from test to live use, because that date starts the monitoring obligation and sets the baseline for drift checks.

Generative AI versus predictive models

Generative systems produce free-form output, so monitoring must look for confabulation, harmful content, information integrity problems and misuse. NIST AI 600-1 ties its MANAGE 4.1 suggested actions to specific generative risks, including CBRN information, confabulation and information security. Predictive models are usually monitored for performance drift, subgroup error rates and data shifts. Decide early which monitoring methods apply to each system type, because one checklist rarely fits both.

Third-party models and APIs

Models and APIs the organization does not control still create post-deployment risk. The provider may change model versions, training data or safety filters without notice. Scoping should list each external model, its version pinning options, the logs the provider exposes and the contractual channel for reporting failures. Where the organization cannot see the model internals, the monitoring plan must rely on its own tests of inputs and outputs, and the contract should say how the provider will share incident details.

Prompts, outputs and feedback data flows

User prompts, generated outputs and feedback ratings are data in their own right, and some contain personal or confidential information. Map where each flow is stored, how long it is kept and who can read it. Monitoring needs these records to detect misuse and errors, but retaining them creates privacy and security obligations. Confirm retention and access rules with the privacy and legal owners before instrumenting tracing, and document any dataset deletion or rectification requests that touch monitored data.

Feedback paths for AI actors

The Playbook tags MANAGE 4.1 with several AI actor categories: AI deployment, operation and monitoring staff, end users, human factors specialists, domain experts, and affected individuals and communities. Each category needs a defined way to report problems, submit appeals or override a decision. Scoping should name an owner for every category that touches the system, and state which groups receive a feedback channel. Missing a group, especially affected communities, is a common gap an assessor will look for.

Decisions to make before scoping

A compliance lead should settle four things before scoping starts: the definition of a deployed system, the owner of the AI inventory, the list of actor categories that need feedback paths, and the approach to third-party models and data retention. Write these decisions down with an approver and a review date. Scoping work that starts without them tends to be redone, because each later choice depends on what counts as in scope.

How an assessor tests post-deployment monitoring under MANAGE 4.1

This table compares six test steps an internal reviewer or independent party can run against MANAGE 4.1, with the evidence each step requests and the findings that appear most often. NIST does not run or endorse any assessment, so the organization chooses who performs the review and sets its acceptance criteria. Read each row as a question the reviewer answers with records, not as a pass or fail rule.

Test area	Test approach and evidence requested	Common findings
Written monitoring plan per system	Confirm a plan exists for each deployed system, covering metrics, owners, thresholds, review cadence and retraining triggers	Plans missing for older systems or written once and never reviewed
Monitoring outputs over a period	Sample dashboards, logs and TEVV reports across several months and check that reviews happened on schedule	Metrics collected but no evidence anyone acted on alerts
User input and appeal channel	Submit a test report or appeal end to end, then trace it to a triage record and a response	Channel exists but routes to an unmonitored mailbox or has no owner
Override and decommissioning records	Review override logs, approvals and retirement records, including data retention and access removal	Overrides undocumented or decommissioned systems still reachable
Incident detection through recovery	Pick sample incidents and trace detection, triage, containment, root cause, recovery and closure	Gaps between detection and ticket creation, or no closure evidence
Change management links	Match model or data changes to change tickets, test results and approvals before redeployment	Model updates released without linked monitoring baseline reset

How generative AI changes what gets monitored after launch

NIST AI 600-1, the Generative AI Profile, adds seven suggested actions under MANAGE 4.1, numbered MG-4.1-001 to MG-4.1-007, and the monitoring scope for a generative system is wider than for most predictive models. The profile ties these actions to risks including confabulation, CBRN information or capabilities, harmful bias and homogenization, human-AI configuration, information integrity and information security. Treat them as suggested actions that the organization may adopt, adapt or decline, not as a checklist. The Playbook, which is the companion resource for the framework, makes the same point about itself.

Two of the actions change the monitoring design most. MG-4.1-002 asks organizations to establish and evaluate post-deployment monitoring with attention to confabulation (fluent but unfounded output) and to CBRN or cyber misuse. In practice, this means keeping a recurring test set of prompts that probes these behaviors, running it against the production model and its retrieval layer, and recording the results over time. Confirm with your risk owners which thresholds trigger a review, since the profile does not set them for you. Logs of prompts, responses and tool calls, such as those a tracing tool like Langfuse can capture, are the raw material for this evaluation.

MG-4.1-006 asks organizations to track dataset modifications that may affect whether content origins can still be verified. For a generative system, that covers knowledge base edits, document deletions, rectification requests and changes to the sources a retrieval step draws from. Record each change with a date, an owner and the reason, so that an investigator can later explain why a given output cited a source that no longer says what it said. Ask your engineering team to confirm where this history is stored and how long it is kept, because the profile describes the outcome, not the retention period.

How to build a post-deployment monitoring plan that holds up in review

This sequence turns MANAGE 4.1 into a working monitoring plan with named owners, measurable thresholds, feedback channels, and documented paths for appeal, retesting, decommissioning and recovery, so an assessor can trace each deployed system from launch to retirement.

Assign an accountable owner for each system
Name one accountable owner per deployed AI system, along with the operators, domain experts and deployers who share monitoring duties. The output is a monitoring ownership record that lists each role, its responsibilities and its escalation contact, linked to the AI system inventory maintained under GOVERN 1. The step is complete when every system in the inventory has a named owner who has accepted the role in writing.
Define metrics and thresholds for each characteristic
Select the metrics that track validity, reliability, safety, security, fairness, privacy and explainability for the risks identified during MAP and MEASURE, then set a threshold that triggers review for each one. The output is a monitoring metrics register that records the metric, its data source, its threshold and the person who may change it. Confirm with the owner that every significant mapped risk has at least one metric and that each threshold has a documented rationale.
Set up logging and feedback intake
Configure logging for inputs, outputs, model versions, tool calls and errors so that performance can be reconstructed later, and open at least one channel where users and other AI actors can report problems. For generative AI systems, tracing tools such as Langfuse record each request as a trace with timing, inputs, outputs and token usage, which supports this step. The output is a logging specification and a feedback intake procedure. The step is done when a test request produces a complete record and a test report reaches the owner.
Write appeal and override procedures
Document how an affected person can contest an AI-driven decision, how a human reviewer can override the output, and how overrides are recorded and fed back into the system. The procedure should name who reviews appeals, the timeframe you commit to (confirm this internally, since NIST does not set one) and how the outcome is communicated. The output is an appeal and override procedure with a sample case log, and the step closes when a reviewer has walked through the procedure on a test case.
Define triggers for post-deployment TEVV and red teaming
Specify the events that start a re-test, such as a metric crossing its threshold, a change to the model or data, a new user population, or a reported incident, and state which tests run each time. Include the red-teaming cadence you set, the dataset modification tracking required for deletion and rectification requests, and the process for sharing errors and near misses with incident databases. The output is a TEVV and red-team trigger schedule. Garak can support generative AI probing for hallucination, data leakage, prompt injection and jailbreaks, and its JSONL report and hit log become the evidence for this step.
Document decommissioning criteria
Define the conditions under which a system is suspended, restricted or retired, including unresolved high-priority risks, sustained threshold breaches, loss of a lawful basis for data use and the availability of a non-AI alternative. The record should also state how data, models and logs are preserved or deleted at retirement and who signs off. The output is a decommissioning criteria document attached to the system record. The step is complete when the owner and the risk function have each approved the criteria in writing.
Connect incidents to recovery and change management
Route incidents from monitoring into a single case process that tracks assets, evidence, tasks and a timeline, then link each resolved incident to a documented change request for the model, data, prompt or configuration. DFIR-IRIS can hold cases with a full audit trail and chain of custody for evidence, while GLPI's Assistance module supports tickets, problems and changes under ITIL practices. The output is a linked incident and change record for each event. Confirm with your tool vendor which features you need before you rely on them.
Set and record the review cadence
Agree a recurring review of metrics, incidents, appeals, overrides and open changes, with the attendees and decision rights for each review written down. Schedule a formal look at the whole plan whenever the system changes materially or when outside guidance such as a revised AI RMF changes the expectations. The output is a review calendar and signed meeting minutes, and the step is done when the first review has been held and its actions assigned to named owners.

Which evidence shows MANAGE 4.1 is working, and how to keep it current

MANAGE 4.1 is shown by a chain of records, from the plan that was approved through the monitoring output, the tests, the user input and the changes that followed. Each artifact below has an owner and a review date, and the records link to one another so an assessor can trace a monitoring signal to a decision. Retention periods should come from your own records policy, not from this page.

Approved monitoring plan per system

A dated plan for each AI system that names what is monitored, the metrics and thresholds, the data sources, the people who receive alerts and the actions a breach triggers. Assign a named owner and a review date tied to each material change in the system, its data or its use. Check that the plan references the current risk register entries it is meant to watch, and that superseded versions are archived rather than overwritten. Confirm with your own records policy how long prior versions are kept.

Monitoring dashboards and periodic reports

Dashboards show performance and trustworthiness indicators over time, and periodic reports summarize them for the accountable owner. Export the reports on a schedule your governance body sets, and record who reviewed each one and what they decided. Keep the underlying query or configuration under version control so the same view can be reproduced for an auditor. Where a threshold was crossed, the report should link to the ticket that handled it.

Post-deployment TEVV and red-team reports

Test, evaluation, verification and validation results taken after release, covering validity, bias, privacy and security, plus red-team findings at the cadence the plan sets. Each report should state the test scope, the version tested, the pass criteria and the remediation owner. Schedule re-tests after any model, prompt, retrieval or dataset change, and retain the raw outputs alongside the summary. For generative AI systems, the Generative AI Profile adds confabulation and information security tests to the set.

User feedback and appeal logs

A log of complaints, feedback, appeals and overrides from users and affected people, with the disposition of each entry, the decision maker and the date it closed. Track recurring themes so they feed back into measurement and system design. Confirm who can appeal, how the appellant is told the outcome, and how long open items may stay open under your own service standards. Sample closed cases during each review to confirm dispositions were actually applied.

Override and decommissioning records

Records of each time a human overrode the system output and why, plus the approval and data-handling steps for retiring a system. Override logs show whether human oversight works in practice, so review them for patterns that point to a model problem. Decommissioning records should cover model disposal, data deletion or retention, access removal and any notice to users. Assign an owner to each record and check it against the inventory so no retired system remains listed as live.

Incident and change tickets linked to triggers

Incident records and change requests, each tied back to the monitoring alert, test finding or user report that opened it. A ticket should show the trigger, triage, containment, recovery and the post-change verification that closed it. Use an ITSM or case tool that keeps a full audit trail and lets you filter tickets by AI system. Review open and recurring tickets at each governance meeting, and sample closed ones to confirm the link to the originating trigger is intact.

What meeting MANAGE 4.1 costs in money and effort

This table separates the cost components of a post-deployment monitoring program, shows who is paid for each one, and marks whether it is one-time or recurring. Read it as a checklist for a written quote: most of the effort sits in people's time, which open-source tooling reduces but does not remove.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring for commercial tools, usually one-time setup for self-hosted open source	Number of AI systems monitored, retention needs, and whether tracing, case management and ticketing are bought or self-hosted	Choose self-hosted open-source components such as Langfuse, DFIR-IRIS and GLPI, and confirm license terms and hosting costs with each vendor or project
Engineering time for instrumentation and logging	Mostly one-time per system, with recurring updates when models or pipelines change	Number of components in each AI system, how many operations are traced, and how inputs and outputs are handled for privacy	Standardize trace schemas across systems and reuse the same instrumentation pattern for each new deployment
Staff time for feedback review and appeals	Recurring	Volume of user reports, override requests and appeals, plus the number of people trained to adjudicate them	Define triage categories and response paths in advance so routine reports do not need senior review
Post-deployment TEVV and red-teaming	Recurring, at a cadence the organization sets	Risk tier of the system, change frequency, and the scope of validity, bias, privacy and security testing	Run automated probes such as garak on a schedule and reserve human red-teaming for major changes or high-risk findings
External testing or review	Recurring or per engagement	Whether independent testers or reviewers are used, and how much scope they cover	Agree the scope in writing with a fixed deliverable list, and confirm what the reviewer will test before work starts
Evidence upkeep	Recurring	Number of logs, decisions, change records and incident files kept, and how long each must be retained	Keep evidence in case and ticket records as work happens, not as a separate reconstruction at audit time
Independent auditor sampling time	Recurring at each assessment cycle	Number of systems in scope, how many records the auditor samples, and how easily records can be retrieved	Index records by system and date, and confirm with the auditor in advance which samples they will select
Implementation partner preparation	One-time for setup, recurring if retained for support	Number of systems, existing tooling, and how much instrumentation or documentation is missing	Ask for a written, fixed-scope proposal that separates setup, documentation and any ongoing support

Which self-hosted open-source tools produce MANAGE 4.1 evidence

MANAGE 4.1 asks for post-deployment monitoring that captures input, handles appeals and overrides, and runs incident response, recovery and change management. The four tools below each cover one of those evidence streams, and an assessor will expect their outputs to be reviewed, retained and tied to named owners.

garak red-team reports for LLMs

garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Running it on a recurring schedule against the deployed model gives MANAGE 4.1 a repeatable post-deployment test record. Confirm that the probes match the risks named in your monitoring plan, and that someone reviews the hit log and records the response.

Langfuse traces as monitoring evidence

Langfuse (MIT) records each trace as the full set of operations in a request, including LLM calls, retrieval steps, tool executions and custom logic. Each trace carries timing, inputs, outputs, token usage and metadata. This gives monitoring teams a record of what the system did in production, which supports performance review and the evaluation of user input. Check how your team handles personal data in captured inputs and set retention rules before enabling full capture.

DFIR-IRIS incident case records

DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases, builds a consolidated investigation timeline, and logs evidence with SHA-256 verification and chain of custody. Reports generated from case data show how an AI incident was detected, contained and recovered. Confirm which alert sources your monitoring stack can send to it, and who approves incident closure.

GLPI tickets for feedback and change

GLPI (GPL-3.0-or-later) Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices. Plannings, statistics, recurrent tickets and a Kanban view help teams track user feedback, appeals and overrides from creation to resolution. Change records document updates made after deployment, which is the evidence MANAGE 4.1 asks for on change management. Confirm that appeal and override requests can be routed to the right reviewer and that closure reasons are captured.

Who owns the monitoring plan, who builds it and who checks it

Your organization owns the monitoring plan and every decision it produces. MANAGE 4.1 describes an outcome the organization must achieve: monitoring plans that capture and evaluate input from users and other AI actors, handle appeals and overrides, decommission systems, and run incident response, recovery and change management. Those decisions belong to named people in your organization, who must be able to explain them later to a regulator, customer or assessor.

Plan ownership: A named accountable owner signs off the monitoring plan, its scope and its review cycle.
Thresholds: Your risk and business owners set the metric thresholds that trigger investigation, rollback or escalation.
Appeals and overrides: Staff who are accountable for outcomes decide appeal results and when a human overrides the system.
Decommissioning: Leadership decides when a system is retired, paused or superseded, and records the reasons.
Alert duty: On-call and operations staff act on alerts within the response procedure you define, and record what they did.

Check that each of these decisions has a named owner, a documented rationale and a dated record.

What do buyers ask about cost, effort and outside help for MANAGE 4.1?

Can we do MANAGE 4.1 post-deployment monitoring in-house?

Yes, the organization owns its AI risk management and can carry out MANAGE 4.1 with its own staff. The work covers defining monitoring plans, capturing user input and appeals, running post-deployment testing, setting up incident response and change management, and deciding when a system is decommissioned. Teams that already run operations, security and service management tooling usually have a head start, while teams without that base often ask an implementation partner to help set up the systems and records. Whichever path you choose, the decisions and accountability stay with your organization.

How much effort does MANAGE 4.1 take, and what drives it?

Effort depends mainly on how many AI systems are in production, how much risk each one carries, and how much of the monitoring already exists. A single internal tool with limited impact needs a much smaller plan than a customer-facing system that affects credit, health or employment decisions. The main drivers are:

The number of deployed systems and how often their data or models change
The depth of post-deployment testing, including bias, privacy and security checks
Whether generative AI components need extra monitoring for confabulation or misuse
How mature your ticketing, logging and incident processes already are

Ask for an effort estimate that lists each system and each driver separately.

Do we need a certificate to show we meet MANAGE 4.1?

No. The NIST AI RMF is voluntary, and NIST does not run a certification, accreditation or conformity assessment program for it, nor does it validate or endorse any organization's use of the framework. Customers or regulators that ask about MANAGE 4.1 usually want documented monitoring plans, test records and incident logs that they can review. If a contract requires an independent opinion, the organization needs to agree with the customer on which independent assessor will review the evidence, since no AI RMF certificate exists to point to.

What does MANAGE 4.1 require from our internal staff?

Your staff must make the decisions that the framework assigns to the organization, even when an outside partner does the technical setup. This includes naming an owner for each monitored system, deciding what counts as an incident, approving appeal and override procedures, and signing off on decommissioning. Operations, security, data and domain experts all contribute, and the Playbook tags this subcategory to several AI actor groups, including affected individuals and communities. Plan for named people in these roles and for time to review monitoring results on a regular schedule.

How long does a MANAGE 4.1 engagement take?

The duration depends on scope, meaning how many systems are covered, how much existing tooling can be reused, and how many approvals and integrations are needed. DeployOpen gives a timeline only in a written scope agreed before work starts, so any date given before that point is not a commitment. To compare offers, ask each provider to break the timeline into phases such as discovery, configuration, testing, documentation and handover, and to state which dependencies on your team could delay each phase.

What should we ask for in a quote for MANAGE 4.1 support?

Ask for a written scope that lists each AI system, the monitoring and testing activities for each, the tools to be deployed or integrated, and the deliverables such as runbooks, dashboards and evidence records. The quote should separate one-time work, such as initial setup and documentation, from recurring work, such as monitoring reviews, testing cycles and upgrades, and state what each part costs or requires. Also ask what your staff must provide, which assumptions the price depends on, and what changes would require a new quote. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes, implements and prepares MANAGE 4.1 evidence

DeployOpen works on MANAGE 4.1 by building the post-deployment monitoring plan into the client's own infrastructure, using self-hosted open-source platforms for monitoring, incident handling and change records. The organization keeps ownership of its AI risk decisions, while DeployOpen prepares the systems and documentation that show the plan operates as written.

How we scope

Written scope names the AI systems, environments and monitoring signals covered by the post-deployment plan.
Scope defines which user input, appeal, override and incident channels are in and out of the engagement.
Deliverables, timelines and responsibilities are agreed in writing before any work starts, as all engagements are fixed-scope.

How we build

Self-hosted tracing and monitoring are configured inside the client's infrastructure to capture inputs, outputs and tool calls for review.
Ticketing and change-management workflows are set up to record user reports, overrides, decommissioning requests and approvals.
Incident case records with audit trails and evidence logging are configured so that response and recovery steps stay traceable.

How we hand over

Runbooks document how monitoring alerts are triaged, escalated and closed, with named roles for each step.
Evidence packages map monitoring logs, tickets, change records and test reports to the MANAGE 4.1 outcome for internal review.
Handover covers configuration records and training so the client's own teams can operate the plan after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer.
Post-deployment reviews can be scheduled to re-run monitoring checks and update the plan when the system changes.
Confirm with DeployOpen which assessor, auditor or internal reviewer will examine the evidence, since DeployOpen does not issue reports or certificates.