Buying an AI tool can look deceptively simple: choose a subscription, connect a mailbox or customer system, and invite the team. The difficult questions often appear later, when confidential information has already been entered, staff depend on the output, or the supplier changes the product.
A short due-diligence process helps a small business understand what it is actually buying, what data the system receives, and what happens when it fails.
Start With the Business Decision
Before comparing products, define the job. What decision or task will the tool support? Who will use it? Which data will it need? What is the cost of an incorrect output? Which actions must remain subject to human approval?
A clear use case makes supplier answers testable. “Uses enterprise-grade AI” says very little. “Must summarise support tickets without retaining customer data or sending replies automatically” creates requirements that can be checked.
1. What Data Will the Tool Receive?
List the data involved: names, contact details, customer messages, employee records, contracts, source code, financial information, health data, credentials, or commercially sensitive documents.
Minimise this before procurement. If the tool can deliver value using anonymised, redacted, or less detailed information, design the workflow that way.
2. Is Our Data Used to Train or Improve Models?
Ask whether prompts, uploaded files, outputs, feedback, and metadata are used to train, fine-tune, evaluate, or improve any model. Check whether the default differs between free, consumer, business, and enterprise plans.
Opt-out wording should be explicit and contractual where the issue matters. A dashboard switch may change, and a marketing page is not the same as a binding commitment.
3. Where Is Data Stored and Processed?
Identify hosting regions, international transfers, remote support access, and every material sub-processor. Ask how the supplier informs customers when locations or sub-processors change.
If personal data is involved, the business needs a lawful transfer and processing arrangement, not simply a claim that the provider is “GDPR ready”.
4. Who Is the Controller and Who Is the Processor?
Data-protection roles follow what each party actually decides and does. A supplier processing personal data only on documented instructions may be a processor. If it uses the information for its own purposes, it may be a controller for that processing.
The ICO’s AI contracts and third-party audit guidance recommends documenting roles throughout the supply chain and setting out responsibilities, processing instructions, controls, and decision boundaries in writing.
5. How Long Is Information Retained?
Ask about active data, logs, backups, deleted accounts, cached content, abuse monitoring, and support records. Confirm whether administrators can set retention periods and permanently remove prompts, files, embeddings, and generated outputs.
6. What Security Controls Protect the Service?
Look for practical controls rather than a row of certification logos:
- Multi-factor or phishing-resistant authentication.
- Role-based access and separate administrator permissions.
- Encryption in transit and at rest.
- Audit logs and exportable activity records.
- Secure development and vulnerability management.
- Independent security testing.
- Incident detection, notification, and response.
- Controls that prevent one customer’s data leaking to another.
The NCSC’s guidance for secure AI development advises organisations to assess and monitor AI supply chains, protect models, prompts, data and logs, and require suppliers to meet appropriate security standards.
7. Can We Control What the AI Can Access and Do?
For connected or agentic tools, ask for granular permissions. Can the system read an inbox without sending mail? Can it prepare a CRM update without committing it? Can access be limited to selected folders, teams, customers, or record types?
Choose the smallest useful permission set. High-impact actions should support approval gates, limits, and rapid revocation.
8. How Accurate Is It for Our Use Case?
Supplier benchmarks may not reflect your language, customers, documents, or workflow. Define an acceptable error rate before procurement and test the tool on representative examples, including incomplete, unusual, and adversarial inputs.
Record false positives, missed information, fabricated claims, inconsistent answers, and performance across relevant user groups.
9. How Can Staff Check an Output?
Useful systems expose sources, confidence, version information, or a clear activity history. If the tool produces a recommendation with no way to inspect the evidence, human review may be little more than guesswork.
10. What Happens When the Product Changes?
AI services can change model, prompts, limits, features, policies, and sub-processors quickly. Ask how material changes are communicated, whether versions can be pinned, and whether the customer can test an update before it affects a live workflow.
11. What Happens During an Incident or Outage?
Confirm notification times, support routes, recovery targets, service status, breach cooperation, and access to logs. For an important workflow, define a manual fallback and make sure the business can continue if the service is unavailable or suspended.
12. Can We Leave Without Losing Control?
Check contract length, price changes, data export, deletion evidence, integration removal, and ownership of prompts, configurations, fine-tuning data, and generated material. Avoid creating a process that cannot function or be reconstructed outside one supplier.
When Is a DPIA Needed?
If the proposed use is likely to create a high risk to people’s rights and freedoms, a Data Protection Impact Assessment may be legally required. The ICO recommends considering a DPIA at the procurement stage so privacy and risk controls shape the choice before deployment.
Its AI accountability and governance guidance also stresses that buying from a third party does not remove the customer’s responsibility to evaluate trade-offs and demonstrate compliance.
A Simple Approval Record
For each approved tool, keep a short record containing:
- The business owner and intended use.
- Approved users, data, and integrations.
- Supplier and sub-processor documents reviewed.
- Controller and processor roles.
- Security, retention, and training settings.
- Testing results and known limitations.
- Required human approvals.
- Review date, renewal date, and exit plan.
The Bottom Line
An AI supplier is part of the business’s data and operational supply chain. The cheapest time to discover an unacceptable retention policy, weak access control, or unusable exit process is before the contract is signed.
Define the use case, minimise the data, test real performance, and make the supplier’s promises specific enough to verify. Good due diligence does not need to be enormous; it needs to happen before convenience turns into dependency.
This article provides general information and is not legal or data-protection advice.