Physical AI Foundations / 05

When Devices Become AI-Powered, Product Management Becomes Lifecycle Management

AI-powered devices force product teams to manage hardware and model dependencies, capability limits, power budgets, OTA failure paths, data flows, cybersecurity and end-of-life support.

M.K.September 3, 202614 min read

A near-future city with connected smart devices, edge-computing nodes and distributed infrastructure representing the long operating life of AI-powered physical products

M.K. / FIELD NOTESPhysical AI / AI Infrastructure / 2026

When an AI capability appears on a smart-device roadmap, the easiest mistake is to treat it like one more software feature.

How accurate is the model? Do we need an NPU? Should inference run locally or in the cloud? Those questions matter, but they are not enough.

Once a physical product ships, it becomes tied to constraints that are hard to change later. The sensor is selected. Memory is soldered onto the board. Battery capacity and thermal headroom are fixed. Connectivity will vary in ways the product team cannot control. The boot chain and OTA design may already be difficult to alter by the time mass production starts.

AI adds another layer of change on top of those fixed decisions. Models evolve. Runtimes change. Accelerators differ across hardware revisions. Prompts may behave differently when a system model changes. The boundary between local and cloud processing can move over the life of the product.

That is why I do not think the main shift for product managers is simply that they now need to "understand AI."

The larger shift is that they need to manage a system whose intelligence can keep changing after the hardware has shipped.

In my earlier article on why Edge AI matters again, I focused on where inference should happen. This article moves one level closer to product management: once those decisions are embedded in a camera, wearable, appliance, vehicle component or robot that may remain in the field for years, what new questions belong in the product specification?

An AI feature is a dependency chain, not a checkbox

Connected hardware was already a multi-layer product before generative AI arrived.

A typical device can involve sensors, an MCU or SoC, firmware, an OS or RTOS, connectivity, a mobile app, backend services and fleet management. Add AI and the dependency chain becomes longer:

sensor → preprocessing → runtime → accelerator → model → rules or tools → local action → cloud service

A change at any one of these layers can alter the user experience.

Current on-device AI frameworks make this visible. Google moved LiteRT's advanced GPU and NPU acceleration into its production stack in 2026, while still addressing a fragmented hardware world across different SoCs and accelerators. ExecuTorch's current backend guidance is similarly hardware-specific: XNNPACK, Vulkan, QNN, Core ML, MPS, OpenVINO and Arm Ethos-U are different deployment paths for different targets.

The point is not that a product manager should become the person who exports models or tunes delegates.

The product question is simpler and more important:

What exact combination of hardware, OS, runtime and model does the promised capability depend on?

If that is not explicit early, a team can end up with an AI demo that works beautifully on a development device while the commercial product matrix supports the feature reliably on only some SKUs, OS releases or hardware revisions.

I use the term AI dependency map for the artifact that makes those assumptions visible. It is my own product-management framing, not an industry standard.

For an AI device, I would want that map before I trust the feature list.

"Supports AI" is too vague. Define the capability envelope

AI features are often described as binary capabilities: summarization, voice control, image understanding, offline inference.

Physical products are rarely that clean.

Apple's current Foundation Models documentation requires applications to check model availability before using the system language model. Availability can depend on whether the device is eligible, the region is supported and the model is ready. Apple explicitly provides unavailable states that a product must handle instead of assuming the model is always there.

Google Play for On-device AI, which is still labelled beta as of September 3, 2026, makes another part of the problem concrete. It can distribute custom ML models at install time, by fast-follow delivery or on demand, and it supports device targeting so different model variants can be delivered according to device characteristics such as model, system properties or RAM.

Both examples point to the same product-management problem.

"AI supported" should not be a yes-or-no checkbox.

A more complete definition asks:

Which device classes can run the capability? What happens if the model is missing or still downloading? Is there a degraded path when the preferred accelerator is unavailable? Which features remain offline? What happens if the cloud service is unreachable? Do older devices receive the same model or a smaller one?

I call this the capability envelope: the product is not promising an abstract AI capability. It is promising that the capability works within a defined set of hardware, software, model and connectivity conditions.

That distinction becomes especially important when marketing language is written long before the full device matrix has been tested.

Power, latency and thermals belong in the product specification

Edge AI discussions often stop at the question of local versus cloud inference.

A product team has to go further and ask how much resource consumption the feature is allowed to create.

Google's 2026 engineering guidance on LiteRT and NPUs names device thermals, battery life and frame drops as practical constraints in real-world on-device AI. Arm's current Edge AI documentation similarly frames low-power, resource-constrained hardware and low-latency inference as parts of the same design problem.

