AI, when it solves. Not when it decorates.

“We could add some AI.”

The sentence comes up earlier and earlier in projects.

Sometimes before the problem has even been precisely defined.

The intent is understandable. Artificial intelligence now opens remarkable possibilities: interpreting complex data, recognising patterns, automating certain tasks, working with natural language or supporting a decision.

But a technology, however powerful, is not a need.

So the first question should stay surprisingly simple: what will the AI solve here?

Starting from the problem changes the whole discussion #

Imagine a system that has to automatically recognise a situation from data that’s hard to characterise with a few deterministic rules.

We have a problem. Machine learning may well be an excellent answer.

Conversely, imagine an application that applies five perfectly known business rules to structured data.

We already know how to write those rules. Adding an AI model doesn’t necessarily make the system more intelligent. Above all, it can make it harder to explain, to test and to maintain.

In both cases, the question isn’t “Where can we put AI?”, but “Which approach best solves the problem?”

AI also brings new constraints #

A model doesn’t simply replace a few lines of code. It introduces its own technical system:

get data that’s representative enough;
prepare it;
choose an evaluation method;
measure the errors;
handle the cases the model knows poorly;
monitor its behaviour as real-world data shifts.

Depending on the application, you also have to weigh compute resources, latency, energy consumption, data privacy, or dependence on an external service.

AI can therefore remove complexity in one place while creating it in another.

That isn’t a flaw. It’s an engineering trade-off.

An impressive demo isn’t the solution yet #

Some technologies produce a spectacular effect very quickly.

A camera recognises an object.
A model generates a report.
An interface answers a question in natural language.

In a few hours, the demo can be convincing.

But like any prototype, the demo doesn’t answer every question.

What happens on the atypical cases?
How do we measure an error?
Which error is acceptable?
What does the system do when it doesn’t know?

And above all: have we improved the original problem?

A feature can be technically impressive without bringing much value to the system that uses it.

Sometimes the best AI is the one you remove #

This may be the most interesting test.

If a function can be done in a simpler, more deterministic and more robust way without an AI model, removing it can be an architectural improvement.

Conversely, when a problem specifically resists deterministic approaches — lots of data, complex signals, variability that’s hard to model, natural language — AI can become an extremely relevant tool.

In that case, it’s no longer there to make the product modern. It’s there because it enables something the previous architecture could barely do, or couldn’t do at all.

And the difference is fundamental.

AI should have to justify its place #

We naturally ask a new sensor why it’s necessary. A new circuit board what it brings. A new software service why it should exist.

Artificial intelligence shouldn’t escape this rule.

Before integrating it, we can ask it the same questions as any other technical choice:

What problem does it solve?
How will we measure the gain?
What constraints does it introduce?
And what would happen if we didn’t use it?

If the answers are solid, AI has probably found its place.

If not, it may simply be decorating the architecture.