Embedded World North America 2026: Four Takeaways for Embedded Engineering Teams
After three days of talks, demos, and conversations at Embedded World North America in Anaheim, our team returned with plenty to discuss. We connected with partners and engineering teams working through familiar challenges: bringing more intelligence into devices, managing growing software complexity, and getting reliable products to market.
Across those conversations, four themes stood out.
Four Takeaways from Embedded World North America 2026
1. AI on devices is moving into real products
The conversations around running models on small hardware are becoming more concrete. The challenge now is making those capabilities reliable within tight constraints on memory, power consumption, and response time. That puts firmware integration and testing at the center of bringing AI into production. A successful demonstration is an important step, but teams also need to understand how a model behaves under the conditions their product will encounter in everyday use.
2. Security has to come first
For engineering teams, planning for secure updates and vulnerability management early can help avoid expensive changes later in development, and ultimately help your organization move significantly faster. At the same time, regulations such as the EU’s Cyber Resilience Act reinforce the need to address security throughout a product’s lifecycle. Security decisions affect architecture and maintenance, making them part of product planning from the outset. Addressing those questions early also gives engineering and security teams clearer expectations as development progresses.
3. Open ecosystems are gaining attention
RISC-V and Zephyr featured prominently at the event, reflecting growing interest in open approaches across hardware and software. RISC-V provides an open instruction set architecture, while Zephyr offers an open-source real-time operating system for resource-constrained devices. Their visibility highlighted how central these ecosystems are becoming to embedded engineering conversations. For teams evaluating them, the practical questions include hardware support, integration effort, and how the product will be maintained over time.
4. Software remains essential to getting hardware to market
Advanced chips depend on firmware, drivers, and development tools that make their capabilities usable. Integrating and validating that software is a major part of turning a promising hardware platform into a reliable product that ships on time. Indeed, this is what we do every day in Qubika’s Embedded Engineering Studio, where we have deep expertise helping our clients connect hardware and software in order to ship world-class products.
Stop Asking If AI Belongs in Embedded. Start Asking Where.
In my talk, I started by explaining why general-purpose AI models, which learn mostly from the public internet, often struggle with embedded engineering. There are two main reasons.
The first is a knowledge gap. Proprietary codebases, internal hardware documentation, and years of accumulated engineering know-how rarely make it into a model’s training data. Put simply, most embedded engineering never happened in public.
The second is a higher risk of hallucination. In specialized, low-level work, a single wrong register address or timing assumption can turn a plausible-looking answer into an unusable one.
Where AI is already delivering value
Despite these limits, AI is already paying off for embedded teams, especially when it is grounded in a company’s own technical knowledge. Requirements review, firmware scaffolding, and test generation are strong places to start.
A practical way to judge any use case is to ask one question: how quickly and reliably can an engineer check the output? Reviewing a suggested unit test is straightforward. Validating a diagnosis that hinges on hardware timing is a very different challenge. The easier the output is to verify, the better the fit.
That is why architecture decisions, hardware debugging, and safety-critical work still demand close engineering oversight. AI can contribute, but engineers make the final call.
Technology is only half the work
Technical readiness is only part of the picture. Individual engineers can become more productive almost immediately, but turning those gains into team results takes more: updated workflows, clear rules for accessing and sharing data, and defined ownership of AI-assisted outputs.
Getting real value from AI means both making the right knowledge available and building the processes that let teams use it well.
Thank you to everyone who stopped by, shared their challenges, and exchanged ideas with our team. I look forward to continuing those conversations.
