A convincing AI demo shows what a product can do. It rarely shows every place your customer records will travel, how long uploaded files remain available or what happens when the underlying model changes.
An AI vendor due diligence checklist helps a small business turn those unknowns into specific questions and evidence requests. Before approving a tool, establish what it will do, which data it needs, who receives that data and how your team can control, test and stop its use.
The goal is a proportionate decision. A tool drafting public product descriptions needs a different review from an agent reading customer mailboxes or changing financial records.
Information verified as of November 3, 2026. The questionnaire and fictional comparison below are planning tools, not a legal opinion or an independent vendor audit.
What to confirm before approving an AI vendor
- Define the exact product, subscription, model and features being purchased.
- Separate model training, operational retention, safety review and deletion.
- Request the AI subprocessor list and understand each relevant party’s role.
- Check access controls and action permissions, not just encryption claims.
- Test the intended workflow using harmless data before allowing sensitive information.
- Record unresolved requirements as approval blockers or explicit exceptions.
- Assign an owner to review material changes after purchase.
Start with the workflow and data boundary
Before sending a questionnaire, write a short purchase brief. It should name the business task, users, input data, expected output and permitted actions.
For example: “Three support employees will use the tool to draft replies from approved policy text. A person must approve every reply. The tool may not send messages, issue refunds or change customer accounts.”
That brief makes vendor answers easier to assess. A broad statement that the product is “secure for business” does not establish whether it can meet your particular access and approval requirements.
NIST’s Generative AI Profile, published July 26, 2024, provides a risk-management reference for generative AI. Its use does not certify a vendor. Apply it to the actual system, including the integrations and third-party components involved.
Match each claim to evidence
A useful evidence record includes the requirement, vendor answer, supporting document, version or date, reviewer and decision. Keep a copy or stable reference where permitted; a website can change after the purchase.
| Evidence type | What it can establish | What it does not establish alone |
|---|---|---|
| Contract or applicable data-processing terms | The documented commitments applying to the purchase. | That every control works as intended. |
| Product documentation and configuration | Available settings, supported features and stated limitations. | That your account has those settings enabled. |
| Independent assurance report | Assessment of the stated organization, systems, controls and period. | Guaranteed output accuracy or coverage of every AI feature. |
| Controlled pilot | Observed behavior for the tested workflow and configuration. | Performance across every future input or model update. |
| Sales answer or marketing page | A claim that should be clarified and checked. | A complete technical or contractual assessment. |
For a SOC 2 report, check its type, reporting period, scope, exceptions and relevant customer responsibilities. For an ISO certificate, check the certified entity, scope and validity. A badge on a website is a starting point for review, not the end of it.
AI vendor due diligence checklist: evidence-request questionnaire
Send the following questions with your purchase brief. Ask the vendor to identify which answers apply to the exact plan, model, deployment and enabled features. “Not available” is more useful than an ambiguous yes.
| Question to ask | Evidence to request | Decision check |
|---|---|---|
| Which legal entity provides the service, and which product terms apply? | Order form, service terms and applicable data-processing agreement. | The entity and plan match the proposed purchase. |
| Which models and external providers process our requests? | Data-flow diagram and model-provider disclosure. | Upstream processing is sufficiently understood. |
| Are inputs, outputs, uploaded files or feedback used for model training or improvement? | Applicable terms and feature-specific settings. | Permitted use matches the data policy. |
| How long is each data category retained? | Retention schedule covering content, logs, backups, files and safety records. | Periods and exceptions are acceptable. |
| What does deletion remove, and when? | Deletion procedure, timeframes and backup or legal exceptions. | Exit requirements can be met. |
| Which subprocessors receive our data, and for what purpose? | Dated subprocessor register, locations and change-notification process. | Relevant recipients and change controls are acceptable. |
| Who can access customer content? | Support-access controls, authorization process and audit evidence. | Human access is bounded and accountable. |
| How do administrators manage users and credentials? | Documentation for MFA, SSO, roles, provisioning and API-key controls. | Required controls are available on the purchased plan. |
| What can connectors or agents read and change? | Permission list, approval controls and action logs. | Access and actions can be limited to the task. |
| How is security assessed and incidents handled? | Relevant assurance report, testing summary and incident-notification terms. | Scope, exceptions and escalation arrangements are understood. |
| How are output quality and model changes managed? | Evaluation methods, limitations, release notices and version controls. | Your workflow can be tested and revalidated. |
| How do we export data and leave? | Export format, deletion process, renewal terms and transition support. | The company can exit without an unplanned dependency. |
For regulated or especially sensitive use, add the requirements relevant to that workflow and jurisdiction. A vendor’s general compliance claim does not establish that your particular use is permitted.
AI vendor data retention: ask more than “Do you train on our data?”
Training and retention are different questions. A vendor can exclude customer content from model training while still retaining it to operate the service, maintain conversation history, investigate misuse or comply with legal obligations.
Ask separately about prompts, responses, uploaded documents, embeddings or indexes, conversation memory, diagnostic logs, feedback and backups. Include connected services that receive the same information.
Current Anthropic documentation illustrates why product-specific review matters. Its commercial retention page, dated July 1, 2026, distinguishes standard API handling from products that preserve conversations and identifies exceptions. Its zero-data-retention guidance limits eligibility by product and arrangement and identifies additional exceptions.
This is an example of evidence to examine, not a recommendation or a complete assessment of that vendor. Ask any supplier to confirm the rule for your selected model, feature and organization in writing.
The US Federal Trade Commission’s January 2024 discussion of AI privacy commitments emphasizes that providers must honor their privacy and confidentiality promises. For procurement, preserve the relevant commitments and resolve conflicting statements before approval.
AI subprocessors: follow the data beyond the product name
An AI application may depend on model providers, hosting companies, search services, monitoring tools and support platforms. Their roles and access can differ, so do not assume every listed company receives the same data.
Request the current register and ask which entries apply to your product and enabled features. Check processing locations, support access, notification of changes and any contractual objection or termination process.
As a recent example, Anthropic’s Trust Center published a subprocessor update on October 14, 2026. The practical lesson is that an approved supplier’s processing chain can change after purchase; assign someone to receive and assess those notices.
AI vendor security questions should cover actions, not just storage
A drafting assistant and an agent that sends email or updates customer records have different failure consequences. Ask whether the product can operate read-only, require approval for external actions and expose an audit trail that identifies what happened.
Check connector scopes before connecting company systems. Our Google Workspace app-access audit explains how to connect each permission to an owner and business requirement.
For a global audience, the UK Information Commissioner’s Office opened an agentic AI call for evidence on October 8, 2026, covering issues including security, transparency and accountability. It is a consultation, not a new universal procurement rule. It reinforces the value of asking how an agent’s permissions and actions are controlled.
Fictional completed vendor comparison
Illustration only: Vendor A and Vendor B below are invented. Their documents, capabilities and answers are hypothetical. No actual company was assessed or tested.
The buyer is a fictional support team seeking reply drafts from approved policy text. It requires human approval, no automatic sending and documented data handling before customer information is introduced.
| Requirement | Fictional Vendor A | Fictional Vendor B |
|---|---|---|
| Applicable product terms | Provided terms naming the proposed business plan. | Provided a general website privacy notice; plan-specific terms missing. |
| Training use | Hypothetical contract excludes training on customer inputs and outputs; feedback is separately addressed. | Sales email says “private”; contractual training position unresolved. |
| Retention | Hypothetical schedule specifies 30-day operational content retention and separately lists exceptions. | “Deleted when no longer needed”; categories and timeframes missing. |
| Subprocessors | Dated register and change-notification procedure supplied. | Names its hosting provider but does not identify the upstream model provider. |
| Connector access | Documentation describes a limited connector; effectiveness still needs testing. | Requires broad mailbox access; narrower option unconfirmed. |
| Human approval | Draft-only configuration documented; automatic sending disabled for the proposed pilot. | Approval feature appears in the demo but purchased-plan availability is unresolved. |
| Assurance | Relevant report supplied for reviewer assessment; exceptions still need review. | Security badge shown; underlying report not supplied. |
| Exit | Export procedure and deletion-request process supplied. | Export format and deletion evidence unresolved. |
| Decision | Eligible for a synthetic-data pilot after remaining document review. | Do not connect customer data; request the missing evidence first. |
Vendor A has not “passed security.” It has supplied enough hypothetical evidence to justify the next controlled step. Vendor B’s missing answers are unresolved requirements, not proof of misconduct.
Do not average away a critical gap. If your requirement prohibits an unsupported data use, a lower price or better demo should not compensate for failing that requirement.
Use a controlled pilot to test the claims
Start with fictional or otherwise approved nonsensitive material. Record the plan, model, settings, connector permissions and test date so later results have a clear context.
- Test the business task. Use representative examples, missing information and difficult cases.
- Check authority boundaries. Confirm that a draft-only tool cannot send or change records through the configured workflow.
- Review output quality. Record factual mistakes, unsupported promises and corrections required.
- Check administration. Test adding and removing users, permission changes and available activity records.
- Check exit behavior. Test the available export and deletion workflow using harmless sample content.
- Document limits. A disappearing chat does not prove deletion from every backup, log or upstream system; obtain the applicable evidence.
Our AI email reply workflow provides fictional examples and approval checks for a support use case. Use the AI workflow ROI template to include review time, rework and setup costs when deciding whether the tool is worthwhile.
Approve a defined use, then monitor changes
Record the approved task, data categories, users, product configuration and restrictions. Name a business owner, technical owner and exception approver. “Approved AI vendor” is too broad if only one low-risk workflow was reviewed.
Reassess when the vendor changes model providers, retention terms, subprocessors, permissions or action capabilities. NIST’s AI RMF Manage guidance supports ongoing monitoring and documented management of third-party risks rather than treating procurement as a one-time exercise.
For departure or termination, use the SaaS offboarding checklist to remove access and transfer ownership. Contract cancellation, connector revocation and vendor-data deletion should each have an explicit completion check.
Buy the evidence-supported workflow
An AI vendor due diligence checklist should produce a clear decision: proceed to a controlled pilot, approve a bounded use, request missing evidence or decline the proposed workflow.
Ask specific questions, retain dated answers and test what you can observe. Share the questionnaire with the people responsible for operations, IT and customer data so that approval rests on a common evidence record.
Frequently asked questions
What belongs in an AI vendor due diligence checklist?
Include the intended use, data flows, training use, retention, deletion, subprocessors, access controls, agent permissions, security evidence, output evaluation, incident handling and exit terms. Record who reviewed each requirement and what evidence supports the decision.
Does “not used for training” mean the vendor stores nothing?
No. Training use and retention are separate. Content may remain for service operation, conversation history, safety review or legal obligations. Ask for category-specific periods and exceptions for the exact product and model.
What are AI subprocessors?
They are downstream providers involved in processing data under the relevant service arrangement. Their roles may include hosting, model processing, search or support. Review the applicable list, purposes, locations and change-notification process.
Is a SOC 2 report enough to approve an AI tool?
No. It is one piece of evidence. Check its scope, period and findings, then separately assess the product’s data handling, permissions, output behavior and suitability for your workflow.
What should a small business do when a vendor will not answer?
Record the requirement as unresolved. Restrict the evaluation to approved harmless data if appropriate, request clarification or choose an alternative. Do not treat silence as confirmation that a required control exists.
Sources & Fact-Checking
Reviewed on November 3, 2026: NIST’s generative AI risk profile and Manage guidance, FTC commentary on AI privacy commitments, current Anthropic commercial retention and Trust Center materials, and the ICO’s October 2026 agentic AI consultation. Government and standards sources provide risk-management context; vendor-authored pages describe that provider’s stated practices and are not independent audits.
- NIST: Generative Artificial Intelligence Profile — published July 26, 2024; foundational generative AI risk-management guidance.
- NIST AI RMF Playbook: Manage — ongoing risk decisions, monitoring and third-party management.
- FTC: AI Companies—Uphold Your Privacy and Confidentiality Commitments — January 2024 commentary on honoring data-use promises.
- Anthropic: Commercial data retention — dated July 1, 2026; product-specific retention and exceptions.
- Anthropic: Zero-data-retention eligibility — current scope, approval requirements and exceptions.
- Anthropic Trust Center — subprocessor information and an October 14, 2026 update.
- ICO: Agentic AI call for evidence — opened October 8, 2026; consultation context, not a final procurement standard.
The questionnaire, evidence categories and completed comparison are original editorial tools. Both comparison vendors are fictional. No real vendor’s security, contractual compliance or performance was independently verified; assess current purchase-specific documents and seek specialist review where the proposed use requires it.
