MANAGE 3.2 Monitoring pre-trained models

What pre-trained model monitoring under MANAGE 3.2 asks for

If your team builds AI systems on pre-trained models, MANAGE 3.2 requires you to monitor those models as part of regular AI system monitoring and maintenance. The outcome sits in MANAGE 3 (third-party AI risks and benefits) of the Manage function in NIST AI 100-1, and it applies to the models you pull in for development, not only to the finished system you deploy. The reason NIST singles them out is in Appendix B, which lists pre-trained models among the risks that are new or increased compared with traditional software. They can increase statistical uncertainty, and they can make bias management, scientific validity and reproducibility harder to establish because you did not train the model and may not see its full training data or evaluation history.

For a compliance lead or engineer, the practical starting point is the AI inventory. Confirm that every pre-trained model used in development is recorded there with its source, version, license, the components it connects to, and the system it feeds. Then check who owns the ongoing monitoring of each entry. A model that appears in code but not in the inventory is the most common gap an assessor will find first. The Playbook suggestions for this subcategory also expect independent, continuing monitoring of performance and trustworthiness, remediation of the risks a model introduces, and decommissioning of any model that exceeds your risk tolerances. Decide in advance which metrics, thresholds and owners trigger each of those steps, and record them.

Close with three points about what this does and does not mean. NIST AI 100-1 is a voluntary framework, and no organization is required to adopt it. There is no AI RMF certification, and NIST does not validate or endorse any organization's use of the framework, so no outside body issues a MANAGE 3.2 certificate. The Playbook is a companion of suggested actions, documentation prompts and references, and NIST states it is neither a checklist nor a set of steps. Choose the actions that fit your systems, document why you chose them, and confirm with your own legal, risk and procurement teams which external obligations, such as contract or sector rules, also apply to your pre-trained models.

Which pre-trained models and teams fall in MANAGE 3.2 scope

MANAGE 3.2 covers pre-trained models used for development, so the first question is which models, components and people sit inside that boundary. Each decision below changes what goes into the AI inventory, who monitors what, and how much evidence the monitoring program has to produce.

Fine-tuned models in scope

A model adapted through fine-tuning starts from a pre-trained base, so the base model stays in scope even after your team changes its weights. Record the base model name, version, source and license in the inventory, then log the fine-tuning data, method and date as a separate entry linked to it. Monitoring must follow both, because a risk in the base model carries into every derived version. Ask whether each fine-tuned variant has its own owner and retirement date.

Retrieval-augmented generation pipelines

A retrieval-augmented generation setup may use no changed model weights, yet the retrieval index, document sources and prompt templates all shape output. Treat the generation model and each retrieval component as in scope, and document how they were configured. The NIST AI 600-1 Generative AI Profile lists suggested actions for documenting how pre-trained models were adapted, including through retrieval. Confirm who can change the corpus, and whether those changes trigger re-evaluation.

Open-weight models you host

Open-weight models run inside your own infrastructure, so monitoring depends on your own telemetry rather than a vendor's service level. Your team owns the model files, serving stack and update decisions, which means vulnerability tracking and license review fall to you. Record the exact artifact hash, the serving configuration and the license identifier. Confirm which team receives advisories for the model and its dependencies.

Vendor-hosted models you call

A vendor-hosted model changes behind an API, sometimes without a version change you can see. Monitoring therefore focuses on the contract, the documented model version, the vendor's change notices and your own output testing against a fixed test set. Ask the vendor how it announces model updates, how long old versions remain available and what data it retains. Your third-party risk process should hold these answers in writing.

Connected components like embeddings and tokenizers

Embedding models, tokenizers, rerankers and safety classifiers often ship as separate artifacts with their own versions and licenses. A change to a tokenizer can alter model behavior even when the main model is unchanged, so each connected component belongs in the inventory with its own entry. Software composition tools such as Dependency-Track can track these components through CycloneDX SBOMs and VEX data, which helps you spot known vulnerabilities and license risk.

Teams that share ownership

