The power of AI is useless without control over factory data

Industrial AI: governing data before the model

Three approaches compared.

In recent months, a question we often hear from production managers is no longer "how can artificial intelligence help me in the factory?". The power of AI is useless without control over factory data.

Already using it daily, and perhaps trying to feed it some machine data, we have come to understand its potential.

The most frequent question now is: "which AI should I use for my factory? Claude, ChatGPT, a dedicated model?". It is a legitimate question. But it is the wrong question.

Using an LLM effectively in a factory has nothing to do with the choice of model. Choosing a language model today is almost irrelevant to the final result. The most widely used models, as well as local models, are already capable enough to understand a question in natural language and reason over structured data. The problem is not here.

The real bottleneck of Industrial AI is everything that sits between the model and the actual factory data, meaning what needs to happen before the question is even asked.

Who prepares your factory data for the LLMs? Who updates it, contextualizes it, and verifies its reliability? Who 'translates' it to make it understandable for the model? And who controls the actual use of your factory's specific data, ensuring that the LLM does not use out-of-context data that may be 'statistically plausible' but leads to incorrect answers, hallucinations, or worse?

So, if you are evaluating AI adoption for the factory, you are probably on one of these three tracks.

• the classic IT project: specs, integration, custom development, months of work before seeing anything in production, and once finished, a high risk of ending up with a system too rigid to handle the 'next question' someone on the shop floor will inevitably think of. And, most likely, already obsolete given the pace of technological change.

• a direct, DIY connection to a public 'AI Copilot': extremely fast to try, but with no real context, no governance over what is shared and used, and no repeatability when something in the factory changes.

• The third path is the one almost always missing from the conversation: building a layer that connects the machines and the management systems you already have, builds and maintains your factory's knowledge in a governed way, and makes it available to whatever language model you choose, today or a year from now.

Before the data, context.

It is a simple principle, but worth stating clearly: an LLM does not invent the knowledge of your factory, it amplifies it starting from what you feed it.

If the data is fragmented, if context is missing (a machine stoppage with no record of which order was running, a productivity drop with no indication of whether there was a format change), if the information that allows the AI to 'understand' your factory, your lines and your processes is absent, then the AI, if well controlled, will not fill that gap on its own and will provide partial answers. And if it is not well controlled, it will fill it with information of its own, producing a complete but potentially wrong response.

This is why so many attempts to directly connect a public LLM to an Excel data export or an existing dashboard stall after the first burst of enthusiasm.

It works on a single demo question, then collides with reality: outdated data, no traceability of where it comes from, no guarantee of what happens to the information you passed to the LLM.

What does your factory need for industrial AI?

What is needed to use language models effectively on factory data is a 'factory knowledge management' platform, which must include:

• native machine integration, regardless of brand or protocol, providing a uniform semantic model

• connection to the management systems in use, to provide the operational context for machine data

• a layer that builds factory knowledge from all relevant information, including unstructured documents and informal knowledge, before users ever interact with the AI

• tools to govern LLM usage and the actual use of information

Concretely, the factory must have a consistent historical database of machine and process data. This must be integrated with an AI-friendly data layer where a 'Knowledge Agent' reads and digests technical documents, machine data and the team's informal knowledge, building a referenceable knowledge base.

On top of this data layer (the 'Knowledge Graph'), 'Analyst Agents' then operate, allowing anyone authorized on the shop floor to ask, in natural language, for any information they need.

For example: "why did line 4 lose efficiency yesterday?" or "what were the main causes of scrap last month on the pump assembly lines?". Getting an answer grounded in real data, not invented by the LLM based on 'similar' data from some random factory a few months ago.

If the platform already has these analyses ready, it will use them, already validated and tested; otherwise, when it does not, the Analyst Agents must be able to build them autonomously and on demand, without requiring a separate development project.

The infrastructure that stays yours, whatever model you choose

And if tomorrow the company decides to switch LLM providers, or to add a local model for security or cost reasons, the integration with machines and systems must remain the same, as must the entire knowledge base that has been built, which cannot be lost.

So, the priority is not to choose an AI vendor. It is to understand how to build the layer that runs on your own infrastructure, where you decide, not on the cloud of whoever is selling it to you.

The right question to ask now is therefore not "which AI do I choose for my factory", but "is my factory ready for any AI to work well on my real data?".