Manufacturing has no shortage of AI ideas.

The difficult part is working out whether a good idea is actually ready to become a project.

A manufacturer may already have years of machine data, a Manufacturing Execution System (MES), an Enterprise Resource Planning (ERP) system and dashboards across several plants. That does not automatically mean the data needed for a particular AI use case is available, usable or connected to the outcome the business wants to improve.

The opposite is also true. You do not need perfect data or a fully modernised technology estate to get started.

What matters is whether you clearly understand the manufacturing problem, have enough usable information to investigate it, know who owns the problem, and can measure improvement.

That is a much more useful test of whether you are ready to move forward with AI.

To work out whether an AI use case is ready to move forward, start with what matters the most to the business, the data and the people who will use the result.

1. Start with the manufacturing issue you want AI to improve

A common starting point is “Where could we use AI?”

It sounds reasonable, but it immediately puts the technology ahead of the problem.

A better starting point is much more specific.

Perhaps an important machine fails without enough warning, causing unplanned downtime. Maybe quality problems are discovered at final inspection when rework costs are already high. Or your planning team repeatedly struggles to forecast demand accurately enough to schedule production and materials.

These are operational challenges, and AI is only one possible way to address them.

So before discussing models, platforms or algorithms, describe what is happening today.

• For predictive maintenance, that might be, “We do not identify signs of a particular equipment failure early enough to plan maintenance before production is disrupted.”
• For quality inspection, “A particular defect is difficult to identify consistently during production, so we sometimes find problems further downstream.”
• For forecasting, “Our current forecast does not reflect demand changes quickly enough, leading to repeated changes in production plans.”

The more specific the problem, the easier it is to determine what information is needed and whether AI has a realistic role.

2. Be clear about who owns the use case and the business outcome

Once the manufacturing problem is clear, the next question is who owns improving it. The data or IT team may support the AI work, but ownership of the business outcome needs to sit with the part of the organisation responsible for the problem.

For example, if the problem is unplanned downtime, manufacturing or maintenance needs to be involved. If the problem is poor forecast accuracy, that may be planning or supply chain. If the aim is earlier defect detection, quality and production both have a role.

That does not mean one person needs to run the whole project. It means there should be clear answers to a few practical questions:

• What problem are we trying to solve?
• How does it affect the operation today?
• What would we do differently if AI gave us better information?
• Who is accountable for making that change happen?

Without clear ownership, an AI project can work technically without changing what happens in the business.

This is also why AI governance cannot sit entirely with technical teams. It should be clear who owns the use case and the data, how the output is used, and whether the expected improvement is actually being achieved.

3. Do you have the right data for the AI use case?

Having a lot of manufacturing data is not the same as having the right data.

Predictive maintenance provides a useful example of why having the right data matters.

Temperature, pressure and vibration readings can show how a machine is operating. Still, if the goal is to predict a specific failure, those signals are much more useful when linked to reliable records of what happened to the equipment. To assess whether that supporting information is available, ask:

• When did it fail?
• What type of failure occurred?
• Was a component replaced?
• Was the apparent failure actually planned maintenance?
• What conditions was the machine operating under at the time?

Many predictive maintenance approaches that aim to predict specific failures rely on both operating information and an accurate history of failures or maintenance events.

The same principle applies elsewhere.

For quality AI, a product image is useful only if you can reliably link it to whether the product was acceptable and, ideally, what type of defect occurred.

For forecasting, historical demand alone may not tell the whole story. Changes in price, promotions, seasonality, production constraints or other factors can affect the pattern you are trying to predict. Historical data also becomes less useful if the business or product has changed substantially.

Start by asking, “What information would we need to understand this problem properly, and do we actually capture it?”

4. Is your manufacturing data usable enough to support the project?

The next question is not whether your data is perfect, but whether it is reliable and consistent enough for the problem you are trying to solve.

In manufacturing, practical issues often become visible only when data from different periods, plants or systems are brought together.

A machine may have had a sensor configuration change two years ago. Different plants might describe the same quality defect differently. Maintenance technicians may record the same failure under several codes, while product IDs may not match between production and quality systems.

These inconsistencies do not automatically rule out an AI project, but their importance depends on how closely they relate to the outcome the model needs to predict.

For example, imagine you want to predict bearing failures. The sensor data appears reliable, but the maintenance history records most interventions simply as “repair”.

Even with plenty of data, you cannot reliably distinguish a bearing failure from a lubrication problem or an unrelated maintenance event.

That gap could limit what the project can achieve because the outcome label is unreliable. By contrast, a missing field that has little bearing on the result may not matter. Data quality should therefore be assessed in relation to the specific use case, focusing first on the information most important to the outcome.

5. Which data gaps could stop the AI project before it starts?

Some gaps you can fix during a project. Others change the project completely.

The most important ones to identify early are usually those connected directly to the outcome you want to predict or detect.

• For predictive maintenance, you may find equipment failures are not recorded consistently enough to train a model. If the asset rarely fails, there may be too few examples of the event you are trying to predict.
• For visual quality inspection, you may have thousands of images of good products but very few examples of each defect type.
• For forecasting, you may have several years of sales history, but a recent product change or market shift means much of that history no longer represents what happens today.

