A plant is not ready to implement AI just because it has a historian, a modern SCADA system or a convincing vendor demo. In this guide, a plant is ready when it can frame a concrete operating question, find the evidence behind it, keep a safety boundary in place and assign a person to make the decision that AI cannot make. (NIST 2026 roadmap; NIST AI RMF).
This article proposes an editorial heuristic with eight dimensions. Each dimension gets 0, 1 or 2 points, but the total is not a certification. A zero for the use case, accessible evidence, safety boundary or accountable human blocks the pilot even if the total looks strong. Use the method to decide what needs investigation; it does not replace a risk assessment, functional-safety review, cybersecurity analysis or legal advice.
NIST’s 2026 roadmap for AI and smart manufacturing lists complex industrial data, integration with heterogeneous sensors and controls, and reliable, explainable operation in high-impact settings among the open challenges. (NIST 2026 roadmap) NIST also describes manufacturing analytics as a way to turn process data into knowledge for decisions, while noting that data acquisition and decision-support integration remain barriers. (NIST Data Analytics for Smart Manufacturing Systems).
1. Start with a plant decision you can observe
The first filter is not “which model can we buy?” It is “which concrete decision should become easier to prepare, and how will we know that the answer helped?” A valid question has an object and a time: explain why a line stopped, prioritize a maintenance review, assemble evidence for a deviation or prepare a comparison of parameters inside an approved procedure. “Use AI to optimize the factory” does not define the data, owners or stop condition.
The question needs an owner for the outcome, even when AI only supplies a view or recommendation. It also needs a picture of current work. If a supervisor takes an hour to reconstruct an event, the pilot can measure review time and the number of records that must be reconciled. If the goal is to detect a deviation, define the event, the records that confirm it and the person who decides what happens next. The result does not have to be an improvement. Showing that the assistance adds no value is useful evidence.
NIST describes operations-driven performance measurement as characterizing a system and establishing a baseline against which performance can be compared. (Operations-driven Performance Measurement for Smart Manufacturing Systems) That distinction protects the team from a common trap: measuring model accuracy without measuring whether the decision that motivated the project changed.
The review by Li, Cheng, Møller and Lee covers data problems across the industrial AI lifecycle and proposes connecting data characteristics with model needs and management practices. (Peer-reviewed Computers in Industry article, 2025) It does not provide a universal recipe for one plant. It does support a better question: what data and process knowledge does this task require, and which part can be checked before anyone builds a model?
For a second view on framing the decision, see the NIST 2026 roadmap.
Score this dimension as 0 when the case is expressed as a technology or ambition with no observable decision; 1 when a question exists but lacks a baseline, owner or verifiable success criterion; and 2 when the team has written the decision, scope, baseline, owner and stop condition. A zero blocks the pilot. Before moving on, write a one-page brief naming the event, the human decision, the systems in scope and the data that could test it.
2. Check whether the data can support an answer, not just a chart
More data does not repair missing meaning. Reviewing an industrial event usually requires a stable asset or batch identifier, comparable timestamps, units, operating state, source, procedure version and a way to distinguish a measurement, alarm, human observation and authorized decision. The exact list depends on the question. The minimum for analyzing stops is different from the minimum for reviewing batch quality.
A record that says “temperature 82” is not enough if nobody knows the equipment, unit, operating zone, signal quality or production state in which it was captured. NIST describes an analytics loop in which a system models, captures, transmits, analyzes, communicates and acts on data. If meaning is lost at the handoff, an output can look precise and still be useless for the decision. (NIST Data Analytics)
Audit a small set of records before talking about training. Take known events and check whether the same asset keeps its identity across PLC, SCADA, historian, MES, maintenance and quality systems. Look for clock jumps, unit changes, gaps, duplicates, machine states and fields that exist only in an operator’s memory. A small set of records cannot prove that the whole history is reliable, but it can expose a pilot that depends on manual reconciliation nobody has agreed to own.
Li and his co-authors identify problems distributed across seven stages of the data lifecycle and argue that preparation must account for the model, real-time sensor data and expert knowledge. (Li et al., 2025) That is a reason to include the people who know the process in the audit. Their role is not to turn an opinion into a true label. It is to record what a signal means, which exceptions exist and what evidence could contradict it.
Score 0 when relevant records cannot be located or rely on an inaccessible source; 1 when records exist but have context, quality or lineage gaps that need investigation; and 2 when the team has a bounded inventory, authorized access, documented context and a person who can correct or remove defective data. Accessible evidence is a separate gate. A high total cannot compensate for a team that cannot open, interpret or review the source of a claim.
For a deeper treatment, see industrial data with context. That article focuses on linking records, procedures and events. This checklist asks whether that context is available for the first pilot.
For a comparison of data acquisition and decision support, see Data Analytics for Smart Manufacturing Systems and Operations-driven Performance Measurement.
3. Map context before asking AI to connect signals
AI does not automatically know what a plant tag means or which procedure takes precedence. It can find correlations or gather documents, but the team must define relationships and limits. Which asset belongs to which line? Which recipe version was in force? Which alarm describes a state, and which one requires a response? Which quality record can block a release? Without answers, a pilot can produce a fluent response that mixes different objects.
Context includes operating state. Vibration during startup does not mean the same thing as vibration at steady state. A maintenance note can confirm that somebody intervened, but not that the intervention removed the cause. An output should show its source, timestamp or version, referenced object and the limit of what the record supports. If AI cannot show that trail, its output is a lead for investigation, not evidence for authorizing a change.
OPC UA Part 1 defines a common infrastructure for exchanging industrial information, including information models, messages, transfer and conformance. Its scope includes sensors, actuators, controls, MES and ERP. (OPC Foundation, Part 1) That does not mean any OPC UA installation is ready for AI. A protocol can carry a variable; it cannot decide whether the variable is the right one, whether its server is authorized or whether an application may write to an endpoint.
The practical check is an evidence map for a bounded case. Choose one asset or product family and write its names in each system, the origin of each field, the transformations applied and the procedure that defines its interpretation. Separate measured facts, hypotheses, observations and decisions. If two sources conflict, keep the conflict and assign somebody to resolve it. Deleting the discrepancy to produce a clean dataset gives the team a false sense of readiness.
Score 0 when the team cannot explain what object each signal represents or which source has authority; 1 when a partial map exists but aliases, versions or states remain unresolved; and 2 when scope, lineage, relationships and conflicts are documented for the question. This dimension differs from “data”: an available source can still lack enough context.
The IT/OT integration guide explains the boundaries between plant systems and enterprise systems. In this checklist, that boundary matters as an interpretation limit. Connecting more systems does not decide which relationship is valid.
For the data path behind the map, see NIST Data Analytics and the Li et al. review.
4. Design IT/OT integration as a boundary you can close
In a plant, OT includes systems and devices that monitor or change physical processes. NIST SP 800-82 Rev. 3 says OT protection has to account for performance, reliability and safety requirements as well as threats and vulnerabilities. (NIST SP 800-82 Rev. 3) A first AI integration therefore needs an approved path, a defined purpose and a way to remove access without leaving an unsafe state.
For many pilots, controlled read access is a sensible starting point: the application queries a copy or authorized service and does not write to a PLC, SCADA, DCS or safety logic. This is not a universal rule or an automatic authorization. If the task sends commands, changes a recipe, suppresses an alarm or modifies a setpoint, it is no longer only an analytics test. Engineering, functional safety, cybersecurity and change-management reviews must involve the appropriate authority.
CISA and partner agencies’ OT asset-inventory guidance recommends building an inventory and taxonomy with information about system components. (CISA, Foundations for OT Cybersecurity: Asset Inventory Guidance) For the pilot, inventory interfaces or endpoints, owners, routes, permissions, dependencies, versions and the method for closing access. Record which system preserves the original process if the model is taken out of service.
Score 0 when the path touches physical control without approval, the inventory is unknown or nobody can close access safely; 1 when a route has been proposed but segmentation, permissions, performance or reversibility remain unverified; and 2 when the flow is approved, bounded, auditable and removable without changing operations. A zero at the safety boundary blocks the pilot, even when the application claims only to “help”.
Do not confuse integration with the problem of SCADA, historian, MES and ERP disagreeing. That article looks at exchanges between layers. Here the prior question is whether the required exchange can be authorized and closed.
5. Define safety, human governance and adoption before testing
Pilot safety has two sides. The first is technical: identity, permissions, segmentation, logs, data protection and vulnerability management. The second is operational: what happens if an output is wrong, late, stale or likely to push someone outside a procedure. NIST’s AI RMF is voluntary and general-purpose. It organizes risk work into govern, map, measure and manage, and asks teams to consider trustworthiness during design, development, deployment, use and evaluation. (NIST AI RMF) In a plant, that becomes concrete controls and owners, not a label such as “responsible AI”.
Human governance needs to be observable. Someone with authority must be able to review the source, interpret the output, ignore it, escalate an anomaly and stop the system. That person needs to understand the limits and keep the existing way of working available. Writing “human review” on a slide is not enough if a shift has no time, access or authority to perform it.
Adoption is not the same as holding an initial training session. Check who will see the output, at which point in the shift, what action will change and who maintains the rules when the product or procedure changes. If an operator has to copy values into a parallel spreadsheet, the pilot is creating hidden work. If the security owner cannot review logs or remove access, responsibilities are incomplete.
Regulation (EU) 2024/1689, known as the AI Act, classifies certain systems as high risk, including some safety components subject to harmonization legislation, and sets requirements for risk management, transparency, accuracy, robustness, cybersecurity and human oversight depending on the case. (EUR-Lex, Regulation (EU) 2024/1689) Classification depends on the system, product and use. This article does not determine whether a specific installation falls within a legal category and is not legal advice.
Score safety as 0 when there are no controls or a use boundary, 1 when controls are planned but untested or responsibilities are unclear, and 2 when the route, access, logs, incident procedure and stop mechanism have been tested within scope. Score human governance as 0 when nobody has authority; 1 when a person is named but lacks the time, competence, or decision route to decide; and 2 when role, authority, training and review are documented. Score adoption as 0 when the flow does not fit the shift; 1 when it works only with project-team support; and 2 when the shift can use it and question it without relying on one exceptional person.
To keep the topics separate, see AI capabilities and limits in a plant. That article covers what an assistant can and cannot claim. This section turns that caution into an operating control.
6. Score continuous operation and choose the next scope
The last test is uncomfortable because it comes after the demo. Who maintains the connectors? Who notices a schema change, sensor drift, procedure update or drop in quality? How often is performance reviewed? Where do logs live, and how is evidence of a decision retained? A correct output on day one does not prove that the system remains suitable when the product, shift or source changes.
ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system in an organization. (ISO/IEC 42001) It is a management-system standard, not automatic certification of a model or proof of OT safety. The AI Act also provides for lifecycle risk management for high-risk systems, but its application depends on legal scope and each actor’s role. (EUR-Lex, Article 9)
For a pilot that can operate, create a maintenance sheet: sources and owners, update frequency, quality tests, review thresholds, change log, support, retirement and escalation criteria. Measure what the case requires: review time, reconciled records, false alerts, incidents, exceptions and stop decisions. Do not turn a model score into a substitute for a plant metric.
The decision can fit on four lines. Add the eight dimensions, but apply the gates first. From 0 to 5 points, return to fundamentals: question, evidence, context and limits. From 6 to 11, stay with discovery or a bounded read-only test, with review and no autonomy. From 12 to 16 points, you can evaluate a bounded pilot, never autonomy or control changes by default. (NIST SP 800-82 Rev. 3) Moving from one scope to the next requires more evidence; the band does not grant permission.
| Dimension | 0 points | 1 point | 2 points |
|---|---|---|---|
| Use case | No observable decision | Question lacks baseline or clear owner | Decision, baseline, owner and stop condition defined |
| Data | Samples inaccessible or irrelevant | Samples have gaps | Access, context, quality and owner |
| Context | Signals lack object or authority | Partial map | Relationships, lineage and conflicts documented |
| IT/OT integration | Unsafe or unknown route | Design not validated | Approved, bounded and reversible route |
| Safety | No controls or boundary | Incomplete controls | Controls, logs, incident path and tested withdrawal |
| Human governance | Nobody decides | Owner lacks enough authority | Authority, competence and review documented |
| Adoption | Does not fit the shift | Depends on project team | Usable flow that the shift can question |
| Continuous operation | Nobody maintains or retires it | Maintenance planned | Support, change, review and retirement assigned |
The score is a tool for an engineering and operations conversation. It does not measure compliance, corporate maturity or the safety of an installation. If the plant cannot test a premise, the right result is to investigate or stop. To review a specific case with WizeeMind, contact us about the question, available evidence and boundaries of the first pilot.
Frequently Asked Questions
What does it mean for a plant to be ready to implement AI?
It means the plant can test a specific use case with accessible data, enough context, a safe OT boundary, an accountable person and a way to review results, stop the test and preserve the original process. This article’s score is an editorial heuristic, not a certification. (NIST AI RMF)
Do we need to install new sensors before testing AI in a plant?
Not always. First check which existing records answer the question, what context they lack and whether a new measurement would change the decision. A new sensor can add evidence, but it cannot by itself fix a poorly defined question or an unsafe integration path.
What minimum data is needed for an industrial AI pilot?
There is no universal set. At minimum, the team should be able to identify the variable or event, asset or batch, timestamp, unit and operating state, along with the source, quality and person who can correct or remove the data. The final list depends on the use case.
How can AI connect to a PLC or SCADA without putting operations at risk?
The first pilot should use an approved, preferably read-only path with an asset inventory, segmentation, authentication, logging and a clear boundary that prevents AI from changing control without specific authorization. A change to a PLC, SCADA, recipe or setpoint needs its own assessment.
When can a plant scale an AI pilot?
Only when the test has answered its question with repeatable evidence, has operational and data owners, preserves safety limits and can support updating, review, support and retirement at the next scope. A good local result does not by itself authorize expansion to another line.
Do ISO/IEC 42001 or the AI Act guarantee that a project is safe?
No. ISO/IEC 42001 defines requirements for an AI management system, and the AI Act sets obligations according to the system and its use. Neither replaces a site-specific review of OT, process safety, data, people and applicable law, nor turns an editorial score into compliance. (ISO/IEC 42001; EUR-Lex, AI Act)