The greatest benefits of AI in manufacturing usually come not from the projects that look most impressive in a presentation, but from those that reduce the cost or impact of a specific operational problem and use reliable data. It is important to distinguish between the time required to launch a solution, the time to the first measurable result, and the payback period.
A system that works with technical documentation can be launched relatively quickly, allowing its usefulness to be assessed early. A model that predicts rare but very costly failures may require considerably more preparation while still offering greater long-term financial potential.
This is why the question “where can we use AI?” is rarely a good starting point. A better question is: which operational problem is worth solving, and which technology is best suited to it?
In brief
Where does AI deliver a fast return?
Where the expected loss caused by the problem is high, the data is available and sufficiently reliable, and the achievable benefits can cover the full cost of the solution within an acceptable timeframe.
Does every problem require AI?
No. Integration, conventional automation, or mathematical optimization is often a better choice.
Does messy data rule out AI?
No. Unstructured or fragmented data is not the same as unreliable data.
When does AI automate chaos?
When it accelerates a poorly defined process or works with information that does not reflect how operations actually run.
Where does AI deliver the fastest return in a manufacturing company?
The application with the greatest financial potential is not always the best choice for a first pilot. The scale of the problem, the availability and reliability of data, the cost of launching the solution, and the time needed to achieve the first measurable result all matter.
It is worth distinguishing three concepts from the outset:
| Concept | What does it mean? |
|---|---|
| Potential business benefit | The scale of the benefit or avoided loss that the solution may deliver |
| Time to the first measurable result | How quickly the solution’s impact on the actual process can be observed |
| Return on investment (ROI) | The relationship between net benefits and the total cost of the solution over a defined period |
An application that can be tested quickly does not always deliver the highest return. Conversely, the project with the greatest potential does not have to be the best first implementation.
Technical knowledge and documentation
One application that can be verified relatively quickly is the use of generative artificial intelligence to work with existing technical knowledge.
In many companies, the problem is not a lack of information. Machine manuals, procedures, service documentation, tickets, and records of previous failures exist, but they are scattered across folders, systems, and formats. A technician has to know where to look, find the right document, and analyze its contents independently.
An AI system can significantly reduce the time needed to find and analyze information. Simply connecting a model to a folder of documents is not enough, however. The solution should take into account the current versions of documents and user permissions, identify the source of its answer, and be able to decline to answer or clearly state that the available information does not support a reliable conclusion.
Deviation analysis and exception prioritization
Processes in which an employee reviews numerous reports, records, alerts, or events every day solely to find the few cases that require action are also good candidates.
A system can detect deviations at an initial stage, group events, and direct attention to those with the greatest operational significance.
The value does not lie in producing yet another automatically generated report. The value lies in reducing the amount of information a person must review manually before noticing a problem that requires a decision.
A similar approach can be used in purchasing and materials management. The system does not have to place orders automatically – it can identify the components most at risk of shortage, delivery delay, or excess inventory.
Is predictive maintenance a good first AI project?
Not always. Predictive maintenance can have very high potential, but it usually requires a longer, more consistent, and better-described data history than simpler AI applications.
A model trained to predict a specific type of failure will usually need a sufficient history of events and information about the signals that preceded earlier problems.
Prediction accuracy alone is not enough. A forecast must arrive early enough for action to be possible. A model that accurately warns of a failure five minutes before a machine stops may provide no practical benefit if the maintenance team needs two hours to intervene. Too many false alarms will also quickly undermine trust in the system.
It is therefore worth considering simpler applications as well: access to knowledge, diagnostic support, analysis of fault history, or detection of unusual machine behavior.
Quality control – not just image recognition
AI also works well where quality can be assessed using repeatable data: images, measurement results, process parameters, or nonconformance history.
Computer vision can support product defect detection. Machine learning models can analyze relationships between process parameters and quality outcomes. Generative AI can help classify descriptions of nonconformances and find similar cases.
If experienced inspectors regularly assess the same cases differently, the acceptable criteria, escalation rules, and cost of both types of error must be established before automation: allowing an actual defect to pass and unnecessarily rejecting a correct product.
Production planning – AI does not replace optimization
Planning clearly shows why AI should not be treated as a single technology.
A machine learning model can predict a more realistic operation time. Generative AI can assemble source data and present the factors that influenced a risk assessment in a readable form. Such an explanation should be based on data or an analytical model, not solely on the narrative produced by a language model.
Algorithms and optimization engines, meanwhile, are used to build a schedule under multiple constraints.
Even a mathematically optimal result is only as good as the completeness of the process model. If a critical constraint is omitted – for example, the availability of a specific operator, tool, or material – the system may produce a plan that is mathematically correct but impossible to execute on the shop floor.
The best solution may therefore combine prediction, optimization, and decision support.
Should every operational problem be solved with AI?
No. If a problem can be solved reliably with a simpler mechanism, AI may only increase the cost, complexity, and number of components that will later require maintenance.
If data needs to be sent to the ERP system after an order is approved, an integration is needed. If an order above a defined threshold requires additional approval, a business rule is sufficient. If the task is to find the best combination among many alternatives under known constraints, mathematical optimization may be the right tool.
AI is particularly justified where unstructured information must be interpreted, patterns recognized, items classified, outcomes forecast, or situations handled that cannot reasonably be described by a complete set of rigid rules.
| Nature of the problem | Usually the right approach |
|---|---|
| “If A happens, do B” | rule-based automation or workflow control |
| Data must be transferred between systems | integration |
| The decision follows from unambiguous conditions | business rules |
| The best option must be found under multiple constraints | mathematical optimization |
| An outcome must be predicted or unusual behavior detected | machine learning |
| Information in documents or text must be searched and interpreted | semantic search, language processing, and potentially generative AI |
| Features or defects in an image must be recognized | computer vision; multimodal models when an image must be combined with text or other context |
| The problem contains several of the elements above | a hybrid solution |
In complex processes, the last option is often the most useful.
A planning support system can retrieve data through conventional integrations, use a predictive model to estimate operation times, an optimization engine to build a schedule, generative AI to present the context and factors affecting the risk assessment, and business rules to control operations that require human approval.
The best solutions that use AI do not have to be systems built around AI. They should be systems that solve a specific business problem, with AI responsible only for the part of the task where it improves the outcome or reduces cost.
Does AI make sense if a company has messy data?
Yes – if the problem is the unstructured form or fragmentation of the data. Incorrect or outdated information, or events that the company does not record at all, are much greater obstacles.
“Messy data” can refer to at least three different situations:
| Problem | What does it mean for an AI project? |
|---|---|
| Unstructured data | PDFs, emails, descriptions, and documents can be good sources for AI |
| Fragmented data | the method for combining it, its meaning, and the authoritative sources must be established |
| Unreliable or missing data | it may prevent the system from operating reliably |
There is no need to organize all of a company’s data before the first project.
If the goal is to reduce failure diagnosis time, the most relevant data concerns machines, tickets, previous repairs, and technical documentation. Sales or financial data does not need to be part of that project.
Can AI work with PDFs, spreadsheets, and emails?
Yes. The fact that information is stored in these formats does not rule out its use by AI.
What matters, however, is readability, structure, the ability to extract the content reliably, versioning, and context.
A poor-quality scan, a complex spreadsheet with macros, or a document without version information may require additional preparation.
The problem is not the PDF itself. The problem may be five PDFs describing the same procedure when no one knows which one is current.
What should be done with data fragmented across ERP, MES, and other sources?
First and foremost, it must be given a shared context.
The ERP system may contain order and due-date data, the MES may hold information about current production progress, the warehouse system may contain materials data, and an additional spreadsheet may record exceptions not handled by the other systems.
Each source may be correct. The problem arises when it is unclear how records should be linked, which source is authoritative for a given type of information, how statuses should be mapped between systems, and what the absence of a particular value means.
An AI model should not guess the meaning of statuses, identifiers, or relationships between data.
Can AI fix poor-quality data?
Only partially.
It can detect unusual values, classify data, identify inconsistencies, and help organize it. It cannot, however, reliably reconstruct an event that the company never recorded.
If a machine stopped but the downtime was not entered into the system, that information simply does not exist. If employees select a random failure cause solely to close a ticket, the failure history does not reflect the actual causes.
AI can help organize information. It cannot create a reliable picture of operations where the company itself does not record reality.
When does AI automate chaos instead of improving a process?
When it increases the speed of a process before the company establishes whether the process is correct, the data is unambiguous, and the result can be verified.
This is most often visible not in spectacular failures, but in manual workarounds to the official process: additional spreadsheets, decisions made by phone, statuses interpreted differently by different departments, or knowledge available to only a few people.
| AI helps when… | AI automates chaos when… |
|---|---|
| the problem is clearly defined | it is unclear exactly what should be improved |
| the data describes reality sufficiently well | the data is outdated or incomplete |
| the authoritative source is known | the sources present conflicting information |
| the result can be verified | it is unclear what a correct result looks like |
| a specific operational outcome is measured | simply launching AI is considered a success |
| exceptions are known and handled | the actual process relies on informal workarounds |
Operational reporting is a good example.
Suppose a model is expected to prepare a daily summary of production results based on the ERP system, a production report, and a management accounting spreadsheet.
If all sources use the same definitions and it is known which source is authoritative for each metric, the system can quickly identify deviations and provide their context.
If, however, each source defines efficiency differently, calculates it at a different stage of the process, or uses a different time interval, AI may produce a highly convincing summary based on data that contradicts itself.
A fluent and logical answer is not proof that the input information is correct.
How can you determine whether a process is a good candidate for AI?
A good use case combines a significant business problem, sufficient process and data readiness, and an acceptable risk of error.
How should the consequences of an error be assessed?
Before comparing the potential benefits of individual projects, a broader question must be answered:
what will happen if the system returns an incorrect result, fails to provide it on time, or is unavailable?
A solution that incorrectly classifies an internal document is assessed differently from a system whose recommendation may lead to a product being rejected, a machine being stopped, or the schedule of an entire line being changed.
Risk depends on the impact of an error, its probability, detectability, the time available to respond, and whether the decision can be reversed.
It is easier to reduce when mechanisms exist to identify situations requiring additional review, a decision can be passed to a person, an operation can be reversed, or the process can switch to a safe mode.
A fallback mode must also be defined: how the process works without the AI solution and who takes over the decision when the system is unavailable or cannot provide a result within the required time.
If an error can cause serious consequences that are difficult to reverse, the scope of automation should be correspondingly smaller.
Value and readiness matrix
After assessing risk, the use case should be considered across two dimensions.
| Low process and data readiness | High process and data readiness | |
|---|---|---|
| High business value | prepare the conditions and then run a pilot | a good candidate for a business pilot |
| Low business value | do not prioritize | low priority; automate only at low cost or if needed to launch a more important process |
The combination of high value and high readiness means the problem is significant, the right data is available, the process is understood, and the result can be measured.
High value with low readiness does not mean that AI makes no sense. If the cost of a machine failure is very high but the appropriate event history is missing, the first stage may be to improve the way those events are recorded.
Low value with high readiness is the category in which it is easy to implement AI simply because it is technically straightforward. The fact that something can be automated easily does not mean it is worth doing.
Low value with low readiness usually means there is no justification for investment.
Five business questions before starting an AI project
After assessing risk, it is worth answering five questions:
- What exactly is the operational problem we are solving?
- What cost does this problem generate, and which operational outcome does it affect?
- Which decision or activity do we want to improve, how is it performed today, and who is responsible for it?
- What data do we need, and can we trust it sufficiently?
- How will we know unambiguously that the solution works better than the current way of working?
If the answers lead to the conclusion that an integration or conventional automation is sufficient, the analysis has done its job.
The purpose of qualifying a project is not to prove that AI is needed. It is to select a solution whose expected outcome justifies its cost, complexity, and risk.
Proof of Concept, business pilot, and operational deployment – how do they differ?
These three stages answer different questions and should not be treated as interchangeable.
| Stage | Main question |
|---|---|
| Proof of Concept (PoC) | Can the technology perform the required task? |
| Business pilot | Does the solution improve the outcome in a limited but real process? |
| Operational deployment | Can the solution be maintained, monitored, and scaled safely? |
A PoC can demonstrate that a model correctly classifies documents or answers questions using instructions. It does not yet prove that an employee will work faster as a result or that the solution will be cost-effective.
A pilot should use real or representative data, involve target users, and include the most important elements of the future process.
A pilot does not have to operate at a large scale. It can be limited to one line, product type, group of machines, or several users. However, elements that may determine the outcome should not be removed – for example, an integration if access to current data is the project’s main risk.
A baseline must be defined before the pilot
Without a reference point, it is impossible to know whether an improvement has occurred.
If the system is intended to support diagnostics, measurements may include the time spent searching for information, the time required to identify the cause, and the mean time to repair and restore equipment to operation.
If it is intended to detect deviations, the relevant measures are analysis time, the number of cases requiring action, and the time between the occurrence of a problem and its detection.
When comparing results before and during the pilot, parallel changes in volume, product mix, staffing, materials, or process organization must also be taken into account.
Positive user feedback is important, but on its own it does not demonstrate a return on investment.
Should a pilot assume full autonomy from the outset?
No. During the first pilot, an AI system should primarily recommend, prioritize, or classify rather than independently make decisions with major consequences.
This makes it possible to observe how often a user accepts a recommendation, in which situations it is rejected, and when the system lacks sufficient information.
Formal human approval alone is not an adequate safeguard. The user must have access to the sources, criteria, and information needed to assess the recommendation, as well as enough time to verify it properly.
Only observation of actual cooperation between a person and the system shows which decisions can safely be automated to a greater extent.
Quality must still be measured after launch
Operational deployment does not end the work on the system.
Processes, products, documentation, machine parameters, and user behavior change. A model that worked well during a pilot may require renewed validation after several months.
Monitoring should cover not only application availability, but also output quality and changes in key process parameters.
Example: what might an AI pilot in a manufacturing company look like?
Consider an illustrative company in which a planner analyzes several hundred deviations related to production orders every day. Most require no action, but some may lead to a delay, a material issue, or a conflict with another order.
This is an illustrative scenario, not a description of a specific implementation.
Problem: the planner spends a significant part of the day reviewing information manually to find the small group of events that require action.
Baseline: before the pilot begins, we measure analysis time, the number of cases reviewed each day, the number of cases that actually require intervention, and the time between the emergence of a significant problem and its detection.
Data: the ERP system provides information about orders and due dates, the MES or another system that records production execution provides current progress data, and the warehouse system provides information about the availability of key materials. First, it must be established whether identifiers and statuses allow this information to be combined reliably.
Pilot scope: instead of changing the schedule automatically, the system assesses risk and prioritizes events. The planner still makes the decision. The pilot covers one line or a selected group of orders.
Safeguards: an incorrect indication does not change the plan automatically. A false alarm means an additional review by the planner, while a failure to flag an order that is genuinely at risk is recorded and analyzed.
Comparison with a simpler alternative: the model’s result should also be compared with a simple rule-based mechanism. If a few transparent rules identify at-risk orders just as effectively, there is not enough justification for using AI.
Success criteria: before the pilot begins, the main metrics and the minimum values that would justify further development of the project must be defined. These might include:
- a defined reduction in manual analysis time,
- the maximum acceptable percentage of important problems missed by the system,
- the required reduction in response time,
- an appropriate percentage of warnings that enabled effective intervention, provided that a sufficient number of such events occurred during the pilot.
Diagnostic metrics: it is also worth monitoring:
- the number of false alarms,
- the percentage of recommendations rejected by the planner,
- the types of cases for which the system performs worst,
- the impact on on-time order completion, if the scope and duration of the pilot allow it to be assessed reliably.
Decision: if the system meets the predefined criteria, reduces manual analysis, and improves response time with an acceptable error rate, the scope can be expanded. If inconsistent statuses between systems turn out to be the greatest problem, the next investment may be to improve the data and integrations rather than to develop a more advanced model.
Such a pilot answers a business question. It does not merely test whether the model “can analyze data.”
How should the return on AI in a manufacturing company be measured?
Return on investment is assessed by converting a change in operational performance into monetary value and comparing it with the full cost of the solution over the same period. The number of users, model queries, or generated reports describes use of the tool, not its profitability.
It is worth distinguishing three basic measures.
Net benefit:
monetary value of benefits over the period analyzed – total cost of the solution over the same period
Simplified ROI:
(monetary value of benefits over the period analyzed – total cost of the solution over the same period) / total cost of the solution over the same period × 100%
Payback period:
the time after which cumulative benefits, less ongoing costs, cover the initial investment.
Not every project requires an elaborate financial model, but these concepts should not be treated as interchangeable.
If a benefit cannot be converted into monetary value reliably, it is better to present it as a separate operational outcome than to include it in an apparently precise ROI calculation.
The KPI should follow from the problem
For maintenance, relevant measures may include downtime, mean time to repair and restore equipment to operation, or the number of unplanned stops.
In quality control, relevant measures may include the scrap rate, inspection cost, or the percentage of products that pass the process correctly the first time.
In planning, these measures include on-time performance, lead time, and the number of urgent schedule changes.
A system that supports work with documentation may primarily reduce the time spent searching for information and diagnosing problems.
There is no need to force every project into the same KPI.
Time freed up does not always mean cost savings
If AI reduces the time needed to prepare a report from two hours to thirty minutes, it frees up one and a half hours of work.
This does not automatically mean a saving equivalent to one and a half hours of pay.
The benefit arises when the employee can handle greater scale, respond to problems faster, reduce overtime, or use the time for more important tasks.
It is therefore important to distinguish between time freed up and the benefit achieved through that time.
The benefit may come from avoiding a loss
For failures, quality problems, delays, or material shortages, the main benefit may be avoiding a costly event.
Such an outcome must be calculated carefully. A warning about a potential risk does not necessarily mean that the system prevented the entire possible loss.
The greater the benefit attributed to avoided events, the more important a reliable method of comparison with the previous way of working becomes.
The cost of AI is much more than the model
The total cost of ownership should include, among other things:
- process analysis,
- the time contributed by subject-matter experts and users involved in the project,
- data preparation,
- integrations,
- implementation,
- infrastructure,
- licenses or APIs,
- training and changes to ways of working,
- security, access control, and audit,
- monitoring,
- maintenance,
- revalidation,
- handling cases that require human intervention,
- changes following updates to source systems.
The model itself does not have to be the most expensive part of the project. In operational solutions, integrations, exception handling, and embedding the system in daily work often account for a large share of the cost.
Model accuracy is not yet a business KPI
A model with high overall accuracy may be highly useful or completely unacceptable.
Imagine a process in which only 1% of products have a defect. A system that classifies every product as correct would achieve 99% overall accuracy while failing to detect a single defect.
For rare events, the types of errors made are therefore far more important than overall accuracy alone: how many real problems the system misses and how many false alarms it generates.
The cost of each of these errors also matters.
An incorrectly labeled document may simply be sent for manual review. Allowing a critical product defect to pass may be unacceptable even when the model’s overall performance is very high.
Where should a manufacturing company start with AI implementation?
With the problem, not the technology.
First, identify several areas in which the company regularly loses time or money or faces significant risk. Then compare them in terms of potential benefit, process and data readiness, and the consequences of an error.
The next sequence is straightforward:
problem -> process -> data -> technology -> pilot -> measurement -> scaling decision
The outcome of the analysis does not have to be an AI project. The company may need an integration, simpler automation, an improvement in how events are recorded, or a change to the process itself.
That decision is better than implementing AI simply because it can technically be built.
Frequently asked questions about AI in manufacturing companies
Does AI in manufacturing require a large amount of data?
No. The amount of data required depends on the type of application.
Generative AI can work with existing documentation, procedures, and event descriptions without building a large training dataset from scratch. A predictive model created for a specific process may, however, require a sufficiently long and representative history.
The question should therefore not be “do we have a lot of data?” but “do we have the data needed to solve this specific problem?”
Is an MES required to implement AI in manufacturing?
No. An MES can be a highly valuable source of information, but it is not a prerequisite for every project.
Data can come from ERP systems, production execution systems, warehouse systems, quality systems, machines, documentation, or spreadsheets. What matters more is whether it describes the necessary part of the process with sufficient reliability.
Does a company need its own data science team?
No. For a first, limited project, a company can use the expertise of an external team.
It must, however, involve people who understand the process and the data well and can assess whether the system’s output is correct.
As the number and significance of AI solutions grow, the company will need greater internal capabilities in architecture, data, security, monitoring, and system management.
Does an AI solution have to run in the cloud?
No.
Cloud, on-premises, and hybrid architectures are all possible. The choice depends on the type of solution, source systems, required performance, cost, security, and data-processing rules.
The technology should follow from the project’s requirements, not the other way around.
Can AI use confidential company documentation?
Yes, but the architecture must be designed deliberately.
It is necessary to establish where data is processed, what information leaves the company’s infrastructure, who can access it, how long it is stored, under what rules it can be deleted, and whether it may be used to train or improve models.
Access-control, activity-logging, and audit mechanisms may also be needed.
The confidentiality of documentation does not rule out the use of AI. It does, however, affect how the solution should be built.
