In the previous lessons we defined Machine Learning, traced its history and classified its types. Now it's time to answer a very practical question: what is ML actually used for in the professional world? In this lesson we will tour the most relevant applications sector by sector — retail, healthcare, finance, industry, transportation, language and vision — ground several concrete use cases at MercaFresh, and finish with something that sets a good professional apart: the criteria for deciding when using ML makes sense and when it doesn't. Knowing when not to apply ML saves as much money as knowing how to apply it well.

1. The ML you already use without knowing it
2. Applications by sector
3. Concrete use cases at MercaFresh
4. When does using Machine Learning make sense?
5. When NOT to use Machine Learning?
6. A note on responsibility

Before talking about sectors, notice that ML already mediates your daily life:

• The spam filter in your email (classification, as we saw in the previous lesson).
• The recommendations for shows, music or products that platforms show you.
• Your phone's face unlock and the auto-tagging of your photos (computer vision).
• The autocorrect and predictive keyboard when you type messages.
• The "fastest route" your navigation app suggests, which predicts traffic.
• The near-instant approval (or blocking) of a dubious card payment.

Invisibility is the norm: the ML with the greatest economic impact is not the kind that makes the news, but the kind that works silently inside everyday processes.

This is the sector of our running case study, and one of the most mature in ML adoption:

• Recommendation systems: "customers who bought X also bought Y". On large platforms, a substantial share of sales comes from automated recommendations.
• Demand forecasting: how many units of each product will sell, so you buy and stock just the right amount (regression).
• Churn prediction and customer lifetime value (CLV): whom to target with retention campaigns (classification and regression).
• Customer segmentation for personalized marketing (clustering).
• Dynamic pricing and promotion optimization.

• Image-based diagnostic support: detecting tumors in mammograms or retinopathies in eye fundus images, with performance comparable to specialists on specific tasks (classification on images).
• Risk prediction: the probability of hospital readmission or of a patient developing complications.
• Drug discovery: screening millions of candidate molecules; the AlphaFold case (predicting the 3D structure of proteins) accelerated years of lab work.
• An important note: in healthcare, the model assists the professional, it does not replace them; the clinical decision remains human.

• Real-time fraud detection: deciding in milliseconds whether a card payment is legitimate (classification, with the added challenge that fraud is extremely rare compared with normal transactions).
• Credit scoring: estimating the probability of default before granting a loan.
• Money laundering detection and anomalies in account movements.
• Algorithmic trading and financial time series forecasting.

• Predictive maintenance: anticipating a machine's breakdown from sensor data (vibration, temperature), so it can be repaired just before it fails instead of on fixed schedules.
• Visual quality control: cameras that spot defective parts on the production line.
• Process and energy consumption optimization: for example, cutting the cooling energy of data centers.
• Renewable generation forecasting (wind, solar) to balance the power grid.

• Delivery route optimization considering traffic, time windows and vehicle capacity.
• Estimated time of arrival (ETA), the one you see in navigation and delivery apps.
• Autonomous driving: perceiving the environment (vision), predicting the behavior of other vehicles, and decision-making (where the reinforcement learning we introduced in the previous lesson comes in).
• Mobility demand forecasting: how many vehicles will be needed and where.

More than a sector, these are capabilities that cut across every sector:

• Natural Language Processing (NLP): machine translation, sentiment analysis of reviews, customer service chatbots, document summarization, and the generative AI assistants of the current era (lesson 01-02).
• Computer vision: object and face recognition, automatic document reading (OCR), visual inspection, satellite image analysis.

Now let's come back down to our online supermarket and connect sectors with business realities. These three use cases are representative of what a data team tackles in e-commerce:

Situation: MercaFresh's home page shows the same 20 featured products to every customer. With ML: each customer sees a personalized selection ("your usual shop", "you might be running out of..."). If a customer buys diapers every 3 weeks and it's been 20 days since the last time, the system suggests them.

• Data needed: purchase history per customer, catalog, co-purchased baskets.
• Business value: higher average basket, fewer forgotten items, more loyalty.

Situation: fresh products expire; over-buying creates shrinkage (losses from spoilage) and under-buying creates stockouts (unhappy customers). With ML: a regression model predicts the units of each fresh product for the coming days using history, holidays, promotions and weather.

• A 2% reduction in fresh produce shrinkage can be worth hundreds of thousands of euros a year for a mid-sized chain.
• This is the canonical regression example we will follow in modules 4 and 6.

Situation: MercaFresh promises 1-hour delivery slots, and honoring them is expensive. With ML:

• Predict the actual time of each delivery (regression) so impossible slots aren't sold.
• Forecast driver demand by zone and time slot to size the workforce.
• Detect anomalous orders (odd addresses, atypical amounts) before they leave the warehouse.

The snippet sums up the typical transition in companies: from a reasonable but rigid rule (an average plus a fixed cushion, which ignores holidays, promotions or the weather) to a prediction specific to each day and product. It's not that the rule was absurd; it's that it leaves money on the table.

Not every business question deserves a model. ML pays off when most of these conditions hold at the same time:

