Does your product need AI?

AI has become the answer to almost any product question, often before anyone has asked whether the question needs it. Sometimes a model is the only way to make a product do what it promises. Just as often, a few lines of plain logic would do the same job for less money and with fewer surprises. These five questions help tell the two apart, and they're worth asking before anything is built.

Start with the people who do the job today. If they can describe what they look for precisely enough to fit in a sentence, it can usually go straight into code. "Sound the alarm if the temperature stays above 80 °C for ten minutes" is a rule. It needs no training, it behaves the same way every time, and anyone can check it.

AI earns its place where the pattern is real but nobody can spell it out. An experienced technician hears that a bearing is starting to wear. An inspector sees the difference between a scratch and a reflection on a glossy part. A door camera has to tell a delivery from a passing cat. People do these things easily and explain them badly, and that gap is exactly where a model learns from examples instead of instructions.

A model is only as good as the examples it's given, and the examples that matter most are usually the rarest. A machine that has run for years may have failed only a handful of times, and a production line built to make good parts makes very few bad ones.

That doesn't have to stop the project, but it shapes it. Sometimes the answer is to teach the model what normal looks like and have it flag anything else. Sometimes it's to collect data for a while before building anything. Either way, it's worth knowing how much you have, and how much you'd need, before the work starts, because it decides more about the result than any choice of model.

Any model is right most of the time and wrong some of the time. The useful question is what each kind of mistake costs. A missed fault and a false alarm are rarely equal. Missing a cracked part might mean a recall, while a false alarm means someone takes a second look. A false alarm every night, on the other hand, teaches people to ignore the alarm.

Knowing the costs lets you tune the model toward the cheaper mistake and decide what happens around it, such as when it should ask a person and what it does when it isn't sure. If a single wrong answer is unacceptable, AI can still help, but not on its own.

Every AI feature should be measured against the plain alternative, whether that's a fixed threshold, a table of values or a person doing the job. The comparison is cheap to make, and it's surprising how often it's skipped. Without it, you can't tell whether the model adds anything at all.

Sometimes the simple way wins outright. Sometimes it handles nine cases in ten, and the model is only needed for the tenth. A product built like that is cheaper to run and easier to trust than one that sends every case to a model.

A rule written today works the same in five years. A model drifts out of step with the world it learned from. Sensors age, suppliers change materials, and users find ways of using the product nobody planned for. It needs data coming back, and someone to check now and then that it's still right.

It also has to run somewhere. On the device, it has to fit in limited memory and power. On a server, every answer has a cost, and that cost grows with every product sold. Both are solvable, but they belong in the plan from the start, not in a surprise invoice after launch.

The answer is rarely all or nothing. A door camera can use plain logic to decide whether it's dark and whether anyone is home, and save the model for the one question logic can't answer. Is that a person? The rules do the work they're good at, and the model only gets the question that needs it.

Starting simple is also the cheapest way to find out whether you need a model at all. Build the simple version first, measure where it falls short, and let those cases decide whether a model is worth adding. Sometimes it is. When it isn't, you've saved the cost of a model you didn't need.

Whether your product needs AI is a question with an answer, and it rarely takes long to find. The answer comes from your own data, a plain alternative to beat and an honest look at what a wrong answer would cost.

That's where we start. Tell us what your product should recognize, predict or decide, and we'll tell you whether a rule could do it, whether a model would do it better and what it would take to find out on a prototype.