How Should Companies Perform AI Vendor Due Diligence in 2026?

What AI Vendor Due Diligence Actually Means

AI vendor due diligence is the structured review of a supplier before its technology is used, renewed, or allowed to influence consequential decisions. It is broader than asking whether a model performs well: the review must examine the vendor’s data practices, security controls, model development, subcontractors, contractual limits, regulatory exposure, and ability to support an incident. That distinction matters because an apparently accurate chatbot can create legal and operational exposure through confidential prompts, biased recommendations, unsafe outputs, or automated decisions. It can also expose the customer to risks originating outside the vendor, including cloud hosting, training-data sources, software libraries, retrieval databases, payment providers, and monitoring tools. As of 28 September 2026, a mature review should therefore treat an AI purchase as a chain of managed dependencies rather than a single software contract. The objective is not to certify that the vendor is risk-free, because no supplier can offer that assurance. The objective is to identify material risks, assign them to accountable owners, test whether the controls work, and define what happens when they fail. For corporate innovation labs and product experiments, the depth of review should be proportional to the consequence of wrong output, the sensitivity of the data, and the difficulty of reversing the deployment.

Also worth reading: How Should Companies Choose a B2B Innovation Lab SaaS Platform in 2026? · Which AI Diligence Evaluation Metrics Should Corporate Innovation Teams Use in 2026? · What Is Enterprise AI Agent IAM and How Should Companies Secure Autonomous Systems in 2026?

A Risk-Based Due Diligence Framework

A useful process begins by classifying the proposed use rather than accepting the vendor’s generic category. A tool that summarizes public product documents does not present the same exposure as one that screens loan applicants, recommends prices, ranks job applicants, or makes eligibility decisions. Teams should document the intended users, affected parties, data categories, decision impact, autonomy level, geographic reach, and whether humans can meaningfully override the system. A common threshold is to classify an application as high risk when it affects access to employment, credit, housing, insurance, health care, education, or essential services. Regulators can apply additional obligations even when a provider is not itself a financial institution, which is why customers in regulated sectors should review their responsibilities rather than relying solely on a vendor’s compliance marketing. Internal innovation experiments should also be classified by actual capability, including access to production data or customers, even if the pilot is described as temporary. The resulting risk tier determines how many references, technical tests, contract clauses, and independent reviews are warranted. This approach is more defensible than treating every AI tool with a questionnaire because it concentrates limited review time on systems capable of causing material harm.

Evaluating Data, Models, and Security

The technical review should verify what data enters the service, what information may be retained, where processing occurs, and how outputs are used to improve models or train related products. Contracts should distinguish between customer content, prompts, telemetry, embeddings, derived data, and aggregated statistics because those terms may carry different deletion and reuse rights. The vendor should be asked whether customer data is used for foundation-model training by default and whether contractual or technical settings can prevent that use. A review should also examine encryption in transit and at rest, identity controls, administrative logging, vulnerability management, penetration testing, incident notification, backup restoration, and employee access to production information. For retrieval-based systems, the permission model deserves particular attention: an encrypted database still creates exposure if users can retrieve documents outside their normal authorization. Security questionnaires should be supported by architecture diagrams and evidence rather than accepted as a complete answer. Buyers can request SOC 2 reports, independent penetration-test summaries, disaster-recovery results, and recent audit findings, while recognizing that certification does not prove that a particular model is accurate, fair, or safe for the buyer’s intended purpose.

Testing Performance, Bias, and Human Rights

Accuracy testing must reflect the buyer’s real task, population, language, and operating conditions. A vendor benchmark can establish general capability, but it rarely proves performance on a company’s proprietary documents or edge cases. Test sets should include normal examples, ambiguous cases, missing data, adversarial inputs, multilingual records, and cases where the safe response is to decline or route the request to a person. Results should be reported by subgroup rather than as one aggregate percentage, because a satisfactory average can conceal materially worse outcomes for smaller populations. For example, a 95% overall extraction rate may still be unacceptable if error rates exceed 10% in one language or for a particular document format. Bias cannot be eliminated by a general fairness promise; it must be measured against a legally and operationally relevant baseline. Buyers should also ask whether the vendor conducted human-rights due diligence for training data, suppliers, labor practices, surveillance uses, and public-sector contracts. Criticism directed at one prominent analytics company illustrates why corporate customers now need contractual audit rights and remediation procedures even when a particular deployment has no direct connection to the criticized contract.

Contractual Allocation and Regulatory Exposure

