The Question
Enterprise vendor risk management programs have matured significantly over the past decade. Most large organizations run structured vendor assessments covering cybersecurity controls, data handling practices, business continuity, and contractual liability. SOC 2 Type II reports, ISO 27001 certifications, and standardized security questionnaires (CAIQ, SIG, custom frameworks) are now table stakes in enterprise procurement.
None of these frameworks were designed for AI. SOC 2 Type II covers the security, availability, processing integrity, confidentiality, and privacy of a vendor's infrastructure. It says nothing about whether the vendor's AI model produces discriminatory outputs, whether training data was collected legally, how the vendor detects and responds to model degradation, or what happens when the AI system the enterprise relies on for consequential decisions produces a systematic error.
When an enterprise deploys a third-party AI system for hiring, credit decisions, fraud detection, medical triage, or customer service routing, it inherits the AI-specific risks of that system. The deploying enterprise is the entity with regulatory and legal exposure when those risks materialize — not the vendor. EU AI Act deployer obligations, EEOC employer responsibility guidance, and financial services model risk management requirements all place substantive governance responsibility on the deploying organization, not just the technology provider.
The existing vendor risk assessment apparatus cannot satisfy that obligation. The due diligence framework needs to extend to AI-specific risks that standard vendor questionnaires do not cover.
AI vendor due diligence is not IT security due diligence with AI added — it is a distinct assessment covering model provenance, training data, bias testing, and incident history that most procurement functions are not yet equipped to conduct.
Why This Matters Now
In early 2025, a regional U.S. bank was cited by its primary federal regulator in an examination finding related to its AI-powered commercial loan underwriting tool. The finding noted that the bank had completed its standard vendor due diligence, including SOC 2 review and contractual data handling requirements, but had not conducted assessment of the model's validation history, performance monitoring practices, or demographic outcome distribution. The examiner's finding referenced the OCC's model risk management guidance (OCC 2011-12) and the interagency guidance on model risk management (SR 11-7), both of which place model validation and performance monitoring responsibilities on the bank — irrespective of whether the model is developed internally or procured externally.
The bank's vendor contract did not include provisions for model validation documentation, performance reporting, or notification requirements when the model was updated. The bank had, effectively, deployed a consequential credit decision model with standard software vendor due diligence and no AI-specific governance.
This pattern is not limited to financial services. The FTC's 2024 AI enforcement actions included cases where enterprises faced unfair trade practice scrutiny for deploying AI vendor systems whose behavior the enterprises had not assessed. The SEC's AI risk disclosure guidance created documentation requirements for AI-related material risks that cannot be satisfied without vendor due diligence documentation. The EU AI Act's Article 28 deployer obligations require enterprises to verify that high-risk AI systems they deploy meet the Act's requirements — verification that requires AI-specific vendor due diligence, not just standard security assessment.
The 2026 Stackcurve AI Governance CURVE™ Report found that 67% of enterprise respondents conducting AI vendor procurement had not added AI-specific due diligence criteria to their standard vendor assessment process. Sixty-seven percent means most enterprise AI deployments are proceeding without adequate governance of the systems being deployed.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Governance CURVE™ Report evaluated vendor documentation transparency across 28 commercial AI vendors, scoring each on five due diligence dimensions: model provenance documentation, governance process transparency, data use disclosure, bias testing evidence, and incident history disclosure.
ValidMind customers in financial services demonstrated the strongest AI-specific vendor assessment practices, driven by regulatory examiner expectations established through SR 11-7 compliance programs. Financial services is the sector most advanced in AI vendor due diligence.
Among AI application vendors, Salesforce (Einstein AI), Workday (AI hiring and workforce planning tools), and ServiceNow (AI-driven workflow automation) demonstrated above-average documentation transparency for enterprise AI applications — publishing model cards, bias testing summaries, and data use policies for AI features. All three have dedicated AI governance disclosure programs developed in response to enterprise customer due diligence requests.
Vendors built on foundation model APIs — the largest and fastest-growing category of enterprise AI applications — showed the widest variance in documentation quality. Vendors building on OpenAI, Anthropic, or Google APIs range from those that maintain application-level model cards and bias documentation to those that provide no AI-specific documentation beyond the foundation model provider's published materials. The absence of application-level documentation is a governance gap: foundation model cards describe base model behavior, not the behavior of the application built on top of it.
IBM OpenPages with Watson was assessed as providing the most complete AI vendor due diligence framework for organizations with existing IBM GRC deployments, covering model risk assessment workflows aligned to SR 11-7 and EU AI Act requirements.
The full vendor rankings are in the 2026 Stackcurve AI Governance CURVE™ Report — free to download.
The Gap Most Buyers Miss
Standard vendor assessments address the question: "Can we trust this vendor's infrastructure and data handling?" AI vendor due diligence must address a different and broader question: "Can we trust this vendor's AI system to behave as represented in our deployment context?" The five-category AI vendor due diligence framework covers the dimensions standard assessments miss.
Category 1: Model Provenance
What models does the vendor use? Are they proprietary, fine-tuned from an open-source base model, or accessed via third-party API (OpenAI GPT-4o, Anthropic Claude, Google Gemini)? The answer determines where the due diligence burden rests. A vendor using OpenAI GPT-4o via API has model provenance from OpenAI — review OpenAI's model card, data use policies, and terms of service as part of due diligence. A vendor with a proprietary model bears the full documentation burden.
What is the training data lineage? Is any training data subject to copyright disputes (scraped web content during the period of active litigation against OpenAI, Stability AI, and others), privacy regulation challenges (training data containing personal data without clear consent basis), or licensing restrictions? Training data legal exposure is the vendor's problem until it becomes a deployer's problem through regulatory action or litigation.
Category 2: Model Governance
What is the vendor's model validation process before deployment? How are updates — including updates to fine-tuning, RLHF processes, or underlying API model versions — communicated to customers? This question is particularly important for vendors using foundation model APIs: when OpenAI updates GPT-4o or Anthropic updates Claude, the application behavior changes without the enterprise deployer taking any action. Is the vendor's model governance process designed to detect and communicate behavior changes from upstream model updates?
Category 3: Data Use
Does the vendor use customer data — prompts, inputs, outputs — to train or fine-tune models? This question has direct GDPR, CCPA, and enterprise data governance implications. OpenAI's API terms for enterprise customers explicitly state that API inputs and outputs are not used for training. Some smaller vendors' terms do not provide equivalent clarity. Require explicit contractual language.
Where is inference data processed geographically? For regulated industries with data residency requirements — financial services, healthcare, public sector in the EU — inference data processing geography is a compliance requirement, not a preference.
Category 4: Bias and Fairness
Has the model been tested for bias relevant to your specific use case? A hiring tool tested for bias in software engineering candidate screening may not have been tested for bias in nurse hiring or logistics coordinator hiring. The relevant question is not whether bias testing exists but whether it covers the demographic variables and use case contexts of your deployment.
Can the vendor provide bias testing results — actual evaluation metrics disaggregated by demographic group — not just attestations that testing was conducted? Attestations are not evidence. Quantitative test results that can be evaluated against your organization's acceptable threshold for disparate impact are evidence.
Category 5: Incident History
Has the vendor experienced AI-related incidents: hallucinations that caused harm to users, model outputs that exposed data from other customers through prompt injection, bias-related complaints or regulatory inquiries, or significant performance degradation events? How were incidents handled — disclosed to customers, root-caused, and remediated with documented prevention measures?
AI incident history is not widely disclosed. Require vendors to attest in writing to AI-related incidents in the prior 24 months and their resolution. The contractual obligation to disclose creates accountability even where voluntary disclosure culture has not yet developed.
The EU AI Act deployer obligation framework
EU AI Act Article 28 establishes that deployers of high-risk AI systems bear responsibilities including verifying the provider has fulfilled their obligations, implementing human oversight measures, and monitoring the system for serious incidents. These obligations cannot be fulfilled through standard vendor questionnaire responses. They require the AI-specific due diligence framework above, documented as part of the enterprise's EU AI Act compliance record.
Questions Your Buying Team Should Be Asking
1. Is this AI system built on a proprietary model, a fine-tuned open-source model, or a third-party foundation model API — and if a third-party API, which one, and what are the data use terms of that API contract?
The model architecture determines where documentation responsibility sits and what terms govern data use. A vendor that cannot clearly answer this question about their own product architecture is a governance risk regardless of other evaluation criteria. The answer also determines the scope of due diligence: API-based vendors require review of both the vendor's terms and the underlying API provider's terms.
2. What is your process for communicating model updates to enterprise customers — specifically, how do you notify customers when the underlying model (including upstream API model updates) is updated in a way that may change output behavior?
Silent model updates are a material governance risk for deploying enterprises. Model behavior changes without notice prevent enterprises from re-evaluating the model against their governance criteria before the updated model is in production. Require contractual notification commitments and evaluate whether the vendor's current process fulfills them.
3. Can you provide bias evaluation results disaggregated by the demographic variables relevant to our use case — not an attestation that testing was done, but the quantitative results?
This question separates vendors with genuine bias evaluation programs from vendors whose bias compliance narrative is primarily attestation. Accepting attestations without evidence in AI vendor due diligence is the equivalent of accepting a vendor's claim that they have a SOC 2 report without requesting it. The evidence standard should be consistent.
4. Does your product use our data — prompts, inputs, inference outputs — to train or fine-tune any model, and what are the explicit contractual commitments regarding data use, retention, and deletion?
Data use for model training is a GDPR and CCPA issue with direct legal consequence for the deploying enterprise. The answer must be in the contract, not just the vendor's FAQ. If the vendor's current contract terms do not explicitly address this question, require amendment before signing.
5. In the past 24 months, has your organization experienced any AI-related incidents — including model outputs that caused harm, data exposure through AI system behavior, bias complaints from end users, regulatory inquiries related to AI system behavior, or significant performance degradation events — and how were they handled?
Incident history is the most revealing indicator of AI governance maturity. Vendors with strong AI governance programs have incident response processes, post-incident documentation, and disclosure practices. Vendors without them either have not experienced incidents yet (a function of deployment scale and maturity) or have experienced incidents that were not managed through a governance process.
The Stackcurve Take
The gap between standard vendor due diligence and AI-specific vendor due diligence is not a documentation refinement — it is a governance architecture difference. Standard due diligence evaluates vendor infrastructure. AI due diligence evaluates model behavior, training data provenance, governance process maturity, and incident history. The former does not substitute for the latter when the enterprise is deploying consequential AI.
The enterprises building this capability are doing so because regulators — financial services examiners, EU AI Act supervisory authorities, the FTC, and the EEOC — are examining whether deploying enterprises understand the AI systems they deploy. The enterprises that cannot demonstrate AI-specific vendor due diligence are accumulating regulatory exposure that will not be mitigated by pointing to a passed SOC 2 audit.
The practical starting point: add a five-category AI due diligence module to the existing vendor risk assessment process. It does not require replacing the existing process — it augments it with the AI-specific questions that the existing process was not designed to answer.
The 2026 Stackcurve AI Governance CURVE™ Report covers AI vendor due diligence frameworks, vendor transparency scores across 28 commercial AI vendors, and contractual language guidance for AI procurement. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.