GOVERN 6.1 Third-party AI risk policies: evidence and audit

GOVERN 6.1 third-party AI risk policies: what the NIST AI RMF expects

GOVERN 6.1 is a voluntary outcome in the NIST AI RMF that asks for policies and procedures addressing AI risks tied to third-party entities, including the risk of infringing a third party's intellectual property or other rights. There is no AI RMF certification, so no one issues a pass for this outcome. When a customer, contract or regulator asks how third-party AI is governed, the answer is a documented set of policies, the evidence that people follow them, and the records of how vendor systems were checked before and during use. The outcome sits in the Govern function, and the NIST AI RMF Playbook suggests that those policies cover transparency into training data, algorithms and limitations, thorough testing of third-party AI, clear usage instructions, and the legal and ethical issues of procuring third-party software, hardware and data.

The reason this is hard is that third-party AI is often adopted without a single owner. Staff sign up for AI tools on their own (shadow AI), so the organization does not hold a complete list of what runs on its data. Vendors frequently treat their models and training sources as proprietary, which limits what a buyer can learn about data provenance or known limitations. Contract terms are often silent on content ownership, usage rights, output quality, security and provenance, and the procurement file may never have been updated to cover intellectual property, privacy and security risks. A practical first step is to inventory every third-party AI system in use, including embedded features in existing software, and to record for each one what the vendor disclosed, what the contract says, and who approved it. Confirm with your legal and procurement teams which clauses your current templates already contain before drafting new language.

Which third-party AI is in scope for GOVERN 6.1 policies

GOVERN 6.1 applies wherever an outside entity supplies AI, data or software that the organization relies on. The hard part is deciding where that boundary sits, because scope determines which vendors, datasets and contractors the policy must reach. The cards below cover the common cases and the AI actor categories that shape them.

SaaS AI features

A vendor's product may switch on a model-driven feature, such as summarization, scoring or a chat assistant, inside a tool you already license. Treat it as in scope even though no model was purchased separately. Check whether the feature sends your data to a model you do not control, whether the vendor retrains on your inputs, and whether the feature can be disabled per tenant. Ask the vendor to name the underlying model provider.

Embedded models in purchased software

Some products ship with a pre-trained model inside the binary or an appliance, with no visible API. The Playbook's transparency expectations still apply to training data, algorithms and limitations. Ask for model cards or equivalent documentation, the update cadence for the embedded model, and how you would learn of a change in behavior after an update. Record the component in your AI inventory so it is not missed at renewal.

Third-party datasets

Training, fine-tuning or evaluation data bought, licensed or scraped from outside sources creates intellectual property and privacy exposure that GOVERN 6.1 names directly. Scope in any dataset that feeds a model you build, tune or evaluate. Confirm the license terms, permitted uses, provenance and whether the data includes personal information. Ask whether the supplier can show the rights it claims to hold.

Open-weight models

Open-weight models carry no vendor service, but they still come from an entity outside your organization with its own training data and license. Scope them in as third-party AI. Record the model version, the license terms, the source and the checksum of each artifact you deploy. Test the model in your context, because its published evaluations may not match your use case.

API-accessed foundation models

A hosted foundation model reached through an API is third-party AI even when your team writes all the prompts and application logic. Scope in the provider, the model version you call and any subprocessors that handle prompts or outputs. Check retention of inputs, use of data for training, the provider's change notice practice, and whether contract terms cover content ownership and output rights.

Contractors building AI for you

When a contractor designs, trains or delivers an AI component, the organization still owns the policy outcome. Scope the contractor's deliverables, its own subcontractors, the data it touches and the models it hands over. Procurement terms should require disclosure of third-party components and access to test results. Confirm who holds rights to the code, model weights and training data at project close.

How an assessor tests GOVERN 6.1 third-party AI policies

This table compares the steps an assessor takes when testing GOVERN 6.1, what each step looks for, and where programs typically fall short. NIST does not validate or endorse organizations, so the review is run internally or by a customer during due diligence, and the findings are only as strong as the records behind them.

