Before You Add AI: A Practical Checklist

We get asked to "add AI" fairly often, and we think it's a reasonable thing to ask. The technology genuinely does things now that it couldn't a few years ago. But the request usually arrives as a solution rather than a problem, and the most useful thing we can do is work backwards to what's actually being solved.

These are the five questions we run through before writing any code. They're worth running through yourself first — several of them will save you money regardless of what you conclude.

1. Could a rule do this?

Start here, always, and be genuinely willing to accept the answer.

A large share of "AI" requests describe work that is repetitive but not ambiguous. Flagging invoices over a threshold. Routing enquiries by which form they came from. Reminding someone when a date passes. These need automation, and automation is not the same thing as a model.

A rule is cheaper to build, instant to run, free to operate, and — the part people undervalue — explainable. When it does something surprising, you can read it and see why. When a model does something surprising, you're investigating.

If you can write down the logic in a paragraph and it's right most of the time, you don't have a machine learning problem. You have a scripting problem.

Where models genuinely earn their place is where the rule would need hundreds of exceptions, or where the input is messy human language, images, or something that doesn't fit neat categories.

2. Do you have the data — really?

"We have lots of data" and "we have data you can learn from" are different claims.

The questions that matter:

• Is it labelled? To predict which customers will churn, you need historical records of customers who did and didn't. Not just a customer list.
• Is it consistent? If the way you recorded something changed two years ago, you may effectively have half as much usable history as you think.
• Is it accessible? Data locked in scanned PDFs, or in one person's spreadsheet, needs a data project before it can support an AI project.
• Is it representative? A model trained on last year's customers will reproduce last year's patterns, including any that you'd rather not repeat.

This is where most AI projects actually stall — not on modelling, on the state of the data. It's also why the first phase of honest AI work often looks disappointingly like tidying up.

3. What does a wrong answer cost?

Models are wrong sometimes. That is a property of the technology, not a defect to be engineered away, and the design has to start from it.

So price the failure:

• Cheap and recoverable — a slightly odd product recommendation, a support enquiry routed to the wrong desk. Fine. Ship it.
• Expensive but visible — a bad demand forecast leading to over-ordering. Workable, with review built in.
• Expensive and invisible — quietly declining a legitimate customer, or misreading a figure that flows into accounts unnoticed. Be very careful here, and don't automate the final decision.

The rule of thumb we use: the higher the cost of being wrong, the more the system should recommend rather than decide.

4. Who reviews the output, and can they?

"Human in the loop" is easy to say and often not real. If a person is meant to check the system's output, ask honestly:

• Do they have time? Reviewing two hundred suggestions a day is not review, it's clicking approve.
• Can they see why the system suggested it? Without that, they can't do better than guess.
• Is disagreeing with it easy, and is it recorded? Those disagreements are the most valuable feedback you'll get.
• Are they measured in a way that makes overriding it costly to them? If so, they won't.

A review step that people rubber-stamp is worse than no review step, because it creates confidence that nobody has actually earned.

5. How will you know it still works in six months?

This is the question that separates a demo from a system, and it's the one most often skipped.

Models degrade — not because the code changes, but because the world does. Customer behaviour shifts, you add a product line, a competitor opens nearby. The model keeps confidently applying patterns that used to be true.

Before launch, you want:

• A measure of "working" that's a number, not a feeling.
• Somewhere that number is visible without asking a developer.
• A defined threshold at which someone is alerted.
• A named person who owns it.
• A way to turn it off and fall back to the previous process without a deployment.

That last one is worth insisting on. Any AI feature in a business process should have an off switch that a manager can reach.

Where it genuinely pays off

None of this is an argument against AI. The cases where it clearly earns its place share a shape: high volume, messy input, tolerable error, and a human able to catch what matters.

• Pulling structured fields out of documents that arrive in twenty different formats.
• Answering the same forty customer questions at three in the morning, and handing over cleanly when it can't.
• Sorting a large inbox of enquiries so the urgent ones surface first.
• Flagging transactions that don't look like the others, for someone to check.

Notice that in each case the model is narrowing work for a person, not replacing the decision.

Start smaller than feels satisfying

The most common mistake we see isn't picking the wrong technology — it's picking too big a first target. An ambitious first AI project has too many moving parts to tell you which one is failing.

Pick one narrow, annoying, repetitive task. Measure how it's done today. Build the smallest thing that helps. If it works you'll have both a result and, more usefully, a realistic sense of what the next one takes.

If you've got a process in mind and want an honest read on whether it's worth it, describe it to us. Telling you a rule would do the job is a perfectly good outcome of that conversation.