Five questions to ask before any AI project

I get asked to build AI into businesses fairly often, and a meaningful share of the time my honest answer is that the problem in front of us is not an AI problem. It is a process that nobody has redesigned in a decade, or two systems that need an API between them, or data that nobody trusts yet.

That is not a reason to be discouraging about AI. It is the opposite: clearing those out first is what makes the genuine AI opportunities obvious and much easier to justify. These are the five questions I work through before anything gets built.

1. Could a rule do this?

If the steps are known, the inputs are structured and the same input should always produce the same output, you want a rule or a scheduled job — not a model.

A rule is cheaper to run, faster, auditable, and it does not need an evaluation suite to tell you whether it is still working. The temptation to use a model anyway usually comes from the fact that the model is quicker to prototype. That is a real advantage during the demo and a liability for the next five years.

The honest test: could you write down the logic in a page of plain English? If yes, write it down and implement it. Save the model for the parts you could not.

2. Does the information already exist somewhere?

An enormous amount of manual work is people moving information between systems that could talk to each other and do not. Somebody reads a number off one screen and types it into another, or copies a list into a spreadsheet every Monday morning.

That is an integration problem. It is well-understood, it is deterministic, and it is usually the highest-return work available in a business because it is both cheap and completely reliable once done.

You can tell you are looking at one when the person doing the work is not making any decisions — they are just being the connection between two things.

3. Is the process itself the problem?

Automating a bad process faithfully gets you a bad process that runs faster and is now harder to change. This is the most expensive mistake in this category because the result looks like success for about six months.

The signal is when you ask why a step exists and nobody knows, or the answer is that a system that was replaced three years ago used to require it. Steps like that should be deleted, not automated.

Redesign first, then automate what survives.

4. Is the data good enough yet?

Models do not repair bad data. They repeat it, faster and with more confidence, which is considerably worse than a spreadsheet being wrong quietly.

If records are duplicated, fields are used inconsistently, or half the organisation does not trust a particular system, that has to be addressed before anything is built on top. This is unglamorous and it is frequently the real project.

A useful test: ask two people in different teams the same question about the data and see whether you get the same answer.

5. Is judgement genuinely required?

If you get through the first four questions and the problem is still standing, it usually looks like this: the input is unstructured — documents, tickets, emails, conversations, images — and the rules for handling it are too many, too fuzzy or too changeable to write down.

That is what models are actually good at. Reading something messy, working out what it means, and producing something structured from it.

When a problem has that shape, AI is not a nice-to-have. It is very often the only reasonable option, and it is worth doing properly.

Why this ordering saves money

Working through these in order tends to remove most of the initial list, and that is the point. What remains is a much smaller set of genuinely AI-shaped problems, with the process and data work that would have undermined them already dealt with.

Projects that skip this step do not usually fail during the build. They fail about four months later, when it turns out the model was doing an excellent job on data nobody trusted, inside a process that should have been retired.