The Internet of Things was the concept that could enable devices without built-in intelligence to share and transmit data with external software systems. Artificial intelligence was the field that could extract insights and inferences from massive amounts of data.
AIoT — Artificial Intelligence of Things — combines these two approaches together.
But for developers, implementing AIoT is not a small tweak of connecting some sensors to a neural network. An end product could feature hardware, connectivity, data ingestion, storage, stream processing, machine learning, APIs, dashboards, security and physical automation layers.
In other words, there is a fascinating engineering question: how should one approach the development of an application that can transform physical world observations into actionable insights?
A (Very) Simplified Architecture
A naive AIoT architecture could be represented as a series of transformation steps:
Physical Environment
↓
Sensors / Devices
↓
Connectivity
↓
Data Ingestion
↓
Storage + Stream Processing
↓
AI / ML Models
↓
Applications / APIs
↓
Human or Automated Actions
Each layer adds complexity and engineering challenges. A single temperature sensor, for example, might provide a simple time series of values.
Those values, however, would rarely be immediately useful for analysis. Once thousands of data points have been aggregated, statistical properties or summary data could be generated.
It is likely that this information will be combined with values from other sensors (vibration, status, number of hours in use), or contextual metadata (equipment type, time, maintenance records), to generate new insight or transform the data into a usable format for models.
As another example, AI/ML layers might ingest a list of recent sensor readings and attempt to classify, predict, or find anomalies.
The Model Is Not Everything
When designing an AIoT application, it can be tempting to focus exclusively on the ML components.
The reality, however, is that the data pipeline defines the quality of insights an ML model can generate.
There is a long list of potential issues with physical world observations:
Noisy measurements
Device or sensor failure
Drifting or incorrect timestamps
Missing or erroneous values
Duplicates
Incompatible units
Other device issues
Secure and auditable data transmission
Data retention requirements
To give a single example, if a given machine reports a temperature of 82, it is challenging to say what this means without additional context.
Was this in Celsius or Fahrenheit? What is the expected operating temperature for this machine? What kind of machine is this? What was the temperature five minutes ago? Has this machine historically operated at this temperature?
AIoT applications need to retain enough context with a given measurement to be useful for analysis.
Should Processing Be Local or Remote?
Another design consideration is the choice between a cloud versus an edge architecture. Some AIoT applications can directly transmit data to cloud infrastructure for processing.
Other applications might require lower-latency operations, or have limited bandwidth or connection stability.
Cloud processing could leverage large-scale cloud infrastructure to perform transformations and machine learning model inferences.
Some possible advantages of this approach include:
Scalability
Centralized processing and storage
Potentially simpler architecture
Ability to perform cross-device analytics
This approach is best for applications with less strict latency or connectivity constraints.
Edge processing refers to any application where computations take place closer to the source of data.
This might help reduce latency, reduce bandwidth, or allow certain applications to function even when disconnected from the network.
In some applications, latency is so crucial that transmitting an image to a remote server for analysis would be too slow or consume too much data.
An edge computer could analyze a vision workload and only transmit relevant or anomalous findings to a central server.
In many cases, the solution is not an exclusive choice between edge or cloud: an application can leverage a hybrid architecture.
Designing APIs
Once physical observations have been transformed into useful insights, developers might want to design an API for other applications to consume.
An API might provide an interface such as:
{
"device_id": "machine-104",
"timestamp": "2026-09-18T16:20:00Z",
"temperature": 78.4,
"vibration": 0.82,
"status": "operational"
}
An application or service consuming this data could leverage this information to update users, calculate additional values, or even perform transformations on the data (such as an ML model).
For more sophisticated applications, event-driven architectures can be helpful.
Rather than having an application constantly poll devices for updates, events can be sent once certain conditions have been met.
A sample list of events might include:
device.connected
sensor.updated
temperature.threshold_exceeded
anomaly.detected
maintenance.required
This can create a more responsive and efficient application architecture.
When To Use Machine Learning
AI is not always a necessary component of data analysis.
A simple approach to analyzing data is to define a set of rules:
IF temperature > threshold THEN generate alert
This can be a helpful baseline for many applications.
Machine learning can become relevant when the relationship between variables is more complex:
temperature
- vibration
- operating hours
- historical failures
- load ↓ ML model ↓ failure-risk estimate This example suggests that a combination of features could be used to predict whether a machine will fail soon. Depending on the use case, ML techniques can supplement or replace conventional analytics techniques. Some example applications for AI in AIoT applications include: Anomaly detection, predictive maintenance, demand forecasting, asset classification, computer vision, route optimization, and energy optimization The question of when to apply ML depends on a use case and the data available to an application. ## Physical Devices Need Management Too One consideration unique to AIoT applications is that physical devices need to be managed. A given organization might have hundreds or thousands of physical devices deployed in a production environment. This means that developers need to think about questions like: How are devices initialized? How do applications authenticate to these devices or sensors? How are software updates distributed? How are certificates managed? How can applications determine if a given device is functioning properly? How do applications handle network failures and outages? How do applications respond if hardware fails? How are versions of software managed? A high-quality model might not compensate for an application that lacks a strong infrastructure layer. ## Security Takes On A New Meaning Security considerations also change from a conventional software application to AIoT. If an IoT device or sensor were to be hacked, it could potentially provide an attacker access to an organization's private network or data. Depending on the domain, such an event could also disrupt or endanger physical processes. Security must therefore be considered throughout the architecture: Device ↓ Network ↓ Gateway ↓ Cloud / Server ↓ API ↓ Application At each stage, appropriate measures might include authentication, encryption, access control, network segmentation, firmware signing, logging, and monitoring. The specific security controls would be defined based on the threat model for a given application. ## The Operational Question First One of the most common mistakes developers make with AIoT applications is to focus on the AI/ML layer before defining the actual problem. A better workflow is to reverse this process. A possible outline could be:
- Determine the operational insight that is needed;
- Determine what information is currently missing to generate this insight;
- Determine what physical signals can help generate these insights;
- Define the data pipeline;
- Create a baseline definition of these insights (rules or conventional analytics);
- Determine whether machine learning techniques add value;
- Create a prototype, test it in a real environment, and measure its impact;
- Only then develop this into a fully production-quality system;
- Always measure the operational insight of this system. This process ensures that AI is added only when relevant. This avoids the risk of an otherwise conventional software application getting bloated with ML components. For organizations considering this space at a venture scale, Aperture Venture Studio has a philosophy of looking at industrial problems and building AIoT applications around them: https://apertureventurestudio.com/about-us/ ## Measuring Impact Finally, an AIoT application's impact should always be measured using operational rather than technical metrics. Model accuracy may be important, but it is only one consideration in an application. Other possible metrics could include: Less unplanned downtime, Higher utilization of assets, Fewer inventory issues, Faster detection of incidents, Lower energy consumption, Less required manual data entry, Or other relevant operational metric Applications that generate sophisticated ML insights but have little impact on operations are unlikely to be viable long-term. ## The Engineering Challenge Ahead AIoT brings together software engineering, data science, ML engineering, embedded systems engineering, networking engineering, and operations engineering. This combination creates complexity, but it also creates an interesting space for engineers and developers to work within. The most valuable AIoT applications will be those that best balance between the different components of the stack. Applications will collect meaningful and reliable signals from the physical world. Infrastructure will help distribute and manage these insights. Data scientists will transform these into useful information. ML engineers will extract patterns and insights that traditional applications miss. Developers will build applications that help operations staff make better decisions. AIoT is not about making devices intelligent. Instead, it is about about building a system that can make decisions about the world consistently and reliably. The goal is not intelligence. The goal is reliability.
Top comments (0)