Almost every page about machine learning answers a question nobody asked. They tell you what it can do, industry by industry, and leave you exactly where you started: unsure whether the thing sitting on your desk is a machine learning problem.
That is the question this page answers. Machine learning is good at one specific kind of work, which is finding a pattern in what happened before and applying it to what happens next. Everything else is somebody else's tool, and knowing which is which will save you more than any list of applications.
So we will go in order. What kind of problem it solves. How it differs from the AI everyone now means. What the data actually demands, which is the part that decides whether a project works. Where it reliably delivers, where it is the wrong instrument, and what has genuinely changed recently.
One promise: this page names the cases where the answer is do not use machine learning. Those cases are common, and a page that cannot describe them is selling rather than explaining. If you are weighing up a build, this sits next to our custom software development services work.
What is machine learning, in terms of the problem it solves
The textbook definition is that machine learning is software that improves at a task by learning from data rather than by being explicitly programmed, which is accurate and not much use on a Tuesday morning.
Here is the version you can act on. In ordinary software, a person works out the rule and writes it down. In machine learning, you supply many examples of a situation and its outcome, and a program works out the rule for itself.
That is the whole difference, and it explains everything downstream. It explains why machine learning needs so much data, because the examples are the specification. It explains why the results are probabilities rather than certainties, because a rule inferred from examples is a good guess rather than a proof. And it explains why nobody can fully explain the rule afterwards, because no person wrote it.
The one question that tells you if it is a machine learning problem
Ask this: could a competent person write down the rule?
If yes, write the rule. It will be cheaper to build, faster to run, easier to test and possible to explain to an auditor. Flag any transaction over ten thousand from a new account is a rule. Do not train a model for it.
If no, and the reason is that the pattern is real but too tangled to describe, that is a machine learning problem. An experienced fraud analyst who says I can tell when something is off, but I could not write you the rule is describing exactly the condition machine learning exists for.
There is a third answer, and it is the most common one in practice. No, because we do not know what happened afterwards. If you have no record of which transactions turned out to be fraudulent, there is nothing to learn from, and the first project is a data project rather than a model.
Machine learning vs AI: what people mean now
This has become genuinely confusing, and the confusion costs real money because the two lead to different projects.
Artificial intelligence is the broad field. Machine learning is one approach within it, and the dominant one for decades.
Machine learning trains a model on your data to do one narrow thing well. It predicts which customers will leave, sorts invoices into categories, or spots the unusual reading in a stream of sensor data. It knows nothing except what your data taught it.
The AI most people now mean is a large language model or an image model, trained by somebody else on an enormous general corpus. You do not train it; you describe what you want and it responds. It is broad, immediately available, and it knows nothing specific about your business.
How machine learning models are built, without the mathematics
You do not need the mathematics to make good decisions about this. You do need the shape of the process, because every argument about a project maps onto one of these steps.
It has four steps: gather examples where the outcome is known, show them to an algorithm that adjusts itself until its guesses match those outcomes, check it against examples it has never seen, then put it to work on new cases where the outcome is not yet known.
The third step is the one that matters and the one most often fudged. A model tested on the same data it learned from will look excellent and mean nothing, in the same way a student who has seen the exam paper will score well.
Training, inference and the gap between them
Two words worth knowing, because they have different costs and different failure modes.
Training is the learning, and it is expensive, slow, done occasionally, and dependent on your historical data.
Inference is using the trained model on a new case, and it is cheap, fast and constant in production.
The gap between them is where projects quietly fail. Training happens once, on a tidy extract, in a controlled environment. Inference happens forever, on live data, with fields missing, formats changed and categories that did not exist when the model was trained.
A model that performs beautifully in a notebook and poorly in production has usually met this gap. The fix is not a better model; it is making the data that reaches the model in production look like the data it was trained on, which is an engineering problem rather than a data science one.
Why accuracy is the wrong number to ask for
The first question everyone asks is how accurate is it. It is the wrong question, and a single example shows why.
Suppose one transaction in a thousand is fraudulent. A model that declares every transaction legitimate is 99.9% accurate. It is also completely useless, because it never catches anything.
Accuracy hides this whenever one outcome is much rarer than the other, which is true of almost every interesting business problem. Fraud is rare, equipment failure is rare, and customers cancelling in any given month are rare. That is why they are worth predicting.
So ask two questions instead. Of the cases the model flagged, how many were real? And of the real cases, how many did it catch? Those two numbers trade against each other, and choosing where to sit between them is a business decision rather than a technical one.
False positives and false negatives are business decisions
Every model that makes a call gets two kinds of thing wrong, and they cost different amounts.
The training data problem nobody warns you about
Machine learning is a data problem wearing a model's clothes. Most of the effort, most of the cost and nearly all of the failures live in the data rather than in the algorithm.
This is the part missing from almost every page on this subject, and it is the part that decides whether your project works.
Labelled data, and who does the labelling
Supervised learning needs examples where somebody has recorded the answer. Those recorded answers are labels, and they usually do not exist.
You want to predict which support tickets will escalate. Do you have, for each past ticket, a reliable record of whether it escalated? Often the answer is that it is implied by three other fields and nobody has ever written it down as a single fact.
So somebody has to create the labels. That means either a query that reconstructs the answer from history, which is cheap when it works, or people reading past cases and marking them, which is slow and expensive. Labelling thousands of examples is a real project with a real budget, and it is routinely discovered halfway through a proof of concept.
Two things go wrong here even when the labelling happens. The first is disagreement: give the same hundred cases to two people and they will differ on a meaningful share. If people cannot agree on the answer, a model has no consistent thing to learn. The second is leakage: a field that looks helpful but is only ever filled in after the outcome is known. The model finds it, performance looks spectacular, and the system is useless in production because that field is empty at the moment of prediction.
Data quality beats model choice
Teams spend weeks choosing between algorithms and days on the data. The returns run the other way round.
A mediocre algorithm on clean, representative, well-labelled data will outperform a sophisticated one on messy data, reliably. This is one of the few claims in this field that almost everybody who has done the work agrees on.
What clean means here is specific: consistent, so the same thing is recorded the same way every time; complete enough, so the fields the model relies on are usually present; representative, so the historical data reflects the situations the model will actually meet; and current, because a model trained on the world of three years ago has learned a world that no longer exists.
Representativeness is the one that causes quiet harm. A model trained only on your existing customers learns about people who already chose you. Ask it about a new market and it will answer confidently and be wrong, because it has never seen anyone like them.
If the data is not in a state where questions can be asked of it, that is the first project, and it is a exercise rather than a machine learning one. The same ground gets covered from the other direction on .
Machine learning applications that reliably work
Most articles organise this by industry, which is a poor way to learn it. Healthcare and retail use the same four shapes of problem on different data. Learn the shapes and you can recognise your own problem wherever it sits.
Four shapes. Almost every successful machine learning application in business is one of them, and our page on AI and machine learning in digital transformation covers how they land across an organisation.
Prediction from history
What is likely to happen next, given what happened before?
This is the workhorse: which customers will cancel, which machines will fail, how much stock will sell next month, and which invoices will be paid late.
It works when the future genuinely resembles the past in the respects that matter, and the past is recorded. It fails when something structural changes, which is why the drift section above matters more than it looks.
The common mistake is predicting something nobody can act on. A model that says a customer will probably leave is worth nothing unless somebody does something differently as a result. Decide the action before you build the prediction. More on the organisational side of this in AI business use cases.
Sorting and routing at volume
Which pile does this belong in?
Incoming emails to the right team, support tickets by urgency, documents by type, images by what is in them, transactions as routine or needing review.
This is classification, and it is the most dependable thing machine learning does, because the categories are known and examples are usually abundant. It works best where the volume is high enough that people cannot keep up and the cost of an occasional mistake is low enough to absorb.
A good design keeps a human in the loop where confidence is low. Route the clear cases automatically, send the uncertain ones to a person, and the system handles the bulk while people handle the hard part.
That pattern is the one most likely to survive contact with an actual operation.
Finding the unusual thing
Which of these does not look like the others?
Anomaly detection, and it suits problems where you know what normal looks like and cannot enumerate all the ways things go wrong. Fraud, intrusion, manufacturing defects, sensor faults, unusual account behaviour.
Where machine learning is the wrong tool
This is the section the rest of the internet leaves out, and it is the most useful one on the page.
Machine learning is fashionable, which means it gets proposed for problems it does not suit. The cost is not only the wasted project. It is the credibility the next proposal loses when this one fails.
Problems a rule solves better
If a person can write the rule down, write the rule.
A rule is faster to build, cheaper to run, testable, explainable, and changeable by someone who is not a data scientist. It does not drift or need retraining. When it is wrong you can see exactly why and fix it in an afternoon.
Plenty of things called machine learning problems are a handful of conditions. Approvals under a threshold, routing by region, flagging a missing field: these are rules, and dressing them up as a model adds cost and removes clarity.
The same logic is why robotic process automation exists as a separate discipline. A repetitive process with a defined sequence does not need a model. It needs the sequence automated, which is a solved problem with better tools.
A good test: try the rule first. If the simple version gets you most of the way, you have your answer and it cost a week. If it gets nowhere, you have learned that the pattern really is too tangled to write down, which is exactly the finding that justifies a model.
Decisions that must be explained
Some decisions carry an obligation to say why: credit refusals, hiring outcomes, medical decisions, anything a regulator or a court may examine.
Machine learning is awkward here, structurally rather than incidentally. The model found a pattern nobody wrote, so nobody can fully state the reason. There are techniques that explain which factors mattered most for a given decision, and they are genuinely useful, but they approximate the model's reasoning rather than reproducing it.
Sometimes an approximation is enough, and sometimes it is not, in which case a simpler model or an outright rule is the right answer even at some cost in accuracy.
There is a second issue on the same ground. A model trained on historical decisions learns the patterns in those decisions, including the ones nobody would defend out loud. If past hiring favoured a group, a model trained on it will too, and it will do so consistently and at scale. That is a known failure mode, not a hypothetical, and it needs deliberate checking rather than hope.
Situations with no history to learn from
Machine learning trends that change what you can build
Most trends sections list the same four items and explain none of them. Here are four that have actually changed what a normal team can attempt, with what each one changes.
Foundation models and the fall in the cost of starting
The biggest shift is that for many problems you no longer train from nothing.
Large models trained on enormous general corpora can be adapted to a specific task with a fraction of the data that training from scratch required. For language and image work especially, problems that needed a research team and a labelled corpus are now reachable with a small team and a modest set of examples.
What this changes in practice is the shape of the first project. The expensive, uncertain phase used to be building the model. Now it is more often integration, evaluation and the operational work of keeping it behaving.
What it does not change is the data. A general model knows nothing about your business. Adapting it to your problem still needs your examples, and the labelling question comes back in the same form.
Edge inference, and running the model where the data is
Models increasingly run on the device rather than in a data centre: phones, cameras, vehicles, industrial sensors.
Three reasons, and all three are practical: latency, because a round trip is too slow when a decision is needed in milliseconds; connectivity, because the device may not have a reliable link; and privacy, because data that never leaves the device is far simpler to govern.
The constraint is size. A model that runs on a server with no memory limit will not run on a sensor, so edge deployment means smaller models, and smaller usually means slightly less accurate. That trade is often worth it, and it needs to be a decision rather than a surprise. On phones specifically this shapes what is feasible in AI in mobile app development.
Explainability, from research topic to requirement
Explainability used to be an academic interest. It is becoming a requirement, driven by regulation, by procurement and by the reasonable position that an organisation should be able to say why it did something.
The practical effect on projects is twofold. Simpler models are being chosen deliberately, accepting a little less accuracy for the ability to explain a decision. And explanation tooling is being built in from the start rather than added when somebody asks.
If your domain is regulated, treat explainability as a design constraint alongside accuracy. Retrofitting it is expensive, and discovering you cannot explain a model already making decisions is worse.
How to start a machine learning project without wasting a quarter
Start from a decision, not from the technology.
Pick one decision your organisation makes repeatedly. Not a strategic one made twice a year, an operational one made hundreds of times: which ticket goes where, which order to check, which customer to call.
Then ask three questions, in this order, and stop at the first no.
What information is available at the moment the decision is made? Not what exists somewhere in the business, but what is actually available, in a system, at that moment. A model cannot use a field that is filled in the following week.
Do we have a record of what happened afterwards? For hundreds or thousands of past cases, do we know how they turned out? If not, this is a data project first: start recording, and revisit in six months with something to learn from.
What would we do differently if we knew? If the answer is nothing, the prediction is interesting rather than useful. Decide the action before you build the model, because the action determines how accurate the model must be to be worth having.
If all three answers hold, you have a candidate. Now keep the first version small.
Use the data you already have rather than waiting for an ideal dataset. Try the simple approach first, including the rule. Measure against what you do today, because the honest comparison is not against perfection but against current practice, and current practice is often worse than people assume. Put it in front of the people who will use it early, because a model that operations does not trust will not be used however good it is. And plan the second version, since the first one is a way of finding out what you did not know.
The pattern to avoid is the one most organisations follow: a six-month project, a large dataset assembled in advance, a sophisticated model, and a first contact with reality at the end. Reverse it: small, quick, in front of users, then better.
Machine learning applications: quick answers
What is machine learning in simple terms?
In ordinary software a person works out the rule and writes it down. In machine learning you supply many examples of a situation and its outcome, and a program works out the rule for itself. That is why it needs a lot of data, why its answers are probabilities rather than certainties, and why nobody can fully explain the rule afterwards.
What is the difference between machine learning and AI?
Artificial intelligence is the broad field; machine learning is one approach within it. In everyday use, machine learning usually means a model trained on your own data to do one narrow thing, while AI now usually means a large general model trained by somebody else. The difference that matters is where the knowledge lives: a trained model holds your patterns, a general model holds the world's and knows nothing about you.
How much data does machine learning need?
There is no universal number, and any figure quoted as a minimum ignores the variables that decide it. What matters is having enough examples of each outcome you care about, especially the rare one, and having reliable records of what actually happened. A few thousand well-labelled examples of a clear pattern often beat a million rows of inconsistent data.
What are the main types of machine learning?
Three. Supervised learning trains on examples where the answer is known and covers most business applications. Unsupervised learning finds structure without being told what to look for, and its output needs a human to interpret. Reinforcement learning learns by trial and feedback, and suits control problems more than business software.
When should a business not use machine learning?
When a person could write the rule down, because a rule is cheaper, testable and explainable. When the decision must be explained in full, since a model's reasoning can only be approximated. And when there is no history to learn from, in which case the first project is collecting the data rather than building a model.
Where to take your machine learning idea next
The useful first step is smaller than most people expect. Take one decision your team makes repeatedly, write down what information is available at the moment of the decision, and check whether you have a record of what happened afterwards.
If both exist, you have the beginnings of a machine learning problem and a week of work will tell you more than a quarter of reading. If they do not, no model will help yet, and the honest work is getting the data first.
If you want a second opinion on whether something you are looking at is a machine learning problem, talk to 4Labs Technologies. Bring the decision rather than the technology. The most useful answer is sometimes that you do not need a model.
