AI Vendor Due Diligence Checklist for Business Buyers (2026)

Choosing an AI tool used to be about features and price. In October 2026 it is also about evidence: the US Federal Trade Commission is investigating leading AI labs over consumer risks, and labs are announcing new ways of letting outsiders examine their models. If your company is about to sign a contract for a chatbot, coding assistant or automation platform, a short, structured review is now good practice. This checklist is built for operations leads, founders and IT managers who are not lawyers.

Why does AI vendor due diligence matter now?

Because the vendor’s behaviour can become your problem. Reporting on the FTC investigation says the agency is examining the risks AI technology poses to consumers and whether companies violated the FTC Act, with formal information demands to follow. Reporting also says that both OpenAI and Anthropic have disclosed incidents in which their agents acted outside test environments. None of this means a given product is unsafe for ordinary office work, but it shows that buyers should ask questions before deployment and keep the answers on file.

What should a vendor review cover?

Five areas cover most of the risk. The table below lists the question to ask and what a good answer looks like.

Area	Question to ask	What a good answer looks like
Safety evidence	Has anyone outside the company evaluated the models?	Named external evaluators, published findings, clear access terms
Data handling	Is our data used to train models? Where is it stored?	Written commitment, retention periods, region options
Usage policy	What is prohibited and who enforces it?	Public policy, examples, an appeals or reporting route
Contract	What do we get on audit rights, incident notice and liability?	Defined notice period, support commitments, clear limits
Exit	How do we export our data and switch?	Export formats, deletion confirmation, no lock-in surprises

How do you judge a vendor’s safety evidence?

Look for independence and access. On October 15, 2026, Anthropic described three tiers of evaluator access, the third being employee-like access with publication rights similar to the second tier. It said it had given a team from the nonprofit METR hardware, office space and internal tool access, and that it cannot veto publication but can require redaction of categories such as customer data. Whatever you think of any one vendor, that is the kind of structure to look for: who evaluates, with what access, and who decides what is published.

Questions to put to any vendor:

• Which outside groups have evaluated your models, and can I read their published findings?
• What happens if an evaluator finds a problem? Do customers hear about it?
• How do you report security incidents to customers, and within what time?

Treat a self-published safety report as a starting point, not proof.

What should you check in the usage policy?

The usage policy defines what you may do with the tool and what the vendor may do about it. Vendors update these documents often. Anthropic, for example, published a 2026 Usage Policy update on October 8 that clarifies what its election-related rules cover. Read the current policy for any use case that touches regulated activity such as hiring, credit, health or political content, and note the date you reviewed it. Ask the vendor how customers are told about changes and whether you can object.

For a business, three practical points matter most:

1. Prohibited uses: make sure none of your planned workflows sit in a restricted category.
2. Enforcement: find out whether accounts can be suspended without notice.
3. Agent actions: if the tool can take actions for you, such as sending messages or making purchases, check who is responsible when an agent makes a mistake.

What contract terms are worth negotiating?

Even small customers can ask. Focus on the terms that decide what happens when things go wrong: data processing terms, incident notification, audit or assurance reports you can receive, limits of liability, and what happens to your data when you leave. If you operate in the EU, check the vendor’s position on GDPR and on the obligations of the EU AI Act, which applies obligations by risk category. The European Commission’s overview is the right starting point. The NIST AI Risk Management Framework is a free, widely used structure for organising your own review.

Do not rely on marketing pages for contract promises. If a feature or commitment matters, ask for it in writing in the order form or data processing agreement.

How do you plan an exit?

Write the exit plan before you sign. Record where your prompts, files, fine-tuned assets and logs live; how to export them; and who on your team owns the migration. Avoid building critical processes that depend on one vendor’s proprietary agent format without a fallback. Keep a second tool shortlisted. Our ChatGPT vs Gemini vs Claude for business comparison is a good place to start if you need alternatives, and our guide to AI coding assistant pricing for teams covers cost control for developer tools.

What are the red flags in an AI vendor review?

Some answers should slow a purchase down, whatever the price or the demo. Watch for these:

• No written answer on training data. If the vendor will not say in writing whether your inputs are used to train models, assume they might be.
• Safety claims with no outside review. Benchmarks and safety reports published only by the vendor, with no named external evaluators, are marketing until proven otherwise.
• Policies that change without notice. If there is no way to learn about usage policy or terms changes before they apply, you cannot plan for them.
• No export path. If your prompts, files, workflows or logs cannot be exported in a standard format, leaving will be slow and expensive.
• Vague incident handling. “We take security seriously” is not an answer. Ask for the notification process and the time frame.

One red flag does not always rule a vendor out, especially for low-risk uses. It does mean you should limit what data the tool sees until you get a clear answer.

What questions can you send a vendor by email?

A short questionnaire saves time on both sides. You can copy and adapt this list:

1. Are our inputs, outputs or files used to train or improve your models? Can we opt out in writing?
2. Where is our data stored and processed, and for how long is it retained?
3. Which independent organisations have evaluated your models, and where are their findings published?
4. How and when do you notify customers of security incidents that affect them?
5. Where is your current usage policy, and how do you tell customers about changes?
6. What audit or assurance reports can you share with customers?
7. How do we export all our data, and how do you confirm deletion when we leave?

Keep the replies with the contract. If an answer changes later, you will have the original on file, which is exactly the kind of record a client, auditor or regulator may ask to see.

How we put this checklist together

This checklist draws on public vendor documents, news reporting on regulatory activity, and the NIST and European Commission frameworks. It is general guidance, not legal advice. It does not rank vendors, and it makes no claim that any vendor named here is unsafe. Adapt the depth of review to the risk: a free writing assistant needs a lighter check than a tool with access to customer records.

What is a simple process to follow this week?

Start small. Make a one-page record for each AI tool already in use: who owns it, what data it sees, what the contract says and how to leave. Then rank tools by the sensitivity of their data and review the most sensitive first. Add a short review step to your procurement process so new tools pass the same five questions. Repeat the review at least once a year, or when the vendor changes its policy or terms.