AI vendor due diligence: most organizations do not build AI. They buy it, and the review has to change accordingly.
For most small and midsize organizations, AI risk is vendor risk. The AI in the environment arrives through purchased tools, embedded features, and AI-enabled services, and the organization's exposure runs through terms it did not draft and behavior it does not control. AI vendor due diligence is the discipline of examining that arrangement before relying on it: what the vendor does with the organization's data, what the contract actually promises, and what changes when the vendor ships its next feature.
What AI vendor due diligence examines
- Data handling, retention, and model training terms
- Subprocessors and where the data actually goes
- Security posture and what certifications actually attest
- The vendor's representations about the AI itself
- Contract clauses: training opt-outs, confidentiality, output ownership
- The change path: what the next release enables by default
Why AI changes the vendor review.
Organizations have reviewed software vendors for years, and AI does not discard that discipline; it adds questions the standard review never asked. Ordinary vendor review asks whether the vendor will protect the data. AI vendor review additionally asks what the vendor will do with it: whether customer content is retained, whether it trains models, whether human reviewers see it, which subprocessors and model providers actually receive it, and what the vendor's AI claims, about accuracy, about bias, about capability, actually commit the vendor to. These questions matter because the organization inherits its vendors' behavior in its own representations: what it tells customers, carriers, and regulators about its data handling is only as true as the least examined AI service in the stack.
The second change is procedural. Traditional vendor risk assumed a procurement moment when review could occur. Embedded AI removed it: features arrive in release notes and default-enabled settings, inside products the organization approved years ago for what they did then. AI vendor due diligence therefore has to run as a standing process with a change-monitoring component, not as a gate that AI walks around, which is the same finding developed on the shadow AI page from the employee side.
Six areas the review examines.
These six areas are the working structure of the review, and together they define the checklist and the record set that the review produces for each vendor and each embedded feature.
Data handling and training terms
Whether customer content is retained and for how long, whether it is used to train or improve models, whether an opt-out exists and is actually configured, and whether human review of content occurs. This is the clause set that determines whether using the tool is compatible with the organization's confidentiality obligations at all.
Retention, deletion, and subprocessors
Where the data physically goes: the subprocessor list, the underlying model providers, the jurisdictions involved, and whether deletion on termination is a contractual commitment or a marketing sentence. AI services are frequently assembled from other AI services, and the organization's data travels the whole chain.
Security posture and what certifications attest
The vendor's security program, examined with precision about what each artifact proves. A SOC 2 report and an ISO 27001 certificate speak to information security; an ISO/IEC 42001 certificate speaks to the vendor's AI management system. All are favorable evidence, and none of them answers the data handling questions above, which live in the contract.
The vendor's AI representations
What the vendor actually claims about the AI: its intended use, its limitations, its accuracy and bias testing, and the documentation behind the claims. These representations are what the organization will point to when its own use of the tool is questioned, so the review records them rather than assuming them.
Contract allocation
The clauses that decide who carries what: training use restrictions, confidentiality scope, ownership of AI output, indemnification for the vendor's AI behavior, notice obligations when the vendor changes models or features, and audit rights. Standard templates predate these questions, so silence in the contract is itself a finding.
The change path
How the organization will learn what the vendor ships next: assigned ownership for reviewing AI feature announcements and administrative settings, a default posture for new AI features pending review, and the route by which each change reaches the inventory. Without this element, the review is accurate for one day.
A checklist is only as good as the records it leaves behind.
The durable output of vendor due diligence is a record per vendor and per embedded feature: the questionnaire responses or terms excerpts the review relied on, the configuration decisions made, the contract clauses that govern, the decision itself with its owner and date, and the next review date. That record set is what ISO/IEC 42001 asks for through its third-party and resource objectives, what the NIST AI RMF asks for through its Govern and Map functions, and what customer questionnaires and cyber insurance applications are reaching for when they ask how the organization oversees its AI vendors. The review earns its cost twice: once in the decision it informs, and again every time a counterparty asks the question and the answer is already in the file.
In this practice the vendor review runs inside the wider governance work described on the AI governance overview: the inventory establishes which vendors and features exist, the review examines them, the use policy encodes which are approved, and the change path keeps all three current. The work is independent advisory; no tool is resold and no vendor is favored, which is worth stating plainly on a page about examining vendors.
AI vendor due diligence, answered briefly.
What is AI vendor due diligence?
The review an organization performs before relying on a vendor's AI tool, embedded feature, or AI-enabled service: data handling and training terms, retention and subprocessors, security posture, the vendor's AI representations, the contract clauses allocating risk, and the process for catching future feature changes.
Our vendor added AI to software we already own. Now what?
Treat the feature as a new system entering the inventory: identify what data it can reach, read the AI-specific terms attached to it, decide in the administrative console whether it should be enabled, and record the decision. The procurement review never happened for this feature, so this review is the only one it will get.
Does a vendor's ISO/IEC 42001 certificate settle it?
No. The certificate attests that the vendor operates an AI management system, which is favorable evidence about its governance. What the vendor may do with your data lives in your contract and the data processing terms, and reading those remains the core of the review.
Discuss Your AI Vendor Exposure
Inquiries may involve reviewing the AI vendors and embedded features already in your environment, building the standing review and change-monitoring process, or examining a specific AI service before your organization commits regulated or confidential data to it. Call, email, or send a note. I respond personally to every inquiry, usually within one business day.
Discuss an Assessment
Whether the question is what your current vendors may actually do with your data, how to review the AI features that arrived without procurement, or what record set your customers and carriers will ask to see, the first conversation carries no commitment and no pitch.
Discuss an Assessment →