What Clients Actually Complain About in AI Projects

Across a long run of delivery, the complaints that arrive during AI projects are strikingly consistent, and strikingly rarely about the technology. Almost nobody says the model is not good enough. What they say is some version of: I did not know that, I was told this was done, and why is this taking so long now when the first part was quick.

All three are avoidable, and all three come from the same root.

"The first part was fast and now nothing is happening"

This is the most common, and it is structural rather than anyone's fault.

The early phase of an AI project produces visible output quickly. Within a fortnight there is something answering questions. Then the work moves to data quality, integration, permissions, edge cases and the failure paths — which is most of the effort and produces almost nothing a client can see.

From outside, that looks like a project that started well and stalled. From inside it is the normal shape. The mistake is not the shape, it is failing to say in advance that this is the shape, so the client builds an expectation from the first fortnight and then watches it be violated for three months.

The fix is to describe the curve at the start and to report on the invisible work in terms of what it removes. "We found that the customer table has four ways of recording the same company and we are reconciling them" is legible progress. "Still working on data" is not.

"I was told it was working"

Almost always a definition problem rather than a false statement.

An engineer saying a feature works generally means: it does the thing, on the cases tested, in the environment we have. A client hearing it works means: my team can use it now. Those are separated by weeks of hardening, and nobody notices the gap until it produces a disappointment.

The remedy is unglamorous and effective: never report status in binary. Say what works, on what data, with what known gaps, and what remains before the people who will use it can use it. It takes one extra sentence and it prevents the single most damaging category of misunderstanding in delivery.

"Nobody told me it could do that / couldn't do that"

Both directions cause trouble. A capability the client did not know about goes unused; a limitation they did not know about is discovered by a user, usually in front of someone senior.

Limitations in particular have to be stated early, repeatedly and in writing, because they are the thing people forget. If the system does not handle documents in the third format their regional office uses, that fact needs to have been said at the start, restated at the demo, and written in the handover — otherwise it will be experienced as a defect rather than as a boundary everyone agreed.

"It gave someone a wrong answer and nobody caught it"

This one is a genuine defect, and it is the one worth designing hardest against.

Its cause is almost always that nothing was decided about what the system does when it cannot answer. Left to its default, a model produces something plausible. A user acts on it. The error surfaces later, attached to a decision somebody made in good faith.

There is no recovering the trust cheaply. The prevention is to make refusal and escalation explicit behaviours with their own tests, and to make every substantive answer carry its source so a person can check in seconds rather than choosing to trust.

"Why are we paying for changes to something you built"

Usually a scope conversation that never happened.

AI systems attract change requests more than conventional software, because using one generates ideas about what else it could do. That is a good sign, and it is also a budget problem if nobody drew a line between fixing what was agreed and building what was not.

Drawing it early is kinder than drawing it in month five. Clients are rarely unhappy about paying for new work; they are unhappy about discovering mid-project that the boundary is not where they assumed.

The common root

Every item on this list is a communication failure that hardened into a delivery problem. None of them requires better engineering to prevent — they require saying the uncomfortable thing at the point where it is still cheap to say.

The pattern in the projects that end well is not that fewer things go wrong. It is that when something does, the client hears it from us first, in plain terms, with what we intend to do about it. Clients forgive a great deal of difficulty. They do not forgive finding out late.