The Role of Artificial Intelligence in IoT App Development

Get in touch:

Thinking through a new idea or stuck with a challenge? Drop us a message—we'll listen, brainstorm, and help move things forward.

Where AI Enters an IoT Product

AI-powered IoT, sometimes called AIoT, is the use of machine-learning models to interpret sensor data from connected devices, either on the device itself or in the systems behind it. The phrase is applied to three distinct engineering problems, each carrying a different cost structure. A team's first productive step is to separate them. In the stalled builds we have been asked to look at, one had been resourced properly and the other two quietly assumed to belong to somebody else.

On the device. Edge AI is inference that runs on the device itself rather than in the cloud. The model executes within the product's own microcontroller or SoC. It might classify vibration signatures, detect an unusual current draw, spot keywords through a microphone, or filter camera frames before data exits the enclosure. With memory counted in kilobytes and power in milliwatts, the model must be quantised to fit. In return, latency, bandwidth, and privacy improve because only meaningful information leaves the device.

In the gateway or on-premise. Here, a local machine such as a plant server, edge gateway, or store controller runs the model and observes multiple devices simultaneously. The tier supplies a cross-device perspective unavailable to an individual sensor, retains information within the building, and continues through a WAN outage.

In the cloud. Training, fleet-level pattern discovery, and workloads needing extensive history or substantial compute belong here. The user-facing application generally resides here too, encompassing the dashboard, alert queue, mobile app, and work-order integration.

Illustrative ranges drawn from our builds and widely used hardware, rather than survey evidence.

Within IoT app development, "app" means the cloud layer, the operator interface, and the connective plumbing spanning all three tiers. That plumbing consumes the schedule. Purchase a model API but omit the application layer, and the result is a demonstration no operations team will adopt.

Our take: one pattern has repeated across the handful of stalled IoT builds we were asked to recover over the last three years — a handful of engagements, not a dataset. The model works. What is missing is a dependable route from its output to a decision someone owns. Early scopes particularly neglect the gateway tier because neither the firmware team nor the cloud team owns it. The actual product consists of thresholds, override, audit trail, and escalation; the model is only one component.

How Big the Gap Between Hype and Installed Base Really Is

Published in January 2026 and publicly summarised that February, IoT Analytics' 124-page State of Enterprise IoT 2026 values the 2025 enterprise IoT market at $324 billion and counts 21.1 billion connected devices at the end of 2025. Each increased 13% year over year. Enterprise connections, rather than consumer ones, account for 45% of the total, and the firm's 2026 projection is 14% growth.

One figure deep in the report ought to guide the roadmap: by December 2025, a true edge AI component existed in less than 1% of those 21.1 billion connections. Knud Lasse Lueth, CEO of IoT Analytics, rounds that up to the nearest whole point. For planning, his wording is the part that matters: "1% of IoT devices today have a true edge AI component, but that share is increasing fast."

That figure supports two valid interpretations, and they point in opposite directions.

The optimistic interpretation begins with silicon already entering the market. In its published summary of the 2Q 2026 market update, ABI Research forecasts edge AI chipset revenue growing from $34.4 billion in 2026 to $96 billion by 2031. During the same period, unit shipments rise from 711.3 million to 1.59 billion, equal to a 17% compound annual growth rate. By 2031, manufacturing is expected to lead vertical revenue at $24.9 billion, followed by smart home at $18.4 billion and automotive at $14.6 billion. Neural accelerators are now being added to components that previously lacked them, eroding the hardware limitation that kept on-device inference impractical for a decade.

The more cautious interpretation distinguishes inference-capable silicon from products that actually employ it. What sits between the 1% and the chipset forecast is software that mostly has not been written yet. Model pipelines. Over-the-air update routes for models as well as firmware. Drift monitoring. And the application logic that decides what happens when a model fires.

Today, this divide represents the commercial opening in IoT app development. The opportunity lies in software, not hardware.

Four Use Cases With a Defensible Business Case

Not every AI feature in an IoT product earns back its build cost. Four categories consistently do. Their common feature is an existing manual or rules-driven process whose cost can be measured, allowing improvement to translate directly into money.