MANAGE 3.2 work spans AI development, operations and third parties, and gaps usually appear where ownership is unclear. Development teams know why a model was selected, operations teams see drift and incidents, and third parties hold the upstream model documentation. Assign one accountable owner for each inventory entry and name the contact for each third party. The NIST AI 100-1 Appendix A tasks for third-party entities, operation and monitoring, and AI deployment set the expected responsibilities.

How an assessor tests pre-trained model monitoring

This table compares four areas an assessor examines for MANAGE 3.2, showing the test approach, the evidence to request and the findings that appear most often. NIST does not validate or endorse any organization, so the assessor is your own auditor or internal reviewer using the AI RMF subcategory as the criteria. Use the table to prepare evidence before the review starts.

Area	Test approach	Evidence requested	Common findings
Inventory of pre-trained models	Compare the AI inventory against models actually loaded in development, notebooks, pipelines and deployed services	Inventory entries naming each pre-trained model, its source, version, license and the systems that depend on it	Models pulled from public hubs during experiments never recorded, or inventory entries with no version or owner
Independent and continual monitoring	Sample monitoring records and check that someone other than the model's builders reviews performance and trustworthiness on a set schedule	Monitoring plan, metric definitions, dated results, reviewer sign-off and alerts tied to the connected components	Monitoring defined on paper but not run, or performed only by the team that adapted the model
Remediation records	Trace a sample of identified model risks (for example, bias, drift or known vulnerabilities) to a documented fix and a re-test	Tickets or change records, risk register entries, re-test results and approvals for each treated risk	Risks logged with no owner, fixes applied without re-testing, or open items past their stated review date
Decommissioning decisions	Check that the organization defined risk tolerances for pre-trained models and that out-of-tolerance models were removed or retrained	Written risk tolerance criteria, decision records for retired models and evidence the replacement was tested	No tolerance defined, or models kept in production after results exceeded the agreed limits
Third-party model documentation	Confirm that vendor or upstream model documentation is collected and reviewed before adoption and after each version change	Vendor documentation on file, version change notices and review records	Upstream model updates adopted silently, with no record of the version actually running

How to implement MANAGE 3.2 step by step

The sequence turns MANAGE 3.2 from a principle into a working loop: each pre-trained model is inventoried with its provenance, measured against agreed tolerances, watched independently, fixed or retired, and tracked until the record is closed.

Inventory every pre-trained model in use
The AI system owner and the platform team list each pre-trained model that feeds development, including its source, version, license and adaptation method, such as fine-tuning or retrieval-augmented generation. Connected components, such as embedding models, tokenizers and third-party libraries that load model weights, are recorded alongside it. The output is a model entry in the AI inventory linked to the systems that depend on it. The step is done when every model in a development pipeline has an owner and an inventory record, and the team can show the record for a sample model on request.
Agree monitoring metrics and tolerances
The owning team, with risk and business stakeholders, selects the metrics that show whether each model still performs and behaves as expected for its use, such as accuracy on a reference set, bias indicators, toxicity or hallucination rates and drift in outputs. For each metric the team records a tolerance and the action that follows when it is exceeded. The output is a monitoring specification approved by the accountable owner. The step is done when every metric has a threshold, a named owner and a documented response.
Set up independent and continual monitoring
Monitoring runs on a schedule that does not depend only on the team that built the model. Independent testers or a separate platform function execute the tests, using tools such as garak for language model probes, and capture results in logs. Application traces, for example from Langfuse, can record inputs, outputs and token usage for production calls. Dependency scanners such as Dependency-Track and Trivy track known vulnerabilities and license changes in model-related components. The output is a dated log of test runs and alerts. The step is done when a run has produced a result that someone other than the builder has reviewed.
Route findings into remediation
Each alert or failed test is triaged against the tolerances set earlier and assigned to an owner. The owner decides whether to adjust prompts or filters, add a documented control, fine-tune, switch to another model version, or accept the residual risk with sign-off from the accountable executive. The fix and its reasoning are written into the model record. The output is a finding ticket with a recorded decision and evidence that the fix was retested. The step is done when every open finding has a decision and a verified outcome.
Define decommissioning triggers and retraining options
The team writes the conditions under which a pre-trained model is removed from use, such as performance that stays outside tolerance after remediation, a newly disclosed vulnerability without a vendor fix, or a license that no longer permits the use. For each model it also records the retraining or replacement path, including which candidate models are approved and how their adaptation would be documented. The output is a decommissioning procedure per model and a list of approved alternatives. The step is done when each model has written triggers and a named fallback.
Execute and record decommissioning
When a trigger fires, the owner removes the model from production and from development pipelines that still reference it, then confirms that dependent systems no longer call it. Archived weights, configuration and test results are retained according to the organization's record policy. The output is a decommissioning record that links the trigger, the decision, the approver and the date of removal. The step is done when the inventory shows the model as retired and a check confirms no active workload still uses it.
Review the monitoring cycle and update the inventory
At a regular interval set by the organization, the team reviews the monitoring results, the number of findings, the retirements and whether the tolerances still match the system's risk. Changes to metrics, tools or owners are approved and reflected in the inventory and monitoring specification. The output is a review record that feeds back into step one. The step is done when the review has been signed off and the inventory and specification show the current state.