Inference is not an abstract API call. It consumes power, memory, bandwidth and thermal headroom.

The same feature can behave very differently if it runs once per second, once every ten seconds, or only after a sensor event wakes the system. Camera frame rate, microphone wake strategy, location frequency, model size, quantization and whether a model remains resident in memory all become product decisions because they affect responsiveness and battery life.

I use intelligence budget as a shorthand for this constraint set.

At minimum, I would include latency, memory, power, thermal headroom, bandwidth and cloud cost.

Again, this is my framework rather than an established industry term.

The value of the framework is that it forces trade-offs into the specification. Without a budget, teams often end up asking engineering to make the feature faster, more accurate and lower-power at the same time without defining which constraint is allowed to move.

Model versions are becoming product versions

This may be one of the most underestimated changes in AI-enabled devices.

Traditional connected products already track firmware, app and backend versions. AI products increasingly need to track model versions too, and those versions do not necessarily move together.

A platform-provided system model may change with an OS update. A proprietary model may be delivered as a separate package. A hybrid product may use one local model and a different cloud model, each changing on its own schedule.

Apple's current Foundation Models guidance makes the behavioural consequence explicit. Apple tells developers to test prompts against old and new model versions when the system model changes, compare the output and, when needed, maintain prompt versions for different model releases.

That creates an unusual product-management situation:

The application can remain unchanged while the AI behaviour changes.

So I think AI device teams need to manage behaviour versions, not only software versions.

A useful product question is:

Which parts of this AI behaviour are allowed to change when the model changes, and which parts are part of the product promise?

I call this a model behaviour contract.

A safety reminder may be allowed to change its wording but not cross a defined risk threshold. A recommendation feature may improve, but a model update should not silently expand the scope of data leaving the device. A voice assistant may become more capable, but the fallback path should not disappear because one model revision behaves differently.

This kind of contract may never look as clean as an API schema. It still needs to be testable through regression suites and product acceptance criteria.

Otherwise every model update is, in part, a new product being delivered into old hardware.

OTA is not just maintenance infrastructure. It is a product capability

AI makes device updates more complicated because firmware, models and configuration may have different version relationships.

NIST's IoT cybersecurity baseline treats secure software update as a core device capability, including authorized updates and mechanisms to verify the source of an update. That does not mean NIST prescribes one universal rollout or rollback architecture. Those remain product and system-design choices.

Current platform guidance shows how concrete the engineering becomes. AWS IoT recommends code-signing firmware so the device can verify authenticity before installation. NVIDIA's current Jetson Linux image-based OTA documentation supports different update paths, including systems with rootfs A/B enabled, and requires the OTA client to validate downloaded payloads according to the product's security requirements. NVIDIA also recommends security mechanisms such as signatures or encryption for OTA packages.

The product principle underneath those details is straightforward:

Having OTA is not the same as having an update strategy.

The product team still needs to define the failure path.

What happens if a firmware update fails? Should a model update roll back with firmware or independently? Can configuration be reverted separately? Does a new model first reach a small percentage of the fleet? How does a device that has been offline for a month cross multiple versions when it reconnects? What still works safely after the formal support period ends?

For AI devices, update architecture belongs in the product requirements before mass production, not as an operational detail left for after launch.

Once thousands of devices are in the field, some missing update capabilities cannot be fully repaired by saying "we will add that in the next release."

Local AI does not remove the privacy problem

"We run AI locally, so the product is private" is too broad a claim.

On-device inference can reduce the need to send some raw data off the device. But a product may still have telemetry, cloud sync, remote support, model evaluation, crash logs, user accounts or service diagnostics.

The European Commission's current GDPR guidance on data protection by design and by default says privacy safeguards should be considered from the earliest stages of processing design. By default, only necessary personal data should be processed, retention should be limited and access should be restricted.

For a product manager, the most practical starting point is not the privacy copy. It is the data-flow diagram.

Where is raw sensor data created? Which preprocessing happens locally? Does the cloud receive raw data, embeddings, metadata or only events? How long is each class of data retained? Who can access it? What data is collected for model improvement? Which paths can the user disable, and what capability remains after they do?

The right question is not whether local or cloud is inherently safer.

It is why each piece of data moves, what changes when it moves and who becomes responsible for it.

This is also where the product-lifecycle discussion connects to my earlier article on AI camera event quality. Good edge filtering can reduce bandwidth, but it can also reduce the amount of raw information that ever needs to leave a device. That can be a useful architectural advantage, but it is not a substitute for privacy and security design.

The product lifecycle is becoming more important than the launch date

NIST IR 8259 Rev. 1, published in April 2026, broadens the IoT manufacturer perspective across pre-market and post-market activities, including maintenance, support and end-of-life communication.

