IoT has been great at answering one class of questions recently and for now, it's been good at getting people to ask themselves this:
What is happening in the physical world?
Sensors, RFID equipment, cameras, Industrial Internet-of-Things can answer all sorts of queries: temperature, how hot machinery is, how machines are vibrating, where things are, if machines are moving, and so on.
The more difficult question is:
What should be done now?
And this is where AIoT comes into the picture.
AIoT, or Artificial Intelligence of Things, is a concept that suggests that connected, or observable systems should be married with machine learning, computer vision, analytics stacks, and various other AI fields, as opposed to IoT being a data gathering layer, and AI being a separate application running elsewhere.
A very simple view of an architecture would be something like:
Physical Environment
↓
Sensors / Cameras / RFID
↓
Edge Devices / Gateways
↓
Data Processing
↓
AI / ML Models
↓
Events / Predictions / Insights
↓
Applications and Human Actions
Where each layer performs specific duties.
Sensors and other devices gather data about the physical world.
Gateways can perform transformations / analysis closer to the source.
Databases, data platforms, message queues, and related systems transport or store that information.
AI and analytics engines analyze the data or find patterns in it.
Applications and user-facing systems then present those findings or predictions in a consumable form.
It's also at the edges, or between layers that some of the most interesting engineering happens.
Edge Computing
It's not always feasible to send every record collected by a sensor into a cloud system somewhere.
Especially with video where bandwidth is a prohibitive factor, and the processing power needed to extract meaning from the video stream is substantial.
Edge computing helps alleviate that by allowing some data processing closer to the source, reducing the bandwidth burden, and offloading some of the computing work.
For example, an edge device would receive video stream from a camera and process it with an object detection model running locally instead of sending all the video into the cloud.
The results of that model could be pushed upstream in a structured format with events, rather than having to process raw video:
{
"event": "restricted_area_entry",
"confidence": 0.94,
"timestamp": "2026-09-26T07:30:00Z"
}
Rather than the parent application receiving a video feed, it can receive structured events with predictions in them.
This can help reduce the amount of information that needs to be processed, or simplify the transformations needed if the video feed must be analyzed downstream.
The same approach can be applied in situations where upstream connections are unreliable, and data should stay as close to the source as possible for security or confidentiality reasons.
AIoT and ML
When one thinks of AIoT projects, it's easy to think of a typical supervised learning pipeline, like
collect sensor data → train model → deploy model
...but the reality is that there's a much larger engineering stack involved.
The reality is that a production system would include things like:
Device provisioning
Identity & authentication
Protocol parsing
Data normalization
Message queues
Time series databases
Edge computing and containers
Serving and model serving
Monitoring and alerts
API connections
Security
Observability
...and the model itself would be only a small part of that.
A high-recognition model would be completely useless if the data in the pipeline is noisy or contains measurement inaccuracies, the machine-learning inference pipeline is too slow, or the predicted result never gets delivered to the person who has to act on it.
Data Quality and ML
Quality of data is the most important aspect of any machine learning pipeline.
If a machine learning model receives erroneous readings from a vibration sensor that are inconsistent with actual measurements due to a calibration error, it would interpret those values as normal operating conditions even if they represent abnormal wear.
Likewise, inconsistent timestamps, missing or redundant data, or identifying tags that change from one system to another can lead to poor data quality issues that are challenging to identify after deployment.
This is why data engineering is such a crucial part of any AIoT project.
A pipeline that takes raw data, validates it, transforms it, extracts features, and feeds those features into a model can greatly benefit from such transformations:
Raw data
↓
Validation
↓
Normalization
↓
Feature extraction
↓
Model inference
↓
Decision or event
The exact implementation will vary according to the use case, but the point is that the quality of the model is not the sole factor in model performance.
An Example: predictive maintenance
Let's take a use case that many know about and that many have tried to implement already: predictive maintenance.
A system that monitors a machine with several temperature and vibration sensors can send out an alert once temperature reaches a certain threshold.
An AIoT application, however, would look at other factors besides simple temperature: vibration levels, load, operating hours, previous maintenance records, and whether the machine is currently actively producing.
The model can then estimate how likely it is that the current set of circumstances represents an anomalous situation similar to previous known causes of equipment failure.
That's not to say that AIoT magic can predict every equipment failure ahead of time, but usually the value proposition of such an AIoT system is to spot patterns worthy of human investigation earlier than a simple threshold-based approach is able to.
Computer Vision
AIoT is interesting in computer vision applications too, with the main architectural distinction being that computer vision pipelines will have a camera as an input.
A computer vision pipeline might contain objects like:
Camera
↓
Edge Inference
↓
Object detection
↓
Tracking
↓
Event logic
↓
Message broker or API
↓
Application
The application would then consume events generated as a result of processing video.
For example, the following event would be much more interesting to an application:
Person detected
+
Restricted zone
+
Duration > threshold
↓
Generate event
That way, instead of having to consume a video stream or analyze video files, an application can receive structured machine-learning events. Also, it might be worth designing systems where the output of the AI pipeline matches an action that the application has to make.
Security
Whenever there is a connection between physical equipment and a network, there are always security implications.
While having a compromised cloud application is one thing, having physical equipment that can be controlled or monitored by an unauthorized third party is an entirely different matter.
That said, AIoT systems need to pay special attention to device-level authorization, secure communications, encrypted data at rest and in transit, segmented networks, secure boot, firmware upgrades, logging infrastructure, auditing, and so on.
Physical systems will be increasingly exposed to the internet, and devices should be treated as end-points in a perimeter defense strategy, rather than as dumb terminals that only send data upwards.
AIoT and Physical AI
AIoT is closely related to the concept of Physical AI, which has also been gaining popularity in recent years.
The two concepts are not mutually exclusive: AIoT generally refers to a system of connected things, whereas Physical AI refers to AI systems that have perception and reasoning about, or the ability to effect change upon, a physical environment. Eventually, Physical AI systems might include a combination of computer vision, sensors, robotics, planning systems, digital twins, generative AI, or other elements.
Many groups, such as Aperture Venture Studio, are working on the space of AIoT and Physical AI applications for the industrial and physical worlds.
Events and Event-Driven Architectures
Event-driven architectures are something that I've written about elsewhere, but applying event-driven principles to AIoT platforms can yield interesting results.
Instead of having multiple applications having to consume raw sensor data, an application can instead consume data in the form of events produced by an AIoT data processing platform:
Sensor readings
↓
Feature extraction
↓
AI inference
↓
"Abnormal vibration detected"
↓
Event bus
↓
Maintenance application
In this approach, instead of having to process raw sensor data, a business application only has to deal with "vibration was abnormal", and potentially attach relevant data like the calculated probability to the event in order to make a decision about maintenance.
Designing Applications Around Events
Many applications in the physical world are built around making decisions based upon observations of the physical world.
As such, these applications work best when they can consume events that represent a state change that the application has to act upon.
A simple example is a manufacturing application that must shut down a machine if "overheating" is detected.
The decision "must shut down the machine" is not made by the machine itself, but rather the machine relays information to a supervisory application that then has to make a decision based on this information.
Observability in AIoT Systems
The critical element of AIoT systems, the one that is often the hardest to deliver on, is actually making sure that all the parts of the system function properly.
Making sure that the machine learning model works correctly is only half the equation: if the device stops functioning, there's no data anymore.
If the data pipelines break, models can ingest wrong data.
If models do not return a prediction quickly enough, no decisions can be made.
And if an application receives a signal from a machine learning model, but the operator does not see it, or receives too many unrelated signals, nothing can be done.
That is why production-grade AIoT systems require observability across all components. It's not enough to know if the machine learning model is working correctly. The system needs to know that the device is transmitting data, the data pipelines are correctly processing records, the model has a reasonable inference latency, and that the final events or actions taken are actually useful.
Final thoughts: Systems vs Trends
AIoT systems tend to be interesting systems engineering problems first and foremost.
Many successful projects, or at least the ones that are truly production-grade, combine solid physical systems, strong data engineering fundamentals, judicious use of machine learning, secure connectivity, and purpose-built applications that are engineered to help make decisions based on the physical world.
It will be fascinating to watch how the entire ecosystem evolves around edge AI / edge computing. Edge devices will become more sophisticated. Models will become smaller. Sensors will become more interesting and complex. And Physical AI will bring in new capabilities in perception and control.
But at the end of the day, the critical element of turning these developments into production-ready systems will be the question of whether an AIoT system can make the right decisions based upon physical observations.
Top comments (0)