Which evidence passes for pre-trained model monitoring

MANAGE 3.2 asks whether pre-trained models used in development are monitored as part of regular AI system monitoring. An assessor will trace each model from the inventory through its monitoring, its component reports, its tests, its fixes and its retirement. The cards below describe the six artifacts that usually carry that trail, what an assessor looks for in each, and how to keep it current between reviews.

AI inventory entries for pre-trained models

Each pre-trained model used in development needs its own inventory record, separate from the application that uses it. The record should name the model and its version, the source and license, the team that owns it, the systems that depend on it, and any fine-tuning or retrieval-augmented generation applied to it. An assessor checks that the inventory matches what runs in production, not what was approved at launch. Review the entries at each model update, and add a field for the date of the last independent check so gaps are visible.

Monitoring plans and logs

The monitoring plan states which performance and trustworthiness signals are tracked for each model, how often, and who reviews them. The logs show those checks actually happened, with timestamps, results and follow-up actions. Tracing tools such as Langfuse can capture inputs, outputs, token usage and tool calls for LLM applications, which helps show behavior over time. Confirm the log retention period with your own policy and with the auditor before the review, because gaps in logs are a common finding.

Dependency and component reports

Software bills of materials and vulnerability records show what a model's serving stack and surrounding components contain, and whether any component carries a known vulnerability, is outdated, or carries license risk. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX and tracks license use by SPDX identifier. Trivy can generate SBOMs and scan existing ones. An assessor will ask whether these reports cover the connected components of the model, not only the application code, and whether findings reach an owner.

Adversarial and behavioral test results

Independent testing shows whether a pre-trained model still behaves within its defined limits. For language models, garak probes for hallucination, data leakage, prompt injection, toxicity and jailbreaks, and writes a JSONL report of every attempt plus a hit log of attempts that found a vulnerability. An assessor looks for the test scope, the date, the model version tested, who ran the tests, and what was done with each hit. Ask whether the tests are run by a team independent of the model developers.

Remediation tickets

When monitoring finds a risk introduced by a pre-trained model or its connected components, a ticket should record the finding, the risk owner, the fix or compensating control, the verification step and the closure date. NIST's MANAGE 3.2 guidance calls for remediation of risks these models introduce. Assessors sample tickets to see whether findings from SBOM reviews, test hits and monitoring alerts reach a documented outcome. Link each ticket to the inventory entry it concerns so the trail can be followed in both directions.

Decommissioning decisions

A decommissioning record documents the decision to retire or retrain a pre-trained model that performs outside its risk tolerance, along with the date, the approver, the replacement model if any, and the steps taken to remove it from production and the inventory. The NIST AI 600-1 generative AI actions for MANAGE 3.2 specifically call for decommissioning or retraining models that perform outside defined limits. Assessors check that the decision followed the stated thresholds and that the inventory was updated afterward, which is easy to skip.

What meeting MANAGE 3.2 costs in money and effort