Test step	What the assessor checks	Common finding
Policy existence and approval	A written third-party AI policy exists, names its scope, and shows approval by a accountable executive or governance body with a review date	Policy is a draft, unsigned, or never reviewed since it was written
Scope coverage	The policy covers third-party AI models, AI-enabled SaaS features, training data and pre-trained models, not only traditional software contracts	Policy covers only traditional software and omits embedded AI features in vendor products
Policy owner	A named role owns the policy, approves exceptions, and receives vendor AI risk reports	No owner is named, or ownership sits with procurement alone with no risk function involvement
Procurement trace	Sampled purchase records and onboarding tickets show the policy's transparency, testing and legal checks were applied before contract signature	Vendors onboarded before the policy existed were never re-assessed
Contract terms	Contracts address intellectual property ownership, usage rights, data handling, model change notice and rights to audit or receive documentation	Missing IP clauses, no notice of model changes, and no right to receive testing evidence
Transparency evidence	Vendor documentation covers training data sources, known algorithm limitations and intended usage instructions, as the policy requires	Vendor answers are marketing material or questionnaires left unverified
Testing of third-party AI	Records show the organization tested the vendor system before use, or relied on vendor testing that the policy accepts and the assessor can review	No test record exists for a vendor AI feature in production
Sampling and conclusions	The assessor samples a set of vendors across risk tiers, then records gaps and whether the owner tracks remediation	Gaps are noted but no remediation owner or due date is recorded

How to write and operate third-party AI risk policies

This sequence turns GOVERN 6.1 from an outcome statement into a working policy set. It moves from knowing which third-party AI and data the organization depends on, through tiered risk rules and procurement terms, to a review cycle with recorded outputs that an assessor can trace.

Inventory third-party AI systems and data
Compile a register of every third-party AI system, model, dataset and AI-enabled software service in use, in development or in procurement. Record the vendor, the business owner, the purpose, the data categories involved and whether the vendor trains on your data. Procurement, IT and the teams that use these tools should each confirm their entries. The step is complete when every entry has a named owner and the register is reconciled against purchase records and access logs.
Define third-party AI risk tiers
Set risk tiers for third-party AI using criteria tied to your risk tolerance from GOVERN 1, such as impact on people, sensitivity of data processed, degree of automated decision-making, and how hard the function would be to replace. Governance, security and the business owner approve the tier definitions. The output is a tier rule set plus a tier assigned to each inventory entry, with the reasoning written down for any entry that a reviewer might challenge.
Draft the third-party AI risk policy
Write the policy so that each tier sets minimum expectations for vendor transparency into training data, algorithms and known limitations, for pre-deployment testing of third-party AI, for clear usage instructions for staff, and for review of the legal and ethical issues in procuring third-party software, hardware and data. Legal, privacy, security and the AI governance lead review the draft. The step closes when the policy is approved, names its owner and maps each requirement to the tier it applies to.
Add procurement and contract requirements
Translate the policy into a due diligence checklist and standard contract clauses. Typical clauses address content and data ownership, permitted usage rights, quality and security commitments, provenance expectations for generated content, notice of material model changes, and intellectual property and privacy indemnities where the vendor allows them. Procurement and legal own the clauses; the AI governance lead signs off on exceptions. Confirm each clause with counsel, since enforceability depends on jurisdiction and the vendor's terms. The output is a clause library and a checklist applied before signature.
Test third-party AI before and after adoption
Set the testing requirements for each tier, covering validation of vendor claims in your own context, checks for harmful bias and security weaknesses, and confirmation that usage instructions match actual behavior. Higher tiers receive more testing and independent review. The testing owner records the test plan, results and any accepted residual risk. The step is complete when each in-scope system has a dated test record that the business owner has accepted or escalated.
Set review cycles and monitor changes
Define how often each tier is re-reviewed, and which events trigger an earlier review, such as a vendor model update, a change in the data processed or a new incident. Use the inventory from the first step as the baseline. Assign an owner for watching vendor notices and for re-running due diligence. Ask vendors to confirm their change-notice commitments in the contract. The output is a review calendar and a change log that shows when each third-party AI system was last reviewed and why.
Record outputs as versioned evidence
Keep each output of the sequence (inventory, tier rules, policy versions, clause library, checklists, test records and review logs) in a version-controlled repository with named approvers and dates. Software bills of materials and dependency scans can be attached to the relevant system entries where they exist. An internal audit or external assessor should be able to trace any control statement to the record that supports it. The step is complete when a reviewer can pick any inventory entry and follow it through tier, contract, test and review records.

Which contract terms and due diligence questions GOVERN 6.1 leads to

GOVERN 6.1 asks for policies that address AI risks from third-party entities, and the NIST AI 600-1 Generative AI Profile makes that concrete in two suggested actions, GV-6.1-004 and GV-6.1-009. The first points to contracts and service level agreements that state who owns generated content, what usage rights the buyer holds, and what quality, security and content provenance the vendor commits to. The second points to procurement due diligence that covers intellectual property, privacy and security risks before a vendor is selected. For a team buying a generative AI product or model, the policy should name these terms as required fields in every procurement, so that a contract cannot be signed with the topic left open.

