AI Vendor Due Diligence Checklist for Founders and Compliance Leads

An AI vendor due diligence checklist should establish whether a specific service, in a specific configuration, is suitable for your intended use. Before approval, document the use, data flows, supplier chain, legal roles, security controls, performance tests, contract terms, human oversight, and exit plan. Give each unresolved issue an owner and a decision: fix before launch, restrict the pilot, escalate, or reject.

This checklist is a practical review template for SaaS founders and compliance leads, not a statutory questionnaire or a certification. Scale the evidence to the possible harm. A drafting tool using public material needs less scrutiny than a system ranking job applicants or an agent that can change customer accounts. A vendor's reputation cannot establish the safety of your deployment.

When to run the review

Start before uploading real customer information, connecting production systems, or accepting binding customer commitments. Repeat the review when an existing supplier adds AI, the purpose changes, new data enters the service, another model or subprocessor appears, or human review is reduced. Renewal is a useful checkpoint, but it should not be the only trigger.

Use the checklist for purchased AI services, embedded APIs, and AI features inside ordinary SaaS products. If a feature does not involve AI, your normal supplier review may suffice. If no personal data is involved, some privacy questions may be inapplicable; security, confidentiality, reliability, and contractual questions can still matter. Record the reason for every “not applicable” answer.

For each item below, capture the answer, evidence link, reviewer, review date, and any remaining gap. Prefer a dated contract clause, configuration export, or test result over an unqualified sales assurance.

1. Define the approved use and accountable people

• What exact task will the service perform, and for whom?
• Which people could be affected by incorrect outputs or actions?
• Does it draft, recommend, rank, decide, or execute an action?
• Who owns the business outcome, technical configuration, and approval?
• Which uses, data categories, and integrations are explicitly excluded?

Write a boundary that engineering can enforce: “Draft support replies from approved help articles; an employee reviews every reply; no account changes.” Avoid approving “AI for support” without limits. Record the product tier and environment, because a trial account and an enterprise deployment may have different terms and controls.

Evidence to retain: a one-page use description, named owners, architecture sketch, and excluded-use list. An unanswered ownership question should stop approval until someone accepts responsibility.

2. Identify the supplier and model chain

Ask which legal entity provides the service, which models it uses, where processing occurs, and which other organisations receive your data. Establish whether requests can be routed to different models and whether your configuration fixes or permits those choices.

Request a current supplier and subprocessor list, relevant service documentation, model/version information where available, and the notification process for material changes. Distinguish information the vendor cannot disclose from information it has not yet supplied. Missing detail should remain a visible uncertainty, with its effect on approval explained.

Decision check: can you identify the organisations and service components that matter to the proposed risk? If not, narrow the pilot to non-sensitive material or escalate. A long list of company logos is not a data-flow map.

3. Map data handling and privacy responsibilities

Trace prompts, uploaded files, retrieved documents, outputs, feedback, support access, and logs. Ask separately about retention, deletion, training use, human access, and regional processing for each relevant data type. “We do not train on your data” does not answer how long abuse-monitoring logs remain or who can inspect them.

Where GDPR applies, determine controller and processor roles for each activity. Article 28 requires sufficient processor guarantees and a compliant processing contract; Article 35 requires a DPIA where processing is likely to create high risk. Consider lawful basis, transparency, and Chapter V requirements for relevant international transfers. These checks depend on the actual processing, not the label “AI.” GDPR, Articles 5–6, 13–14, 28, 35 and Chapter V.

Evidence to retain: the data-flow map, applicable processing agreement, retention settings, transfer assessment where relevant, and documented DPIA screening. Test deletion with a safe sample rather than assuming that removing a workspace removes every retained copy.

4. Check the AI Act scope and applicable dates

Record your organisation's role, the system's intended purpose, and the relevant obligations. Do not assume that buying a vendor product always makes your organisation only a deployer: branding, modification, or a changed purpose can affect responsibilities. Check prohibited practices and applicable transparency requirements separately from high-risk classification. AI Act, Articles 3, 5, 6, 25 and 50.

As checked on 8 September 2026, the amended timetable applies the main Annex III high-risk rules from 2 December 2027 and the corresponding Annex I product-related rules from 2 August 2028. This is not a delay of every AI Act obligation. Record the provisions and transition rules relevant to your deployment. European Commission: AI Omnibus enters into force.

Decision check: request the evidence relevant to the identified role and system. A general “AI Act compliant” declaration cannot replace a reasoned scope assessment. Escalate uncertainty before using the system for consequential decisions.

5. Verify security and integration boundaries

Ask how the service authenticates users, separates customer environments, protects secrets, records access, and manages vulnerabilities. Inspect the scope and period of any independent assurance report. Check whether it covers the AI service and configuration you intend to use, and review material exceptions.

For connected tools, list permissions individually. A support assistant that reads knowledge articles should not automatically receive permission to export all tickets or issue refunds. Test whether retrieved content can redirect the assistant, whether unauthorised material can appear in outputs, and whether risky actions require a separate approval.

Evidence to retain: access configuration, relevant assurance evidence, integration permissions, test findings, and remediation decisions. Give technical owners explicit responsibility for disabling unnecessary access before launch.

6. Test usefulness, failure, and human oversight

