There’s a free service we don’t advertise: spending an hour with a business that’s frustrated their AI project didn’t deliver, and helping them work out why. After several dozen of these conversations across the last year, the failures cluster into a small number of repeating patterns. The same mistakes, the same blind spots, across very different businesses.
The good news is that all of them are avoidable. The bad news is that the avoidance has to happen before the project starts — by month four it’s usually too late to save the original budget.
Here are the six we see most often.
1. Buying the tool before sizing the problem
The single most common pattern. A founder reads about a tool, gets excited, signs up for a trial, hands it to a member of staff, and waits to see what happens. Sometimes it sticks. Usually it doesn’t. By month three, the subscription is on autorenewal and nobody can remember whether anyone is actually using it.
The underlying error is treating the tool as the project. “We adopted Copilot” isn’t a project. It’s a procurement event. A project requires a defined workflow, a defined success metric, and a defined evaluation window.
The antidote is the fifteen-minute rule: before any AI tool gets bought or any subscription gets activated, fifteen minutes of arithmetic on hours-per-week saved versus annual cost. If the saving doesn’t obviously beat the cost, don’t buy. If it does, write the number down — and re-check at day 60.
2. Treating AI like it’s magic
The over-correction in the other direction. “We can use AI for that” without any sense of what AI is actually good and bad at. The result is projects that ask AI to do things it’s structurally unsuited to — picking part numbers from manufacturer catalogues, estimating labour cost on a job, making clinical decisions, choosing legal positions.
Large language models are extraordinary at plausible. They are not extraordinary at correct, especially in domains where correctness has a specific, narrow technical answer. A part number is correct or it isn’t; an LLM gives you a part number, often confidently, sometimes wrong.
The antidote is to ask, for any AI use case: “what happens when this is confidently wrong?” If the answer is “nothing serious, a human catches it” — proceed. If the answer is “a customer gets billed wrongly / a patient gets the wrong dose / a part order goes through with the wrong SKU” — change the architecture so a human is in the loop, or pick a different problem.
3. Outsourcing the thinking to the vendor
In a small business, this looks like asking the vendor “what should we use AI for?”. In a large organisation, it looks like commissioning a strategy from a Big Four consultancy. Both produce slide decks and very little operational change.
The reason is straightforward: the vendor’s incentive is to sell you their tool, and the consultancy’s incentive is to be re-engaged for the implementation. Neither has a strong incentive to tell you that the most leveraged opportunity in your business doesn’t involve their product.
The antidote is to do the workflow audit yourself before talking to anyone. Walk the floor. Ask each member of staff what bit of their job they’d like to never do again. Sum the hours. Then go to vendors with a specific brief — “we want to automate the quote-to-invoice flow, here’s the volume, here’s the saving we’re targeting” — rather than an open question.
4. Underestimating the data work
The most under-budgeted part of nearly every AI project. The model isn’t the hard bit; getting clean, well-structured, well-permissioned input data into the model is the hard bit. Many projects never recover from a discovery moment in week 5 where it turns out the source data is split across three Excel spreadsheets, two SharePoint folders, and someone’s laptop.
This is particularly bad in public-sector work where the source data lives behind authentication that takes weeks to navigate, in formats that nobody’s touched in a decade, with PII issues that need a fresh DPIA before anything can move.
The antidote is to do a data audit in week one, before any architecture decision. List every data source. Document who owns it. Confirm the access path. Sample the actual records. Identify quality issues. Build the data prep budget assuming the data is worse than people are claiming. Most projects come in 30–50% under-budget on data work; pad accordingly.
5. Picking the wrong architecture for the data sensitivity
Particularly common in regulated environments — NHS Trusts, police forces, defence-adjacent businesses. A business chooses an off-the-shelf SaaS tool because it’s cheap and easy, then discovers six months in that the data they wanted to feed it can’t legally leave the perimeter. The project either gets quietly mothballed or rebuilt from scratch on different infrastructure.
The error is choosing the model and tool first, before checking the data flow. The right order is the opposite: check the data classification, derive the architecture constraint, then pick a tool that fits. UK-hosted SaaS, UK-resident managed inference, and air-gapped on-premise are all viable for different sensitivity levels. SaaS tools that won’t commit to UK data residency are not viable for any sensitivity level above OFFICIAL.
The antidote is the DPIA-first rule: information governance assessment before procurement. The DPIA tells you which architectures are viable; the architecture tells you which tools are viable. Doing it in any other order risks a six-figure rebuild.
6. Skipping the human side
The most insidious failure mode. The system gets built, the launch happens, the metrics look fine for the first month — and then quietly the team stops using it. Reverts to the old way. Tells the manager “yeah it’s great” when asked. Six months later, the subscription is still being paid, the system isn’t being used, and nobody wants to be the one to admit it.
The reasons are usually some combination of: the system is harder to use than the old way, the team wasn’t involved in the design, the training was 30 minutes on launch day and never repeated, the change-management piece was deemed ‘not technical work’ and nobody owned it.
The antidote comes in three parts. First, involve the actual users in the design. Not their manager. The person whose job is being affected. Second, train properly on launch day and again at day 30. The 30-day training is the one that sticks because by then the team know what they don’t know. Third, measure adoption, not just availability. “The system is live” is not a success metric. “The team are running 80% of jobs through the new flow at day 60” is.
A pattern across all six
If you re-read the six, a single underlying mistake becomes obvious. All six are variations of moving fast on the procurement and architecture decisions, and slow on the workflow, data, and people decisions. The dominant culture in 2026 is to do the technology first and then to retrofit the rest. The successful projects do exactly the opposite.
There is a useful test you can apply to any AI project that’s being proposed in your business right now: ask “what does success look like at day 90, measured in numbers we already track?”. If you can’t answer it, the project isn’t ready to start. If you can answer it, write the number down and pin it to the wall — that’s your evaluation criterion.
The businesses that get a good return on AI in 2026 aren’t doing anything magic. They’re running the workflow audit first, sizing the prize honestly, picking architectures that fit the data, and treating the human side as half the project. That’s it.
If you’d like a hand running that workflow audit — or you’ve got a project that’s six months in and not delivering, and you want a second opinion before you write it off — that’s exactly the conversation we have for free. Half an hour, no obligation, and we’ll tell you straight what we’d do.