Third-Party AI Tools: Building a Defensible Vendor Due Diligence Record

Every third-party AI tool your institution buys leaves a paper trail. The question is whether that trail will hold up when someone — an accreditor, an auditor, a regulator, or a plaintiff’s lawyer — asks you to explain how you vetted it.

Most institutions don’t have that trail. They have a purchase order, a vendor pitch deck, and the memory of a meeting in a conference room. When the question comes, that is the whole record. This post is a practical guide to building the record you wish you had: what to ask before you buy, what to keep while you run the tool, who should sign off, and what to do when the contract renews.

A file is not a defensible record

A file is anything you happened to save. A defensible record answers four specific questions:

• What did we know before we bought it? What did the vendor tell us about the model, the data, and the risks — and in writing?
• What did we check on our own? What did our team verify independently of the vendor’s claims?
• Who decided, and on what basis? Which named person approved the tool, and what did they rely on?
• What changed after we deployed it? Did the vendor update the model? Did an incident occur? Did we re-assess?

The difference matters because the burden is on you. If a student’s grade is challenged, an applicant’s file is reviewed, or a regulator asks how an automated decision was made, you will be asked to show how you vetted the tool that produced it, and without a record you have little to show. A defensible record is not a legal shield; it is the thing that lets you demonstrate, concretely, that you were careful.

The frameworks your institution is likely to be measured against all point in the same direction. The NIST AI Risk Management Framework organizes work into four functions — Govern, Map, Measure, and Manage — and its Govern function includes a category on third-party software, data, and supply-chain risks (GOVERN 6) [1]. ISO/IEC 42001, the international standard for AI management systems, provides a structured framework for establishing, implementing, maintaining, and continuously improving AI management systems [2]. The common thread: third-party tools are not a procurement detail. They are a governance object with a lifecycle.

Before you procure: the questions to ask in writing

The single most important habit is to move the vendor conversation from the room to the record. Ask these questions, and keep the answers in writing.

What model is under the hood, and is it itself third-party? A vendor’s product often wraps a model built by someone else, trained on data the vendor did not collect, and integrated with components from other providers. The NIST Generative AI Profile (NIST AI 600-1) calls this out explicitly in its Value Chain and Component Integration risk: generative AI value chains involve many third-party components such as procured datasets, pre-trained models, and software libraries, which may be improperly obtained or not properly vetted [3]. Knowing the chain is the first step, because you cannot assess a risk you have not identified.

What training data does it use, and where did that data come from? Provenance matters for intellectual-property exposure, for the quality of outputs in your domain, and for privacy. This is part of the updated due diligence the NIST Generative AI Profile recommends for generative AI procurement — checking intellectual property, data privacy, and security before you commit [3].

How are outputs generated, and can they be identified as AI-generated? Article 50 of the EU AI Act sets a floor here: providers of AI systems that generate synthetic audio, image, video, or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated, and providers of systems intended to interact directly with people must design them so that people are informed they are interacting with an AI system, unless that is obvious; deployers have separate disclosure duties for deepfakes and for certain AI-generated public-interest text [4]. Even if you are not subject to that regulation, the principle is a useful procurement question: can the tool’s outputs be distinguished from human work?

What documentation do you provide about the model? A short technical document describing the model’s intended use, how it was evaluated, and where it performs well or poorly — the kind of “model card” proposed in the research literature [5] — tells you what to expect. A vendor who cannot produce any documentation about how their model behaves is a signal worth recording, in itself.

What is your incident-notification process? If the model is changed, if a vulnerability is disclosed, or if the tool begins producing out-of-scope outputs, how and how quickly will you be told? The NIST Generative AI Profile treats vendor contracts as a control surface in their own right — reviewing liability, service-level terms, and incident-notification clauses is part of the governance work, not an afterthought for the legal team [3].

Frame all of this as a supplier risk assessment. The NIST Generative AI Profile lists building a framework for assessing supplier risk, writing contract clauses specifically for evaluating third-party generative AI, and maintaining an inventory of third-party entities with an approved-provider list as governance actions [3]. Those three artifacts — the assessment, the contract language, the approved list — are the backbone of the pre-procurement record.

What to keep: the record itself

Once the tool is in use, the record does not end at the purchase order. The items that make it defensible:

• The vendor’s written responses to every question above, including any documentation they declined to provide.
• Your independent risk assessment, separate from the vendor’s marketing. This is where your team’s own judgment lives.
• The approved-provider list entry for this tool, with the date it was added and who added it.
• The contract clauses covering liability, service levels, and incident notification, as signed.
• A log of third-party content changes — model updates, version bumps, feature additions — with dates. The NIST Generative AI Profile specifically calls for records of changes to third-party generative AI content, because a tool you approved in one version is not automatically the tool you approved in the next [3].
• Documentation of the value-chain risks you identified and the fallbacks you put in place, so that if the vendor’s model degrades or is pulled, you have a recorded plan.
• A record of any third-party incidents that affected your use, and how you responded.

The pattern to notice: each item is a dated, attributable artifact. “We reviewed the tool” is not a record. “On [date], [name] recorded that the vendor’s model was updated from version X to Y, and the change was re-assessed against the original risk criteria” is.

Who signs off

A defensible record names a person, not a committee in the abstract. The NIST AI Risk Management Framework’s description of AI actors says procurement tasks are conducted by actors with financial, legal, or policy management authority for acquiring AI models, products, or services from a third party [1]. In practice this means: one accountable owner for the tool, a documented approval that references the specific version you evaluated, and a clear line for who re-approves when that version changes.

The sign-off does not have to be a C-suite signature. It does have to be a signature at the level of authority that can actually commit the institution. A department chair approving a low-risk drafting tool is appropriate; the same person approving a tool that makes automated decisions about students is not. Match the level of sign-off to the level of risk, and record that match.

At renewal

The record is a living thing, and the renewal date is its natural checkpoint. Continuous monitoring is a named governance action in the NIST Generative AI Profile: deployed third-party generative AI should be monitored over time, not just at onboarding [3]. At renewal, re-run the due diligence you did at procurement — re-check the model’s standing against current incident and vulnerability information, confirm the training-data and documentation situation has not changed, and verify that your approved-provider entry still reflects reality.

If nothing has changed, that is a finding worth recording: “Re-assessed at renewal; no material change.” If something has changed, the record should show the change, the re-assessment, and the decision. Either way, the renewal itself becomes part of the trail rather than a silent renewal of a tool you no longer fully understand.

References

1. National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1," NIST Technical Series, 2023. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. NBN (Bureau for Standardization, Belgium), "ISO/IEC 42001 - AI management," NBN. [Online]. Available: https://www.nbn.be/en/management-systems/iso-iec-42001
3. National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1," NIST Technical Series. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
4. European Commission, "Article 50: Transparency obligations for providers and deployers of certain AI systems," AI Act Service Desk. [Online]. Available: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
5. M. Mitchell et al., "Model Cards for Model Reporting," arXiv:1810.03993. [Online]. Available: https://arxiv.org/abs/1810.03993

Where this fits

A vendor due-diligence record is one artifact in a larger set. It sits alongside the use-case inventory that tells you where AI is being used, and the evidence you build before the audit asks that shows how outputs are reviewed and controlled. The inventory identifies the tool; the due-diligence record shows you vetted it; the review trail shows you supervised it. Together, they are the answer to the question no one wants to be asked cold.

Start with the next tool you are about to buy. Ask the questions in writing, keep the answers, name the approver, and calendar the renewal. That is the record.