1. Anomaly detection and condition monitoring

This category delivers the greatest value while receiving the least recognition. It is intentionally more limited than "predictive maintenance." Anomaly detection asks a manageable question: does this reading differ from what this asset normally produces? Prediction asks a much harder one: when will it fail? The difference matters. No failure history is required for anomaly detection, whereas most assets have not failed frequently enough to support training a failure model.

The Industrial AI Readiness Report 2026 found 64% of industrial respondents using or planning AI for predictive maintenance and 55% for process optimisation. 53% expected reduced downtime and 52% expected improved OEE. Ambition is widespread; execution is what separates teams. In our own engagements, the ones that deliver have almost always started with anomaly detection and grown into prediction, rather than the other way round.

2. Computer vision at the edge

Visual inspection, occupancy and counting, safety-zone monitoring, defect classification, and reading licence plates or labels. For vision, on-device inference comes closest to being mandatory. Continuous cloud video is costly, commonly exceeds what the available connection can carry, and is often banned outright by site privacy rules. Running the model on the camera and sending events alone addresses both the bandwidth expense and the privacy issue at once.

3. Security and threat detection on the device fleet

Connected-device AI adoption is most advanced here, although the survey evidence reveals its boundaries alongside its appeal. Takepoint Research conducted the State of AI in OT Cybersecurity 2026, with sponsorship from Nozomi Networks and BlastWave. Threat detection and alerting led reported AI functions at about 34%, followed by network monitoring and anomaly detection at 32%, SOC augmentation at 25%, then incident response and triage at 22%. Every figure from this survey carries a caveat: its public summary gives one-decimal precision without revealing a sample size. The rounded values here should therefore be treated as directional.

As with fraud detection, human operators cannot handle a fleet of this scale and noise. Alert volume creates a quantifiable cost, while the alternative is a rules engine with an already established false-positive rate.

4. Natural-language operations layers

This is both the newest category and the one most readily over-scoped. Placed across telemetry, maintenance records, and manuals, a language model allows a technician to ask "what changed on line 3 last night" rather than piece the response together from four systems. It succeeds when retrieval grounds it in your own data and its access remains read-only. We hold that connecting one to actuate equipment is today's least defensible application of the technology — a position, not a finding. Failure has physical consequences, yet the model cannot indicate when it is guessing.

Deciding Where the Model Runs

This choice establishes the bill of materials, cloud expenditure, latency limits, and regulatory exposure. It is taken early, generally once, and reversing it costs heavily. Four constraints determine the answer and merit consideration in the following sequence.

Latency. Any decision required sooner than a network round trip must occur on-device: a safety interlock, machine stop, valve closure, or frame-rate-bound vision task. No later consideration can overrule this requirement.

Bandwidth and connectivity cost. Sample one axis at 10 kHz and 16 bits without stopping, and a vibration sensor generates roughly 1.7 GB of raw signal a day. That is more than most cellular IoT plans carry in a month. Financial viability often requires on-device feature extraction followed by transmission of those features, or transmission only after detecting an anomaly. Consequently, AI placement and connectivity must be selected together, not sequentially.

Data residency and privacy. Where raw information includes footage of people, patient telemetry, or material that site security policy prevents from leaving the premises, local model execution is required irrespective of cheaper alternatives. In our experience this is the constraint clients are least willing to negotiate, and the one most often discovered late.

Model size and update cadence. The cloud suits large models retrained often; the device suits small and stable ones. A model requiring weekly retraining from fleet-wide information cannot remain solely on a microcontroller lacking an update route. And if you are building an over-the-air model update path anyway, you have already built most of the hard part of an edge deployment.

The final column is asymmetric. An error in latency or residency makes the design invalid. A bandwidth mistake can be survived, yet its cost multiplies with every shipped device. It therefore tends to surface only when the pilot turns into a rollout: twenty devices hide a cost structure that three thousand devices expose.

In practice, most systems divide responsibilities among all three tiers. Thus the productive design question is not "edge or cloud"; it is which tier should own each decision and how each tier behaves when connectivity fails. A system that degrades gracefully offline is a different, and better, product than one that goes dark.

