How to Choose a Manufacturing AI Use Case and Judge Its Value

What an AI use case is, and what it is not

A use case is a bounded operating decision or workflow where an AI capability would be applied, with a stated measure of success. It is not a model, a platform, or a general capability such as "predictive analytics." The distinction matters because readiness, baseline, risk, and cost can only be judged against a specific piece of work.

Microsoft's guidance on physical AI in manufacturing explains that manufacturers do not need to automate an entire plant to begin, and recommends starting with one operational problem where the outcome matters and the boundaries are clear. The examples Microsoft names are quality inspection, maintenance triage, machine programming, and process optimization. Those examples come from a vendor writing about its own platform, so treat them as illustrations of scope, not as a ranking of the best places to begin.

SAP makes the same argument from the other direction. Its Industry AI leadership writes that AI innovation too often turns into a search for problems to solve, and says SAP starts with the customer's desired business value and works backward. For a manufacturer, the practical reading is to begin with a recognizable pain, such as an exception that takes too long to resolve, and ask whether AI is the right response at all.

How the pieces fit together

A use case touches several systems, and each can play a different role. The examples below are illustrations of how to think about those roles, not a design your environment necessarily follows.

• ERP: if the use case concerns demand or supply decisions, ask whether the ERP is where the orders, materials, and financial facts the model needs originate.
• WMS: for fulfillment-related decisions, ask whether warehouse events originate there.
• A data platform: ask whether records from those systems are brought together and reconciled there.
• An AI/ML platform and BI: the platform hosts the model or agent, and BI is where results may be shown to people.

Which system is authoritative for a given record varies by manufacturer, and the architecture should be established in your own environment instead of assumed. The useful question for any use case is where the relevant facts originate, how they cross from one system to another, and who owns each record along the way.

NIST frames the broader problem in a way that supports this view. Its Advanced Manufacturing Data Infrastructure and Analytics program states that manufacturers need robust data infrastructure and trusted analytics to prepare, model, understand, and use their data for better decision-making. The program also says that technologies are seldom one-size-fits-all solutions, and that research into the role of humans in the process is needed to adopt solutions in existing operations. In other words, the data foundation and the people who work with it are part of the use case, not background to it.

Establishing a baseline you can trust

A baseline is the measured current state of the decision or workflow before any AI is introduced. Without it, a pilot can show activity but cannot show improvement. The sources reviewed here do not prescribe a specific baseline method, so what follows is professional guidance for how to apply the underlying principle.

NIST's AI Risk Management Framework describes the purpose of measurement this way: where tradeoffs arise, measurement provides a traceable basis to inform management decisions. The framework also expects that objective, repeatable, or scalable test, evaluation, verification, and validation processes are in place and documented. Apply that discipline to the baseline. Before the pilot, we recommend that you:

1. Name the decision and its owner. State what is being decided, by whom, and how often.
2. Pick one to three measures that reflect the decision's actual quality, such as time to resolve an exception, rework rate, or forecast error. Choose measures your own records can produce today.
3. Check that the measures reconcile. If two systems report the same metric differently, resolve that before measuring, or the pilot will inherit the disagreement.
4. Record the period and conditions the baseline covers, so a later comparison is fair.
5. Write down total operating cost, including the effort of people who will review or correct outputs, not only licensing or compute.

SAP's article on industry AI explains that the number of models, pilots, or agents a company deploys tells us very little, and that what matters is whether AI transforms the core processes where business value is created. A baseline tied to a core process is what lets you tell the two apart.

Assessing readiness: data, process, integration, ownership

Readiness is not a single score. It is a set of questions about whether this specific use case can run reliably in your operation. We suggest asking the following, and treating any unresolved answer as a reason to narrow the scope or fix the foundation first.

Data fitness. Are the records the use case depends on complete, current, and consistent across the systems that hold them? Ask where the data comes from, how it is transformed, and whether you can trace a result back to its inputs.

Process stability. If the underlying process changes weekly or is handled differently by each shift, a model will learn a moving target. Ask whether the workflow is stable enough to measure and automate.

Integration readiness. Ask how facts will cross from the originating system to where the model runs, and how its output returns to the workflow. A recommendation that no one sees at the point of decision does not change the baseline.

Accountable ownership. Ask who owns the data, the model's behavior, and the decision it informs, and who responds when it is wrong. These may be different people, and the answer should be explicit.

Governance belongs in this assessment from the start. Microsoft's author states that when AI moves from recommending on a screen to acting in the physical world, value and risk both become physical, and that operating limits, identity and security, observability, validated fallback, and human approval and override must be designed into the system. That passage concerns physical systems, but the principle carries over to any use case where an output can trigger action: decide in advance what the system may recommend, what it may execute, and where a person must approve or intervene.

Designing a pilot that can support a scale decision

A pilot is an experiment with a decision attached. Design it so the evidence at the end can justify either scaling or stopping. A workable structure includes:

• A defined scope limited to the one workflow and the systems it needs.
• Human review at the points where an incorrect output would matter, with the approval and override rules written down before launch.
• Documentation of the model and its limits. NIST's generative AI profile suggests documenting assumptions and limitations, data provenance, data quality, proposed use and organizational value, and evaluation data, among other details.
• Stop conditions agreed in advance, such as an accuracy threshold not met, review effort exceeding the time saved, or an unresolved data problem. These are our recommendation; the sources do not set specific thresholds, and you should set yours against your baseline.
• A pre-agreed comparison of pilot results to the baseline, using the same measures and a comparable period.

NIST's framework also notes that options when tradeoffs appear may include recalibration, impact mitigation, or removal of the system from design, development, production, or use. Building that option into the pilot plan, instead of treating it as failure, keeps the scale decision honest.

Finally, think about repeatability before you start. Microsoft's author argues that a successful machine or workcell becomes an enterprise capability only when its data, integration, governance, and operating model can be reused across lines, plants, and fleets; otherwise, the organization scales exceptions instead of capability. Ask whether the pattern you prove in the pilot could be reused elsewhere, because that affects how much of the investment pays back at scale.

Limits and distinctions

Several cautions apply to everything above.

• Value is not guaranteed. A good baseline lets you measure improvement; it does not predict it. Whether operating value justifies the risk and cost is a judgment you make from your own pilot evidence.
• Vendor examples describe what those companies report. The customer results in Microsoft's and SAP's material are those companies' own accounts of their own customers and platforms, and your operation may see different results.
• The right architecture is specific to you. Which system is authoritative, and how data should move, depends on your existing environment.
• Scope boundaries matter. AI that reads business records and supports decisions is different from AI that controls equipment. This explainer addresses the first kind. Machine control and robot behavior involve specialist engineering and safety considerations outside its scope.

A checklist for the decision

Before committing budget to a use case, you should be able to answer each of these in plain terms:

1. What specific decision or workflow is this, and who owns it?
2. What are the one to three measures, and what are their current values?
3. Do those measures reconcile across the systems that report them?
4. Where do the needed facts originate, and how will they reach the model and return to the workflow?
5. What will people review, approve, or override, and who is accountable for errors?
6. What is the total operating cost, including review effort?
7. What result would make us scale, and what would make us stop?
8. Could the proven pattern be reused beyond this one line or site?

If several answers are unknown, that is useful information. It may point to foundation work, such as data reconciliation or ownership, that should come before the pilot.