Every Ai tool I trial looks good in the demo. That is what a demo is built to do, and after enough of them you stop being impressed by the part where it works. The question I have learned to ask instead is duller and takes a good deal longer to answer: if this company changed its terms, had a bad month, or disappeared on Friday, what would I lose on Monday? Most vendor websites will not tell you. The answer sits in the terms, in a subprocessor list nobody links to from the homepage, or nowhere at all, and that gap is what decides whether a tool gets anywhere near real work in my business.
The cost of skipping the boring questions
The government's own research suggests most businesses are not asking them. The Cyber Security Breaches Survey 2025/2026, run by DSIT and the Home Office across 2,112 businesses, found that 43% had identified a breach or attack in the previous twelve months, which works out at roughly 612,000 UK businesses. Around 31% of businesses were using Ai, adopting it or actively considering it, and of that group only 24% reported having any security practice or process in place to manage the risks that come with it. Three quarters of the businesses putting Ai into their operations have nothing written down about what happens when it goes wrong.
The same survey shows where the gap opens, which is at the point of purchase. Only 22% of businesses said cyber security was a consideration to a large extent when buying new software, while 38% said it was not a major concern because they buy from established companies, and 12% did not consider it at all. Scrutiny of suppliers is thinner still, with 15% of businesses having formally reviewed the risks posed by their immediate suppliers, 6% having looked at their wider supply chain, and just 11% requiring their suppliers to hold any certification at all.
Verizon's 2026 Data Breach Investigations Report shows what that arrangement costs from the other end. Third-party involvement in breaches rose 60% in a year and now accounts for 48% of all breaches, so about half of the incidents in that dataset arrive through somebody else's software. The same report found frequent use of Ai tools by employees jumped from 15% to 45% in a single year, most of it outside any approval process. If you are not choosing your Ai tools deliberately, your staff are choosing them for you.
Why the check gets skipped
An Ai tool does not arrive the way a supplier arrives. There is no procurement process, no contract review and no onboarding call, because it turns up as a card payment of a few tens of pounds a month and starts touching customer data within the hour. Nothing about that experience prompts you to behave as though you are appointing a supplier, which is exactly what you are doing. The sums are small enough that the decision never reaches the person who would ask the awkward questions, and in a small business that person is usually the owner, who bought it.
The demo compounds the problem. It shows the tool working on a clean example chosen by the vendor, which tells you about its ceiling and nothing about its floor. Commercially the floor is what matters: how it handles your messiest input, what it does when its model provider has an outage, and whether it says so or quietly produces something plausible and wrong. I wrote a while ago about a content pipeline of my own that failed silently for three months, and the lesson holds just as firmly for the tools you buy as for the systems you build. Silent failure is the default behaviour of automated work, and a subscription does not change it.
What a tool worth trusting has already published
The vendors I end up trusting are boring in one specific way: they have already written the answers down. Their terms state plainly whether your inputs train their models, and where the default is on, the business tier turns it off in a contractual term instead of a support email. Retention is a stated number of days. There is a named list of subprocessors, so you can see which model provider actually sits behind the badge, and a data processing agreement you can sign without having to ask for it twice.
Independent assurance is starting to catch up with that expectation. ISO/IEC 42001, the first management system standard for Ai, sets out how an organisation governs the Ai it develops, provides or uses, and certification against it is voluntary and audited by an independent body. A vendor holding it has at minimum been made to write its own controls down and have somebody else check them, which is more than most software companies have ever had to do. The UK regulatory direction points the same way. The ICO consulted on draft guidance for automated decision-making and profiling until 29 May 2026, and the government is preparing the secondary legislation that will require the ICO to produce a statutory code of practice on Ai and automated decision-making, a commitment made during the passage of the Data (Use and Access) Act 2025. However you feel about another code of practice, the questions below will be put to you by a client, an insurer or a tender document sooner than you think.
Where a vendor will not answer, the silence is still useful information. A company that cannot answer a plain question about retention or training defaults inside a week will not answer one in the middle of an incident, and an incident is exactly when you will need it. I treat a slow or evasive reply at trial stage as a finding in its own right, and I have walked away from capable tools on that basis alone.
The five questions I ask before a tool touches real work
- What happens to what I put in? I want four answers: whether my inputs train the vendor's models and what the default setting is, how long they are retained, which country they are processed in, and what is actually deleted when I cancel. If those four take longer than ten minutes to find in the published terms, that difficulty is my answer.
- Can I get my work back out in a form that is still worth having? An export button is not the test. The test is whether the export carries the structure as well as the content, because a spreadsheet of records stripped of the relationships between them is a filing cabinet emptied onto the floor. Where the value only exists inside the vendor's own interface, I am renting it.
- How does it behave when it is wrong? Every Ai tool is wrong sometimes, so what I care about is whether it goes wrong loudly or quietly. I look for a log I can read, a record of what it did and when, and a point where a person approves anything with money or a client's name attached to it. Decide which decisions the tool will never be allowed to make on its own, and set that boundary before you switch it on rather than after the first bad output.
- Who is accountable, and to whom? A named company with a registered address, a data processing agreement, a published subprocessor list, and ideally ISO 27001 or ISO 42001 certification behind it. Where the tool is a thin wrapper around somebody else's model, I want to know whose model, because that is the supplier whose outage quietly becomes my outage.
- What breaks if this is gone in ninety days? Write the sentence out in full and read it back. If the honest answer is that a core process stops and there is no manual fallback, the tool has earned a contract, a named owner and a documented workaround, and it should not still be sitting on somebody's personal card.
None of those five questions is about the model, and that is deliberate. Model quality is the one part of the decision that improves on its own every few months without you lifting a finger. Data handling, exit routes, failure behaviour and accountability only improve if somebody makes them a condition of buying, and in a small business that somebody is you. Take the Ai tool you rely on most and run the five questions over it this week. If you cannot answer two of them today, you have just found the most useful hour of work in your quarter.