AI Vendor Due Diligence Checklist for 2026 Procurement Teams
Enterprise checklist for AI vendor evaluation: compliance artifacts, provenance evidence, security controls, and audit-ready documentation for 2026.
AI vendor due diligence runs on evidence, not assurances
AI vendor due diligence requires verifiable evidence — signed artifacts, audit logs, compliance attestations — across five procurement stages: screening, technical assessment, compliance verification, contract negotiation, and ongoing monitoring. The failure mode in most AI procurement is accepting narrative in place of artifacts. A vendor deck can claim encryption, testing discipline, and responsible data handling; none of that is checkable. An evidence-based process asks a different question at every stage: what document, log, report, or attestation proves this claim, who produced it, and when. That framing does two things. It filters out vendors who cannot substantiate their own marketing, and it leaves the buyer with a defensible record — useful when an auditor, regulator, or board member later asks why this vendor was approved. The checklist below follows the five stages in order.
Stage one: screening should disqualify quickly
Screening exists to eliminate vendors cheaply before deep assessment starts. Keep the questionnaire short — ten to fifteen questions — and make every question answerable with a document. Ask for a current security overview, a list of subprocessors, a summary of where customer data is stored and processed, and a plain written statement of whether customer data is used to train or fine-tune models. Ask which compliance attestations exist today, not which are planned. Then watch response behavior as closely as response content. A vendor that takes weeks to produce a subprocessor list will not produce incident evidence quickly during a real breach. Disqualify on two grounds at this stage: refusal to answer data-training questions in writing, and inability to name a security owner. Both predict problems that no contract clause will fix later.
Stage two: technical assessment goes below the marketing layer
Technical assessment establishes what the vendor actually built. Start with architecture: where models are hosted, whether the product wraps a third-party foundation model or runs proprietary models, and how tenants are isolated. Trace the data path — what leaves your environment, what is retained, for how long, and what is logged. Ask for a dependency inventory, ideally as a software bill of materials, and for equivalent documentation of the AI stack: which models, which versions, which training data sources. Vendors reselling a frontier model behind a thin interface are not necessarily bad choices, but they carry the upstream provider's risks, terms, and outage profile, and you should price that in. The output of this stage is a written description of the system that the vendor confirms as accurate. Later claims get measured against it.
Verify attestations; do not accept compliant-ready language
"SOC 2 ready," "SOC 2 aligned," and "built to SOC 2 controls" all mean the same thing: no independent audit has been completed. Treat these phrases as roadmap statements, not attestations. When a vendor claims SOC 2, request the actual report under NDA and read it. Check whether it is Type I, which evaluates control design at a single point in time, or Type II, which tests operating effectiveness over a review period. Check the scope — which systems and trust services categories were covered — and read the exceptions section, where auditors record control failures. For ISO 27001, verify that the certificate's scope statement covers the product you are buying, not just a corporate office. An attestation with a narrow scope can be less meaningful than a candid unaudited security document.
Map the vendor to your regulatory exposure
Regulatory obligations for AI systems depend on jurisdiction, sector, and role, and the vendor's answers should reflect that. Under the EU AI Act, the obligations of a provider who places an AI system on the market differ from those of a deployer who uses it, and requirements scale with risk classification — high-risk systems carry duties around technical documentation, logging, human oversight, and post-market monitoring. Implementation timelines for the Act have shifted since adoption, so confirm current dates with counsel rather than relying on a vendor's summary. Ask the vendor directly: which role do they take for your use case, how do they classify the system, and what documentation will they hand you to satisfy your own obligations. A vendor that has not thought about your regulatory position is transferring that work to you silently.
Demand security controls with artifacts behind them
Every security control worth having produces an artifact. Access control produces role definitions and access review records. Encryption produces a documented standard covering data at rest and in transit, including model inputs and outputs. Vulnerability management produces remediation timelines and evidence they are met. Incident response produces a written plan, a named contact, and dates of the last test. Penetration testing produces a summary letter from the testing firm. Ask for each artifact, and pay attention to gaps between policy and proof: a vendor with an impressive access-control policy but no record of ever running an access review has a policy, not a control. For AI-specific surfaces, add prompt-injection handling, model input logging, and abuse monitoring to the list. The artifact requirement keeps the conversation concrete.
Provenance evidence separates mature vendors from the rest
Provenance is the vendor's ability to prove where their system came from and what changed in it. Concretely: versioned releases with signed or checksummed artifacts, a dependency manifest that maps to public advisory databases for vulnerability matching, model documentation that is versioned alongside the model, and audit logs that record who changed what. Test it with one question: for the model version currently serving your requests, what changed relative to the previous version, and when? A mature vendor answers from records in minutes. An immature one answers from memory, or asks an engineer. Provenance evidence matters because it compounds — it is the raw material for the vendor's own compliance reports, incident investigations, and your audits. A vendor who cannot reconstruct their own history cannot support yours.
Negotiate contract terms that keep evidence flowing
Due diligence findings decay unless the contract preserves them. Negotiate audit rights or, at minimum, a commitment to share future attestation reports within a defined window of issuance. Set breach and security-incident notification timelines in hours or days, not "promptly." Prohibit training or fine-tuning on your data without explicit written consent, and make the prohibition survive termination. Require advance notice of material model changes and subprocessor additions, with a right to object. Define exit terms while the relationship is friendly: data export format, deletion timelines, and written certification of deletion. Finally, tie the vendor's compliance representations to the specific documents reviewed during diligence, so a later dispute references artifacts rather than sales conversations. None of these clauses is exotic; all of them are cheaper to obtain before signature than after.
Due diligence does not end at signature
The vendor you evaluated and the vendor you are running in production diverge over time. Models get replaced, subprocessors change, attestations lapse, companies get acquired. Ongoing monitoring is the fifth stage of diligence, and it should be scheduled, not reactive. Reassess annually at minimum: request the newest attestation report, refresh the subprocessor list, and reconfirm data-use terms. Between cycles, watch for triggers that warrant an off-schedule review — a disclosed incident, a major model swap, a change of ownership. Keep the entire record — questionnaires, reports, correspondence, decisions — in one place with named owners, because that file is what you will produce when your own auditors ask how third-party AI risk is managed. Treated this way, the checklist stops being a procurement gate and becomes a living control.