What MANAGE 3.1 asks you to do with third-party AI
MANAGE 3.1 expects you to monitor the AI risks and benefits from third-party resources regularly, and to apply and document the risk controls that follow from that monitoring. If your organization uses vendor models, APIs or AI features embedded in other products, this subcategory is where an assessor will look for proof that you are still watching those systems after the contract was signed. MANAGE 3.1 sits in MANAGE 3, third-party AI risks and benefits, within the Manage function of the AI RMF Core in NIST AI 100-1. The framework is voluntary. NIST does not certify organizations against it, and no independent body issues an AI RMF certificate. What you can show is an operating program with records, which an auditor or customer may then review under their own process. The work is hard for three reasons. Vendors change models, prompts, safety filters and hosting regions without notice, so a system that passed testing last quarter may behave differently today. Vendor documentation is often thin or marketed rather than technical, which leaves gaps in what you know about training data and known limits. Proprietary algorithms also restrict how much you can test, so your evaluation has to work with the access the vendor allows. The Playbook suggests establishing TEVV for third-party systems that respects these proprietary limits, which means agreeing test access and evidence formats in the contract before go-live.
In practice, the decisions that matter are these. Set a monitoring cadence for each third-party AI system, assign an owner who receives vendor change notices, and record the organizational risk tolerance that triggers review or decommissioning. Keep vendor documentation on file and check it against what the system does in your environment. Let the vendor report vulnerabilities and biases through a defined channel, and decide in advance what happens if a system exceeds tolerance. Confirm with each vendor which change notification terms, audit rights and test access they will commit to in writing, because those terms determine what evidence you can actually produce.
Which third-party AI systems fall under MANAGE 3.1
MANAGE 3.1 applies to any AI capability your organization gets from outside its own walls, but the work differs sharply by how the capability arrives. The cards below separate the scoping decisions that change monitoring effort, from a SaaS feature switched on by a vendor to a dataset that shapes a model you train yourself.
SaaS AI features
An AI feature inside a software product you already license, such as an assistant, summarizer or scoring module, is in scope once it processes your data or influences your decisions. The key check is whether the vendor enabled the feature by default or in a later release, because that changes when your risk tolerance applies. Confirm which model providers sit behind the feature, whether your data is used for training, and how the vendor notifies you of material changes to the feature.
Hosted model APIs
A model served through a provider's API is in scope whenever your application sends it prompts, records or documents. Monitoring focuses on the provider's model versions, deprecation notices and changes to data retention terms, which can shift without any change to your code. Decide whether you pin a specific model version or accept upgrades, since that decision sets how often you re-test outputs against your documented risk tolerance.
Embedded vendor components
Libraries, classifiers or inference engines bundled into your own systems come from third parties even when no contract names them as AI. Dependency inventories, such as a CycloneDX SBOM, are the evidence that shows which components exist and which versions are running. Dependency-Track can track vulnerable or outdated components and license risk against that inventory, so a component you did not select directly still falls within your monitoring.
Third-party datasets
Training, fine-tuning, evaluation and retrieval corpora obtained from outside vendors or data brokers are in scope because their defects propagate into outputs. The decisions that change effort are whether you can document provenance, whether licenses permit your use, and whether the vendor allows independent validation. Generative AI actions in NIST AI 600-1 point to data poisoning and value chain risks as areas to test, so ask for collection methods and change logs before ingestion.
Outsourced AI services
Work performed for you by a contractor, such as model tuning, labeling, or an AI-driven decision service run by a managed provider, is in scope because the contractor operates the system on your behalf. The contract determines who performs TEVV, who can share vulnerability reports and who must decommission the system when it exceeds your tolerance. Confirm these rights before signing, because they are hard to add later.
Pre-trained models in development
Open or commercial pre-trained models that your team downloads and adapts are a separate scoping question with their own monitoring track. MANAGE 3.2 covers pre-trained model monitoring, including inventory, independent monitoring, remediation and decommissioning, so this card only marks the boundary. Decide early which team owns each third-party model so that MANAGE 3.1 and MANAGE 3.2 records do not overlap or go unowned.
How an assessor tests monitoring of third-party AI
This table compares five areas an assessor is likely to test under MANAGE 3.1, what each test looks for, the evidence the organization should have ready and the gaps that come up most often. Because NIST AI RMF is voluntary and has no certification, the assessor works from the organization's own risk tolerance, and the result is an internal or independent assessment report rather than a certificate.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Vendor inventory against live usage | Compare the register of third-party AI systems and models with production logs, API keys, procurement records and staff tool use. Evidence: current inventory with owner, purpose, risk tier and last review date. | Shadow AI tools missing from the register, or retired vendors still listed as active. |
| Vendor documentation and model or system cards | Sample third-party systems and check that vendor documentation (system cards, model cards, data and usage terms, change notices) is on file and was reviewed against the organization's intended use. Evidence: dated review records and documented gaps. | Documentation collected at procurement but never re-reviewed after vendor version changes. |
| TEVV results for third-party systems | Ask for the testing, evaluation, verification and validation the organization ran on each third-party system, including how testing respected vendor proprietary algorithms. Evidence: test plans, results, acceptance criteria and sign-off tied to the risk tolerance. | Acceptance based only on vendor claims, or no re-testing after a model update. |
| Vulnerability and bias intake from third parties | Confirm a channel exists for vendors and third parties to report vulnerabilities and biases, and trace a sample of reports to triage, remediation and closure. Evidence: intake procedure, ticket records and vendor notifications. | No defined intake route, or reports received by email and never logged or tracked. |
| Decommissioning decisions beyond tolerance | Select systems where monitoring showed risk above the stated tolerance and check for a documented decision to restrict, replace or retire them, with dates and approvers. Evidence: decision records, decommissioning plans and evidence that data and access were removed. | Threshold breaches recorded but no decision made, or access left active after a system was withdrawn. |
Implementing third-party AI monitoring step by step
This sequence turns MANAGE 3.1 into a working routine: it sets the risk tolerance that decides what counts as a problem, inventories every third-party AI dependency, collects the documentation needed to test them, and then runs monitoring, vulnerability intake and decommissioning decisions on a schedule the organization can defend. Each step closes with a named artifact that an assessor or internal reviewer can inspect.
Confirm risk tolerance for third-party AI
Start by confirming the organizational risk tolerance that applies to AI systems, and whether third-party AI needs its own thresholds. Governance and risk owners agree the tolerance levels, the impacts that breach them, and who may accept residual risk. The output is a short, approved tolerance statement that every later step references. You know the step is done when a reviewer can point to a threshold and explain what happens when a third-party system crosses it. Confirm with your risk function whether an existing enterprise risk appetite already covers AI or needs an extension.
Build and maintain the third-party AI inventory
List every AI system, model, API, embedded feature and dataset that comes from an outside party, along with the internal owner, the business use, the data it touches and the contract that governs it. Procurement, engineering and business units all have to contribute, because shadow tools often surface outside IT. The output is a register with one row per third-party dependency and a named owner for each. It is complete when a spot check of recent purchases and API keys finds no unregistered service. Schedule the register for review whenever a new vendor is onboarded or an existing one changes its model.
Collect vendor documentation
For each inventory entry, request the documentation the vendor provides about the system: intended use, known limitations, evaluation results, data handling, security attestations, change notices and, for generative models, system or model cards. Record what was received, what was refused and what is missing. The output is a documentation file per vendor with a gap list that the owner must resolve or accept. Ask vendors to confirm which documents are current, because a card from an earlier model version does not describe the system you run.
Set TEVV and monitoring cadence
Decide how each third-party system will be tested, validated and verified, and how often. Where the vendor restricts access to proprietary algorithms, agree on test methods that work through the interface, such as scenario testing with your own data or review of vendor evaluation reports. Set the monitoring signals, such as output quality checks, drift indicators, incident feeds and vendor release notes, and the review frequency for each. The output is a monitoring plan per system. Check that the plan names the person who reviews each signal and the record each review produces.
Route vendor and third-party vulnerability reports
Define one intake path for vulnerability and bias reports about third-party AI, whether they come from vendors, from internal staff, from users or from security testing. Triage each report against the risk tolerance, assign an owner, and track it to a documented outcome. Testing tools can feed this path: a dependency analysis tool can flag known vulnerable components in a model serving stack, and a language model probe can flag jailbreaks or data leakage. The output is a triage log with a disposition for every report. Confirm that the vendor contract obliges timely notice of vulnerabilities.
Define decommissioning triggers
Write the conditions under which a third-party AI system must be restricted, suspended or removed. Typical triggers include monitoring results beyond tolerance, an unresolved high-priority vulnerability, a vendor withdrawing support or changing terms, or a documentation gap that cannot be closed. Each trigger names who can invoke it and the fallback process, such as a non-AI alternative or manual procedure. The output is a decommissioning procedure attached to each high-impact system. It is complete when the team can state, for a given system, what happens on day one of a trigger without further discussion.
Record decisions and close the loop
Record each monitoring outcome, triage decision, tolerance exception, acceptance of residual risk and decommissioning call with the date, the decision maker and the evidence reviewed. Feed these records back into the inventory and the monitoring plan so that the next cycle starts from current facts. The output is a decision log that an internal auditor or external assessor can trace from a finding back to the signal that raised it. Review the log periodically to confirm that decisions follow the tolerance statement, and that accepted risks have an owner and an expiry.
Evidence that passes MANAGE 3.1 and how to keep it current
MANAGE 3.1 is tested through records, not declarations: an assessor looks for dated, owned evidence that third-party AI risks were monitored and that controls were applied and written down. The six artifacts below connect inventory, vendor documentation, testing, reported issues, monitoring rhythm and retirement decisions, so each one should be traceable to the others.
Third-party AI inventory
This is the register of every AI system, model, API and dataset supplied by an outside party, with the business owner, the vendor, the version in use and the systems that depend on it. An assessor checks whether the inventory is complete by sampling production systems and tracing them back to an entry. Refresh it at each change request and at a fixed review date, and record who approved each change and when. Confirm that the inventory covers embedded AI features inside software the organization already licenses.
Vendor documentation register
This register lists the documents each third party provided, such as model cards, system cards, data handling statements, security attestations and terms covering training data reuse, along with the version and date received. Assessors look for evidence that someone read these documents and recorded what they meant for the organization's risk tolerance. Refresh the register when a vendor publishes a new version, and flag any document that has passed the date the vendor committed to updating it.
TEVV reports for third-party systems
Testing, evaluation, verification and validation reports show what the organization ran against a third-party system, including tests on outputs, data leakage and vulnerability scans. Where the vendor restricts access to proprietary algorithms, assessors accept testing designed around that limit, but they expect the limit itself to be documented. Refresh these reports after every model update, fine-tuning change or retrieval source change, and keep the test inputs and results with the date and tester name.
Vulnerability and bias reports from third parties
These are the notices, tickets and reports that vendors or downstream users sent about vulnerabilities, biased outputs or harmful behavior, together with the triage decision and the fix or workaround applied. Assessors trace each report to a documented response and check the response time against the internal standard. Confirm that a reporting channel exists for third parties and that intake from it is logged. Refresh the log at each monitoring review and close entries only with a recorded owner.
Monitoring cadence records
These records prove that third-party AI was monitored on the schedule the organization set, covering dated review meetings, automated checks, metric reviews and sign-off by the named owner. Assessors compare the planned cadence in the policy with the actual dates and look for gaps. Refresh the records by keeping each review's agenda, findings and follow-up actions, and note any missed review along with the reason and the catch-up date.
Decommissioning decisions
A decommissioning decision records that a third-party system was retired or replaced because it exceeded the organization's risk tolerance, or because the vendor could no longer meet the documented controls. The record should name the trigger, the approver, the replacement or fallback, and the date data access and credentials were revoked. Assessors check that retired systems no longer appear in production and that the inventory was updated. Refresh these decisions as they occur and review open exit plans at each monitoring cycle.
What meeting MANAGE 3.1 costs in money and effort
This table lists the main cost components of monitoring third-party AI under MANAGE 3.1, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to frame a quote request, since most of the cost sits in staff time rather than software licenses.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendors for commercial tools; no license fee for Apache-2.0 or AGPL-3.0 options, though hosting still applies | Usually recurring (subscriptions) or one-time (perpetual), depending on vendor | Number of third-party AI systems tracked and whether SBOM, vulnerability and model-scanning tools are commercial or open source |
| Engineering time to build monitoring | Internal platform or security engineers, or an implementation partner under a written fixed scope | One-time, with some later rework | Number of integrations with vendor documentation, model registries and ticketing; how much custom reporting is required |
| Staff time to run open-source tools | Internal staff who operate Dependency-Track, Trivy or garak in your own environment | Recurring | Frequency of scans, number of components per system and how much triage each finding needs |
| Evidence upkeep | Internal risk, compliance and engineering staff who keep third-party documentation, risk tolerance records and decommissioning decisions current | Recurring | Vendor change frequency, number of model or version updates, and how often risk tolerance is reviewed |
| TEVV of third-party systems | Internal testers, vendors (where contracts allow) or external testing specialists | Recurring for each test cycle, one-time for initial baseline | Depth of TEVV, whether proprietary algorithms limit access, and whether generative AI value chain testing is in scope |
| External testing or review | Independent security testers or assessors engaged for specific systems | Recurring or episodic | Criticality of the third-party system, scope of red teaming and whether results must be shared with regulators or customers |
| Auditor sampling | Independent auditors or assessors who sample evidence; DeployOpen does not issue audit reports or certifications | Recurring with each assessment cycle | Number of third-party AI systems sampled, quality of evidence and how well records are organized before fieldwork |
| Vendor and contract administration | Procurement, legal and vendor management teams | One-time for contract terms, recurring for reviews | Vendor change frequency, contract clauses for documentation and vulnerability reporting, and number of suppliers |
Open-source tools that produce third-party AI evidence
MANAGE 3.1 expects third-party AI risks to be monitored and controls documented, which means producing records over time. The four tools below each generate a different kind of record: assessment evidence, component inventories and vulnerability findings, software bill of materials, and model probing results. None of them decides whether a vendor is acceptable, and each should be confirmed against your own environment before you rely on it.
Running assessments across frameworks
CISO Assistant (AGPL-3.0-only) is a governance, risk and compliance platform that ships more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2 and DORA, and runs audits and compliance assessments against them. For MANAGE 3.1 it can hold the third-party AI risk register, record vendor documentation reviews and link each finding to the controls it affects. The AGPL-3.0-only license requires attention if you modify and expose the software to users over a network. Confirm the framework content you need and how it maps to your own control set.
Component inventory and vulnerability tracking
OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified versions, and tracks license risk using SPDX license IDs. For third-party AI, this produces dated evidence that a vendor's components were reviewed and that known issues were tracked to a decision. Confirm that your vendors can supply CycloneDX SBOMs and VEX documents, since the quality of the output depends on the input.
Generating and scanning software bills of materials
Trivy (Apache-2.0) identifies OS packages and software dependencies in a target, can produce them as a software bill of materials, and can scan an existing SBOM. It helps you build the component record for systems you host, and it can check an SBOM a vendor supplies against current vulnerability data. Trivy covers software dependencies, not model weights or training data, so model-level evidence needs other records. Confirm which target types and SBOM formats your pipeline needs before adopting it.
Probing language models and logging results
garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Those files can serve as third-party TEVV evidence when a vendor model is re-tested after a change or fine-tuning, provided the test scope and prompts are documented. Results depend on the probes chosen, so confirm coverage against the risks your use case creates.
What NIST AI 600-1 adds for generative AI third parties
The Generative AI Profile, NIST AI 600-1 (published July 26, 2024), adds five suggested actions to MANAGE 3.1, numbered MG-3.1-001 to MG-3.1-005, that make third-party monitoring specific to generative AI. Each action is tagged to one or more generative AI risks from the profile's list, including CBRN Information or Capabilities, Data Privacy, Harmful Bias and Homogenization, Information Integrity, Information Security, Intellectual Property and Value Chain and Component Integration. The tags tell you which risk areas an action is meant to cover, so a team that buys a foundation model or API can trace each monitoring activity back to a risk it is meant to address. The profile is a set of suggested actions, not a checklist. Your organization decides which actions apply to its use case, documents why it skipped any, and records the evidence it produced for those it kept.
The value chain actions ask you to test third-party generative AI for risks that enter from upstream components, such as data poisoning, malware and other vulnerabilities in model artifacts, libraries and data sources. In practice, this means the supplier's model and its dependencies belong in your software and data inventories, and their vulnerability status is checked on a schedule rather than only at purchase. A second group of actions asks you to re-assess model risk after the system changes. Fine-tuning a third-party model or adding retrieval-augmented generation can alter its behavior, data exposure and failure modes, so the MANAGE 3.1 risk assessment should be repeated for the modified system, not inherited from the base model's assessment. A third set asks you to review system cards and model cards supplied by the model provider. Confirm which versions of those documents you hold, whether they match the model version you deploy, and what gaps they leave for your intended use.
Before adopting these actions, confirm three things with your legal, procurement and engineering leads: which generative AI third parties are in scope, what contract rights you have to receive updated documentation and vulnerability notices, and whether your provider permits the testing the profile describes. Testing that touches a hosted model may need the provider's agreement on rate limits, acceptable use and reporting. The profile is cross-sectoral, so sector rules may add requirements beyond it. Because NIST has said that AI RMF 1.0 is being revised and has not published the revision, check the current version of AI 600-1 and the Playbook before you cite specific action numbers in a contract or audit file, and record the version you used.
Who does what for third-party AI monitoring
Your organization owns the AI risk decisions that MANAGE 3.1 asks for. Your leadership sets the risk tolerance that third-party AI must stay within, decides which vendor systems are acceptable, and signs off on the controls applied when a system carries risk. The vendor relationship also stays with you, including contract terms, notification duties and the decision to continue, restrict or retire a third-party model.
- Risk tolerance and acceptance: Set the thresholds that define when a third-party system is out of tolerance, and record who may accept residual risk.
- Vendor relationships: Own the contracts, service terms and escalation paths with each AI provider, including how the provider reports vulnerabilities and changes.
- Monitoring decisions: Review monitoring results on a set cadence and decide on remediation, restriction or decommissioning.
- Documentation ownership: Keep vendor documentation, such as model and system information, current and on file.
- Decommissioning authority: Confirm who can stop a third-party system that exceeds tolerance and how dependent workflows will be moved.
Check that each of these duties has a named owner and a written approval path before any partner work begins.
An implementation partner such as DeployOpen prepares the systems, tooling and evidence that your team uses to meet MANAGE 3.1. The work happens inside your infrastructure, and the partner does not make the risk decisions or sign for your organization. Scope, deliverables and timelines are normally fixed in writing before work starts.
- Inventory tooling: Set up a record of third-party AI components, their versions and their owners, so monitoring has a complete list to work from.
- TEVV setup: Build test, evaluation, verification and validation pipelines for third-party systems in a way that respects proprietary algorithms, using open-source scanners and probes where they fit.
- Monitoring pipelines: Connect vulnerability and component data, such as SBOM and VEX feeds, to alerts that reach your team.
- Evidence packs: Assemble logs, test results, reports and decision records into an organized set that an assessor can review.
- What is usually outsourced: Tooling setup, pipeline integration, hardening and recurring test runs are common candidates. Risk acceptance, vendor negotiation and final sign-off usually stay internal.
Ask any partner to show in writing which deliverables it prepares and which decisions remain with your staff.
Only an independent assessor, auditor or certification body issues reports or certificates against a framework. NIST does not certify or validate organizations for the AI RMF, so an assessment of MANAGE 3.1 is a review you commission, not a certificate you receive. Independence means the assessor did not design, build or operate the controls it tests.
- Reports and opinions: Only the independent assessor issues findings, reports or opinions on how your third-party monitoring performs.
- Line on independence: A partner that built the pipelines can explain them to the assessor, but it should not also grade them.
- Sampling and testing: The assessor selects vendors and records to test, then checks that the evidence shows monitoring actually occurred.
- Scope agreement: Confirm with the assessor which framework version, vendor set and period it will test before fieldwork begins.
- Your responsibility: Provide access to people, records and systems, and keep your own decision records clean enough for independent review.
DeployOpen prepares systems and evidence for assessment but does not issue audit reports, attestations or certifications. Confirm the assessor's qualifications and its scope in writing.
Where organizations fall short on MANAGE 3.1
MANAGE 3.1 asks organizations to monitor AI risks and benefits from third-party resources regularly and to apply and document controls. The gaps below recur across programs because each one breaks a link in that chain: knowing what third-party AI is in use, reading what vendors provide, testing what is actually deployed, hearing about problems from outside, and removing systems that fall out of tolerance.
No current third-party AI inventory
Many organizations cannot list which third-party AI systems, models and AI features their teams use, because purchases arrive through business units, SaaS add-ons and embedded APIs. Without that list, monitoring has no scope. The step that closes this gap is an inventory of every third-party AI component with its owner, business purpose, data classes and contract reference, reviewed on a set schedule and whenever procurement or engineering adds a dependency. Ask who is accountable for keeping it current.
Vendor documentation never reviewed again
Vendors often supply model cards, system cards, security attestations and data handling statements during onboarding, then nobody reads them again. Documentation goes stale when a vendor changes its model, training data or subprocessors. The step that closes this gap is a named reviewer for each vendor, a recurring review tied to the vendor's release notes and contract renewal, and a record of what changed and what the organization did about it.
TEVV blocked by proprietary algorithms
Testing, evaluation, verification and validation of a third-party system often stops at the vendor's boundary because the contract gives no access to test artifacts, evaluation results or a sandbox. MANAGE 3.1 expects TEVV that respects proprietary algorithms, so the workable path is a negotiated arrangement that protects the vendor's code while still allowing black-box testing and review of results. Check whether the contract grants this access before go-live, not after an incident.
No intake for third-party vulnerability reports
Vendors, researchers and users may find vulnerabilities or bias in a third-party AI system, yet many organizations have no channel that routes those reports to the people who can act on them. MANAGE 3.1 expects third parties to be able to report vulnerabilities and biases. The step that closes this gap is a published reporting address, an internal triage owner, a response expectation written into the vendor contract, and a log linking each report to the control it changed.
No decommissioning trigger
Teams rarely agree in advance on what makes a third-party AI system unacceptable, so removal happens only after a visible failure. MANAGE 3.1 calls for decommissioning third-party systems that exceed the organization's risk tolerances. The step that closes this gap is a written set of thresholds, drawn from the organization's risk tolerance, that tie monitoring results to a defined action, a fallback process, and an owner with authority to switch the system off.
Questions buyers ask about MANAGE 3.1 cost, effort and outside help
How much effort does MANAGE 3.1 take to meet?
The effort depends on how many third-party AI systems you depend on, how much each one changes, and how much documentation the vendors already provide. MANAGE 3.1 asks for regular monitoring of third-party AI risks and benefits and for controls that are applied and documented. Recurring work includes reviewing vendor documentation when versions change, re-testing third-party systems against your risk tolerance, tracking vulnerability reports and deciding when a system must be decommissioned. The one-time work is building the inventory, agreeing the risk tolerance and setting up the records. Ask any partner to split their estimate into one-time setup and recurring monitoring so you can see which part grows with your vendor count.
Can an in-house team meet MANAGE 3.1 without outside help?
Yes, an in-house team can meet MANAGE 3.1 without an outside partner, because NIST AI RMF is voluntary and no one outside your organization needs to approve the approach. The questions to answer honestly are whether your team has the skills to test third-party models, whether it can read vendor system cards and model cards critically, and whether it has time to run monitoring on a schedule. Many teams find the gaps are in testing and evidence collection rather than in policy. Outside help is most often used to prepare systems and records or to run security testing, while your organization keeps ownership of the risk decisions.
What do third-party AI vendors need to provide for MANAGE 3.1?
Your vendors need to supply enough documentation and access for you to monitor their systems and for you to apply your own controls. The Playbook suggests keeping documentation for third-party systems, letting third parties report vulnerabilities and biases, and building testing that respects proprietary algorithms. In practice, that means asking for technical documentation, the model or system cards that describe the system, a point of contact for vulnerability reports, notice of material changes and clear terms for what testing you may run. Put these obligations in contract terms before you sign, because a vendor that cannot share documentation makes monitoring harder to evidence.
How long does MANAGE 3.1 preparation take?
Preparation time depends on the drivers rather than on a fixed figure, and NIST does not publish a duration for MANAGE 3.1. The main drivers are the number of third-party AI systems in scope, whether an AI inventory already exists, how mature your vendor documentation is, and whether your risk tolerance is already written down. Generative AI services add work because the Generative AI Profile lists actions for value chain risks such as data poisoning and for re-assessing models after fine-tuning or retrieval-augmented generation. Ask for a written timeline that lists the systems in scope and the steps that depend on vendor responses.
Does NIST AI RMF have a certificate I can show a customer?
No, NIST AI RMF has no certificate, accreditation or conformity assessment program. NIST does not validate or endorse any organization's use of the framework, so no vendor can issue a valid AI RMF certificate. When a customer asks for evidence, you can describe how your controls map to the MANAGE 3.1 suggested actions and provide the records behind them. If a customer wants an independent opinion, an assessor can review your approach and evidence, but that opinion is a report on your work and is not a NIST certification. Confirm the exact wording your contract requires before you promise anything.
What should I ask for in a quote for MANAGE 3.1 support?
Ask for a written scope that names the third-party AI systems, the monitoring frequency, the testing methods and the evidence you will receive at the end. A useful quote separates one-time setup from recurring monitoring, states which tasks the partner performs and which stay with your staff, and lists what you must supply, such as vendor contacts and documentation. Ask how changes in scope are priced and how vendor delays affect the timeline. DeployOpen does not publish a price list, and most engagements are fixed-scope, so the quote follows from the written scope and the scope should be agreed in writing before work begins.
Which MANAGE 3.1 tasks can a partner take on?
A partner can usually prepare the technical side of MANAGE 3.1, while your organization keeps ownership of the risk decisions. Tasks that are commonly outsourced include building the software and model inventory, generating a software bill of materials, running vulnerability tracking, and setting up model testing with tools such as garak. DeployOpen can plan, implement and document self-hosted tooling inside your own infrastructure and can run security testing of AI systems and agents. Decisions on risk tolerance, decommissioning and accepting residual risk stay with your leadership. Only an independent auditor or assessor issues reports, so an outside firm can prepare evidence but cannot certify the outcome.
Which open-source tools produce MANAGE 3.1 evidence?
Several open-source tools produce evidence that supports MANAGE 3.1, and each covers a different part of the work. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, identifies components with known vulnerabilities and tracks license use with SPDX IDs. Trivy identifies OS packages and software dependencies and can produce an SBOM or scan an existing one. garak probes language models for issues such as prompt injection and data leakage and writes a JSONL report and a hit log. CISO Assistant can record assessments and map controls across frameworks. Confirm each tool's fit with your environment before relying on it, because tooling supports the evidence but does not replace your documented controls.
How DeployOpen scopes and prepares third-party AI monitoring evidence
DeployOpen helps organizations set up the systems, monitoring routines and documentation that show how third-party AI risks and controls are watched over time under MANAGE 3.1. The organization keeps ownership of its risk tolerances, vendor decisions and accountability, while DeployOpen plans, builds and documents the supporting environment inside the client's own infrastructure.
How we scope
- Agree in writing which third-party AI systems, models and vendor integrations fall within the MANAGE 3.1 scope.
- Confirm with the client which risk tolerance and monitoring thresholds the organization has already documented or will document.
- Define which evidence the client's assessor or auditor will ask for, so deliverables match the assessment plan.
How we build
- Set up a component inventory for third-party AI using SBOM tooling such as Dependency-Track and Trivy in the client's environment.
- Configure scheduled testing of language models with garak, recording JSONL reports and hit logs for each run.
- Build review workflows that route vulnerability reports and vendor documentation changes to named owners.
How we hand over
- Deliver monitoring runbooks, configuration records and evidence folders mapped to the agreed scope.
- Document how decommissioning decisions are triggered when a third-party system exceeds the client's risk tolerance.
- Walk the client's staff through each control so they can produce the evidence themselves after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope engagement.
- Re-run monitoring checks after vendor model updates or material changes, as the written retainer scope allows.
- Ask the client's independent assessor to confirm any assessment outcome, since DeployOpen does not issue reports or certificates.
