The gap isn’t AI

The founding thesis of this firm fits in one sentence: AI projects fail before the model is ever called.

They fail at selection — the wrong use case, chosen on hype, because a competitor announced something or a demo looked miraculous. They fail at foundations — intelligence pointed at data that is trapped, duplicated or quietly wrong. And they fail at adoption — working software that a team routes around within a month, because nobody made using it easier than not using it.

Notice what’s absent from that list: the AI. Model quality is the one input that improves every quarter without your effort. Everything that actually determines your outcome — the problem chosen, the data underneath, the people around it — is untouched by every model release.

What should a business do differently, if that’s true?

The short answer: choose the problem more carefully than the technology, fix the data before building on it, and treat adoption as part of the job. Three unfashionable conclusions, each worth more than any model upgrade.

Selection is worth more than execution. An unglamorous automation that removes re-typing pays for itself in a quarter; an impressive chatbot on top of chaotic data is depreciation on a subscription. The least fashionable projects often pay best, and the discipline of saying “not yet” to the exciting one is most of the strategy.

The boring work comes first. Most businesses don’t have an AI problem; they have a data problem. Before intelligence can be applied, information has to be captured, connected and trusted. Any AI engagement that skips the plumbing is selling you the fixture without the pipes.

Adoption is delivery, not aftercare. Software nobody uses is the most expensive kind. Adoption is the point at which using the new tool is easier for the team than not using it. If training, rollout and a feedback loop aren’t inside the engagement, the engagement isn’t finished — it’s abandoned at the moment it is most fragile.

How do you tell a good first AI project from a bad one?

The short answer: a good first project removes work someone does every week, runs on data you already trust, and is something the team itself wants gone. A bad one is chosen because it demos well.

The test is what the project takes away, not what it adds. If you can name the person whose week gets shorter, and the hours involved, the project has a return you can check. If the best description is “it will make us more AI-driven”, it doesn’t yet.

The gap isn’t AI. It’s AI done well — and “done well” is a job description, not a slogan. It’s ours.

Frequently asked questions

Why do most AI projects fail?

Most fail before the model matters, at one of three points: the wrong problem is chosen because it sounds impressive, the data underneath isn’t trustworthy, or the finished tool isn’t used by the people it was built for. Model quality is the one factor that keeps improving without any effort from the business.

Will a better AI model fix a project that isn’t working?

Rarely. Models improve every few months on their own, but they don’t change the problem you chose, the data you feed them or whether your team uses the result. If a project is failing on any of those three, a better model produces the same disappointing result, only faster.

Do we need perfect data before starting with AI?

No, but you need trustworthy data for the specific thing you are automating. That means one agreed source for the numbers involved. Fixing that for one process is a small job. Waiting until all your data is perfect means never starting.

How do you get a team to actually use a new AI tool?

Treat adoption as part of delivery, not something that happens afterwards. Train people on their own work rather than a demo, roll out to one team first, and fix what isn’t working in the first two weeks. A tool nobody uses has delivered nothing, however well it was built.