AIoT is shorthand for the combination of artificial intelligence and the Internet of Things. The term covers a wide range of systems, from a thermostat that learns a household schedule to a factory that predicts bearing failures from vibration data, but the underlying idea is consistent: connected devices produce data, and a learned model turns that data into decisions, either on the device itself or somewhere upstream.
The reason the pairing matters is that the two technologies cover each other’s weaknesses. A classic IoT deployment is good at collecting telemetry and bad at interpreting it; dashboards fill up with numbers nobody reads. Machine learning is good at finding patterns but needs a steady supply of real-world data, which is exactly what sensors provide. Put together, you get systems that can notice, classify and act without a person watching every stream.
This guide gives a working definition, explains where the intelligence can live, lists the patterns that show up most often in practice and, just as important, describes the cases where adding AI to a connected product is a mistake.
A working definition
An AIoT system has three ingredients. First, there are things with sensors and often actuators: a motor, a camera, a door lock, a soil probe. Second, there is connectivity that moves data from those things toward wherever it will be processed, and moves commands back. Third, there is a model that was trained on data rather than hand-written as fixed rules, and that performs inference on new data to produce an output: a class label, a score, a bounding box, a predicted value or a recommended action.
The third ingredient is what separates AIoT from ordinary IoT. A rule engine that sends an alert when temperature exceeds a threshold is automation, not AI. A model that learns what “normal” looks like for a particular compressor and flags deviations is AI, because the decision boundary came from data instead of from an engineer typing a number.
What changes when you add a model
Adding a learned model to a connected product changes the engineering problem in ways that are easy to underestimate.
The data pipeline becomes a training pipeline as well as an operational one. You need labeled or at least representative data before deployment, which means a collection phase that may take weeks on real equipment. Model training usually happens in the cloud or on a workstation, while inference happens wherever the decision is needed.
Behavior becomes probabilistic. A rule either fires or it does not; a classifier has a confidence, a false positive rate and a false negative rate. Product decisions have to account for that, for example by asking for confirmation when confidence is low rather than acting immediately.
The system can degrade silently. Sensors drift, machines are serviced, seasons change, and a model trained on last year’s data may slowly become wrong. This is called model drift, and catching it requires monitoring that most IoT platforms do not provide by default. The practices for retraining, versioning and redeploying models are collectively called MLOps, and they add a lifecycle on top of the existing device lifecycle.
Where the intelligence runs
The single most important architectural choice in an AIoT system is where inference happens. There are three broad options, and most real deployments mix them.
In the cloud
Devices stream raw or lightly processed data to a backend, and models run there. This is the simplest option to build and the easiest to update, since the model lives in one place. It is a good fit when decisions are not time-critical, when the model is large, or when the valuable insight comes from comparing many devices against each other. The costs are bandwidth, latency, cloud compute and a dependence on connectivity.
At the edge
Inference runs on a gateway or a local server close to the devices, which is the subject of the edge AI guide. This keeps raw data on site, which matters for video and for privacy-sensitive deployments, and it keeps working when the internet link drops. The trade-off is a fleet of machines to manage and models that must be small enough to run on them.
On the device
The model runs on the microcontroller or system on chip inside the thing itself. This is the domain of TinyML and of chips with a built-in neural processing unit. On-device inference gives the lowest latency and the best privacy, and it allows battery-powered devices to decide locally what is worth transmitting. The models involved are tiny, often compressed with quantization to fit in a few hundred kilobytes or less.
A useful rule of thumb: push inference as close to the sensor as the model size and the update strategy allow, and send upstream only what the upstream actually needs. The edge vs cloud vs fog guide covers the general version of this decision.
Patterns that come up again and again
A handful of AIoT patterns account for most deployments.
Anomaly detection learns a baseline for a signal and flags departures. It is popular because it does not require examples of failures, which are rare by definition. It underpins most condition monitoring products.
Predictive maintenance goes one step further and tries to estimate when a component will fail, using vibration, current, temperature or acoustic signatures. The predictive maintenance guide explains the signals and the models.
Computer vision turns cameras into sensors that count people, read gauges, inspect parts or detect intrusions. Running it locally avoids streaming video to the cloud, as described in the on-device vision guide.
Keyword spotting and other audio tasks let a device listen continuously at very low power and wake a larger system only when something relevant is heard.
Sensor fusion combines several modalities, for example an accelerometer and a microphone, to classify activity or machine state more reliably than either alone.
The newest pattern is the AI agent: a large language model that reads device state, reasons about a goal and calls device functions as tools. Agents are covered in the smart home and factory guides.
When AIoT is worth it, and when it is not
AI earns its place when the decision depends on patterns that are hard to write down as rules, when the volume of data is too large for people to review, or when the value lies in reacting quickly on site. A model that detects a failing pump a week before it seizes pays for itself the first time it is right.
It is not worth it when a threshold would do. Many “AI-powered” products are rule engines with a marketing label, and the honest version is cheaper and easier to debug. It is also risky when you cannot collect representative training data, when the cost of a wrong decision is high and there is no human in the loop, or when the team has no plan for monitoring and retraining after launch. A model that is never updated is a liability waiting for the world to change.
A sensible path is to start with plain telemetry and rules, instrument well enough to collect good data, and introduce models where the rules visibly fall short. The data pipeline guide describes the plumbing that has to exist before any of this works.
Where to go next
- Edge AI explained looks at running inference on gateways and local hardware.
- TinyML explained covers models that fit on microcontrollers.
- How IoT works: from sensor to cloud and back is the plain IoT foundation that AIoT builds on.
- Edge computing explained explains the infrastructure side of local processing.
Topics: AIoT, machine learning, edge AI, fundamentals