Manager's guide to BLE, Wi-Fi, mobile, and sync risks that delay connected product launches, with ways to fix them early.
Read: Why Connected Devices Fail Between Prototype and Production →The AIoT Maturity Model
A practical roadmap from connected devices to autonomous products, with an honest way to locate where your product stands today.
AIoTMaturity modelArchitectureConnected Products
Every hardware company wants AI in its product right now. The vision comes easily: predictive maintenance, autonomous optimization, a conversational interface on top of the machine, intelligent automation across the fleet.
Most companies skip the question that decides whether any of it works: is our connected product actually ready for AI?
AI cannot compensate for unreliable connectivity, noisy data, unstable firmware or a weak software architecture. It amplifies what is already there. A model trained on gaps produces confident nonsense at scale. Before a product can be intelligent, it has to be solid. The maturity model below is the roadmap we use to find out where a product stands and what realistically comes next.
L0Disconnectedhardware only
L1Connectedtalks to cloud
L2Smartremote + rules
L3Intelligentunderstands data
L4Predictivesees ahead
L5Autonomousacts itself
Why you need a maturity model at all
AI is not binary. No product simply "has AI" or "doesn't." Every connected product sits somewhere on a continuum between a disconnected device and an autonomous system, and pretending otherwise is how budgets get burned.
The most common failure pattern we see: a company invests in AI two levels too early. The models are fine. The data feeding them is sparse, unversioned and biased by connectivity gaps. The pilot never leaves the lab, and "AI" gets blamed for what is actually an architecture problem.
Maturity models are not new. Industry 4.0 and digital-transformation frameworks have used them for a decade, and Gartner publishes one for AI adoption. What most of them miss is the connected-product reality underneath: firmware, radios, OTA, telemetry. This model puts the engineering back in.
AI
Data
Connectivity
Firmware
Hardware
Every layer inherits the weaknesses of the one below it.
The six AIoT maturity levels
Find your product below and assess it honestly. For each level, see what it enables, what it takes, and the practical next step.
L0Disconnected
The product is the physical device. All value lives in hardware; the only feedback channel from the field is a support call.
Typical
Established manufacturers with a proven mechanical or electronic product, such as a lab instrument with a local display or a power tool.
Engineering challenge
Adding a radio without disrupting a working production line: certification, unit cost, power budget.
L1Connected
The device talks to an app or the cloud. You can see status and history; you can't do much about it remotely yet.
Typical
First-generation IoT products: a BLE device plus a companion app that shows live values.
Engineering challenge
Pairing UX, silent reconnection and fleet visibility. Usually there is no OTA yet, so every shipped bug is forever.
L2Smart
Remote control, OTA, schedules and threshold rules such as "if temperature > X, alert." Genuinely useful, and entirely hand-authored.
Typical
Most products marketed as "smart" today: thermostat schedules, threshold alerts on an industrial gateway.
Engineering challenge
Config sprawl, brittle rules and silent data-quality problems that nobody notices because nothing consumes the data yet.
L3Intelligent
Models interpret the data: anomaly detection and pattern recognition. The system understands what it sees, while a human still decides what to do.
Typical
A vibration model flags a bearing weeks before any threshold rule could describe the failure.
Engineering challenge
Labeling, false-positive rates that erode trust, and deploying versioned models to devices in the field.
L4Predictive
The system sees ahead to remaining useful life, demand and failure windows, with measured accuracy. Reaction becomes scheduled intervention.
Typical
Predictive maintenance that plans the service visit into the next scheduled downtime instead of after the breakdown.
Engineering challenge
Model lifecycle includes versioning, rollback and drift, plus the edge-vs-cloud tradeoff: latency and privacy against iteration speed.
L5Autonomous
The product acts on its own decisions. People define constraints and audit outcomes, such as a fleet balancing energy across sites or a device ordering its own consumables.
Typical
Rare, and concentrated where the economics justify it: energy, logistics, large industrial fleets.
Engineering challenge
Safety cases, liability, explainability and graceful degradation for the day the model is wrong.
What actually changes between levels
The level names sound like marketing. The differences underneath are concrete engineering capabilities:
DimensionEarly (L0–L2)Late (L3–L5)
ConnectivityPeriodic sync, manual re-pairingAlways-on, self-healing links
DataStatus codes and logsVersioned, model-ready telemetry
Decision makingThe user decides everythingThe system decides within guardrails
MonitoringSupport tickets, after the factFleet-wide observability
OTA updatesRare, risky, or noneStaged rollouts with rollback
AI capabilityNone, or hand-written rulesEdge + cloud models with a lifecycle
Human roleOperatorSupervisor
Seven dimensions of AIoT maturity
A product is never simply "at Level 3." It is at Level 3 in some dimensions and Level 1 in others. The lowest dimension caps what the whole product can safely do. Each dimension gates the next:
1Connectivity: nothing above it works without a reliable link.
2Software architecture: decides whether you can evolve without rewrites.
3Data quality: models inherit every flaw in ingestion.
4AI capabilities: from hand-written rules to learned behavior.
5Operations: OTA, observability, incident response for devices and models.
6Security: automation without trust is a liability, not a feature.
7User experience: invisible when intelligence is right, fatal for trust when it's wrong.
Seven mistakes that stall AIoT products
These patterns recur in architecture reviews. Each one costs a year:
Buying AI before fixing dataModels trained on sparse, biased telemetry ship guesses. Data work is the AI investment.
Bolting on a chatbotAn LLM interface is not a use case. Start from a customer problem, not from "we need ChatGPT".
Ignoring Edge AIRound-tripping every decision to the cloud costs latency, money and privacy. Some inference belongs on the device.
Scaling a prototype architectureWhat demos beautifully with 10 devices collapses at 10,000. Architecture debt compounds silently.
No OTA strategyYou can't improve what you can't update, and models age faster than firmware.
Flying blindNo telemetry means every field issue is a customer phone call and every fix is a guess.
Treating models as one-time deliverablesAn unmonitored model quietly degrades. AI in production is an operations discipline, versioned, monitored and rolled back like any other release.
Moving to the next level
Whatever your level, the path up follows the same sequence. Each arrow is a shipped release, not a slide transition:
- Connectivity
A link that survives the real world: pairing, roaming, silent recovery.
- Telemetry
Structured events with versioned schemas, not printf logs.
- Cloud
Ingestion, storage and fleet management that scale past the pilot.
- Reliable data
Validated, traceable to device and firmware version, honest about gaps.
- AI
First models with a human in the loop for anomalies, patterns and classification.
- Prediction
Forecasts with measured accuracy and drift monitoring.
- Automation
Guardrailed actions with rollback always one step away.
- Autonomy
The system operates; people set constraints and audit outcomes.
Where do you stand? A 20-point self-assessment
Count your honest yeses by clicking to check them. The score maps roughly onto the maturity levels above.
Foundation
Data
AI lifecycle
Operations & security
0 / 20
Foundation first
Level 0–1 territory. Connectivity, OTA and telemetry will pay off faster than any model.
Teams use this as a workshop worksheet. A printable version doubles as the agenda for an architecture review.
Email your result
Send your result with recommendations
We’ll email your score (0–20), area recommendations, a Launch Readiness Score PDF link, and a Product Discovery Call booking link.
You may receive a confirmation email first. Then your result, PDF link, and booking link. No spam. Unsubscribe anytime.
The goal is not Level 5
The goal is to build the right engineering foundation before adding intelligence. Reliable connectivity, a scalable architecture, trustworthy data and disciplined operations make AIoT products succeed. The models are the visible tip.
One limitation worth naming: a maturity model simplifies. Use it as a map for sequencing investment, not as scorecard theater. Being honestly at Level 2 with a plan beats claiming Level 4 in a pitch deck.
References
- Artificial Intelligence of Things: A Survey (2024)
- Empowering Things with Intelligence: AIoT Progress, Challenges, and Opportunities (2020)
- Gartner AI Maturity Model
- Artificial Intelligence Maturity Model: A Systematic Literature Review (PeerJ, 2021)
- Readiness and Maturity Models for Industry 4.0
- Development of a Digital Maturity Model for Industry 4.0
Next step
Wondering where your product stands?
We help engineering teams assess connected products, identify architectural gaps, and build a practical roadmap toward reliable AI-enabled products. This spans BLE and mobile apps, scalable cloud architectures, and Edge AI.
Schedule an AIoT Architecture ReviewRead: Why Connected Devices Fail Between Prototype and Production · Open the failure simulator · Get your Readiness Score
More articles
Design reliable UX for connected devices across hardware, apps, BLE, Wi-Fi, cloud, onboarding, errors, and recovery.
Read: UX for Connected Devices: Designing Experiences Across Hardware, Apps, Connectivity, and Cloud →Hardware companion apps: hard parts, partner skills, and questions that separate specialists from agencies.
Read: How to Choose the Right Companion App Partner for Your Hardware Product →