A due diligence process fails if discovered risks disappear into unclear contract language. The agreement should identify permitted purposes, prohibited uses, data ownership, retention periods, deletion verification, model-change notice, subprocessors, audit rights, service levels, security standards, incident deadlines, regulatory cooperation, and termination assistance. It should also state that the customer is responsible for lawful instructions and intended use while the vendor remains responsible for its platform, security failures, IP claims, and documented control commitments. Neither party should be asked to warrant an uncertain future outcome, such as zero bias or perfect model output, but the vendor can warrant process obligations such as testing, disclosure, remediation, and maintenance of agreed safeguards. Contract language becomes particularly important when personal data is transferred across borders or when automated output contributes to regulated decisions. Organizations subject to the EU AI Act should map their role as provider, deployer, importer, distributor, or product manufacturer and review the applicable dates and obligations. Financial institutions should additionally examine model-risk guidance, consumer-protection duties, anti-money-laundering controls, recordkeeping, and outsourcing oversight rather than treating an AI system as exempt software.

Comparison of Due Diligence Approaches

No option is universally best. A small internal review may be adequate for a low-risk writing tool, while a consequential hiring or credit workflow may justify an independent assessment and a limited pilot. The comparison also shows why cost cannot be represented by the vendor’s license fee alone. Due diligence consumes security, legal, privacy, compliance, engineering, procurement, and domain-expert time. A $20,000 annual software subscription could require tens of thousands of dollars of internal effort to evaluate correctly, whereas a more expensive enterprise platform may already include evidence and controls that reduce review effort. Buyers should obtain a scoped proposal and avoid accepting an undefined “AI compliance” package with no test cases, evidence, or remediation record.

A Practical Review Process and Timing

The process should start before procurement negotiations become binding. An initial screening can determine whether the use is permissible, whether required data is necessary, whether the vendor offers acceptable contractual protections, and whether the experiment can proceed at all. If it passes screening, buyers should request security documentation, architecture information, model cards, subprocessor details, incident history, business-continuity tests, and references from comparable customers. Technical evaluation should then use a fixed test set, predefined acceptance thresholds, documented failure categories, and sign-off from the business owner. A pilot should normally run for at least 4–12 weeks for non-decision-support experiments, but the duration should depend on transaction volume rather than a calendar target. A system handling only 50 cases per month needs a longer observation period than one processing 50,000 cases daily. Before deployment, legal and compliance teams should review the final use case and contract rather than a generalized pilot description. Organizations should act immediately when the vendor cannot identify model providers, refuses deletion guarantees, cannot explain security controls, has unresolved material findings, or intends to use sensitive customer data for its own training without permission.

Common Mistakes and Cost Expectations

One common mistake is confusing a polished demo with a production-ready system. Another is requesting a generic questionnaire that asks whether the vendor uses “industry-standard controls” without defining which controls, evidence, or remedies apply. Teams also mishandle inherited risk by assuming a cloud provider approves every model or data source used inside its environment. Others allow employees to connect experimental accounts to confidential repositories before access, logging, retention, and deletion are agreed. Human approval is sometimes presented as a safeguard even when reviewers lack time, expertise, or authority to challenge the output. Cost estimates are also often misleading: usage can rise sharply when context windows, retrieval volume, agent actions, or multimodal files increase. A practical budget should include the subscription or consumption charge, infrastructure, integration, evaluation data creation, security review, external testing, monitoring, legal advice, insurance, and the labor needed to operate the service. Small experiments may cost several thousand dollars, but production deployments can reach six or seven figures once data preparation, governance, and support are included. Procurement should establish a usage ceiling, approval threshold, overage rate, and exit plan rather than waiting for the first invoice to reveal the actual economics.

The Decision Standard for 28 September 2026

The right decision is conditional approval, approval with controls, remediation and retesting, or rejection. Conditional approval is appropriate when residual risks are manageable and can be constrained through limited users, non-sensitive data, low-impact tasks, human review, and short experiment periods. Approval with controls is appropriate for a proven system whose ordinary performance is acceptable but whose failure modes require monitoring, escalation, and periodic recertification. Remediation and retesting should be required for material security findings, unexplained subgroup performance gaps, missing deletion commitments, undisclosed subprocessors, or inconsistent human-rights practices. Rejection is appropriate when the vendor cannot establish lawful data provenance, will not accept responsibility for core failures, offers no viable incident process, or intends to make a high-impact decision with no meaningful human recourse. By 28 September 2026, due diligence should be a repeatable operating discipline rather than a procurement ritual. The evidence package should be retained, material model changes should trigger review, and incidents should feed back into procurement standards. Companies that follow this discipline are not promised perfect AI. They gain something more realistic: a documented way to know where responsibility lies, measure what the system does, and stop or redesign the experiment before an uncertain model failure becomes a customer, employee, regulatory, or reputational event.