AI Vendor Due Diligence in 2026: A Buying Checklist for Small Teams
A new AI tool may promise faster work, fewer support tickets, or better reports. A polished demo can make the choice look easy. The hard questions begin when the tool needs company files, customer data, or access to business systems. Before buying, a team should know what the product can do, what happens to its data, who is responsible for errors, and how to leave the service if needed.
This guide gives small teams a practical AI vendor due diligence process. It is meant for business software, not a high-risk industry-specific legal review. You can use it before a paid pilot or a longer contract. The goal is a clear decision supported by evidence, not a long form that no one reads.
Define the Job Before Comparing Vendors
Write the task in one sentence. For example, we need to help staff search the approved help center and draft answers with sources. Then list the minimum needs: supported languages, access controls, response quality, export, and budget. A tool that solves a different problem well is still the wrong purchase.
Include the current cost of doing the task. Count staff time and common errors. If a team spends two hours a week on the work, a costly AI platform may not pay off. If the task affects many customers, reliability and safe escalation may matter more than a low price. Keep these facts in the buying record.
Name an owner for the decision
One person should own the pilot and gather feedback from users, security, finance, and legal contacts as needed. The owner does not need to know every technical detail, but should know who can answer each risk question. Without an owner, a trial can become a permanent integration without a formal decision.
Ask Where Your Data Goes
Request a clear list of data the product collects, processes, and stores. Ask if prompts, files, outputs, logs, and user details are used to train models. Check retention, deletion, sub-processors, and available data regions. Do not assume every plan has the same privacy settings. Get written answers that apply to the service and plan you intend to use.
A small support team might send customer messages to an AI tool. Those messages could contain names, addresses, and purchase details. Test with masked data first. If the tool needs personal data in production, check the legal basis and contract terms for your regions. The UK Information Commissioner’s Office notes the value of due diligence on accuracy, source, and data duties when buying AI systems.
Check Security and Access
Ask whether staff can use single sign-on, multi-factor authentication, and role-based permissions. Check admin logs, key management, and how a lost account is disabled. If the tool connects to email or a database, inspect the exact permissions it asks for. A document summarizer should not need full control of a company’s mailbox.
Request a security overview and the relevant audit reports or certifications, if available. A badge can support a review but does not answer every question. Look at the specific data flows and controls. If the vendor says all data is encrypted, ask how access is managed and who can view support logs.
Test the least-privilege setup
Create a pilot account with only the data and rights it needs. Try a request for a record outside that account’s role. The tool should fail safely. If it can send messages or change data, keep those actions behind review until the team is satisfied with the controls.
Measure the Product on Your Own Work
Prepare a small test set of realistic tasks with known answers. Include normal work, missing information, and cases that require a human. Compare results with a manual baseline. Record correct outcomes, serious errors, time saved after fixes, and how often staff must intervene. Ask users if the output is clear enough to check.
For a contract search tool, a good answer might find the right clause and link to it. A bad answer may blend terms from two contracts. For a sales assistant, a wrong customer match can be more serious than a poor sentence. Score the risks that matter to your task, not a generic vendor benchmark.
Study the Exit Plan
Ask how to export your content, settings, records, and audit history. Check how the tool deletes data after termination and whether backups remain for a set period. Find out what happens to workflows if the vendor changes model providers, raises prices, or ends a feature. Avoid building a critical service around a function that has no clear replacement.
Run a small export during the trial. Open the output and check that it is useful. A promise of export is less valuable than a file your team can actually read. Note which custom prompts, connectors, and permissions would need to be rebuilt elsewhere.
Read the Service Terms That Affect Operations
Look for uptime commitments, support hours, incident notices, data breach steps, product change rules, and limits on liability. A free trial may have very different terms from an enterprise contract. Ask what happens when an API fails and whether the vendor gives a useful status page. Do not treat a service-level agreement as a guarantee that your own workflow will be error-free.
The NIST Generative AI Profile discusses applying controls to third-party services, including procurement due diligence and service agreements. The useful lesson is to treat vendor risk as part of the business system, not as a problem transferred away by buying software.
Compare Price at Real Volume
A plan may charge per user, request, token, page, hour, or completed workflow. Ask for the unit that matters to your use case. Estimate low, normal, and busy months. Include storage, integrations, premium models, and human review time. A tool with a low base fee can still cost a lot if the workflow makes repeated calls.
Keep a written assumption sheet. For example, if each case takes two model calls and staff handle 500 cases per month, test the price for 1,000 calls plus any storage or platform fees. Then add a margin for retries. Check what the provider does when a limit is reached: stop service, charge more, or reduce capacity.
Ask About Model and Feature Changes
AI products evolve quickly. Ask how customers learn about model changes, new data processors, and retired features. A change may improve quality but alter behavior that your team depends on. Keep a test set so you can check the new version. If the vendor will not provide notice or version controls, decide whether that uncertainty is acceptable.
Also ask how the product handles mistakes. Can a user correct output? Can admins review actions? Can the team pause an integration? If a vendor can show how incidents are investigated and fixed, that may matter more than a long list of demo features.
A Practical Vendor Review Checklist
- A clear business job and named owner
- Written data use, retention and deletion terms
- Least-privilege access and audit controls
- Test results on representative work
- A safe human handoff for unclear cases
- Export and termination path tested
- Pricing estimated at actual volume
- Support and incident process documented
- Change notices and regression tests planned
Use the same checklist for every candidate. Mark each item as passed, open, or unacceptable. Some gaps can be fixed by contract or configuration. A severe privacy or access gap may be a reason to stop. Do not average critical failures into a pleasant overall score.
How to Make the Final Decision
Hold a short review with the pilot owner and affected teams. Decide whether the tool solves enough real work to justify its cost and risk. Write down the reasons. If the answer is yes, begin with limited users and access. If important questions remain open, extend the pilot without sending more sensitive data. If the tool cannot meet a critical rule, choose another path.
ISO/IEC 42001 sets out an AI management system approach with roles, processes, and ongoing improvement. A small company need not claim certification to benefit from that discipline. A simple purchase record, responsible owner, and regular review can prevent an AI tool from becoming an unexamined dependency.
Final Takeaway
AI vendor due diligence is a practical buying habit. Define the job, test with your own work, check data and access, and prove that you can leave the service. The best vendor is not always the one with the most features. It is the one that solves the task within the rules your organization can support.
References
NIST Generative AI Profile, ICO contracts and third parties, and ISO/IEC 42001.
