An AI vendor due diligence checklist turns product claims into an evidence record before a tool receives data, access, budget or operational dependency. The objective is not to collect every security document a supplier owns. It is to verify that the exact product, plan, configuration and intended workflow meet the organization’s requirements.
Complete the evidence review above with the business owner, procurement and the relevant security, privacy, legal, technical and operational reviewers. Record links, dates, scope and unresolved assumptions outside the browser tool. A polished questionnaire response is not proof when it describes another plan, a parent company or a control that the customer must configure.
1. Purpose of AI vendor due diligence
Due diligence supports a documented decision: approve, approve with conditions, request specific evidence, redesign the workflow or reject the supplier. It should expose dependencies and uncertainty early enough to change the selection, contract or implementation.
The review must be proportional. A public brainstorming tool used without organizational data does not need the same evidence as an agent that reads customer records and takes actions. However, “low cost” and “free trial” are not risk categories. First describe what the service will see and do.
2. Scope the exact service and use case
Record the legal supplier, product, edition, hosting option, region, enabled AI features, model providers, integrations, users and administrators. Describe inputs, outputs, decisions, automated actions and affected people. State prohibited data and uses as explicitly as approved ones.
Map where information enters, which parties process it, what is retained and where output travels. Include logs, metadata, support access, backups, connectors and analytics. Use the existing AI privacy and security checklist for a deeper product-level review.
3. Set requirements before reviewing answers
Convert the use case and AI risk assessment into mandatory requirements, weighted preferences and informational questions. A mandatory requirement needs an objective pass condition and an authorized exception route. Otherwise every uncomfortable answer becomes negotiable under schedule pressure.
| Requirement | Acceptable evidence | Weak substitute |
|---|---|---|
| No training on customer content | Plan-specific contract or authoritative terms | General marketing statement |
| Deletion | Retention schedule, process and backup treatment | “Delete in settings” screenshot |
| Incident notice | Contract language with scope and timing | Support page without commitment |
| Export | Tested format and documented procedure | Unverified sales assurance |
4. Request verifiable, scoped evidence
Ask the vendor to identify the source, date, owner and scope behind each response. Useful evidence can include contractual terms, system documentation, current assurance reports, penetration-test summaries, subprocessors, service status history, architecture diagrams, product evaluations and tested export procedures.
CISA’s Software Acquisition Guide supplier response tool structures questions that buyers can put to software suppliers. NIST’s SP 800-161r1 frames cybersecurity supply-chain risk management across the lifecycle. Adapt these principles to the organization and the AI-enabled workflow rather than treating a questionnaire as certification.
Separate verified evidence from claims
Use three states: missing, partial or claim, and verified for the intended service. “SOC 2 compliant” is incomplete until the buyer knows the report period, covered system, control scope, exceptions and availability for review. Likewise, encryption does not answer which data, keys, environments and administrative paths it covers.
Record evidence expiry and change triggers. A provider may change a model, subprocessor, retention option or service architecture after approval. Make material changes and renewals trigger focused reassessment rather than repeating every question on an arbitrary calendar.
5. Evaluate AI-specific and operational dependencies
Review limitations, evaluation methods, failure modes, monitoring and customer controls. Ask how model or feature changes are communicated, whether customers can test before rollout and what happens when an underlying model is deprecated. Check the actual ability to constrain permissions and autonomous actions.
Operational evidence should cover availability, recovery, support, rate limits, export, business continuity and supplier concentration. A tool may pass privacy review and still be unsuitable because a critical workflow has no tested fallback or usable exit.
Verify references and test critical claims
Reference calls are useful when the reference uses the same plan and a comparable workflow. Ask about implementation time, support escalation, unexpected charges, provider changes, export and failures—not only satisfaction. Test critical customer-facing controls in a structured pilot.
Do not upload restricted production data merely to verify a trial. Use representative synthetic or approved test cases, record configuration and compare performance with a baseline and stop rules.
6. Make a conditional, owned decision
Summarize mandatory passes, critical gaps, residual risks, contractual dependencies and implementation actions. Name the approver, use, plan, users, data, conditions, owners, expiry and reassessment triggers. Approval for meeting summaries does not automatically approve recruitment screening or autonomous customer actions.
A high questionnaire percentage cannot cancel a critical gap. If the supplier cannot establish an essential data, access, incident, pricing or exit requirement, change the workflow, negotiate protection or stop.
7. Due diligence examples
Meeting assistant
Verify participant notice options, capture method, bot access, calendar permissions, recording and transcript retention, model-improvement use, workspace sharing, deletion and export. Test a non-sensitive meeting before broader rollout.
Customer-support agent
Map CRM data and action permissions, measure incorrect responses and escalation, constrain account changes, inspect logs and define rollback. The provider’s model quality claim cannot replace testing on the organization’s cases.
Embedded AI feature
Do not assume an already approved platform covers every new AI feature. Confirm whether terms, subprocessors, data flows, retention, regions and administrative controls differ.
Common due diligence mistakes
Use the AI vendor due diligence checklist as a decision record, not as a race to collect positive answers. Unknown or inapplicable responses need explanation and ownership.
- Reviewing the vendor brand instead of the exact plan and configuration.
- Starting with a generic questionnaire before defining the workflow.
- Accepting badges or policies as evidence of a specific control.
- Ignoring model providers, integrations and customer responsibilities.
- Scoring unknown answers as low risk.
- Completing security review without pricing, resilience or exit evidence.
- Approving indefinitely despite material provider changes.
AI vendor due diligence checklist FAQ
The AI vendor due diligence checklist is most useful when every response links to evidence that a later reviewer can understand without reconstructing the purchase.
Who should own the review?
A business owner should remain accountable, while procurement and relevant specialists verify evidence within their authority. No single reviewer covers every domain.
How much evidence is enough?
Enough to decide the defined use at its actual impact and uncertainty. Critical requirements need stronger, scoped evidence than optional preferences.
Can a small vendor pass?
Yes. Evaluate evidence and controls proportionately rather than company size alone. A small supplier may need alternative assurance or tighter deployment limits.
How often should due diligence be repeated?
Review at renewal and after material changes to use, data, models, features, providers, terms, incidents or dependencies.
Methodology and limitations
ScoutChoice designed this AI vendor due diligence checklist around six decision areas: product scope, data, security, AI governance, operations and commercial terms. Critical gaps override the aggregate score. The tool processes selections only in the browser and does not save a procurement record.
This guide provides general procurement information, not legal, cybersecurity, privacy, financial or compliance advice. Adapt it to applicable law, contracts, internal authority, sector obligations and the specific service.