AIoT is artificial intelligence of things, an expression for connected devices, sensors, and models.
The hard part is connecting them in a production environment, not a controlled lab.
It involves unreliable things, non-deterministic events, delayed or noisy data, and variable network connections.
All of which have an impact on how such a system should be architected.
Start With the Physical Problem
A common pitfall is to jump to the AI, asking "where can we use machine learning?"
Ask instead "what physical or operational decision are we trying to improve?"
Examples might be:
Critical assets are hard to accurately locate.
Inventory information becomes out-of-date between inspection intervals.
Equipment behavior changes prior to failure.
Personnel are not aware of potentially unsafe conditions in real-time.
Operational staff spend too much time manually interpreting physical-world events.
Once the problem is understood, the technology can be selected.
Depending on the use-case, technologies such as RFID, BLE, visual, environmental, GPS, or industrial equipment sensors, telemetry, or other data sources may be needed.
Once the physical problem is understood, AI can be considered for where it has value in the resulting decision-support process.
The AIoT Stack is More Than Sensors + ML
An AIoT system can be viewed as a stack of connected elements:
Physical Environment
↓
Sensors / Devices
↓
Connectivity
↓
Ingestion
↓
Storage + Processing
↓
AI
↓
Application
↓
Operational Decision
Each layer represents engineering challenges.
While a sensor might produce great results, someone has to receive them.
The connectivity layer has to deal with intermittent connections and device limitations.
The ingestion pipeline has to manage missing, duplicated, or delayed data.
The AI layer has to operate reliably in order to create value.
The application has to effectively support a person performing a specific task.
Which is why an AIoT product that boasts high model accuracy is not necessarily valuable if that model is not fed good data, and its output is not used effectively.
Data Quality is a Physical Problem
In traditional software, data is often controlled by the developers.
In AIoT, data originates in the physical world.
A sensor can drift, a gateway can be unplugged, a location can be imprecise, and a device can send the same event multiple times.
Take a simple example of tracking inventory movement:
Asset A
Zone 1
Zone 2
Zone 1
Which could be indicative of movement between zones, or possibly imprecise zone detection.
So while a machine learning model might be valuable, such a system has to handle validation, contextual information, timestamps, device metadata, and the possibility of uncertainty before it can make a meaningful impact on the operational domain.
For event-based systems, there are additional engineering concerns:
Can out-of-order events be handled safely?
Will duplicates be removed?
How are gaps in the stream represented?
Can bad sensor readings be automatically flagged?
How long is an event valid for?
Can the source of an event be identified?
In some situations, addressing these concerns can produce more value than chasing higher model performance.
Edge vs. Cloud is an Architectural Decision
Another consideration is where processing should occur: in the cloud or at the edge.
The cloud provides central management and massive processing power, but there are reasons to distribute processing closer to the source, such as reducing latency, conserving bandwidth, or maintaining functionality in the face of disconnection.
A possible architecture would be:
Sensor
↓
Edge Device
↓
Filtering / Inference
↓
Cloud
↓
Analytics
Where the edge is not a replacement, but a collaboration point with the cloud.
Each can handle different responsibilities, such as:
The edge handles time-sensitive filtering.
The cloud manages long-term analytics.
The edge runs lightweight inference, while the cloud stores and trains models.
The selection of an architecture is dependent on many factors, including latency, cost, privacy, compute availability, and the impact of decision-making delay.
Build for Failure
A lab environment can assume that everything works.
A production system has to include failure scenarios.
When building an industrial AIoT system, it is useful to explicitly consider:
What happens when a sensor goes offline?
What happens when data arrives late?
What happens when a device returns an impossible value?
What happens when an AI model is uncertain?
What happens when the network is disconnected?
What happens when two sensors disagree?
The last few items are not "edge cases" in the physical world, but commonplace realities.
This is where observability is critical.
A production system must make it possible to distinguish between a faulty device, a connectivity problem, an ingestion issue, processing problems, model uncertainty, and application logic errors.
Without such visibility, debugging an AIoT system can be significantly more challenging than traditional software.
As a result, graceful degradation is often as important as building a system that functions correctly under ideal conditions.
AI Should Support Decisions, Not Just Make Predictions
A prediction is only useful in the context of an action.
An example is an unusual pattern being detected by an AI system. A simple display of this information might look like:
Anomaly detected: 87% confidence
This might not be very helpful to a person trying to interpret it.
A more useful example would provide additional context about the situation:
Asset: Pump-17
Condition: Abnormal vibration
Confidence: 87%
Historical context: Similar patterns occurred around maintenance events
Suggested action: Schedule inspection for next maintenance window
Making decisions based on AI can be as simple as providing this additional context and presenting it to the correct person for review.
The key is to recognize that a prediction should be informative, not prescriptive.
This is also why confidence levels should be included with predictions: a high level of confidence can be treated differently than a low level.
Operational personnel need enough context to effectively interpret a prediction and take action.
Think in Systems, Not Components
This is the biggest difference between prototyping and production: the product is not defined by its components, but by its ability to make a change in the world.
The component parts (sensor, model, or dashboard) are merely enablers for a more significant change.
That requires developers to think in terms of a system that incorporates:
Hardware
Connectivity
Data engineering
AI
Edge and cloud infrastructure
Applications
Reliability engineering
Monitoring
Human workflows
This approach is even more important when considering deployments at scale.
A system that works in one location might need substantial re-engineering to support additional facilities with different devices, data characteristics, network infrastructure, and human workflows.
The challenge is to achieve functional and reliable scale, not just computational scale.
Where AIoT Gets Interesting
The most interesting applications of AIoT are typically found at the intersection of software intelligence and physical constraints.
Businesses are actively pursuing problems related to visibility, industrial operations, safety, and other areas where physical-world information can be leveraged by people.
A venture-building approach to AIoT has the opportunity to identify recurring problems and determine if connected data and AI can produce a better solution. Aperture Venture Studio
A Practical Pre-Deployment Checklist
Before deployment, an AIoT system should consider the following:
What physical problem are we trying to solve?
Where is the data coming from?
How reliable is this data?
How are duplicates and out-of-order events handled?
What happens when devices disconnect?
Which processing is ideal for the edge?
What workloads belong in the cloud?
How are uncertain predictions managed?
How are device, pipeline, and model failures monitored?
What action should occur after receiving an AI-generated insight?
Can this architecture support additional deployments?
These questions ensure that the focus is not on creating an impressive prototype, but on building a dependable system.
The Engineering Challenge is the Integration
AI is providing new ways to recognize patterns, make predictions, and support decisions.
IoT is allowing access to the physical world.
The hard part is in the integration: connecting both to create a reliable and effective system.
That is why building AIoT is more than attaching a machine learning model to an IoT platform: it is about designing the whole system around a real-world problem, the reliability of the data, and the decisions the system is expected to enable.
For developers interested in building AIoT products, asking "where can we introduce AI" is not as valuable a question as "which physical-world decision could be massively improved if we had reliable real-time data and useful intelligence".
Top comments (0)