Finding a gap like this does not necessarily mean abandoning the use case. It helps you decide what the project needs before you begin model development.

It may mean changing the first phase of the work.

Instead of building a predictive model immediately, you might improve failure recording, collect defect examples, add a missing sensor, or strengthen connections between existing data sources.

That can feel slower than starting with the AI model. In reality, finding the gap before building the model can save a lot of wasted effort later.

6. Understand how the process works today before introducing AI

AI does not operate in isolation from the manufacturing process. Before introducing it, understand how the work happens today and where a new output could influence a decision or action.

Take predictive maintenance. When an operator notices an unusual machine condition, who investigates it? What information do they check, when does maintenance become involved, and what triggers a planned intervention?

Now consider how that process would change if an AI model warned that the machine had an increased probability of failure.

Someone still needs to review the warning, judge its credibility, and decide what action to take. If responsibilities are unclear, or production cannot stop the machine when needed, the model has not solved the operational problem.

The same principle applies to quality inspection.

An AI system might identify a possible defect in milliseconds, but the process must determine what happens next. Does the product stop automatically, does an operator inspect it, is it diverted from the line, and who confirms whether the alert was correct?

Mapping the current process and the proposed response makes these practical requirements visible before they become deployment problems.

7. Define what should improve if the AI use case succeeds

It should be possible to explain success without talking about the AI model.

For example:

• Maintenance receives enough warning to inspect a machine before an unplanned stop.
• Quality teams identify a particular defect earlier in production.
• Planners produce forecasts that lead to fewer unnecessary production-plan changes.

These describe a change in the manufacturing process.

That distinction matters because a technically impressive model can still produce a poor business result.

An AI model might become very good at identifying a particular quality defect. But if a simpler inspection method already catches the defect reliably at the same point, the added benefit may be small.

Likewise, improving forecast accuracy has limited value if production plans cannot respond to the forecast because of fixed capacity or long supplier lead times.

The key question is not simply whether the model performs well, but what will actually change in the operation if the project is successful. Defining that change gives the project a clear business outcome and provides the basis for deciding how to measure its value.

Decide how you will measure whether the project delivers value

Do this before the project starts.

If the goal is to reduce unplanned downtime, establish how much downtime the relevant failure currently causes.

If you want to identify defects sooner, understand the current defect rate, where defects are normally detected and what happens when they are missed.

If you want to improve forecasting, agree which forecast accuracy measure matters and at what level. A forecast might look accurate across a whole product category while still being poor for individual products that matter to production planning.

It is also worth separating model performance from business performance.

A computer vision model may be measured by how accurately it distinguishes between acceptable and defective products. The business may care about reduced scrap, fewer escapes to customers or less manual inspection.

Both matter, but they are not the same measurement.

This is why evaluation should be planned as part of the AI system, not added at the end.

8. Make data ownership, access and accountability clear

Manufacturing data often crosses organisational boundaries.

Machine data may sit with operational technology teams. Maintenance history may be in an enterprise asset management system. Quality information may belong to another function. Production data may be managed locally at each plant. Cloud access may sit with central IT.

An AI project can therefore get surprisingly far before someone discovers that an important dataset is difficult to access or nobody is clearly responsible for its quality.

Before starting, establish:

• Who owns the operational problem
• Who is responsible for the important data
• Who can approve access
• Who understands what the data actually means
• Who is responsible for the AI output once it is being used
• Who monitors whether the use case continues to work as expected

This becomes even more important when systems affect safety, people or critical operations.

AI trustworthiness is not only about model accuracy. Established frameworks also consider reliability, safety, security, accountability, transparency and other characteristics throughout the system lifecycle.

9. Check the technical and delivery requirements before you start

Once the manufacturing problem, data and ownership are clear, the technical questions become much easier to answer.

Requirements vary considerably by use case.

Predictive maintenance may require access to high-frequency sensor data, historical maintenance records and a way to connect the model output to existing maintenance processes.

Computer vision may require cameras positioned correctly for the defect being inspected, consistent lighting, sufficient image quality, and a way to process images quickly enough for the production process.

Forecasting may require information from ERP, planning, sales and external sources at consistent levels of detail and time periods.

Then there are practical deployment questions.

Where will the model run? How often does it need new data? How quickly does it need to respond? Does it need to work if connectivity is lost? How will access be controlled? How will you monitor the model once production conditions change?

Do not assume this requires replacing the existing systems.

Often, the practical question is how the AI capability fits around ERP, MES, maintenance, quality or other systems already in place.

10. Why plant teams need to be involved from the beginning

The people closest to the manufacturing process often know things the data does not explain.

An engineer may know that a temperature increase is normal during a particular product run.

An operator may know that a certain quality mark is harmless even though it looks visually similar to a genuine defect.

A maintenance technician may know that a particular alarm frequently appears after cleaning and has nothing to do with equipment health.

