# How to connect factory machines to AI: start with OT data Prepare factory machine data for AI through approved connectivity, production context, useful evaluation and clear responsibility for operating decisions. Canonical: https://vieox.com/insights/industrial-ai-readiness/ Publisher: VIEOX Published: 2026-10-19 Updated: 2026-10-25 ## How do you connect factory machines to AI responsibly? Establish approved machine connectivity, preserve equipment identity, timing, units and production context, and provide the application only the information needed for a defined task. Evaluate its output against representative operating conditions and keep a reviewer responsible for its use. Reading machine data and authorising an operational action are separate decisions. Connecting factory machines to AI begins with usable OT information: which machine produced a record, what work it describes and whether the application may use it. Production, quality and engineering teams also need to evaluate the output and decide who can act. Start with a bounded operating question and a traceable path from the equipment to the reviewer. ## Choose a question someone owns Improve factory performance is an ambition. Help a production engineer investigate recurring waits after a product changeover is a more useful starting question. It identifies an audience, a decision and the information involved. The same discipline applies to quality variation, energy use and maintenance planning. Ask the team how it works today and what would make a new application useful. A faster review, fewer irrelevant suggestions or a clearer explanation may be better success measures than an impressive demonstration. Keep the first scope small enough for the responsible people to examine the results closely. ## Build the information path from machine to application List the equipment, measurements, units, time references and operating circumstances required. Identify gaps and changes in how the data was collected. Agree which information may be used, who owns it and who can access it. A model cannot be expected to resolve an ambiguous equipment label or an undocumented change in units reliably. Map that path explicitly: the approved device interface, the collected record, the maintained equipment and job references, and the information presented to the AI application. Use an agreed extract or integration boundary for the task. Let reviewers return from an output to its supporting observations, and show gaps instead of making a complete-looking input from uncertain associations. As a practical exercise, give the proposed input record to an experienced colleague who was not present when it was collected. Can they explain which operation it represents and what its limitations are? Their questions are a useful starting list for improving the information supplied to an application. ## Evaluate against the conditions that matter A result from one set of conditions does not establish suitability everywhere else. NIST's AI Risk Management Framework calls for performance to be assessed in conditions similar to deployment, with limits on wider applicability documented. For a production review, consider the equipment types, products, operating loads and periods the team will actually encounter. Examine both missed concerns and unnecessary prompts for attention. Compare the application with the existing method. Reserve appropriate examples for evaluation rather than judging only the material used to develop or adjust the application. NIST's Measure playbook provides further guidance on testing and documenting performance. Sources: [1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), [2](https://airc.nist.gov/airmf-resources/playbook/measure/) ## Make human review a real working step Naming a reviewer is only the beginning. Give that person the relevant recorded conditions, the application's output and its known limitations. Make clear what requires further investigation, what can be accepted and where uncertainty should stop a decision from progressing. NIST's Govern playbook recommends defining responsibilities and connecting AI governance with existing organisational controls. Put that into everyday terms: who reviews a proposed explanation of a production interruption, who can authorise work and who is contacted when the result is disputed? Record the outcome of the review so the team can learn from useful suggestions, false alarms and missed concerns. Sources: [3](https://airc.nist.gov/airmf-resources/playbook/govern/) ## Separate an analytical suggestion from authority to act Operational technology (OT) interacts with the physical environment. NIST's OT guidance therefore addresses performance, reliability and safety requirements alongside security. A useful prediction or explanation does not, by itself, establish permission to change a process or operate equipment. Define the boundary before the trial begins. An application might highlight a period for review or suggest an inspection priority while authorised personnel continue to use the site's established procedures. Any connection that could affect physical operations needs its own assessment and approval. The level of review should reflect the consequences of the proposed use. Sources: [4](https://csrc.nist.gov/pubs/sp/800/82/r3/final) ## Keep learning after the first evaluation Agree how the team will report problems, review changes and judge whether the application remains useful. A new sensor, product or operating pattern is a reason to revisit assumptions. Keep a clear record of the version assessed, the relevant data and the decisions made about its use. This makes later discussions concrete. AI for industry depends on foundations that remain useful across applications. VIEOX is an OT-first Deep Tech company focused on making industrial information usable across production, quality, engineering and maintenance. ConverEDGE supports that conversation through machine connectivity and operating context. Begin with the information your people need and the question an AI application would help them examine. Sources: [2](https://airc.nist.gov/airmf-resources/playbook/measure/), [3](https://airc.nist.gov/airmf-resources/playbook/govern/) ## A useful suggestion needs a considered response. During an evaluation, examine both what an AI application proposes and the conditions for using that proposal. ### Questions about the suggestion - What operating question is it answering? - Which information and assumptions support it? - Where are its limits and uncertainties? ### Questions about its use - Who is responsible for reviewing it? - What evidence would change the reviewer’s view? - What separate authorisation is needed for any operational action? ## Practical starting points - Name a focused operating question and the people responsible for it. - Identify the required data, context and access permissions. - Agree evaluation conditions and practical success measures. - Give reviewers enough information to challenge an output. - Document the boundary between a suggestion and authorised action. - Plan how changes, problems and lessons will be reviewed. ## Questions, answered ### Should every operational question use AI? Choose the method that helps the team answer its question reliably. A clear trend, a defined calculation or an experienced review may be sufficient. An AI proposal should be evaluated against those practical alternatives. ### What if an AI application is already in use? Use the same questions to review its inputs, operating scope, evaluation evidence and decision responsibilities. Identify unclear assumptions and improve the review process before expanding how its outputs are used. ## Sources and further reading - [NIST — Artificial Intelligence Risk Management Framework 1.0, particularly Map and Measure](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) - [NIST AI RMF Playbook — Measure](https://airc.nist.gov/airmf-resources/playbook/measure/) - [NIST AI RMF Playbook — Govern](https://airc.nist.gov/airmf-resources/playbook/govern/) - [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final) ## Related reading - [Machine connectivity and PLC data collection](https://vieox.com/insights/converedge-direct-device-communication/) - [Why operational data needs context](https://vieox.com/insights/operational-data-context/) - [Explore ConverEDGE](https://vieox.com/converedge/) - [Discuss your operating question](https://vieox.com/contact/)