This table compares the main cost components of monitoring pre-trained models under MANAGE 3.2, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for requesting a written quote, since no fixed figures for this outcome are published and effort depends on how many models your organization uses.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring if commercial, one-time setup	Number of models and components tracked, and whether SBOM, vulnerability and license analysis run as a commercial service	Use Apache-2.0 or MIT tools such as OWASP Dependency-Track, Trivy, garak and Langfuse, self-hosted in your own environment, and confirm each tool's license terms before adoption
Engineering time to build the inventory	One-time, then recurring upkeep	Count of pre-trained models, how many are fine-tuned or wrapped in retrieval pipelines, and how many teams build on them	Start from a single inventory register with required fields for source, version, license and adaptation method, and assign one owner per model
Engineering time to build independent monitoring	One-time build, recurring operation	Number of performance and trustworthiness signals per model, alerting logic, and integration with existing observability	Reuse existing monitoring pipelines and prioritize models that feed high-impact systems first
Remediation and decommissioning work	Recurring, driven by events	Frequency of vulnerabilities, license changes or drift, and the number of systems that depend on a model being retired	Document decommissioning criteria tied to your risk tolerances before a model is deployed, so retirement decisions follow a set procedure
Evidence upkeep	Recurring	Frequency of model updates, retention periods for logs and reports, and how many teams produce separate records	Generate monitoring reports and garak or trace logs automatically and store them in one evidence repository
External testing or review	Recurring or per engagement	Scope of third-party model testing, the number of models in scope and whether testing covers adversarial behavior	Agree the scope in writing before work starts and test the highest-risk models first, then extend coverage
Auditor sampling	Per assessment cycle	Number of models and monitoring records the assessor selects for testing, and gaps found in earlier cycles	Keep the inventory current and link each model to its monitoring records so samples can be pulled quickly

Which open-source tools produce MANAGE 3.2 evidence

MANAGE 3.2 asks for evidence that pre-trained models are tracked, watched and retired on schedule. The four tools below each generate a different slice of that evidence: component inventories, vulnerability and license findings, model probe results and runtime traces. They support the record, but the organization still decides what is acceptable and when a model must be remediated or decommissioned.

Component inventory and risk tracking

OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX documents, so it can hold the inventory of pre-trained models and the libraries around them as one tracked set. It flags components with known vulnerabilities, outdated or modified versions, and license risk, using SPDX license IDs. For MANAGE 3.2, check that the model artifacts are registered as components, that modified or fine-tuned variants are recorded as distinct entries, and that each finding has a documented owner and disposition.

Vulnerability scanning of model dependencies

Trivy identifies OS packages and software dependencies in a target and can produce them as a software bill of materials. It can also scan an existing SBOM, which lets teams check the serving images, inference runtimes and supporting libraries that wrap a pre-trained model. Confirm that scans run against the deployed image rather than a development copy, that the scan date and target are retained, and that findings feed the remediation record for the model.

Adversarial probing of language models

garak 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. Those two files give assessors a repeatable record of monitoring results over time. Confirm which probes match the model's intended use, rerun them after each upgrade or fine-tune, and decide in advance what hit rate triggers remediation.

Runtime traces of model behavior

Langfuse captures each trace as a set of operations within a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. These traces show how a pre-trained model behaves in production, which supports the regular monitoring MANAGE 3.2 describes. Check that traces are retained long enough to investigate incidents, that personal data in inputs and outputs is handled under the organization's privacy rules, and that alerts link back to the model version in the inventory.

Who does what for MANAGE 3.2: your team, a partner and the auditor

Your organization owns MANAGE 3.2. The NIST AI RMF is voluntary and has no certification, so no outside party makes the decisions for you. Your team decides which pre-trained models count as in scope, what performance and trustworthiness thresholds apply, how identified risks are remediated, and when a model is withdrawn from use. These decisions should trace back to the risk tolerances set under GOVERN 1 and MANAGE 1.

