Common ways the first AI build goes wrong, and what to do instead

First AI builds tend to fail for a small set of repeated reasons: the wrong workflow gets picked, the review step is removed instead of strengthened, the system is treated as a feature instead of an operating change, the rollout skips the people who carry the work, and the build is sized for a demo instead of for real use. Each of these has a calmer alternative.

Mistake one: picking the workflow that is loudest, not the workflow that is heaviest

The first AI workflow that gets picked is often the one someone in a meeting felt strongly about, not the one that is genuinely high-leverage. Lots of energy gets spent on a chatbot or a content tool, while the actual heavy work, the recurring decisions and handovers the team quietly carries, never gets touched.

Instead: spend a week mapping where work waits, where context gets copied, and where the team repairs the same thing more than once. The first useful build is almost always inside that map.

Mistake two: removing the human review instead of strengthening it

It is tempting to treat AI as a way to take a person out of the loop. For most SME workflows, that is the wrong frame. The judgement is still needed; what is missing is the time and context to apply it well.

Instead: design the system so the person who does the work today gets a faster, better-evidenced draft, a clearer recommendation, or a sharper triage signal. Keep the decision human, especially where mistakes are expensive to reverse.

Mistake three: treating it as a feature, not an operating change

Buying or building an AI feature without changing the workflow around it is a common outcome. The feature gets shipped, nobody changes how they work, and after six weeks the usage chart is flat.

Instead: treat the AI system as a change to the operating rhythm. Decide what meeting it lives inside, what it replaces in the existing process, and how the team will notice if it stops being useful. The system is the workflow change, not the model.

Mistake four: skipping the people who actually do the work today

First AI builds often get scoped by leadership and shipped to operators without their input. The operators are the ones who know the exceptions, the workarounds, and the reasons the workflow looks the way it does. Skipping them produces systems that are clean on paper and useless in practice.

Instead: include the people carrying the work in diagnose and design. They do not need to write the brief, but they need to recognise themselves in it. If they cannot, the system will not stick.

Mistake five: sizing the build for a demo instead of for real use

A demo-sized build solves the cheerful path and falls over on the boring edges: bad data, missing context, unusual customers, weird formats. Real work spends most of its time on those edges. A system that only handles the cheerful path adds review burden without removing it.

Instead: size the first build for real use from day one. That usually means a narrower workflow, deeper handling of the edges, and a smaller surface area. Better to ship one workflow that holds up than five that all need supervision.

The honest first step

None of these mistakes are exotic. They are what happens when an AI build is treated as a tech project rather than a business change. The honest first step is to spend a small amount of time on diagnosis before anything is built, and to be willing to hear “not yet” or “not here” if that is the right answer.

Lucumo runs that diagnosis at the start of every engagement. If a useful system is there, the build follows. If it is not, the conversation ends honestly and nobody is sold something they do not need.