Somewhere in most enterprise vendor files sits a due diligence questionnaire that has barely changed in five years: financial health, information security controls, business continuity planning, data privacy compliance, sanctions and adverse media screening. It is a thorough document for the risks it was designed to catch. It was not designed to ask whether the vendor's flagship feature is now generated by a large language model, whose data trained that model, or what happens to the product's behavior the week the vendor swaps foundation model providers without telling anyone.
That gap is no longer theoretical. AI features have moved from a differentiator a handful of vendors advertised to a default layer embedded across procurement software, HR platforms, customer support tools, coding assistants, and analytics products — often added mid-contract, well after the original due diligence was completed and filed away. Regulators are responding faster than most due diligence frameworks are updating: the EU AI Act places direct obligations on organizations that deploy AI systems, not just the vendors that build them, and supervisory bodies overseeing financial services and critical infrastructure are beginning to ask boards pointed questions about which vendors' AI features touch regulated data and decisions.
This piece is written for AI governance leads, procurement and vendor management teams, compliance officers, and legal counsel who are discovering — often only after a vendor renewal or an internal audit — that their due diligence process has no formal way to answer a question that increasingly matters most: does this vendor's use of AI create risk we haven't assessed?
See how Crest.Digital's Agentic AI layer extends due diligence and continuous monitoring to cover AI-specific vendor risk, not just the legacy control categories most questionnaires were built for.
Explore Agentic AI for TPRMWhy Traditional Due Diligence Misses AI Risk
Vendor due diligence, as most enterprises practice it today, is built around risks that are relatively stable between assessment cycles. A vendor's SOC 2 report, financial statements, or data processing agreement do not typically change week to week — which is why an annual or contract-triggered reassessment cadence has worked reasonably well for years. AI-enabled products break that assumption in a specific way: the underlying model can be retrained, fine-tuned, upgraded to a newer version, or switched to an entirely different foundation model provider on a timeline the vendor controls and the customer rarely sees, changing the product's data handling and output behavior without any of the standard triggers — a contract renewal, a security incident, a change in ownership — that would normally prompt a fresh look.
The deeper issue is that most questionnaires simply do not contain the right questions. They ask about encryption standards, incident response plans, and subprocessor lists for data hosting — but rarely ask which model powers a given feature, what data trained it, whether a human reviews its outputs before they reach a customer's business process, or what obligations the vendor has accepted around notifying customers of a material model change. A vendor can pass every existing control in a legacy questionnaire with a clean bill of health while its AI feature set carries risk the assessment was never built to see.
What Changes When a Vendor's Product Runs on AI
Four characteristics distinguish AI-enabled vendor risk from the risk categories legacy due diligence was designed around, and each deserves its own line of inquiry rather than being folded into a general security review.
Foundation Model Dependency
Many vendors do not build their own models; they build a product layer on top of a foundation model licensed from another provider. That dependency is rarely disclosed unprompted, yet it determines which company's data usage policies, security posture, and outage history now indirectly affect the customer's risk exposure.
Third-Party Training Data and Provenance
Whether a model was trained on licensed data, public data, or — critically — a customer's own prior interactions with the product determines both the vendor's legal exposure and the customer's. A vendor that quietly uses customer inputs to further train models serving other customers has created a data usage risk few legacy questionnaires are built to catch.
Autonomous or Semi-Autonomous Decisioning
Where an AI feature moves from suggesting an output to acting on it — auto-approving a transaction, auto-responding to a customer, auto-flagging a compliance exception — the absence of human review before action becomes a governance question in its own right, not a footnote to a broader security assessment.
Model Versioning and Silent Updates
Traditional software changes are versioned, tested, and released on a schedule a customer can track. Model updates frequently are not communicated with the same rigor, meaning a product's behavior can shift meaningfully between one week and the next with no corresponding change log a due diligence process would ordinarily rely on.
Data Lineage, Usage Rights & Human Oversight
Two categories of evidence sit at the center of a modernized AI due diligence process, and both need to move from a verbal assurance to a documented, contractual position.
Data lineage and usage rights cover what data trained or fine-tuned the model behind a vendor's product, and — separately — what happens to the customer's own data once it enters that product. A vendor should be able to state plainly whether customer inputs are used to further train models that serve other customers, what retention period applies to that data within the AI pipeline, and what contractual usage rights the customer retains over any AI-generated output derived from its own information. The absence of a clear answer to any of these three questions is itself a finding, not a neutral result.
Human oversight and change notification address what happens when the model is wrong, and what happens when the model changes. A defensible position requires the vendor to commit, in writing, to human review of AI-generated outputs that materially affect a customer's business decisions — credit approvals, compliance determinations, safety-relevant recommendations — rather than leaving oversight as an unstated assumption. It also requires an explicit commitment to notify customers in advance of a material model version change, a switch in the underlying foundation model provider, or a significant retraining event, so the customer can decide whether renewed testing or a fresh risk assessment is warranted before the change takes effect.
AI Subcontractors and the Fourth-Party Problem
A vendor risk register built around direct, contracted vendors misses a layer that AI adoption has made unavoidable: the foundation model provider sitting underneath the vendor's own product. When a procurement platform, an HR system, or a customer support tool embeds a third-party large language model, the customer's data may pass through that AI subcontractor's infrastructure without the customer ever having assessed, contracted with, or even been formally told about that provider — a fourth-party exposure that sits entirely outside the primary vendor's own security certifications.
Closing this gap requires treating AI subcontractor disclosure as a distinct, mandatory line item rather than an assumption folded into a vendor's general subprocessor list. A rigorous process asks the vendor to name every AI model provider embedded in the product, confirm exactly what customer data (if any) reaches that provider, and specify what flow-down contractual protections apply — most importantly, a binding commitment that the AI subcontractor will not use the customer's data to train models serving unrelated customers. This is the same discipline continuous third-party monitoring already applies to conventional fourth-party mapping, extended to cover the AI supply chain specifically.
Crest.Digital's AI-powered vendor intelligence platform brings AI governance questions, model change tracking, and AI subcontractor mapping into the same continuous due diligence record as every other vendor risk category — with agentic AI orchestrating evidence collection and a named owner confirming every judgment call.
What Regulators and Standards Now Expect
AI governance expectations are moving from voluntary best practice to a documented supervisory and legal expectation, spanning AI-specific regulation, established risk management frameworks, and enforcement guidance.
EU AI Act: The European Union's risk-based AI regulation places direct obligations on organizations that deploy AI systems, not only the providers that build them — requiring deployers of higher-risk AI to understand a system's intended purpose, maintain human oversight, and hold documentation demonstrating that oversight, which effectively mandates a vendor due diligence trail for AI-enabled suppliers. See the European Commission's regulatory framework for AI.
NIST AI Risk Management Framework: The U.S. National Institute of Standards and Technology's AI RMF provides a structured, widely referenced approach to identifying, measuring, and managing AI risk across the full lifecycle — including third-party and supply chain considerations — and is increasingly cited by enterprises building internal AI governance programs. See the NIST AI Risk Management Framework.
ISO/IEC 42001: The first international management system standard for AI, ISO/IEC 42001 gives organizations a certifiable structure for AI governance — including supplier and third-party AI risk — that due diligence teams can reference when evaluating whether a vendor's own AI governance program is mature. See ISO/IEC 42001 on AI management systems.
US Regulatory and Enforcement Signals: The Federal Trade Commission's guidance on AI and consumer protection has repeatedly warned that deploying a third party's AI does not transfer away accountability for how that AI affects customers, reinforcing that due diligence on an AI vendor is not optional simply because the model itself was built elsewhere.
Audit and Governance Perspective: Professional research from bodies including ISACA has identified AI governance gaps in vendor due diligence as a fast-growing area of internal audit findings, reflecting how quickly AI-specific risk has outpaced the update cycle of most third-party risk programs.
Modernizing the Vendor Questionnaire: A Five-Step Framework
Rebuilding due diligence for AI-enabled vendors does not require discarding the existing framework — it requires extending it with a distinct set of questions, evidence requirements, and monitoring triggers.
Inventory Which Vendors Are Already AI-Enabled
Start with an honest inventory of the existing vendor base to identify which suppliers already embed AI or machine learning features, rather than assuming AI risk only applies to newly onboarded vendors.
Add Model Provenance and Data Lineage Questions
Require every AI-enabled vendor to disclose which foundation model powers the product, what data it was trained or fine-tuned on, and what usage rights govern the customer's own data in that pipeline.
Require Human Oversight and Model Change Notification Commitments
Add contractual language requiring human review of AI outputs that affect material business decisions, and advance notice before a material model version change or provider switch.
Map AI Subcontractors as a Distinct Risk Category
Require a named inventory of every AI sub-processor or foundation model provider embedded in the vendor's product, with flow-down protections over how customer data is used by that sub-processor.
Move From Point-in-Time Questionnaire to Continuous AI Risk Monitoring
Track AI-specific risk the same way other third-party risk is tracked — continuously, with defined triggers for reassessment — rather than treating the AI governance questionnaire as a one-time onboarding artifact.
The unifying principle across all five steps: AI-specific risk needs its own evidence trail, owned by a named function, and reviewed on a cadence that matches how quickly a vendor's AI features can actually change — which, for most AI-enabled products today, is considerably faster than the annual reassessment cycle most due diligence programs still run on.
Agentic AI and AI Governance Due Diligence
There is a useful irony in using agentic AI to govern AI vendor risk, but the fit is a practical one: AI governance due diligence is, structurally, an evidence-gathering and monitoring problem at a scale and speed that outpaces a purely manual, periodic questionnaire process — particularly for enterprises with dozens of AI-enabled vendors whose model versions and subprocessor disclosures change on their own schedule.
AI-Assisted Due Diligence and Evidence Collection
Rather than a compliance analyst manually parsing a vendor's AI use policy and subprocessor list for every renewal, an AI-driven orchestration layer can extract the relevant disclosures automatically, flag missing answers against the required question set, and route incomplete responses back to the vendor — compressing a process that often takes weeks into days.
AI-Driven Monitoring for Model and Subprocessor Changes
Because model changes and AI subprocessor updates are rarely announced through the same channel as a formal contract amendment, continuous monitoring tuned to public product announcements, changelogs, and privacy policy updates can surface a material AI change between formal reassessment cycles, rather than the customer learning about it after the fact.
AI-Based Remediation Tracking for Governance Gaps
When a vendor cannot answer a required AI governance question — no clear data lineage statement, no committed change-notification process — AI-based remediation tracking logs the gap as an open finding and follows up on a defined timeline, the same way any other unresolved vendor risk finding is tracked to closure rather than left open indefinitely.
Human-in-the-Loop Governance Where It Matters Most
None of this automation removes the judgment call at the center of AI governance: whether a given vendor's AI risk profile is acceptable for a specific use case remains a decision for a named AI governance, compliance, or risk owner. Human-in-the-loop governance is what keeps AI-accelerated due diligence a faster version of a program people still own, rather than a black box quietly approving AI-enabled vendors on its own.
Executive Checklist: Is AI Governance Built Into Your Vendor Due Diligence?
Use this checklist to assess whether your organization can produce evidence — not just assumption — that AI-enabled vendors have been assessed on AI-specific risk.
AI Vendor Due Diligence — Readiness Checklist
- AI-Enabled Vendor Inventory: Do you have a current list of which existing vendors already embed AI or machine learning features?
- Model Provenance Disclosure: Does your questionnaire require vendors to name the foundation model powering their product and disclose its training data sources?
- Data Usage Rights: Have you confirmed, in writing, whether your organization's data is used to train models serving other customers?
- Human Oversight Commitment: Is there a contractual requirement for human review of AI outputs affecting material business decisions?
- Change Notification Clause: Does the contract require advance notice before a material model version change or foundation model provider switch?
- AI Subcontractor Mapping: Can the vendor name every AI sub-processor embedded in the product, with flow-down data protections in place?
- Continuous Monitoring: Is AI-specific risk tracked continuously, or only revisited at the next scheduled reassessment?
- Named Governance Owner: Is there a specific AI governance, compliance, or risk owner accountable for signing off on AI-enabled vendor risk?
Few enterprises will check every box today — AI-specific due diligence is still an emerging discipline layered onto a mature but AI-blind vendor risk process. The measurable impact of closing this gap typically shows up first in fewer AI-related surprises discovered after a vendor renewal, then in a cleaner audit trail when a regulator or board asks which vendors' AI features touch regulated data, and eventually in a due diligence program that treats AI governance as a standing category of vendor risk rather than an afterthought bolted onto a legacy questionnaire.
Frequently Asked Questions
Traditional vendor due diligence questionnaires were designed around a stable set of risks — financial solvency, information security controls, business continuity, and regulatory compliance — that assume a vendor's product behaves the same way today as it did during the last assessment. Generative AI and machine learning models break that assumption. A vendor's underlying model can be retrained, fine-tuned, or swapped for a different foundation model provider without the customer being notified, which changes the product's behavior, its data handling, and potentially its risk profile without triggering any of the standard reassessment events a questionnaire is built to catch. Most current questionnaires simply do not ask who trained the model, what data it was trained on, whether outputs are human-reviewed, or what happens when the model changes — because those questions did not exist when the questionnaire was written.
A modernized due diligence questionnaire should add five categories of AI-specific questions. Model provenance: which foundation model or models power the product, and is that a proprietary model or a wrapped third-party model such as one from OpenAI, Anthropic, Google, or Meta. Data lineage and usage rights: what data was used to train or fine-tune the model, whether the vendor's own customer data is used to further train models serving other customers, and what contractual usage rights apply. Human oversight: whether AI-generated outputs that affect a customer's business decisions are reviewed by a human before being acted upon, and what the escalation path looks like when a model output is wrong. Change management: whether the vendor commits to notifying customers before a material model change, version upgrade, or provider switch. AI subcontractors: a full inventory of every AI vendor and sub-processor embedded in the product, since a due diligence process that stops at the primary vendor misses the foundation model provider sitting underneath it.
The EU AI Act establishes a risk-based framework that applies obligations not only to organizations that build AI systems but to organizations that deploy them, which places direct due diligence obligations on enterprises using AI-enabled vendor products. For higher-risk AI use cases, deployers are expected to understand the AI system's intended purpose, maintain human oversight, and ensure the system was placed on the market with appropriate documentation and conformity assessment from its provider. In practice, this means an enterprise cannot simply take a vendor's word that its AI feature is compliant — the deploying organization needs its own evidence trail showing it assessed the AI system's risk classification, understood the vendor's documentation, and put oversight controls in place, which is precisely the gap a modernized vendor due diligence process is meant to close.
Due diligence needs to treat the foundation model provider underneath a vendor's product as a distinct fourth-party risk, not an implementation detail. Many software vendors embed a third-party large language model — rather than building their own — which means the customer's data may ultimately pass through an AI provider it never assessed, never signed a contract with, and may not even know exists. A rigorous process requires the vendor to disclose every AI sub-processor by name, confirm what customer data (if any) reaches that sub-processor, and specify what contractual flow-down protections apply, such as a commitment that the sub-processor will not use the customer's data to train models serving other customers. Without this disclosure, an enterprise's AI risk exposure extends one or two layers beyond what its vendor risk register actually shows.
Agentic AI can meaningfully accelerate the mechanics of AI governance due diligence — parsing a vendor's AI use disclosures and model documentation, cross-referencing claimed certifications against public registries, flagging when a vendor's public model-change notices or subprocessor list has been updated since the last assessment, and assembling the evidence trail into one continuously current record instead of a point-in-time questionnaire response. It can also monitor for public signals of a vendor's AI risk profile changing — a new foundation model integration announced in a product release, a reported incident involving the vendor's AI features — between formal reassessment cycles. It does not replace the judgment call of whether a vendor's AI governance is adequate for a given use case; a named AI governance, compliance, or risk owner still makes that determination, with agentic AI supplying faster, more current evidence to inform it.