Why These Projects Stall

Your project's pitch deck likely claims that three-quarters of IoT projects fail. The source is a Cisco survey released in May 2017, which actually reported that 60% of initiatives stopped at proof-of-concept while 26% received a complete-success rating. That nine-year-old result concerns pilots failing to scale, not project failure. Our article on IoT apps for supply chain optimization dissects the statistic; here, the essential point is that it cannot serve as a current failure rate.

Current evidence about what actually halts these projects is more valuable, and for AI-enabled IoT it indicates a specific cause. For the Industrial AI Readiness Report 2026, IIoT World surveyed 272 industrial professionals during 2025 and HiveMQ compiled the report. It found that data quality and availability were identified as the leading challenge by 54%, outranking compute, algorithms, and budget. Legacy integration and data silos were cited by 48%, while 43% selected trust, explainability, and transparency. Production systems already streaming real-time data existed for only 34%; AI was embedded in most core processes for merely 7% today, although 44% anticipated that position within three years.

Together, these findings form a consistent picture, but not one of models failing. They describe organisations unable to move clean, timestamped, contextualised information dependably from equipment to somewhere usable by a model. This is a data-engineering problem, matching the conclusion we reached through another route in data engineering versus data science.

Because this survey supports much of the argument, one caveat deserves emphasis. HiveMQ both compiled the report and sells MQTT data infrastructure, aligning its commercial interest precisely with the report's conclusion. We cite it because it is the newest industrial dataset we found for this question and its result accords with our engagements, not because a sponsored survey settles anything on its own.

Another, less obvious failure mode should be stated because vendors are unlikely to raise it: sometimes the prediction cannot be bought at any price. McKinsey advanced this case for the chemicals industry in December 2019 through Predictive maintenance: the wrong solution to the right problem in chemicals, and the reasoning extends well beyond that sector. A few major events usually account for most unplanned downtime, leaving insufficient data points from which a model can learn. Even a model with predictive ability often provides a horizon too brief for action. Across that industry, losses in overall equipment effectiveness attributed to unplanned maintenance were estimated at 3 to 5 percent. That is real money, but the ceiling is worth knowing before you budget against it.

Our take: almost every predictive maintenance vendor presentation cites a 30-to-50% reduction in downtime and credits McKinsey. We cannot locate a dated publication with a defined scope for that figure. Anyone presented with it should request one, since the range underpins numerous business cases. Our own engagements show both outcomes are real. High-duty-cycle rotating equipment with years of failure history can land results in that region. Sound, honestly built projects on low-failure-rate assets can return nothing, because there was no signal to find. Determine your assets' category before financing the model, rather than afterwards.

Compliance: What Lands on 11 September 2026

For connected products sold into the European Union, a key deadline falls on 11 September 2026.

The EU Cyber Resilience Act, Regulation (EU) 2024/2847 took effect on 10 December 2024. Its reporting obligations apply from 11 September 2026, placing actively exploited vulnerabilities and severe incidents on a 24-hour, 72-hour, and final-report schedule. The primary duties concerning design, conformity assessment, documentation, and CE-marking arrive on 11 December 2027. Our IoT supply chain post explains reporting operations, including notification recipients and timing; this section is limited to the changes created by placing a model within the product.

Three consequences for AI-enabled IoT products are readily overlooked:

• The product includes its model. When model misbehaviour makes a device unsafe, document its failure modes alongside those of the firmware in security and conformity materials.
• A firmware update route alone is insufficient; models require one too. Expectations in the Act for vulnerability handling throughout a product's support period presume an ability to distribute fixes. Manual model retraining and fleet redeployment constitute a compliance deficiency, not merely an engineering nuisance.
• 24 hours requires an on-call rota, not merely a written policy. From 11 September 2026 onwards, the incident process must function at 3 a.m. on a Sunday.

