A client asks for AI in their product. Sometimes the requirement is real and well-formed. Frequently the request is a board expectation, a competitor's announcement, or a genuine problem described in the vocabulary currently available. Building what was asked for, without establishing which of those it is, produces a feature that demonstrates well and changes nothing — and the client concludes that AI did not work for them.
The question that separates them is what decision or task this would change, and for whom. If the answer is specific — our team spends nine hours a week reading these documents, our support agents answer the same forty questions, our analysts cannot review every transaction — there is a real problem with a measurable baseline. If the answer is that we want to be seen as innovative, that is a legitimate business goal and it should be met with something visible and cheap rather than with a difficult system.
Set expectations about accuracy early and concretely, because this is where these projects break down. A model that is right ninety per cent of the time sounds excellent and means that one in ten outputs is wrong. Whether that is transformative or unusable depends entirely on what happens to the wrong ones. Walking a client through that arithmetic before building — with their volumes and their cost of error — is the most useful hour in the whole engagement, and it frequently changes the scope from automation to assistance.
Be direct about the data, since that is what most often kills these projects. The client's data is usually messier, less consistent and less complete than they believe, because nobody has had reason to look at it that way. An honest assessment before commitment — here is what we would need, here is what exists, here is the gap — is uncomfortable to deliver and much better than discovering it in month three, when the budget is spent and the model is producing nonsense that is not the model's fault.
Then design for the wrong answers from the start: a confidence signal, a route to a human, an audit trail of what the system produced and what the person did with it. Clients accept a system that is right most of the time and honest about the rest. They do not accept one that is confidently wrong in front of their customers, and the difference between those two outcomes is a design decision rather than a modelling one.
