Industrial AI Starts With Secure Access to Site Data

Most industrial AI projects do not start with a model.

They start with a much simpler question:

Can we get access to the site data safely?

That might mean live values from a PLC, alarm data from an HMI, pump status from a control panel, trend logs from a historian, energy data from a meter, or production figures from a machine. Before any dashboard, AI assistant, predictive model, or reporting tool can be useful, there needs to be a reliable way to move data from the site into a place where it can be used.

The data often exists already, but it is trapped inside local systems. It might be available on a machine network, an operator panel, a site PC, or a historian that was never designed for cloud dashboards or AI workflows. The tempting shortcut is to expose remote access through port forwarding, open VNC, or direct access to a site device.

A better pattern is to keep the industrial network private and create a secure access layer between the site and the people or systems that need the data. This is where IEC 62443-style thinking becomes useful.

IEC 62443 is not just about adding a firewall and calling the job secure. It encourages a more structured view of industrial cybersecurity: separating systems into zones, controlling communication between those zones through defined conduits, and applying security controls based on risk. In practical terms, that means the PLC, HMI, historian, engineering workstation, site gateway, and cloud dashboard should not all be treated as one flat network.

For a dashboard or AI system, the question should be:

What data is needed, from which system, through which controlled path, and with what level of access?

That is a very different mindset from simply giving remote users broad access to the plant network.

A practical industrial setup might use a small site edge box with separate network interfaces. One interface connects to the machine or controls network. A second interface connects to the internet side, site IT network, 4G router, fibre router, or Starlink router. The PLC and HMI network is not connected directly to the internet router.

This gives a simple but important separation: the site box becomes the controlled boundary between the control network and the outside world.

That boundary still needs to be configured properly. Separate adapters alone are not security if the box simply bridges everything together. The important details are that routing is controlled, access is limited to the devices and ports actually required, and remote users or cloud services are not given open access to the whole plant network.

Tools such as Tailscale-style overlay VPNs can be useful in this type of architecture because they make private, identity-based connectivity easier to manage. The important point is not the tool itself. The important point is that remote access becomes a controlled conduit into the site, not an open door into the control network.

For example, the VPN might allow access only to a dashboard service, a data collection service, or a specific engineering endpoint. In other cases, the site box might collect selected values from PLCs, HMIs, meters, or historians and then forward only the required data onwards to a database or dashboard.

Once that secure access layer exists, the interesting work can begin.

A dashboard can read selected values from the site. A reporting system can collect trends. An AI workflow can analyse alarms, energy, downtime, or process behaviour. A remote engineer can diagnose a problem without needing uncontrolled access to everything.

This matters because industrial AI increases the value of site connectivity, but it also increases the importance of getting the security model right.

If the data cannot be reached securely, the AI project is not ready. If the only access route is a risky remote desktop shortcut, the system needs better architecture before more intelligence is added.

Industrial AI is not just about models. It is about data access, network design, cybersecurity, and practical engineering constraints. The first useful step is often not building the AI system itself, but creating a safe and reliable path from the site to the systems that need to learn from it.