AIoT: AI and IoT Integration
Turning sensor streams into decisions — running analytics on the device where bandwidth or latency demands it, and solving the problem every IoT project hits, which is that nobody labelled the failures.
IoT projects collect data for years and then discover the hard part: the sensors recorded everything except which readings preceded a failure. Without labelled events, the interesting models cannot be trained, and the honest first step is often to instrument the labelling rather than the sensing.
AIoT applies machine learning to data from connected devices and sensors — detecting anomalies, predicting failures, optimising operation and triggering action — with inference running on the device, at a gateway, or centrally, depending on bandwidth, latency and power constraints.
The labelling problem, which decides the project
Anomaly detection needs no labels and tells you something is unusual. Predicting a specific failure needs examples of that failure, and most organisations have far fewer than they think:
- Maintenance records rarely align with sensor data. A work order dated the day after a failure does not tell you when degradation began.
- Failures are rare by design. Well-maintained equipment produces very few positive examples, which is good operationally and difficult statistically.
- Interventions hide the signal. Equipment repaired before failing never produces the failure the model was meant to learn.
- Categories are inconsistent. The same fault recorded three ways by three engineers.
Start by instrumenting the labelling, not the sensing
Where labelled events do not exist, the fastest route to a useful model is often a simple process for maintenance staff to record what happened and when, tied to the sensor timeline. That is unglamorous, cheap, and it is what makes the model possible eighteen months from now. We will recommend it even though it delays the interesting work.
Where the inference should run
| Placement | Suits | Constraint |
|---|---|---|
| On the sensor or device | Very low latency, no connectivity, battery power | Severe compute and memory limits |
| At a gateway on site | Several devices, moderate compute, local action | Needs site infrastructure |
| Centrally in the cloud | Fleet-wide patterns, heavy models, easy updates | Bandwidth cost and connectivity dependence |
| Split across tiers | Detection at the edge, analysis centrally | The common answer in practice |
The split pattern is usually right: cheap detection on the device decides what is worth transmitting, and the expensive analysis happens centrally on the small fraction that matters. Streaming everything centrally is what makes IoT programmes financially unsustainable.
How we build it
Start with anomaly detection, which needs no labels
It delivers value early and, critically, it generates the labelled examples that make specific failure prediction possible later. Anomalies flagged and then confirmed or dismissed by engineers become exactly the training data that was missing.
Handle sensor reality
Calibration drift, replacement sensors with different characteristics, gaps, clock skew and units that changed when someone swapped a supplier. Sensor data is far messier than its tidy schema suggests, and this is where most of the data engineering effort goes. See streaming data engineering.
Model per fleet, not per device — usually
One model across similar devices generalises better and is far easier to operate than thousands of individual models. Per-device calibration on top handles genuine variation, and the choice is made on evidence rather than convenience.
Monitor drift across the fleet, not the unit
Devices age, environments change and firmware updates alter signal characteristics. Fleet-level distribution monitoring catches this; nobody is watching any individual device. See model monitoring.
Make alerts lead to a defined action
Threshold, owner, response and escalation. IoT programmes generate impressive alert volumes and change nothing, because nobody agreed what happens when one fires. That agreement is part of the build.
Plan model updates across the fleet
Staged rollout, version tracking, health checks and rollback — on devices nobody can physically reach. See edge AI deployment.
How the engagement runs
Whether usable labels exist is established first, because it determines what can be built at all.
Data and label assessment
Sensor coverage and quality; whether labelled events exist, and instrumentation designed where they do not.
Placement and architecture
Where inference runs decided against bandwidth, latency, power and cost; the split tier designed.
Build
Anomaly detection first, then failure prediction where labels support it; deployed to the chosen tier.
Alerting and action
Thresholds calibrated against real volume; owners, responses and escalation agreed and wired in.
Fleet operations and handover
Drift monitoring, staged update mechanism and runbook handed over.
What you receive
Working detection on sensor data, with the labelling problem addressed rather than ignored.
Data and label assessment
What the sensor data supports, and a labelling process where events are unrecorded.
Inference architecture
Where each model runs, justified against bandwidth, latency, power and cost.
Anomaly detection
Delivering value without labels, and generating the labels for later prediction.
Failure prediction
Where labelled events support it, evaluated by failure type rather than in aggregate.
Alerting with defined action
Thresholds calibrated, owners named, responses and escalation agreed.
Fleet operations
Drift monitoring at fleet level, staged model updates with rollback.
Is this the right engagement?
Worth being direct. AIoT: AI and IoT Integration is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Sensor data is collected and nothing acts on it.
- Unplanned downtime is expensive and maintenance runs on a calendar.
- Bandwidth or connectivity makes streaming everything centrally impractical.
- A device fleet needs models updated remotely.
- Anomalies are noticed by people rather than by systems.
Choose something else if
- Sensor coverage does not capture the phenomenon you care about.
- The requirement is the data infrastructure. See streaming data engineering.
- No maintenance or operations expertise is available to interpret findings.
- Nobody will act on alerts, which makes the whole thing a dashboard.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
We have years of sensor data. Can you predict failures?
Possibly, and the determining factor is not the volume of sensor data but whether you have labelled failure events aligned to it. Maintenance records rarely line up with the sensor timeline, and well-maintained equipment produces very few failures to learn from. The assessment establishes this in the first three weeks.
What if we have no labelled failures?
Start with anomaly detection, which needs none and delivers value immediately — and which generates labels as engineers confirm or dismiss what it flags. In parallel we usually recommend instrumenting the labelling process itself, which is unglamorous and is what makes failure prediction possible later.
Should the model run on the device or in the cloud?
Usually both. Cheap detection on the device decides what is worth transmitting; expensive analysis runs centrally on the small fraction that matters. Streaming everything to the cloud is what makes IoT programmes financially unsustainable at fleet scale.
How do you handle sensors being replaced or recalibrated?
By treating it as expected rather than exceptional. Replacement sensors have different characteristics, calibration drifts, and firmware updates change signal behaviour — so fleet-level distribution monitoring catches the shift, and the pipeline handles gaps, clock skew and unit changes explicitly.
Will this generate a lot of alerts?
Not if it is done properly, and alert fatigue is the main failure mode. Thresholds are calibrated against real volume during the build, and every alert type gets a named owner, a defined response and an escalation path — because an alert nobody acts on is worse than no alert at all.
Often paired with this
Most clients combine two or three engagements from the Emerging and Frontier AI pillar. These are the ones that most often run immediately before or after.
Digital Twins and Simulation
Twins scoped to a specific decision, validated against reality, at the fidelity the question actually requires.
Read more →Physical AI and Robotics Integration
Perception and decision-making added to existing robotics, with safety kept out of the learned path.
Read more →Autonomous Systems and Drones
Inspection and survey autonomy with the regulatory route established before anything is built.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.