AI for Industrial IoT
Industrial IoT projects rarely fail on modelling. They fail because the sensor data was collected at the wrong resolution, the edge could not run what the cloud designed, or nobody decided what to do when connectivity dropped.
The most expensive mistake in industrial IoT is made at installation, when someone chooses a sampling rate. Vibration analysis needs kilohertz and someone specified one reading a minute, and no model recovers what was never sampled.
AI for industrial IoT covers edge inference architecture, sensor data pipelines and storage design, condition monitoring and anomaly detection, connectivity and offline behaviour, and the cybersecurity and data access obligations that apply to connected industrial products.
Sampling and resolution decisions you cannot undo
Sensor data is only as useful as its resolution, and resolution is fixed at installation. Aggregated averages discard the transients that carry the diagnostic signal, and no amount of modelling recovers information that was never captured.
| Application | Resolution needed | Common mistake |
|---|---|---|
| Vibration and bearing analysis | Kilohertz, raw waveform | One averaged reading per minute |
| Electrical signature analysis | High-frequency current | RMS values only |
| Temperature trending | Minutes is fine | Over-sampling and storage cost with no benefit |
| Process control variables | Seconds | Reasonable defaults, usually adequate |
| Event and alarm sequences | Millisecond timestamps | Timestamps at insertion rather than at occurrence |
| Energy and power quality | Sub-second for transients | Billing-interval data used for diagnostics |
Timestamps at insertion rather than at occurrence destroy sequence analysis
A surprising number of industrial data pipelines record when a value arrived in the database rather than when it was measured, which silently destroys the ordering of events. Anything depending on sequence — root cause tracing through an alarm cascade, lead-lag relationships, event correlation — becomes impossible, and the problem is invisible until someone tries. Check this before designing anything, because it is cheap to fix at source and unrecoverable afterwards.
Edge, cloud and what happens when the link drops
Decide where inference runs before choosing a model
Latency, bandwidth cost, connectivity reliability and data sensitivity all push toward the edge; model size, retraining and monitoring push toward the cloud. That trade-off determines architecture and it should be made explicitly in week one. See edge AI deployment.
Bandwidth is a real constraint at industrial scale
High-resolution vibration data from a few hundred sensors will saturate a plant network and a cellular budget. Edge preprocessing that extracts features and transmits those rather than raw waveforms is usually the workable design.
Offline behaviour is a design decision, not an incident
What the system does when connectivity drops — buffer, degrade, continue on last known model, stop — has to be decided and tested. Industrial connectivity fails routinely and a system that behaves unpredictably then is worse than one that behaves simply.
Model updates at the edge need a rollback path
Pushing a new model to a thousand devices is a deployment problem with real failure modes. Staged rollout, health checks and a tested rollback are requirements rather than refinements.
Cybersecurity and data access obligations
Connected industrial products now carry obligations from two directions: cybersecurity requirements on the product, and data access rights for the user. Both affect architecture rather than just documentation.
- Cyber Resilience Act. Vulnerability reporting obligations began 11 September 2026; the main cybersecurity requirements apply from 11 December 2027, with third-party assessment for high-risk products.
- Security by design over the lifecycle. Vulnerability handling for the life of the product, which for industrial equipment can be fifteen years or more — considerably longer than most software support commitments.
- Data Act access rights. Users can access the data their connected product generates and share it with third parties, and devices must be designed to allow that.
- Machinery Regulation if it is in a machine. An AI component performing a safety function brings third-party conformity assessment from 20 January 2027.
- Model files and configuration are attack surface. Signed, validated model artefacts and protected configuration are part of the security posture, not an optional hardening step.
- Three documentation sets that must agree. CRA, Machinery Regulation and AI Act obligations on one product is a single programme, not three.
How an engagement runs
Architecture and data resolution first, because both are expensive to change afterwards.
Architecture and obligations
Edge versus cloud, offline behaviour, and which of CRA, Data Act and Machinery Regulation apply to the product.
Sensor and pipeline assessment
Sampling rates, timestamp semantics, storage design and whether the data can support the intended application at all.
Build
Condition monitoring or anomaly detection, with edge preprocessing sized to the bandwidth available.
Field trial
Including deliberate connectivity loss, model update and rollback exercises.
Operation
Staged model rollout, device health monitoring, and vulnerability handling over the product lifecycle.
What you receive
Data you can actually model on, and a connected product that meets its obligations.
Data resolution specification
Sampling rates and timestamp semantics fixed correctly before installation.
Edge and cloud architecture
Where inference runs, with bandwidth and offline behaviour designed rather than discovered.
Sensor data pipeline
Feature extraction at the edge where raw transmission is not viable.
Condition monitoring
Against known-good signatures, which needs no failure examples.
Model deployment and rollback
Staged rollout, health checks and a tested rollback across the device fleet.
Compliance architecture
CRA, Data Act and Machinery Regulation obligations handled as one programme.
Is this the right starting point?
Worth being direct. There are situations in industrial IoT where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- Sensors are installed and nobody has verified the resolution supports the intended analysis.
- Cloud-designed models cannot run on the edge hardware actually deployed.
- Connectivity loss produces unpredictable behaviour nobody has specified.
- You ship connected industrial products and need a CRA position before December 2027.
- Model updates across a device fleet have no staged rollout or rollback path.
Do something else if
- Sampling rates are fixed too low and the sensors cannot be replaced.
- Timestamps record insertion time and there is no route to fix it at source.
- You want an AI safety function in a machine without engaging a notified body.
- The edge hardware cannot run anything and there is no budget to change it.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Our sensor data does not seem to predict anything. Why?
Check the sampling rate first. Vibration analysis needs kilohertz raw waveform data, and a great many installations record one averaged value per minute — which discards exactly the transients that carry the diagnostic signal. Averaging destroys information permanently and no model recovers it. Also check whether timestamps record when a value was measured or when it arrived in the database, because the second silently destroys any sequence analysis.
Should inference run at the edge or in the cloud?
Decide before choosing a model, because it determines architecture. Latency, bandwidth cost, connectivity reliability and data sensitivity push toward the edge; model size, retraining and monitoring push toward the cloud. At industrial scale bandwidth is usually decisive — high-resolution data from a few hundred sensors will saturate a plant network, so edge feature extraction with only features transmitted is commonly the workable design.
What should happen when connectivity drops?
Whatever you decided and tested, which is the point. Industrial connectivity fails routinely, so buffering, degradation, continuing on the last known model or stopping are all legitimate choices — and an unspecified choice means unpredictable behaviour at exactly the wrong moment. Specify it, test it deliberately during the field trial, and make sure the behaviour is simple enough that operators can predict it.
What does the Cyber Resilience Act require of us?
Vulnerability reporting obligations began on 11 September 2026, and the main cybersecurity requirements apply from 11 December 2027 with third-party assessment for high-risk products. The demanding part for industrial equipment is lifecycle vulnerability handling: products with fifteen-year service lives need security support across that period, which is considerably longer than most software support commitments assume.
How do we update models across a large device fleet?
With staged rollout, health checks and a tested rollback, treated as a deployment engineering problem rather than a model problem. Pushing a new model to a thousand devices has real failure modes — a model that behaves differently on a subset of hardware, a partial rollout that leaves the fleet inconsistent, an update that degrades performance in a way nobody catches for weeks. Build the rollback before you need it.
Related verticals
Organisations in industrial IoT usually share data, buyers or regulators with these. All fourteen are listed on the Manufacturing & Industrial page.
AI for Heavy Machinery and Equipment Makers
Fleet analytics, service prediction and warranty — with Machinery Regulation and Data Act obligations named.
Read more →AI for Process Manufacturing
Soft sensors, yield optimisation and batch analytics — inside the operating envelope, not against it.
Read more →AI for Discrete Manufacturing
Visual inspection, scheduling and quality root cause — with defect data treated as the real constraint.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.