When not to build a model

The pressure to have an AI programme is real, and it tends to produce projects chosen for how they sound rather than what they would change. A useful assessment produces two lists, and the second one is the more valuable.

When the decision is already deterministic

If the rule can be written down, write it down. A model that learns an existing policy is harder to audit, harder to change and worse at explaining itself than the twenty lines of code that encode the policy directly.

When nobody will act on the output

A prediction that arrives after the decision has been made, or lands with someone who cannot act on it, changes nothing. Before building, trace the path from the model's output to a person or system with the authority and the timing to do something differently. If that path does not exist, the model is not the missing piece.

When the data does not describe the outcome

You can only learn from outcomes you have recorded. If nobody wrote down what happened after each decision, and often nobody did, the honest first project is instrumenting that rather than modelling it. That is unglamorous and it is a prerequisite.

When a hosted model with good retrieval would do

For a lot of language tasks, a hosted model with well-built retrieval and a proper evaluation set gets you most of the way at a fraction of the cost. Training your own is worth it when you have data nobody else has, or a latency or privacy constraint that rules the alternatives out. It should not be the default.

What is left is worth doing properly

Ruling those out usually leaves a short list of good candidates: decisions made often, with recorded outcomes, by someone who can act on a better answer. Those are worth the serving infrastructure, the monitoring and the evaluation harness. The others were never going to repay it.