Security survey results reveal the same separation between intention and control. The State of AI in OT Cybersecurity 2026 reports that roughly 88% of respondents used, evaluated, piloted, or planned AI. In contrast, only about 31% had deployed it in even one function, and about 8% in several functions. Within that context, merely 12% had formally identified the AI-driven decisions capable of directly affecting physical processes, safety systems, or continuity. Controls intended to defend AI tools and models from manipulation, adversarial inputs, or supply chain compromise existed for about 35%, while just under 8% expressed high confidence in them.

The denominator needs careful treatment to avoid exaggeration. The 12% covers every respondent, most of whom have no AI deployment, so it does not mean seven out of eight deployers omitted the mapping exercise. It does show that mapping occurs less often than deployment. More organisations operate AI near physical machinery than have documented which decisions can cause physical movement.

What This Means for the App Itself

Much of the writing about this subject ends with the model, treating the application used by real people as an implementation detail. That treatment is mistaken: adding the AI layer changes four specific aspects of application development.

Uncertainty must be communicated by the interface. A rules engine returns a binary result: either the threshold was crossed or it was not. Models instead return scores. The application must translate that score into action, and setting the boundary is a product choice rather than a data-science choice. Successful apps provide operators with confidence and contributing signals as well as the verdict. A red dot that cannot be examined is ignored.

Each inference must be reproducible after the fact. If, in eighteen months, somebody asks why a batch was flagged, the answer requires its model version, input window, output, and resulting action. Storage and schema must support this from the outset because later retrofitting is almost impossible.

Override is a first-class feature, not an escape hatch. Operators will disagree with the model, and they will be right often enough that burying the disagreement destroys trust in the system for good. Record the override and the reason, and feed both into the next training cycle. That loop is often worth more than the original model.

The application must support the model's release cycle. Firmware, application, and model versions now advance separately. A field device might operate model v4 while the cloud anticipates v6. The app has to handle that mismatch deliberately rather than assume it away — and that is the exact capability the CRA timeline turns into a requirement.

This engineering is not exotic, yet it represents most of the effort. Estimates centred on model accuracy routinely omit it.

How to Scope an AI-Enabled IoT Build

The following order is the one we would use, and it withstands real deployment.

1. Define the decision ahead of the model. Put it in one sentence: when this fires, [role] performs [action] within [time]. If you cannot write that sentence, the feature is not ready to build, and a better model will not rescue it.

2. Audit the data you have, not the data the spec sheet implies. Check sample rate, timestamp reliability, clock sync between devices, gaps, and units. Check too whether the same signal still means the same thing on machines of different vintages. 54% of industrial teams call this their top blocker, so give it a work package rather than filing it under discovery.

3. Ship the rules-based version first. A threshold alert deployed in three weeks tells you whether anyone acts on it. That is the most valuable thing you can learn, it costs almost nothing, and it produces the labelled data the model will need.

4. Use the four constraints to select model placement — latency, bandwidth, residency, update cadence — then document the behaviour of every tier during loss of network access.

5. Build the update path before the model. It needs over-the-air model delivery, versioning, staged rollout, and rollback. For EU-market products the CRA timeline makes it compulsory rather than optional.

6. Monitor drift starting on day one. Ageing equipment, seasonal variation, and new sites all alter input distributions. Two years after commissioning, an unmonitored model that began accurately has become a liability attached to a dashboard.

7. Retain human oversight whenever output causes physical movement. With so few organisations mapping the boundary between AI decisions and physical effects, no cheaper risk control is available.

Our companion article on leveraging IoT apps for supply chain optimization applies this sequence as a worked example in one vertical.

The Bottom Line

Headlines describe AI and IoT as converged. Deployed systems tell another story: under 1% of connected devices execute AI on-device; silicon capable of changing that is now shipping, while much of the software needed to exploit it remains unwritten.

For anyone building in this space, that is a better position than it sounds. Whether the hardware can run the model is no longer the binding constraint. The questions now are whether your organisation can get clean data off its equipment, route a model output to someone accountable for acting on it, and keep that model updated over the air for as long as the product stays in service. The compliance calendar is about to demand all three anyway.

Start with the decision, not the model. Ship the rules-based version first. Build the update path before you need it.