Why Most AI Projects Should Never Exist
Most AI initiatives burn cash because they automate nothing, fix no bottleneck, and create new risks at scale today instead.
Walk into any large organisation right now, and you’ll find the same pattern: dozens of AI pilots, a handful of internal demos, and a quiet backlog of “promising use cases” that never made it past a slide.
This isn’t because teams are lazy or talent is weak. It’s because AI is being treated like a feature, not an investment thesis.
If you want AI to create value, you need a harsher default: most AI projects should be rejected at the door. Not because AI “doesn’t work”, but because most proposals don’t meet the basic conditions for AI to work profitably and safely inside a real business.
The numbers are now catching up with the hype. Gartner has been blunt: it expects over 40% of agentic AI projects to be cancelled by the end of 2027 because of rising costs, unclear value, or weak risk controls.
So the question isn’t “How do we do more AI?”
It’s “Which AI should never be allowed to exist?”
The real reason AI projects fail: they start with the model
Most AI programmes still begin with a solution (“let’s use an LLM”, “let’s build an agent”, “let’s predict churn”) rather than a constraint.
But businesses don’t pay for models. They pay for outcomes: reduced cycle time, fewer errors, higher conversion, lower loss rates, faster decisions, better compliance, and cheaper operations.
When you start with a model, you end up with:
a prototype that impresses,
a workflow that hasn’t changed,
and a set of new operational and legal risks that now need owners.
This is why the “pilot-to-production” gap is so wide. S&P Global Market Intelligence reported that the share of companies abandoning most of their AI initiatives rose sharply year-on-year, and organisations scrapped a large portion of proofs of concept before production.
If you want a simple mental model: AI dies when it meets the business.
Not because the model is weak, but because reality is messy.
AI should be treated like a capital allocation decision
A good AI project is closer to a factory upgrade than an app experiment. It changes processes, controls, roles, and accountability.
That means it needs a higher bar than “we could”.
Here’s the bar I recommend:
An AI project is only worth doing if it is:
attached to a measurable business bottleneck,
deployable into a real workflow,
supported by data you can defend,
governable under regulation and audit,
cheaper (or better) than the non-AI alternative.
If you can’t clear those five, it shouldn’t exist.
The AI Triage: a “kill-first” filter that saves budgets and reputations
Below is a practical triage you can run during a 30–60-minute meeting. If a project fails any of these tests, you either kill it or shrink it until it passes.
1) Bottleneck test: “What is the constraint we are buying back?”
If the proposal can’t name the operational constraint in one sentence, it’s theatre.
Good constraints sound like:
“Invoice exceptions take 9 days because humans re-key data from PDFs.”
“Underwriting review time is dominated by document chasing and summarisation.”
“Customer onboarding stalls because KYC packets are incomplete.”
Bad constraints sound like:
“We want to modernise.”
“Competitors are doing GenAI.”
“We need an AI strategy.”
Kill rule: If the constraint is vague, the project is a vanity project.
2) Counterfactual test: “What is the non-AI fix?”
Every AI plan needs a non-AI baseline. Often, the best solution is boring:
better forms,
fewer handoffs,
a data cleanup,
a rules engine,
a template library,
stronger search,
clearer approvals.
If a £50k process redesign produces 70% of the gain, why would you fund a £1m AI build with ongoing inference costs and new risks?
Kill rule: If the non-AI alternative is cheaper and “good enough”, stop.
3) Workflow test: “Where exactly does this land?”
AI value is not in the chat window. It’s in the workflow step that disappears.
So force specificity:
Which role uses it?
At which moment?
What input triggers it?
What output changes a decision?
What is the human override?
What system records the outcome?
If the answer is “people will use it when they need it”, adoption will be random, impact will be unmeasurable, and the project will be declared “inconclusive”.
Kill rule: If the workflow isn’t mapped, it’s not a project, it’s a demo.
4) Data readiness test: “Would you bet your name on the data?”
AI doesn’t fail because it lacks intelligence. It fails because the organisation’s data is fragmented, unlabeled, inaccessible, or politically owned.
Gartner has also warned that organisations will abandon a large share of AI projects that lack “AI-ready data”. This is not a technical detail; it is the main event.
Ask:
Do we have the data today?
Do we have the rights to use it this way?
Is it stable, or does it drift weekly?
Can we trace model outputs back to sources?
Who owns data quality as an ongoing job?
Kill rule: If data ownership and quality don’t have a named owner, the model becomes the scapegoat later.
5) Economics test: “What is the unit cost per decision?”
AI conversations love “ROI”. AI operations require unit economics.
You need three numbers:
cost per run (inference + orchestration + monitoring),
volume per month,
value per successful output.
This is where many agentic systems die. They look cheap in a sandbox, then explode in production because:
they call tools too often,
they re-run tasks,
they require human review,
they generate extra work downstream.
Kill rule: If you can’t express cost and value per unit, you can’t manage it.
6) Risk test: “What happens on the worst day?”
Most AI risks are not futuristic. They’re basic:
leaking sensitive data,
confident errors,
biased decisions,
unexplainable outcomes,
audit failure,
supplier lock-in.
In Europe, the compliance bar is rising further. The EU AI Act timeline makes it clear that major obligations and enforcement start in August 2026, with earlier requirements applying in stages. If your AI touches regulated decisions, you need governance built in, not bolted on later.
Kill rule: If you can’t explain how the system behaves under stress, you’re not deploying a product; you’re deploying liability.
The hidden killer: “AI that doesn’t remove work”
Here’s a non-obvious insight that explains most disappointments:
If AI adds a step, you don’t have automation. You have decoration.
A classic failure pattern looks like this:
AI generates a summary.
Humans check it (because they don’t trust it).
Human rewrites parts (because it’s not quite right).
Humans paste it into a system (because integration isn’t done).
Net result: you added time, not removed it.
So the right question is not “Is it accurate?”
It’s “Does it delete a step, reliably, with controls?”
The strongest AI projects are not “smart”. They are surgical:
extract one painful task,
reduce it to a constrained output,
integrate it into an existing system,
measure it weekly,
and expand only after repeatable impact.
A practical “never build AI” list
If you want an immediate filter, here are categories that should almost always be rejected:
“General assistants” for the whole company (no workflow, no owners, no measurable outcomes)
AI for processes that are broken (you’ll automate chaos)
AI for low-volume edge cases (unit economics won’t work)
AI replacing decisions you can’t explain (regulatory and reputational risk)
AI without a retraining/monitoring plan (it will drift, silently)
AI, where the best fix is permissions and search (cheaper, safer, faster)
The alternative: build an “AI portfolio”, not an AI backlog
Instead of letting AI ideas pile up, run AI like a portfolio with three buckets:
Efficiency plays (clear unit economics, immediate operational impact)
Risk reduction plays (fraud, compliance, security—value is avoided loss)
Growth plays (pricing, personalisation, sales enablement—harder, but scalable)
Each bucket needs different metrics, governance, and timelines. Mixing them is how you get 40 pilots and zero wins.
A simple rule that changes everything
If you take only one rule from this piece, make it this:
No AI project gets approved without a “kill metric”.
A kill metric is a single number that ends the project if it doesn’t move by a deadline, for example:
“Reduce average handling time by 12% in 8 weeks”
“Cut rework rate by 20% with <2% critical errors”
“Increase straight-through processing from 55% to 70%”
This does two things:
It protects budgets.
It forces teams to design for deployment rather than plausibility.
Most AI projects should never exist because most were never designed to earn the right to exist.
And that’s good news. Because the organisations that get ruthless about bottlenecks, workflow, data, economics, and risk, will do fewer AI projects…
…and get far more value from the ones they keep.