What should a founder check before buying an AI tool or commissioning a pilot?

Look beyond the demo

A good demo can still hide weak data controls, unclear liability or a handover problem. The question is not only whether the tool works in a presentation. It is whether it works in your business, with your data, under your responsibility. The ICO advises due diligence before procuring AI systems, datasets or coding, including checking accuracy, bias and design trade-offs, and planning for deletion or return of personal data and support with UK GDPR obligations.

Treat the supplier as part of the risk

If a vendor hosts the model, stores prompts, trains on your content or connects to your systems, they become part of your operational and governance risk. That means you need to ask who owns what, who can change what, and what happens if the relationship ends. Official procurement guidance also highlights AI assurance, procurement transparency and contract clarity as part of the buying process.

0 of 10 complete

Accuracy is not enough

Founders often ask whether the AI is ‘accurate’. That is important, but incomplete. You also need to know how often it is wrong in the cases that matter to you, whether it fails safely, and whether the system makes it easy to correct or override a bad answer. The Cabinet Office AI Assurance Questionnaire is designed to prompt this kind of lifecycle thinking, including procurement and public transparency questions.

Liability should be explicit

The government Digital, Data and Technology Playbook says AI contracts should consider where liabilities sit if the AI outcome is wrong, especially where data, the algorithm and model training are split across parties. For a founder, that means a contract should not simply say the AI is ‘provided as is’ and leave it there. You need enough clarity to understand who bears the cost and effort of fixing problems.

Know what you can take with you

A pilot can be technically successful and still leave you trapped if the supplier controls the account, the prompts, the data pipeline or the hosting environment. GOV.UK guidance on purchasing strategy says buyers should be explicit about ownership of data and intellectual property, including software code and business rules. That matters because the useful part of many AI builds is not just the model. It is the workflow around it.

Admin access should not be an afterthought

The NCSC advises organisations to protect admin accounts with 2-step verification, keep recovery information current, use separate admin and normal user accounts, and know how to recover access if an admin account is lost or compromised. That advice applies directly to AI tools that can send messages, change data or trigger workflows. If the supplier controls the only admin login, you do not really control the system.

Start with the smallest useful data set

Do not give a new AI tool full access to your records just because it can connect easily. Start with the minimum data needed for the pilot, and be clear about whether that data includes personal data, confidential material or payment-related information. The ICO specifically recommends considering deletion and return clauses, and support for UK GDPR security and breach obligations, when procuring AI-related services.

• Ask where data is stored and which vendors can access it.
• Check whether logs include personal or sensitive information.
• Confirm retention periods for prompts, outputs and uploaded files.
• Make sure there is a process for deletion or export at the end of the pilot.
• Review whether human approval is needed before any external action is taken.

1. 1

   Define one outcome

   Choose the one business outcome you need to prove. For example: reduce manual triage time, draft better first responses, or classify requests more consistently.

2. 2

   Set failure conditions

   Write down what would make the pilot unacceptable. That might include wrong recommendations, no audit trail, weak account controls or unclear ownership.

3. 3

   Test handover early

   Before the pilot ends, ask how the system will be documented, exported and maintained by your own team or another supplier.

4. 4

   Review the contract before broad rollout

   Make sure the contract reflects the way the tool actually behaved in testing, not just the original sales description.

0 of 7 complete

These are not deal-breakers every time

Some issues can be fixed by narrowing the pilot, changing the architecture or adding guardrails. But if the answers remain vague, the safest move is to slow down. That is not caution for its own sake. It is basic commercial discipline.