The due diligence questions follow from the same risks. Ask the vendor where its training data came from, whether it holds the rights to use that data for training, whether customer inputs and outputs are used to train future models, and how it documents data provenance. Ask for the known limitations of the model, the conditions under which its outputs are unreliable, and the testing it has performed on those conditions. Ask how the vendor handles third-party intellectual property claims and what indemnity it offers. Answers should be written into the contract or an attached document, not given verbally. The vendor's written answers are evidence that the policy was applied, which is what an assessor will look for.

Legal review of these terms belongs to counsel, not to the compliance or engineering team. The policy should assign that review to the legal function and define what the procurement team must hand over, such as the vendor's data terms, model documentation and security attestations. Confirm with counsel which jurisdiction's rules apply to your data and your customers, because the requirements for training data and personal information vary by location. Keep the signed terms, the due diligence responses and the counsel sign-off together in one record, so that the evidence for GOVERN 6.1 can be produced when a customer, auditor or regulator asks for it.

Evidence that shows a third-party AI risk policy is working

A third-party AI risk policy only counts as working when its outputs can be found, dated and traced to decisions. The artifacts below connect the written policy to the vendors in use, the contracts that bind them and the tests run before go-live. Each one needs an owner and a refresh trigger, so the record stays accurate between scheduled policy reviews.

Approved policy with version history

The third-party AI policy itself, with an approver, an effective date and a change log showing what changed and why. Version control matters because an assessor will ask which version governed a given procurement. Keep superseded versions available, not just the current one. Between reviews, log every amendment the day it is approved, and check that the policy still names the current NIST AI RMF version and any regulation it cites.

Third-party AI inventory

A register of every external AI system, model, API and dataset the organization uses, with the business owner, the data classes involved and the risk tier assigned. GOVERN 6.1 cannot be applied to a vendor the organization does not know it has, so shadow AI found through expense records, SaaS discovery and developer surveys belongs in this list. Refresh it on every new purchase, every renewal and every quarterly access review.

Vendor due diligence files

For each vendor, a file recording the questions asked about training data sources, model changes, subprocessors, security testing and intellectual property indemnity, along with the answers and who reviewed them. Store the questionnaire version next to the answers so the file shows what was asked at the time. Re-open the file when the vendor announces a material model change or a new subprocessor, not only at renewal.

Signed contract clauses on IP and usage rights

Executed terms covering content ownership, permitted use of inputs and outputs, restrictions on training with the organization's data, service levels, security obligations and provenance expectations. Track the clause text and the signed version in one place, and note any exceptions approved by legal. Check at each renewal that the clauses still match how the system is actually used, because usage often grows beyond the original contract scope.

Vendor transparency documents

Documents the vendor supplies about its system, such as model cards, data statements, limitations, known failure modes and the process for issuing updates. These show whether the organization has the transparency into training data, algorithms and limitations that the policy requires. Record the document version and date received, and request a fresh copy when the vendor releases a new model version, since older documentation may describe a system no longer in production.

Pre-deployment test records and review minutes

Test plans, results and sign-off for each third-party AI system before go-live, including accuracy checks, bias testing, security testing and tests of the vendor's stated limitations. Pair them with minutes from the review meeting that approved or rejected deployment and the conditions attached. Retest after vendor model changes and record that retest as its own entry. Keep the minutes short and dated so the decision trail is easy to follow.

What meeting GOVERN 6.1 costs in money and effort

This table breaks down the cost components of putting GOVERN 6.1 third-party AI risk policies into practice, who is paid for each, whether it is one-time or recurring, and what drives it up or down. The NIST AI RMF itself carries no fee because it is voluntary and has no certification, so every cost below comes from your own staff, legal counsel, tooling, testing and any outside help you choose to buy. Use the drivers column to scope a quote against your own vendor count and risk tiers.

Cost component	Who is paid or who bears the effort	One-time or recurring	What drives it and what to ask for in a quote
Policy drafting and legal review	Internal policy owners and outside counsel	One-time, then periodic review	Number of policy areas and jurisdictions. Ask for the drafting scope, the number of review rounds and who signs off on legal language.
Procurement process changes	Procurement, legal and business owners	One-time build, recurring use	Number of contract templates and purchase channels touched. Ask whether the partner will update due diligence questionnaires and standard contract clauses.
Vendor assessment time	Security, privacy and business teams, possibly an implementation partner	Recurring per vendor and per review cycle	Number of third-party AI vendors and their risk tier. High-risk vendors need deeper review. Ask how tiers are defined and how often each tier is reassessed.
Testing of third-party AI	Internal test teams or external security testers	Initial test, then recurring on change	Model and system complexity, number of releases a vendor ships, and whether testing covers only the vendor's documentation or also hands-on evaluation. Ask for the test plan and what triggers a retest.
Transparency evidence collection	Vendor (documentation) and internal reviewers (review)	Recurring	Depth of vendor disclosure on training data, algorithms and limitations. Ask vendors what they will provide and under what confidentiality terms.
Evidence upkeep and records	Internal compliance or platform staff	Recurring	Retention periods, number of artifacts and how they are versioned. Ask how records are stored, versioned and made available to an assessor.
External review or independent assessment	Independent auditor or assessor, if you engage one	Periodic, optional	Scope of the review and whether it covers intellectual property and contract terms. NIST does not validate or endorse organizations, so confirm with any reviewer exactly what their report will and will not state.