Define acceptance criteria before the demonstration. Build representative cases, including incomplete inputs, misleading documents, unsupported questions, relevant languages, and plausible misuse. Use synthetic or otherwise authorised test material. Record the service configuration and test date so the result has a clear scope.

Evaluate the outputs that matter to your task: correctness, traceability, inappropriate disclosure, inconsistent treatment, and whether the system stops safely when it cannot answer. For consequential recommendations, verify that reviewers have the information, time, authority, and practical ability to challenge an output.

The NIST AI RMF organises risk work around Govern, Map, Measure, and Manage. It can help structure this review, but adopting the framework does not itself prove legal compliance. NIST AI RMF Core.

Decision check: agree which failures block launch and which can be controlled through a restricted use. “A human is involved” is inadequate if the person routinely accepts outputs without checking them.

7. Reconcile the contract with the configuration

Check that the signed terms cover the purchased tier, permitted uses, data handling, confidentiality, security commitments, incident cooperation, material changes, and termination. Ask who owns or may use inputs and outputs, what restrictions apply, and what happens when an intellectual-property complaint arises. Do not infer ownership or protection from marketing copy.

Compare promises with settings. If the contract says a training opt-out is available, establish whether it is enabled and who can change it. If deletion is promised, record the process, exclusions, and evidence you can obtain. Ask how the vendor will help you investigate an incident and meet your own obligations.

Evidence to retain: signed terms, relevant schedules, approved exceptions, and configuration proof. Keep commercial negotiation issues distinct from conditions that must be satisfied before the service receives production data.

8. Record the decision, monitoring, and exit route

Use explicit outcomes: approved within scope, approved with conditions, restricted pilot, escalated, or rejected. Record residual risks, the person authorised to accept them, deadlines, and the next review date. An unresolved launch blocker should not become an ordinary follow-up task just because the release is close.

Assign an owner to watch material service changes, incidents, failed quality checks, user complaints, and expanded use. Decide which events require a fresh review. Confirm that the team can revoke access, remove integrations, export necessary records, request deletion, and continue the workflow if the vendor becomes unavailable.

Evidence to retain: a signed decision record and a tested shutdown or fallback procedure. The approval should be understandable to a colleague who did not attend the supplier calls. Connect it to your investor due diligence evidence instead of rebuilding the story for each review.

A practical approval record

Use this compact record for one vendor and one use. Attach evidence rather than copying entire reports into it.

| Field | What to record | | --- | --- | | Scope | Service, tier, purpose, users, data, integrations, exclusions | | Accountability | Business owner, technical owner, privacy/legal reviewer, approver | | Findings | Evidence references, test results, uncertainties, legal scope | | Decision | Outcome, rationale, residual risks, accepted exceptions | | Conditions | Required action, responsible person, deadline, launch dependency | | Follow-up | Review date, change triggers, incident contact, exit procedure |

A useful completion rule is that every required question has evidence or an explicit gap, every gap has a disposition, and every approval condition has an owner. “Questionnaire returned” is a progress milestone, not an approval decision.

Example: a support drafting assistant

Suppose a SaaS team wants an assistant to draft customer replies. The first proposal connects the entire ticket archive and permits automatic sending. Review identifies private attachments, uncertain log retention, and occasional invented troubleshooting steps.

A restricted pilot could use approved help articles, synthetic tickets, no automatic sending, and documented employee review. Before production, the team would resolve the retention question, restrict retrieval access, test representative failures, and approve the relevant contract. These are illustrative controls, not a guarantee that every support deployment becomes acceptable.

If the team later enables refunds, the original approval no longer describes the use. Reopen the review for write permissions, abuse scenarios, authorisation, and recovery. This is why a reusable record is more useful than a vendor-wide “approved” badge. It also reduces the duplication described in our guide to manual vendor risk reviews.

Common mistakes and FAQ

Is a security certificate enough?

No. It may support particular security claims within its scope. It does not answer whether your data use, legal role, outputs, integrations, and contract are suitable. Retain the certificate alongside deployment-specific evidence.

Does every AI vendor need the same review?

No. Use lighter checks for low-impact, reversible uses and deeper checks for sensitive data, consequential decisions, or broad permissions. Document the reason for the review depth and the conditions that would change it.

What should a founder document first?

Start with the exact use, data categories, business owner, and permissions. These facts let specialists request relevant evidence. Without them, even a detailed questionnaire can describe the wrong service.

What if the vendor refuses important evidence?

Record the refusal and the resulting uncertainty. Consider alternative evidence, a narrower deployment, or another supplier. Do not mark the item complete merely because the vendor says the information is confidential.

When is the checklist finished?

For the current decision, it is finished when the scope, evidence, gaps, conditions, and accountable approver are recorded. The operating process continues through monitoring and reassessment. Start with one proposed vendor this week and make that record reusable.

Sources and image credit

The claim-level links above refer to the GDPR, the current consolidated AI Act, the European Commission's implementation update, and the NIST AI RMF Core. The operational checklist and example are editorial recommendations rather than additional statutory requirements.

Image: Wiki Loves Monuments team meeting in Vienna, photographed by Manfred Werner (Tsui), via Wikimedia Commons, CC BY-SA 4.0. Resized. Used to illustrate collaborative review; no endorsement is implied.