Without that context, a technically sensible analysis can reach the wrong conclusion.

Plant involvement is also important when deciding whether the output can actually be used.

In one real industrial computer vision project, we used existing CCTV infrastructure to identify people and vehicles moving through shared or restricted areas. The work was not simply a model-building exercise. Health and safety and IT and security teams were involved; the solution had to meet strict data-security requirements, and we first piloted it in one factory before extending it to other locations. Holisticon

That pattern is relevant beyond safety. Start with a real operational problem, involve the people who understand it, test the approach in its real environment and learn before scaling.

11. Why manufacturing AI pilots often stall

A pilot can prove that an algorithm works without proving that the organisation can use it.

That is where many difficult questions appear.

The model may need data that was prepared manually for the pilot but cannot realistically be prepared every day.

An engineer may have labelled hundreds of examples by hand, without a process for labelling new data later.

The pilot may display a prediction on a separate dashboard that operators do not normally use.

Or the team may have demonstrated good technical performance without agreeing who is responsible for acting on the result.

Production conditions can also change.

Equipment is upgraded. Products change. Recipes change. Sensors are replaced. Operators work differently. A model trained on yesterday’s conditions will not necessarily continue performing in the same way indefinitely.

Moving from pilot to normal operations therefore means thinking beyond model development.

You need a repeatable data flow, a clear operational process, monitoring, ownership and a plan for what happens when the system no longer performs as expected.

12. What being ready for a manufacturing AI project actually looks like

Being ready does not mean having perfect data, every system integrated, or every technical decision already made.

It means the important questions are clear enough to make a sensible investment decision.

For a practical manufacturing AI project, you should be able to explain:

• The problem: What manufacturing issue are we trying to improve?
• The owner: Who is responsible for that operational outcome?
• The data: What information does the use case need, and do we have enough of it?
• The gaps: What is missing or unreliable, and can we realistically address it?
• The process: How does the work happen today, and where would the AI output fit?
• The measure: What should improve, and how will we know whether it has?
• The delivery requirements: What integration, infrastructure, security and operational changes are needed?
• The users: Who will use the result, and what will they do differently?

If several of those answers are still unclear, that does not mean AI is off the table.

It tells you what needs attention before you commit significant time and budget.

13. How to identify the biggest gaps in your AI readiness

AI readiness is more useful when it is assessed against a specific project rather than treated as one overall technology score.

A manufacturer may be well prepared for one AI project and much less prepared for another. For example, years of well-structured condition-monitoring data for a critical asset could make a predictive maintenance investigation realistic. In contrast, inconsistent quality records across several plants could make a cross-site quality AI project much harder.

That is why it helps to take the project you are considering and look at where the uncertainty sits. The business problem may be clear, but the data may never have been assessed properly. The data may be strong, but ownership of the operational outcome may still be unclear. Or both may be in place, but there may be no baseline to show whether the project has improved anything.

Those gaps should shape what happens next. That might mean spending time investigating the data, agreeing who owns the outcome, establishing a baseline, or testing whether the proposed AI output fits into the production process before moving further.

If you want to look more broadly at whether your organisation has the direction, data and conditions needed to move forward with AI, the AI Readiness Assessment provides a structured way to identify strengths and gaps before deciding where to invest.

14. What a practical manufacturing AI project looks like in practice

A good first AI project is usually narrower than people initially expect.

Imagine a manufacturer interested in predictive maintenance across ten plants.

The first instinct might be to connect every critical machine and develop a company-wide predictive maintenance capability.

A more practical starting point could be one recurring failure on one machine type at one plant.

The team already knows the failure disrupts production, maintenance has several years of service history, relevant condition data is available, and engineers understand which operating conditions matter.

Rather than building a global AI platform straight away, the first phase is to check whether the available data contains enough information to identify the conditions associated with that particular failure.

If it does, the team can test whether a model gives maintenance enough warning to act.

Then comes the important part.

Did the warning arrive early enough? Did maintenance trust it? Could they inspect or repair the machine without creating a different production problem? Did the intervention reduce the disruption the project was meant to address?

Only then does scaling become the next question.

The same thinking works for quality AI and forecasting.

For quality AI, that might mean focusing on one defect rather than every quality problem. At the same time, forecasting could begin with one product family where there is a clear operational issue instead of trying to rebuild forecasting across the whole company.

From there, you can learn what the data supports, test the output with the people who would actually use it and measure the result against what happens today.

AI readiness is not about having everything in place before you begin.

It is about knowing enough to choose a worthwhile problem, understand the gaps, test the idea responsibly and recognise whether it has actually made the manufacturing process better.

What to do next

Before moving further with AI, it helps to review the project against the practical conditions it will depend on.

That means checking whether the manufacturing problem is clear, the right data is available, ownership is defined, the expected improvement can be measured, and the output can fit into the existing process. You can then address any gaps identified at this stage before committing more time and budget to development.

Want to assess where you stand?

The AI Readiness Assessment helps you review the data, ownership and conditions that can affect whether an AI project is ready to move forward.

TAKE THE AI READINESS ASSESSMENT