Inventory ownership: Named owners maintain the AI inventory entries for every pre-trained model, including the version, source, license and the systems that depend on it.
Tolerance setting: Leadership sets the thresholds that define when a model performs outside acceptable limits, and records who approved them.
Remediation decisions: Owners decide whether to patch, fine-tune, replace, add controls or accept a residual risk, and document the reasoning.
Decommissioning authority: A named role has the authority to retire a model that exceeds tolerance, with a documented path for dependent systems.
Oversight of the partner: Your team reviews partner deliverables and signs off on the runbooks that govern alerts and escalations.

Check that each of these decisions has a named owner and a dated record, because an assessor will ask who made each call and when.

Where organizations fall short on pre-trained model monitoring

Most gaps in pre-trained model monitoring come from a model that was never recorded, watched or retired on purpose. The cards below cover the points where MANAGE 3.2 usually breaks down, from the inventory through monitoring, remediation and decommissioning.

Models missing from the inventory

Pre-trained models often arrive inside a vendor SDK, a managed API client or a bundled library, so the development team never registers them as models. MANAGE 3.2 starts with identifying these models in the AI inventory. Check your dependency manifests and build outputs for model artifacts and model endpoints, and record each one with its source, version and the systems that call it.

Monitoring that stops at the application

Teams often watch uptime, latency and error rates for the application but not the model's behavior. The Playbook suggests independently and continually monitoring the performance and trustworthiness of the pre-trained model and the components connected to it, such as retrieval stores, filters and tools. Ask who measures model output quality, and whether that measurement runs outside the team that built the feature.

No risk tolerance for decommissioning

A monitoring dashboard does not trigger action unless someone has defined what unacceptable performance looks like. MANAGE 3.2 calls for decommissioning pre-trained models that exceed risk tolerances, so the tolerance must be written down before a model is deployed. Confirm that each model has measurable thresholds, a named owner who can act on them and a documented path to retire or replace the model.

Components with no version tracking

A model's risk changes when its weights, fine-tuning data, adapters or retrieval sources change, even if the vendor's model name stays the same. Without a bill of materials for these pieces, a vulnerability disclosure or license change cannot be traced to the systems it affects. Ask for a machine-readable component list per model and a process that re-checks it on each update.

Remediation that never updates the inventory

Teams often patch a prompt, swap a model version or add a filter, then leave the inventory unchanged. The record then describes a system that no longer exists, and the next assessor cannot tell which model made which decision. Each remediation should update the inventory entry, the risk record and the monitoring thresholds, with a dated note of what changed and why.

Questions buyers ask about MANAGE 3.2 cost, effort and outsourcing

Can we meet MANAGE 3.2 in-house without an outside partner?

Yes, in principle. MANAGE 3.2 is an outcome in the voluntary NIST AI RMF, and the organization owns its own AI risk program, so nothing in the framework requires an outside firm. The work is an inventory of pre-trained models, independent and continuing monitoring of their performance and trustworthiness, remediation of risks they introduce, and decommissioning of models that exceed risk tolerances. Teams that already run software asset management, vulnerability management and model evaluation can often extend those processes. Teams without those capabilities usually find the gap is in tooling and in the time needed to build repeatable evidence, not in the framework itself. The NIST AI RMF Playbook is the main reference for suggested actions and documentation prompts.

How much effort does MANAGE 3.2 take for our number of models?

Effort scales mainly with the number of pre-trained models in use, how many connected components each one depends on, and how often those models are updated by their providers. A single model used in one internal tool is a small job. Many models across several products, each with fine-tuning, retrieval pipelines, content filters and third-party APIs, is a much larger one, because each connected component needs its own monitoring and remediation path. Ask the team to count models and dependencies first. That count sets the monitoring scope, the number of evaluation suites and the volume of records the process must keep.

Can a consultant certify that we comply with MANAGE 3.2?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. A consultant can help design the monitoring process, prepare the inventory and assemble evidence, but only an organization can claim alignment with the framework, and the claim should be stated in its own words. If a customer or regulator asks for independent proof, the answer depends on the specific contract or law, which may point to a different standard such as ISO/IEC 42001, where an accredited certification body issues the certificate. Confirm the exact requirement in writing before you buy any service.