Who owns the policy, who prepares evidence and who assesses it

Your organization owns the third-party AI risk policy, the vendor decisions it drives and the accountability for them. GOVERN 6.1 asks that policies and procedures address AI risks tied to third parties, including intellectual property and other rights, so the policy must reflect your actual risk tolerance and procurement practice. The NIST AI RMF is voluntary, so no regulator issues your policy for you, and every approval, exception and vendor decision stays with your staff.

Policy owner: Approves the policy scope, sets the risk tolerance for vendor AI and signs off on exceptions.
Procurement: Adds AI-specific questions to due diligence, tracks which contracts include AI systems and enforces the terms.
Legal: Drafts usage rights, content ownership, data handling and liability language for AI contracts and service level agreements.
AI product owners: Record which third-party models, datasets and components each system uses and report changes in vendor behavior.

Confirm internally who holds the policy, who can approve an exception and how often the policy is reviewed before any outside party is engaged.

Where GOVERN 6.1 programs usually fall short

GOVERN 6.1 asks for policies that address AI risks tied to third-party entities. In practice, most gaps appear where those policies meet procurement, inventory and day-to-day vendor use. The cards below describe the gaps we see most often and the first action that closes each one.

No third-party AI inventory

Many organizations cannot list which vendor products embed AI, which models they call through APIs and which business units bought them outside procurement. Without that list, no policy can be applied to anything in particular. Closing action: build an inventory that records each third-party AI system, its supplier, the data it receives, its business owner and the date it was last reviewed, and assign someone to keep it current.

Policies written only for traditional software

Software procurement rules often cover uptime, licensing and patching but say nothing about training data, model updates, drift or output quality. A vendor can change a model without changing its version number, so a policy that reviews only releases will miss the change that matters. Closing action: add AI-specific review triggers, such as material model changes, new training data sources or new use cases, to the existing vendor review process.

IP and usage rights missing from contracts

Contracts often leave content ownership, permitted uses of customer data, rights to outputs and indemnities for third-party infringement unspecified. NIST AI 600-1 points to contract terms covering content ownership, usage rights, quality, security and provenance for generative AI. Closing action: have legal review every AI-capable contract against a short checklist of ownership, data use, output rights and infringement terms before signature.

No transparency requirement for vendor models

Buyers frequently accept a vendor's assurance that a model is safe without asking what data trained it, what its known limitations are or how it was evaluated. The GOVERN 6.1 Playbook suggestions call for transparency into training data, algorithms and limitations. Closing action: make a written disclosure of training data sources, evaluation results, known limitations and intended-use boundaries a condition of purchase, and confirm the vendor will notify you of material changes.

Vendor AI skipped in testing

Internal AI systems usually go through evaluation before release, while third-party AI is often connected to production with only a vendor questionnaire behind it. Testing that a vendor model behaves acceptably for your own use case is the only way to confirm its claims apply to your data. Closing action: require a documented acceptance test on representative data for each high-impact vendor AI system before production use and after each material change.

Policies never reviewed

A third-party AI policy written during a purchase often stays unchanged while vendors, regulations and internal use cases move on. Review cycles that depend on someone remembering to act tend to lapse without a named owner. Closing action: assign an owner, set a fixed review date in the governance calendar and record each review, its findings and any policy changes in version-controlled documentation.

Common questions about GOVERN 6.1 third-party AI policies

Does NIST certify compliance with GOVERN 6.1?

No. NIST does not certify, accredit or validate organizations against the AI RMF, and it does not endorse any organization's approach to using it. The AI RMF 1.0 (NIST AI 100-1) is a voluntary framework with no conformity assessment program. GOVERN 6.1 is an outcome an organization can choose to address, and it can show that it has done so through its own policies, procedures and records. Any statement that a vendor or organization is "NIST certified" for GOVERN 6.1 should be treated with skepticism and questioned. If a customer or contract asks for assurance, ask whether they want internal evidence reviewed by a party they choose, or an independent report issued by an auditor or assessor, since those are different things.

