Every manufacturer now hears "adopt AI." But the hardest question is not which model to buy - it is which problem to point it at. A good AI use case is a specific, high-value question where you have (or can get) the data to answer it, and someone ready to act on the answer. Get that choice wrong and even the best model changes nothing.
This post answers a scoped question: how do you find and prioritize AI use cases on a real shop floor - without boiling the ocean?
What actually counts as an AI use case
An AI use case is not "use AI." It is a specific prediction or classification tied to an outcome. A real candidate has four things:
1) A prediction or pattern - "this bearing will likely fail in the next 200 hours" or "this batch shows early signs of the defect", not a static report. 2) Value - real money at stake: downtime, scrap, energy, or lost throughput. 3) An action - someone can do something *before* it is too late. 4) Data feasibility - the signals that carry the answer exist and can be labeled.
If any one of those is missing - prediction, value, action, or data - it is not yet a use case. It is a wish.
Where to look for candidates
Do not start from the technology. Start from pain. The best hunting grounds:
- Unplanned downtime - which assets stop most and cost most? (predictive maintenance)
- Quality and scrap - where do defects show up late and expensively? (early quality-drift detection)
- Energy - where does consumption spike without matching output? (energy optimization)
- Throughput and bottlenecks - which station limits the line, and why? (bottleneck prediction)
- Planning and demand - where do manual forecasts miss again and again? (demand / maintenance planning)
- Manual inspection - where do people check items one by one? (visual inspection)
Ask an operator and a maintenance lead one question: "What surprises us again and again?" Surprises that repeat are usually your best AI candidates, because a repeating pattern is exactly what a model can learn.
How to prioritize: value x data feasibility
You will always find more candidates than you can build. Score each on two axes:
- Value - money at stake per year if you get it right (downtime hours x fully loaded cost, scrap cost, energy cost, missed throughput).
- Data feasibility - can you actually build it? This is mostly a data-readiness question: do consistent signals exist, are they sampled often enough, is there context (product, shift, setpoint), and can outcomes be labeled?
Plot the candidates on a simple 2x2:
- High value + ready data -> start here. Quick wins that prove value fast.
- High value + data not ready -> invest in data first. Worth doing, but fix the foundation before you model.
- Low value + ready data -> nice to have. Do it later.
- Low value + hard to build -> skip.
The trap most factories fall into is starting in the "high value, data not ready" box - a big, ambitious project on data nobody has structured yet - and stalling. Win in the top-right first, then use that result to fund the harder ones.
Common high-value use cases (and the data they need)
Notice the same pattern in every one: signals + context + labeled outcomes.
- Predictive maintenance - vibration / current / temperature time-series + labeled failure events.
- Quality drift - process signals + inspection results / scrap reasons, labeled.
- Energy optimization - consumption signals + production output + context.
- Throughput / bottleneck - cycle times and machine states per station + stop reasons.
So "feasibility" is really a data-labeling question. Two ideas can have identical value; the one whose outcomes you can label is the one you can build.
A worked example: scoring three candidates
Say three ideas are on the table:
1) Predict failures on packaging line 3. Value: ~120 downtime hours/year x 4,000 EUR = ~480k EUR. Data: PLC signals exist, stop reasons only partly logged. -> High value, medium feasibility. 2) Optimize compressor energy. Value: ~90k EUR/year. Data: energy meter + load signals already available and clean. -> Medium value, high feasibility. 3) Predict scrap on a brand-new product line. Value: potentially high, but only 3 weeks of history exist. -> High value, low feasibility (not yet).
Sensible order: start with #2 - it is fast, doable, and proves the approach to skeptics. Run #1 in parallel while you clean and label the stop reasons that make it feasible. Revisit #3 once it has a few months of labeled history. You are sequencing by readiness, not just by ambition.
Turn a candidate into a buildable use case
Once you pick one, make it concrete:
- Write the question in one sentence - "predict failure on line 3 at least 24h ahead."
- Define success - e.g. catch 70% of failures with fewer than X false alarms.
- Inventory the data - which tags, what sampling frequency, how much history.
- Add context and labels - mark failures, scrap, and stop reasons on the time-series.
- Name the action and the owner - who does what when the model raises a flag.
Steps 3 and 4 are where use cases live or die. This is exactly what a labeling workflow is for: importing your signals, adding context to events, and marking outcomes - so a vague idea becomes a trainable, provable use case.
Practical rule
Do not ask "where can we use AI?" Ask "what repeatable, expensive surprise could we predict - and do we have the data to learn it?" Rank candidates by value and data readiness, win one in the top-right corner, and let that first result pay for the next.
Turn your top use case into an AI-ready dataset: import your signals, add context to events, and label outcomes to make a candidate buildable in Predsense labeling: https://www.predsense.ai/products/labeling