Most of the Ai conversations I have with UK business owners start in the same place. Somebody on the board has asked what the company is doing about Ai, a few licences have been bought, one or two people are experimenting, and six months in nobody can point to a measurable result. The tools work and the demos were impressive, but the business runs exactly as it did before, except that it now carries the cost of the subscriptions and a quiet suspicion that Ai is overhyped. If that sounds familiar, the fault is unlikely to sit with the technology you chose. It sits with what you asked that technology to run on top of.
The measured failure rate of business Ai projects
For a technology sold this hard, the delivery record is poor. Research by the RAND Corporation, built on interviews with 65 experienced data scientists and engineers, estimates that more than 80% of Ai projects fail, roughly twice the failure rate of IT projects that involve no Ai at all. MIT's Project NANDA reached a harsher figure for the current generation of tools. Its State of Ai in Business 2025 report, which drew on 150 leadership interviews, a survey of 350 employees and analysis of 300 public deployments, found that around 95% of enterprise generative Ai pilots deliver no measurable impact on profit and loss.
The trend is also getting worse. S&P Global Market Intelligence surveyed just over 1,000 IT and business professionals in 2025 and found that the share of companies abandoning most of their Ai initiatives had jumped from 17% to 42% in a single year, with the average organisation scrapping 46% of its proof-of-concept projects before they reached production. Budgets are being spent and pilots are being run, and in most businesses the work is quietly shelved before it ever touches a customer.
For a 20-person firm those percentages turn into real money. A few thousand pounds a year in licences is survivable, but the months of management attention a failed pilot consumes, and the scepticism it leaves behind with the team, are much harder to win back. The second attempt always starts in a deeper hole than the first.
It would be easy to read those numbers as proof that the technology itself has failed. However, none of the three studies traced the failures back to the models. The MIT team was explicit that the gap between the roughly 5% of pilots that succeed and the rest comes down to how the tools are integrated into the business, what its authors call a 'learning gap' between organisations and the systems they adopt. That matches what I see inside UK firms every week, because the work that decides the outcome happens before and around the tool, in the process and the data it lands on.
Why adding Ai to a broken process makes it worse
I spent more than fifteen years in regulated manufacturing before starting iS3, and the pattern behind most failed Ai projects is one every Lean practitioner will recognise: automate a bad process and you get the same bad results, produced faster and with more confidence. Ai amplifies whatever operation it lands in, which is useful when the underlying process is stable and measured, and expensive when it is not.
The RAND interviews put numbers against this. The two most common root causes, raised spontaneously by more than half of the specialists interviewed, were people misunderstanding the problem the project was supposed to solve, and limits in the quality and usefulness of the data available. Both problems existed in the business long before any pilot started; the pilot simply made them visible and put a monthly cost against them.
The UK picture points the same way. When the Office for National Statistics asked firms about barriers to adopting Ai, the most common answer was difficulty identifying activities or business use cases, cited by 39%, ahead of cost at 21% and skills at 16%. The biggest barrier, in other words, is that businesses do not know what they would point Ai at, and RAND lists chasing the latest technology for its own sake among the most frequent paths to failure. That is what 'just add Ai' looks like from the inside, a purchase hunting for a problem.
Picture how this plays out in a typical firm. A director buys licences for a drafting tool, the team tries it on live client work, and the first thing the tool meets is a quoting process with three versions of the price list, half the history sitting in email and the exceptions held in one estimator's head. The output looks confident and is wrong in ways nobody has time to check, trust drains away within a fortnight, and the licences quietly lapse at renewal. The failure was built into that process long before the tool arrived.
What the successful minority do differently
The MIT research is worth reading because it also studied the pilots that worked. Successful adopters embedded Ai deeply into one high-value workflow instead of scattering licences across the business and hoping, and they tended to buy specialised tools and partner with vendors, an approach that succeeded around 67% of the time, against internal builds which succeeded roughly a third as often.
There is a second habit worth copying. The successful pilots started narrow and measurable, one workflow with a clear unit of output rather than a company-wide rollout, and they kept the scope tight until the numbers proved the case. A boring first project that pays for itself buys you the credibility, the data habits and the internal appetite for the more ambitious second one.
Behind both findings sits the same discipline. The businesses that get results treat Ai as a change to how the operation runs, with the software as the smallest part of the job. Before anything goes live they can describe the process it will change, they know where the data lives and trust it, and one named person owns the outcome with a budget attached. The boundaries are written down too, covering what the Ai may do on its own, what a human must approve and what it must never touch. At iS3 we call this governance-led Ai, and the honest version of the pitch is that the first month of a good Ai project usually contains no Ai at all.
What to fix first
- Map one process end to end, as it actually runs. Pick the process that eats the most time or leaks the most margin, walk a single real job through it, and write down every step, handoff, delay and exception (the version in the manual, if a manual exists, is usually fiction). Most owners find the real constraint within an hour, and it is rarely where they expected.
- Get the data that process touches into one trusted place. If quotes live in one spreadsheet, job records in another and prices in somebody's head, an Ai tool has nothing reliable to work from. Choose one system of record for each type of information, move to it, and retire the duplicates.
- Give the project one named owner with real authority. That person holds the budget, can change the process, and signs the go-live decision; a committee cannot do any of those things quickly enough to keep a pilot alive.
- Write the decision boundaries before the pilot starts. Agree what the tool may do without a check, what needs human sign-off and what it must never touch, and put it on a single page. ISO 42001, the management system standard for Ai, formalises exactly this idea if you ever need to evidence it to a customer or a regulator.
- Baseline the numbers. Measure the process as it runs today, whether that is time per quote, error rate or cost per job, because without a baseline you cannot tell the difference between a pilot that worked and a pilot that people are being polite about.
None of this groundwork needs a data scientist, and most of it costs attention instead of money, which is why it gets skipped. The consistent lesson, from RAND's interviews through to MIT's 95%, is that the pilots which pay back land on a mapped process, trusted data and a named owner, while the ones that stall land on whatever happened to be lying around. Do the fixing before the buying. If you would like a second pair of eyes on where your operation stands, that readiness work is exactly what iS3 does, and it is a far cheaper conversation than a failed pilot.