What It Actually Means
This is the older, quieter branch of AI, and it has been running in ordinary businesses for years: fraud scoring, demand forecasting, spam filtering, recommendations, predicting which customers are about to leave.
The distinction from generative AI is what comes out. Generative systems produce content. Machine learning produces a judgement about something you already have: a number, a category, a probability.
Why It Is Frequently The Better Answer
Machine learning has been thoroughly out-marketed, and it still fits a great many business problems better.
It learns from your data, so it reflects your customers and your operation rather than the internet in general.
Its output is checkable. A probability can be compared against what actually happened. You can measure whether it is right, which you cannot meaningfully do with a paragraph of generated text.
It is cheap to run once built. No per-request charges to a provider, and predictions in milliseconds.
It does not invent. A classifier can be wrong. It cannot fabricate, because it is choosing among defined outputs rather than producing new content.
If your question is “which of these should we prioritise”, “how much of this will we need”, “is this one unusual” or “what is this likely to be”, this is the tool. Reaching for a language model there is common now and usually worse in every dimension.
What It Requires
Data with outcomes attached. This is the constraint that stops most projects. To learn what predicts a customer leaving, you need history of customers who left and customers who did not, with what you knew about each beforehand. Not opinions. Recorded outcomes.
Enough of it, and reasonably consistent. Hundreds of examples at minimum for something simple, and far more for anything subtle. A business that changed its process eighteen months ago effectively has eighteen months of usable history.
Someone to act on the answer. A churn prediction nobody acts on has cost money and changed nothing. This is the most common way these projects fail, and it is not a technical failure.
What To Ask
- Do we have outcome data, and how far back is it trustworthy? Ask this before anything else. It decides feasibility.
- What decision changes because of this prediction? If nobody can name one, do not build it.
- How accurate does it need to be to be useful? Often lower than people assume. Something modestly better than the current guess is worth having.
- What does it cost to be wrong in each direction? Wrongly flagging a good customer and missing a bad one rarely cost the same, and the model should be tuned accordingly.
- How will we know if it degrades? Models drift as the business changes, silently, and mostly nobody is watching.
The Realistic Version
The pattern that works is narrow and boring: one prediction, on data you already hold, feeding one decision somebody already makes, with a way to check afterwards whether it helped.
That gets built in weeks rather than quarters, it is measurable, and it either earns its place or does not. It also produces the cleanest possible test of whether a business is ready for anything more ambitious, because the discipline it requires, recorded outcomes and someone acting on the answer, is the same discipline everything else depends on.
More terms are in the glossary.