What does GOVERN 6.1 policy work cost, and what drives it?

The cost depends on how many third-party AI systems, data sources and models the organization uses, how many contracts must be reviewed, and how much of the policy set already exists. Costs fall into three groups: internal staff time from legal, procurement, security and the AI owners; external help for drafting, review or testing; and any tooling used to keep records current. Most of the external spend is one-time, such as drafting the policy set and reviewing existing contracts. Recurring costs include periodic review, vendor reassessments and supplier-change updates. When requesting a quote, ask for the scope in writing, the list of artifacts to be delivered, which items the organization must perform itself, and which recurring activities are included or priced separately.

How long does it take to put GOVERN 6.1 policies in place?

The timeline is driven by the size of the third-party AI estate, the state of existing procurement and legal templates, and how quickly internal approvers can agree on risk positions. An organization with a mature vendor management process usually needs less time to extend it to AI than one that has no inventory of AI suppliers. Procurement terms with vendors often take longer than policy drafting because they depend on negotiation. Ask any partner to split the work into phases with written milestones, and confirm which phases depend on the buyer's approvals so that delays are assigned clearly.

What does the buyer's team need to provide?

The organization must own the decisions, and an implementation partner cannot make them on its behalf. The team needs to name an accountable owner for third-party AI risk, provide an inventory of vendor AI systems, data sources and models in use or under evaluation, and make available the current contracts, service terms and procurement questionnaires. Legal must confirm positions on intellectual property, data use and liability, and the security and AI teams must describe how vendor systems are tested and monitored. Expect to supply access to the systems and records the evidence will come from, and to review drafts for accuracy before approval.

Can an in-house team write GOVERN 6.1 policies without outside help?

Yes, many organizations do this internally, and the NIST AI RMF Playbook is written to be used that way. The Playbook offers suggested actions, documentation prompts and references for GOVERN 6.1, but it is neither a checklist nor a set of steps, so the team must decide what applies to its own vendors. The main constraints are time, legal review capacity and whether staff have prior experience with AI-specific clauses such as training data transparency, content ownership and testing of third-party models. Outside help is most often used for an independent review of drafts, for contract language, or for technical checks on how vendor systems are tested.

Can a partner prepare GOVERN 6.1 evidence without issuing any assurance?

Yes. An implementation partner can help prepare the systems, records and documentation that show how third-party AI is governed, but it cannot issue audit reports, attestations or certifications. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. For GOVERN 6.1, preparation might include organizing vendor records, versioned policy documents and supplier test results. The organization keeps ownership of its controls and decides whether to share the evidence with any outside party. Confirm the division of responsibilities in the written scope before work begins.

What evidence does a reviewer usually ask to see for GOVERN 6.1?

Reviewers typically ask for documented policies that cover third-party AI systems and data, a current inventory of vendors and models, and sample contracts showing the terms that were agreed. They also look for records of testing performed on third-party AI before use, the usage instructions provided by vendors, and evidence of periodic review. Version history matters, because a reviewer needs to see what changed, when and who approved it. Tools such as XWiki can keep policy pages under version control, while Dependency-Track and Trivy can produce software and component inventories that support supplier records. Confirm with the organization's own assessor which artifacts they expect, since there is no official NIST checklist for this outcome.

How DeployOpen prepares GOVERN 6.1 policies and evidence

DeployOpen helps organizations put GOVERN 6.1 third-party AI risk policies into operation inside their own infrastructure. We prepare the systems, records and documentation that show how the organization governs vendor AI, data and intellectual property risk, while the organization keeps ownership of its policies and decisions.

How we scope

Agree in writing which third-party AI systems, data sources and procurement processes fall within the engagement.
Confirm which policy topics the organization already has and which need drafting or revision.
Identify the business owners, procurement staff and technical contacts who supply vendor documentation and approvals.

How we build

Set up registers for third-party AI systems, training data sources and vendor-supplied models in the client's environment.
Configure inventory, SBOM and component tracking so vendor software and licence records can be reviewed on a schedule.
Test third-party AI tools against the organization's own usage instructions and documented limitations before approval.

How we hand over

Deliver the written policy set, procurement checklist and vendor due diligence templates for the organization to approve.
Provide evidence packages mapped to each GOVERN 6.1 action, with version history showing what changed and who changed it.
Train the owners who will run the policies so they can maintain registers and renew vendor reviews without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Review vendor changes, new AI tools and updated NIST guidance, and recommend policy updates for the organization to approve.
Prepare evidence refreshes ahead of an independent assessment, which the organization commissions from its own auditor.