When to use machine learning

Machine learning is one of the most expensive ways to express a rule. It introduces uncertain output, evaluation work, data dependencies, and a system that changes when its inputs change. Those costs are justified when the problem contains patterns that ordinary software cannot express well.

I use three questions before a team commits to ML. The order matters because each question rules out a cheaper and more controllable approach.

Can the team write the rules?

If the logic can be stated, write it in software.

Tax calculations, eligibility checks, workflow states, thresholds, and deterministic validations usually belong in code. A rules-based implementation is easier to test, explain, and change. It also tells an operator exactly why the system acted.

This choice can feel less ambitious than an ML project. That is irrelevant. The job is to produce a dependable outcome with the least unnecessary machinery.

A useful test is to ask the domain expert to work through several cases. If the expert can name the inputs, decision steps, and exceptions with consistency, the first version should probably be deterministic.

Can a pretrained model recognize the pattern?

Some rules are hard to enumerate because they live in language, images, or a large number of small variations. A pretrained model may already handle the pattern well enough.

Common examples include:

• classifying the intent of a message
• extracting fields from familiar documents
• summarizing text for a person to review
• answering a bounded question from supplied context
• producing a draft that a person owns

The model still needs evaluation. "The model can do this" is not an acceptance criterion. Build a set of representative inputs, define correct behavior, and inspect the failure cases that could cause harm.

Retrieval and tool calls do not increase a model's judgment. Retrieval supplies information. Tools give the model a way to act. The surrounding system still needs to decide what the model may do, which result is acceptable, and when to ask a person.

Is the useful pattern specific to your data?

Custom machine learning becomes a serious option when the rules are unknown, the pattern is absent from general training data, and the organization owns enough relevant examples.

Fraud detection, demand forecasting, equipment failure prediction, recommendation systems, and domain-specific risk scoring often fit this shape. The signal appears across many examples and is difficult to encode by hand.

Before training, check whether the data describes the decision you need to make. Volume cannot repair the wrong label, a biased collection process, or a target that arrives after the decision point. A smaller dataset with a sound definition can be more useful than a large historical dump.

Custom ML also creates an operating commitment. Someone must monitor drift, retrain when the environment changes, investigate regressions, and decide when the model should stop acting.

The decision in one sequence

Use this order:

1. Write deterministic rules when the decision can be specified.
2. Evaluate a pretrained model when the pattern is common but difficult to enumerate.
3. Train a custom model when the useful signal is specific to your data and simpler approaches fail.

Hybrid systems are common. A model may extract intent while deterministic code applies policy. A custom score may prioritize work while a person makes the final decision. The boundaries matter more than the label attached to the system.

What engineers still own

AI can produce a large share of implementation code. Engineers still own the choice of method, the test set, the failure policy, and the result in production.

Good applied AI work begins by refusing unnecessary uncertainty. Add a model after the system has earned the complexity.