1. There is a plausible pattern to learn (bread demand depends on something: day, weather, promos...).
2. We can't write the rules by hand, because they are too many, too complex or change over time (remember the comparison in lesson 01-01).
3. There is data that is sufficient, relevant and accessible about the phenomenon (and, for supervised problems, with the label recorded).
4. The problem repeats at scale: the same decision is made thousands of times (one purchase order per product per day, one prediction per customer). Automating a decision made twice a year doesn't pay off.
5. An error has an acceptable cost, or there is human oversight for the delicate cases.
6. We can measure the outcome (Mitchell's P): without a metric, we will never know whether the model adds value.

Just as important. Signs that ML is not the way to go:

Rule of thumb: always start with the simplest solution that works (a rule, a historical average, a spreadsheet). That simple solution will also become your baseline: the minimum bar any ML model must clear to justify its existence. We will come back to this idea when we discuss evaluation in module 6.

At MercaFresh, two "no ML" examples:

• Calculating the loyalty club discount (a fixed 5% on fresh produce on Tuesdays): pure business rule; traditional programming.
• Deciding whether to open operations in Portugal: a one-off strategic decision; data helps the analysis, but it is not a repetitive prediction problem to automate.

The applications we've seen touch people's lives: granting or denying a loan, prioritizing a diagnosis, showing or hiding an offer. Every model learns from historical data, and if that data contains biases, the model can perpetuate them; moreover, personal data demands careful legal and ethical handling (in Europe, the GDPR). For now, hold on to this principle: the fact that something can be predicted does not mean it should be. We will cover ethics and privacy in depth in lesson 08-04, once you know how to build models.

• Starting from the technology instead of the problem. "Let's do something with AI" is the prelude to failure; "let's cut fresh produce shrinkage by 15%" is a project. First the problem, then the tool.
• Skipping the simple solution. Without a baseline (historical average, current rule), you will never know whether your model adds value or just complexity.
• Assuming "we have data" means "we have useful data". Millions of rows are worthless if they don't record the key variable (e.g., wanting to predict churn without ever having stored cancellation dates).
• Ignoring the total cost. A model has to be built, deployed, monitored and maintained (we'll see this in module 8). For low-impact decisions, that cost outweighs the benefit.
• Tip: run any proposed ML project through this lesson's list of 6 conditions. If it fails two or more, rethink the project before writing a single line of code.

Match each application with its sector and with the most likely type of ML (use the types from lesson 01-03): (a) predicting the energy a wind farm will produce tomorrow; (b) grouping physical stores by similar sales patterns in order to assign their product range; (c) detecting money laundering transactions among millions of bank movements; (d) a chatbot that classifies customer messages into "order", "return" or "complaint".

Apply the 6 conditions of "when does using ML make sense?" to the following MercaFresh assignment: "We want to predict which delivery time slot each customer will choose when placing their order, so we can pre-assign drivers". State condition by condition whether it holds and conclude whether the project is reasonable.

A MercaFresh executive proposes: "Let's use ML to decide this year's Christmas campaign slogan". Explain in 3-5 lines why this assignment is a poor fit for ML, drawing on the table of signs for "when NOT to use ML", and propose an alternative use of ML that would genuinely help the Christmas campaign.

Solution 1

• (a) Industry/energy — supervised → regression (the label is a number: kWh produced).
• (b) Retail — unsupervised → clustering (there are no predefined groups of stores).
• (c) Finance — classification or anomaly detection (laundering is rare and often lacks reliable labels, so unsupervised/semi-supervised approaches also fit).
• (d) Cross-cutting (NLP) applied to retail — supervised → multiclass classification (three categories).

Solution 2

1. A pattern? Yes: customers tend to repeat slots (work routines). 2. Hand-written rules unfeasible? Yes: each customer has different, changing habits. 3. Data? Yes: the order history records the chosen slot (label included). 4. Scale? Yes: thousands of orders per day. 5. Acceptable cost of error? Yes: mis-pre-assigning a driver has a small, correctable cost. 6. Measurable? Yes: percentage of correctly predicted slots. Conclusion: a reasonable project; it is a supervised classification problem (one class per slot).

Solution 3

It is a one-off decision (once a year), a creative one, with no historical pattern to learn from: there aren't thousands of "labeled Christmases" with slogans and comparable outcomes, so the data, pattern and scale conditions all fail. It falls into the "one-off or extremely rare decision" row of the table: better left to the expert judgment of the marketing team. A sensible alternative use: predicting Christmas demand per product (regression on the history of previous Decembers) or segmenting customers to personalize which version of the campaign each one receives.

We have seen that ML permeates every sector — retail, healthcare, finance, industry, transportation — plus two cross-cutting capabilities, language and vision; we have grounded three use cases at MercaFresh (recommendation, fresh produce demand forecasting, logistics) and, above all, we have learned to decide with judgment: ML pays off when there is a pattern, data, scale and a metric, and it is overkill when simple rules suffice, there is no data, or the decision is one-off. With the what, the where it comes from, the what types exist and the what it's for now covered, only the how it's organized remains: in the next lesson we will study the complete workflow of a Machine Learning project, which will also serve as our map for the rest of the course.