What do our engineers and control owners need to provide?

The work needs named owners on both the engineering and risk sides. Engineers provide the model inventory entries, version history, fine-tuning or retrieval details, evaluation results, logging access and deployment records. Control owners set risk tolerances, decide what counts as a model outside limits, and approve decommissioning. Procurement or vendor management tracks the provider's release notes and contract terms for model changes. Expect some recurring time from each group, because monitoring is continuous rather than a one-time review. Confirm who signs off on each step before the work starts so decisions do not stall.

How long does it take to set up MANAGE 3.2 monitoring?

The duration depends on how many models exist, how much of the inventory already exists, whether monitoring tools are in place, and how quickly risk tolerances can be agreed. Organizations with an up-to-date inventory and clear ownership move faster than those starting from scratch, where discovery of undocumented models often takes the most time. The initial build is usually followed by a recurring operating cycle that never really ends, so plan for ongoing staffing rather than a fixed project end. Ask any provider for a timeline tied to a written scope with milestones, and check what each milestone delivers.

What should we ask for in a quote for MANAGE 3.2 work?

Ask for a written scope that names the systems and models covered, the number of connected components, the monitoring and evaluation methods, the tooling to be deployed and the evidence the work will produce. Request the deliverables by name, such as the model inventory, monitoring procedures, remediation and decommissioning runbooks, and documentation templates. Confirm what is one-time setup and what recurs, including monitoring operation, tool licensing, updates and retesting. State who is responsible for each control, and what the provider will not do, such as issuing any certificate or attestation. DeployOpen provides quotes from a written scope and does not publish a price list.

Which open-source tools can support pre-trained model monitoring?

Several open-source tools cover parts of the work, though none covers the whole outcome alone. OWASP Dependency-Track, licensed under Apache-2.0, consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk. Trivy, also Apache-2.0, can produce a software bill of materials and scan existing SBOMs. garak, Apache-2.0, probes language models for hallucination, data leakage, prompt injection and jailbreaks and writes JSONL reports. Langfuse, MIT-licensed, records traces of LLM calls, retrieval steps and token usage. Confirm each tool's current capabilities and fit with your environment before relying on it for evidence.

How DeployOpen prepares MANAGE 3.2 monitoring and evidence

DeployOpen helps organizations set up the systems and records that MANAGE 3.2 Monitoring pre-trained models calls for, inside the client's own infrastructure. We prepare the inventory, monitoring, open-source tooling and evidence, while the organization keeps ownership of its AI risk decisions and any independent review stays with the client's chosen assessor.

How we scope

Agree in writing which pre-trained models, AI systems and environments fall within the monitoring scope before work starts
Confirm the AI inventory fields that record each pre-trained model, its source, version and connected components
Define the performance, trustworthiness and risk tolerance thresholds that will trigger remediation or decommissioning
Agree deliverables, timelines and responsibilities in a fixed-scope document, with ongoing support available as a retainer

How we build

Connect model and component inventories to a self-hosted SBOM and vulnerability tracker such as OWASP Dependency-Track
Configure scheduled scanning of model dependencies and container images with tools such as Trivy
Set up recurring adversarial and behavioral testing of language models with garak and record results in JSONL reports
Instrument production AI calls with Langfuse tracing so monitoring data stays in the client's environment

How we hand over

Deliver a documented procedure for reviewing monitoring output, opening remediation items and recording decisions
Provide a decommissioning runbook that shows how a model is retired, retrained or replaced when it exceeds tolerance
Hand over configuration files, dashboards and evidence exports so the client's own staff can run the process
Map each delivered artifact to the MANAGE 3.2 suggested actions the client chooses to address

How we support

Review monitoring findings with the client's AI risk owner at the cadence set in the written scope
Update tooling, inventories and runbooks when pre-trained models are replaced or the framework guidance is revised
Offer continuous testing and tooling upgrades under a retainer, with scope confirmed in writing
Coordinate evidence packages for the independent assessor the client selects, without issuing any attestation ourselves