That matters because a connected physical product does not disappear when the launch campaign ends.

The regulatory direction in Europe makes the lifecycle issue even harder to ignore. The EU Cyber Resilience Act entered into force in December 2024. As of September 3, 2026, the Act's reporting obligations are scheduled to start applying on September 11, 2026, while the main obligations apply from December 11, 2027. The European Commission also published implementation guidance in July 2026 that discusses areas including support periods and reporting requirements.

This article is not a legal interpretation of the CRA, and product-specific applicability should be reviewed by a company's legal and compliance teams.

The product-management signal is still clear.

For connected products, shipment is not the end of responsibility.

If an AI device is expected to remain in use for years, then model maintenance, firmware updates, vulnerability handling, cloud dependencies, support periods and end-of-life communication are all part of the product.

That is a structural difference from many web services.

A web service can move most users toward the current software version.

A physical product leaves several generations of hardware and software decisions in the real world at the same time.

The M.K. angle: the new PM skill is managing dependencies that keep moving

Taken together, I do not think the future AI hardware product manager needs to become a firmware engineer, ML engineer or security engineer.

The missing skill is cross-layer dependency management and change management.

Product managers have traditionally worked with features, timelines, cost and user experience. AI devices add a set of contracts that are harder to see but increasingly important:

Capability contract: under which hardware, software, model and environmental conditions does the feature actually work?

Intelligence budget: how much latency, memory, power, thermal headroom, bandwidth and cloud cost can the capability consume?

Data contract: what data is created, processed, retained or transmitted, and where?

Behaviour contract: when the model changes, what may change in the product behaviour and what must remain stable?

Update contract: how do firmware, models and configuration get delivered, verified, staged, failed and recovered?

Lifecycle contract: how long is the product supported, and what remains usable and secure after end of life?

These names are my own analytical framework, not an established product-management standard.

But I think they describe the real work more accurately than asking only which AI chip a device uses.

Once AI moves into physical products, the hard-to-copy advantage is not just a better model benchmark.

It is the ability to make sensors, silicon, runtimes, models, cloud services, security, updates and support periods behave like one reliable product system over several years.

That is one of the reasons Physical AI is a systems problem, not simply a model problem.

What I would watch next

The first signal is whether system models increasingly make AI capability feel like an operating-system capability rather than something every product has to bundle independently.

The second is whether model delivery separates more cleanly from firmware and app releases. Google Play for On-device AI is already making "the model as a separately managed delivery asset" more concrete on Android, but embedded-device practices remain far more fragmented.

The third is AI regression observability. Product teams will need more than crash monitoring. They will need to understand behavioural drift across combinations of model, hardware, runtime and firmware.

The fourth is lifecycle transparency. Cybersecurity rules, enterprise procurement and customer expectations may push support periods, updateability, vulnerability handling and end-of-life disclosure further into the buying decision.

If these directions continue, the AI-device product specification will look less like a traditional consumer-electronics spec sheet.

It will look more like a long-term systems contract.

And the product manager's job will shift from defining what the device can do at launch toward defining how its intelligence is allowed to change safely over time.

Frequently asked questions

Do product managers for AI devices need to know how to train models?

Not necessarily. The more important skill is understanding the dependencies among models, runtimes, hardware, sensors, cloud services and update mechanisms well enough to turn them into testable product requirements. Model training can remain an ML-team responsibility, but the product promise cannot be defined by a model benchmark alone.

Why should a product manager care about model versions?

Because a model update can change behaviour, performance requirements or compatibility even when the application itself has not changed. Apple's Foundation Models guidance explicitly recommends testing prompts across model versions and versioning prompts when necessary. If AI behaviour is part of the user experience, the model version is product information, not only an ML implementation detail.

Can the AI model be updated separately from firmware?

Yes, depending on the architecture. Google Play for On-device AI can distribute custom model packages as separate assets using different delivery modes and device targeting. Embedded products may use very different mechanisms. The important product requirement is to define the version dependencies and recovery paths among model, firmware and configuration before the product reaches scale.

Is on-device AI always safer or more private than cloud AI?

No. Local inference can reduce some raw-data transmission, but overall privacy and security still depend on access control, update security, retention, telemetry, cloud services and device security. The useful question is not which architecture is automatically safer. It is where data moves and how every segment of that path is protected.

What is the most underestimated cost of an AI device?

My view is lifecycle cost rather than per-inference cost: testing across hardware revisions, model regression, OTA, fleet observability, cybersecurity fixes, cloud dependencies, customer support and end-of-life obligations. That is an analytical product-management view, not a universal accounting category, but it is a cost structure worth modelling before launch.