Why we talk some clients out of AI projects

A pattern we see repeatedly: a leadership team reads about a capability, identifies a process that feels inefficient, and asks for a model. Sometimes that is exactly right. Often it is not.

Three signs the problem is not an AI problem

• The rules are already known. If an experienced person can write down the decision logic on one page, you need deterministic code, not a model. It will be faster, cheaper and explainable to your auditor.
• The data is not ready. A model trained on inconsistent, duplicated records learns the inconsistency. Fixing the data is unglamorous and it is usually the actual project.
• Nobody owns the outcome. If no one is accountable for acting on the predictions, the model will be admired in a demo and ignored in production.

What a good AI project looks like

The projects that pay off tend to share a shape. The volume of work is genuinely beyond human capacity. The decision is repetitive but not perfectly rule-based. There is historical data with outcomes attached. And there is a named owner who will change what they do based on the output.

Document classification, first-line support triage, anomaly detection in high-volume sensor data and summarisation of long text all fit that shape well. Strategic decisions, one-off analysis and anything requiring accountability for a judgement call usually do not.

Start with a two-week prototype

We will not quote a large AI build without a short, bounded prototype first. Two weeks, real data, an honest evaluation against the current process. Sometimes the result is a clear case to proceed. Sometimes it is a clear case to stop, and that is a good outcome for a fraction of the cost.

The most valuable thing an AI consultant can say is 'you do not need this', and mean it.