Highlights | At WeAreDevelopers World Congress North America 2026, Northern.tech CTO, Eystein Stenberg, and panelists from Arm, RTI, and Roboflow agreed that edge AI models need the same lifecycle discipline as firmware: versioned, signed, delivered over the air (OTA) with delta updates, and always recoverable via rollback. Mender provides the necessary software update infrastructure for embedded devices and AI models alike.
AI has spent most of the last decade in the data center, trained on GPUs, served from the cloud, and updated with a quick code push and an automated deployment pipeline.
When managing devices in the world of cloud connectivity, the architecture allows the addition or removal of computing resources as demand shifts. Connectivity is assumed; if an update fails, it can be rolled back within seconds from the admin dashboard.
In the physical world, device management works very differently. Connectivity is intermittent, hardware is constrained, and a failed update can cause real-world damage instead of an error page.
The growing shift from cloud to edge computing brings AI into that physical world, and that shift was the thematic anchor of WeAreDevelopers World Congress North America, held September 23–25, 2026, in San José, California.
Highlighting the core theme, a featured panel, “Building AI for the Physical World,” brought together industry speakers: Eystein Stenberg, CTO of Northern.tech; Alex Spinelli, SVP AI & Developer Platforms, Arm; Gerardo Pardo-Castellote, CTO, RTI; and Joseph Nelson, Co-founder & CEO, Roboflow. The panelists' insights point to a common conclusion: deploying AI to physical devices requires lifecycle management, not a one-time push.
Key takeaways for managing the edge AI lifecycle
- Connectivity is the exception, not the default: Teams need to factor in connectivity failures and use delta updates to transmit only what has changed.
- Rollbacks are a safety requirement: A failed cloud update causes costly downtime, while a failed edge update can cause real-world physical damage.
- Unbundle your update payloads: Separate systems, applications, and AI models into independent layers so they can update at different speeds.
- Compliance includes the model: Regulatory frameworks like the EU Cyber Resilience Act (CRA) require models to be included in the Software Bill of Materials (SBOM) with the means to provide full audit trails.
- Leveraging AI requires a lifecycle approach, not a finish line: Edge AI models need to be continuously retrained, updated, or replaced.
- Successful AI deployments require ongoing management: Successful edge deployment requires robust versioning, cryptographic signing, and over-the-air updates, always with a mechanism for rollback.
The conference focused on the growing prominence of edge devices: AI moving away from the server and onto hardware in the field. Edge AI involves deploying machine learning algorithms directly on local hardware, with on-device processing.
Edge hardware includes robots, vehicles, IoT devices, industrial equipment, and sensors, in which compute resources are constrained and connectivity is never guaranteed.
By processing data close to its source, this approach provides real-time, low-latency insights, enhanced data privacy, and reduced bandwidth. However, unlike cloud environments with virtually infinite scalability, edge devices operate under strict physical limitations.
Hardware in the field must balance processing power against thermal limits and, for battery-powered devices, finite battery life. As a result, resource-intensive models are typically optimized, compressed, or quantized to fit the host device’s parameter constraints.
Connectivity at the edge is inherently intermittent, unpredictable, and costly, lacking the stable, high-throughput connectivity of modern data centers. Updates can’t rely on continuous streams, so they must be architected as lightweight, differential payloads that can successfully resume transmission over weak, fluctuating cellular or satellite connections.
#1. Layer updates rather than bundling them
A connected AI product typically runs not a single piece of software, but roughly three layers: the underlying system, the application running on it, and the model itself.
Each of these layers moves at a different speed and carries a different level of criticality. Take payload size for one example. A typical system image is about 200 MB, while a large AI model can reach 10 GB, roughly 50x larger. The image is often tied to specific GPU hardware and sent over slow, expensive cellular networks.
A system update might be infrequent and high-stakes, while an application update might ship weekly. A model update may need to happen independently of either. Bundling all three into a single event removes the ability to update, test, and roll back each layer on its own terms.
#2. Connectivity should never be assumed
Cloud deployment assumes that a network connection is always on, but edge deployment can’t make that assumption. Devices in the field, whether on a factory floor, in a vehicle, or at a remote site, routinely operate over intermittent, low-bandwidth, or entirely offline connections.
Intermittent connectivity fundamentally changes software update management. Pushing a full model to a device each time it changes is bound to fail if the connection drops mid-transfer or bandwidth is scarce.
In the event of no connectivity, safety-critical operations must work offline, with the ability to stop safely and avoid obstacles. And devices should retain necessary data locally.
Delta updates transmit only what has changed, rather than the entire file, and this, along with automatic retry and fail-safe design, makes it the most reliable approach at the edge.
#3. Rollback is a safety requirement at the edge
In a cloud environment, a bad deployment means an error page and a quick rollback. However, on a robot or a vehicle, a bad update can mean something has gone physically wrong in the real world, with potentially serious consequences. The physical risk demands a different standard for how updates are delivered and handled.
Robust rollback is a precondition for deploying AI on any physical devices that move, lift, or operate near people. Teams need to guarantee that a device can return to a known working state after a failed update, without manual intervention or a site visit.
The challenge grows with system complexity. Imagine a fleet of 1 million vehicles, each with about 100 devices running different software. Each vehicle must end up with a complete, tested software combination. If any one device fails to update, every updated device in that vehicle must roll back to the previous combination. A partially updated vehicle runs on a combination of untested software, which is a safety risk in its own right.
At this scale, rollback can't be an afterthought or a manual recovery process. Teams need to treat each vehicle as a single system and design rollback into the update architecture from the start, so that a failure on one device never leaves the whole fleet in an unknown state.
#4. Compliance affects AI models, not just software
Under the EU Cyber Resilience Act (CRA), the AI model is part of the product, and not a separate artifact sitting outside the scope of software compliance. AI models belong in the Software Bill of Materials (SBOM). Edge devices need security updates like any other software component, including any model running on them.
The EU CRA's reporting obligations took effect on September 11, 2026, with most other requirements following by December 2027. In practice, it’s far easier to comply with regulations using purpose-built solutions such as Mender, which provides fail-safe, timely updates and audit trails.
Edge AI requires management across its lifecycle
To succeed, teams need to manage the model running on an edge device across its entire lifecycle, from design, to deployment, to decommissioning. Versioned, signed, delivered over the air, and always with a rollback option.
For many teams, AI deployment is still treated as a “finish line," and deployed with a one-time push, but models need a lifecycle approach. Edge devices need model retraining as conditions change. A device fleet that fails to receive regular updates won’t stay accurate. The entire fleet will drift out of date, and this often won’t be noticed until something goes wrong. Edge AI needs an ongoing lifecycle of versioning, testing, and redeployment.
Looking forward: The physical world has no tolerance for shortcuts
The key takeaway from the conference is that lifecycle thinking is required for AI to succeed in the physical world, in stark contrast to building AI for data and the cloud.
It’s not about who moves fastest from design to deployment. The teams that succeed will treat deployment as the start of the model’s life, not the end of the project. Getting edge AI right means building the infrastructure for continuous management – versioning, rollback, and audit trails – into the architecture from the very beginning, rather than retrofitting it once a fleet is already in the field or after a failed update has caused real-world damage.
For teams further along this path, the discipline already feels familiar. It’s the same rigor that embedded engineers have long applied to firmware, now extended to AI models.
For teams earlier in the journey, the challenge is real, but far from unsolvable. In fact, the infrastructure to manage AI as a living, updatable part of a product already exists, so the gap between where most fleets are today and where they need to be is closing.
See how Mender manages system, application, and AI model updates across your fleet with delta updates, automatic rollback, and a full audit trail. Start a free trial, or book a demo.
