AI for Hardware and Device Makers
Hardware makes every AI decision permanent: the compute you ship is the compute you have for the product's life, and a model update reaches devices you cannot easily reach back.
Software companies can add compute. Hardware companies choose it once, ship it, and live with the decision for years — which means the model and the silicon have to be designed against each other rather than in sequence.
AI for hardware and device makers covers on-device inference and model optimisation within power and memory budgets, fleet telemetry and field analytics, over-the-air model update infrastructure, and the cybersecurity and data access obligations on connected products.
Designing the model and the silicon together
The most expensive mistake in device AI is choosing the compute platform and the model independently. The constraints are hard, interacting and permanent for the product's life.
- Power budget frequently binds before compute does. On battery devices, inference energy per invocation determines how often the feature can run at all.
- Memory ceilings are absolute. A model that does not fit does not run, and quantisation has quality costs that need measuring rather than assuming.
- Thermal limits throttle sustained inference. A model that benchmarks well in a lab may not hold performance in an enclosure under continuous use.
- Accelerator support constrains architecture. The operations your silicon accelerates determine which model designs are viable, and the mapping is not obvious from the datasheet.
- Measure on target hardware, early. Desktop benchmarks predict device performance poorly, and finding that out after tape-out is expensive. See edge AI deployment.
Prototype the model on the actual silicon before the design freezes
The sequence that fails is: choose the platform on cost and availability, then design the model, then discover the model does not fit the power or memory envelope. The sequence that works is to prototype representative models on candidate silicon during platform selection, so the compute decision is made with real numbers. That is a few weeks of work at the point where it is still cheap, and it is unrecoverable afterwards.
Updating models on devices you have shipped
Over-the-air model updates are a deployment problem
Pushing a model to a fleet has real failure modes: hardware variants behaving differently, partial rollouts leaving the fleet inconsistent, and degradation nobody notices for weeks. Staged rollout, health checks and a tested rollback are requirements rather than refinements.
Bandwidth and storage constrain update size
Devices on cellular or constrained connections cannot receive large model files routinely. Delta updates and small models are engineering decisions with commercial consequences for how often you can improve the product.
You need telemetry to know it worked
On-device model performance is invisible without instrumentation, and privacy and bandwidth constrain what you can send back. Deciding what to measure, and how to aggregate it on-device, is a design decision made before shipping.
Support obligations run for the product life
Under the Cyber Resilience Act, vulnerability handling extends across the product lifecycle — which for hardware can be a decade or more, considerably longer than most software support commitments assume.
Connected product obligations
| Regime | What applies | When |
|---|---|---|
| Cyber Resilience Act | Vulnerability reporting, then full cybersecurity requirements | Reporting since 11 Sept 2026; main obligations 11 Dec 2027 |
| EU Data Act | Users may access and share data their device generates | Applying since 12 September 2025 |
| EU AI Act | High-risk only if a safety component of a regulated product | 2 August 2028 where it applies |
| Machinery Regulation | If the device is machinery with an AI safety function | 20 January 2027 |
| Article 50 transparency | Disclosure and marking where users interact with AI or generated media | In force since 2 August 2026 |
| Radio and product directives | Unchanged, and still operative | Now |
The Data Act reaches consumer and industrial devices alike
Users of connected products have the right to access data their use generates and share it with third parties, and devices sold in the EU must be designed to allow it. For device makers whose service or subscription revenue depends on exclusive access to device data, that is the assumption the regulation was written to open up. Designing the access path deliberately is better than having it specified for you later.
How an engagement runs
Silicon and model are evaluated together, before the platform decision freezes.
Constraint and obligations review
Power, memory and thermal budgets; and which of CRA, Data Act, AI Act and Machinery Regulation apply.
On-target prototyping
Representative models benchmarked on candidate silicon, with quantisation quality cost measured rather than assumed.
Model optimisation
Built to the budget, with sustained-load thermal behaviour tested in the enclosure.
Update infrastructure
Staged rollout, health checks, tested rollback and on-device telemetry aggregation.
Operation
Fleet performance monitored, vulnerability handling maintained across the product lifecycle.
What you receive
A model that fits the device you are actually shipping, and a way to improve it afterwards.
On-target benchmarking
Representative models on candidate silicon, with real power, memory and thermal numbers.
Optimised on-device model
Within budget, with quantisation quality cost measured.
OTA update infrastructure
Staged rollout, health checks and a rollback tested before it is needed.
On-device telemetry design
What to measure and how to aggregate it within privacy and bandwidth limits.
Compliance architecture
CRA, Data Act and AI Act obligations handled as one programme.
Lifecycle support plan
Vulnerability handling across a product life measured in years, not release cycles.
Is this the right starting point?
Worth being direct. There are situations in hardware and devices where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- You are selecting a compute platform and have not benchmarked models on it.
- An on-device model does not fit the power or thermal envelope in the enclosure.
- You ship connected devices and have no staged rollout or rollback for model updates.
- You need a Cyber Resilience Act position before December 2027.
- Device data underpins a service revenue model the Data Act now opens up.
Do something else if
- The silicon is fixed, inadequate, and cannot be changed. Say so before spending on modelling.
- There is no over-the-air update path and none is planned.
- You want an AI safety function in machinery without engaging a notified body.
- Device telemetry cannot be returned at all, so nothing can be measured post-shipment.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
When should we involve model work in hardware design?
During platform selection, not after it. The failing sequence is choosing silicon on cost and availability, designing the model, then discovering it does not fit the power or memory envelope. Prototype representative models on candidate silicon while the decision is still open — a few weeks of work at the point where it is cheap, and unrecoverable once the design freezes.
Will quantisation hurt quality?
Sometimes materially and sometimes not at all, and the only way to know is to measure it on your task rather than assume from published results. Quantisation quality cost varies by model architecture, task and data distribution. Build the evaluation before the optimisation so the trade-off is a measured decision rather than a hope.
How do we update models on shipped devices?
As a deployment engineering problem with staged rollout, health checks and a tested rollback. The failure modes are real: hardware variants behaving differently, partial rollouts leaving the fleet inconsistent, and degradation nobody notices for weeks. Bandwidth also constrains how often you can improve the product, which makes delta updates and model size commercial decisions rather than technical details.
What does the Cyber Resilience Act mean for hardware?
Vulnerability reporting obligations began on 11 September 2026 and the main cybersecurity requirements apply from 11 December 2027. The demanding part for hardware is lifecycle vulnerability handling: a product with a ten-year service life needs security support across that period, which is considerably longer than most software support commitments assume and needs planning into the product economics.
Does the Data Act affect consumer devices?
Yes — users of connected products have the right to access the data their use generates and to share it with third parties, and devices sold in the EU must be designed to allow that. For makers whose service or subscription revenue relies on exclusive access to device data, that is precisely the assumption the regulation was written to open up. Designing the access path deliberately beats having it specified for you.
Related verticals
Organisations in hardware and devices usually share data, buyers or regulators with these. All fourteen are listed on the Technology & Telecom page.
AI for Data Centres and Cloud Providers
Cooling and energy optimisation, GPU scheduling and capacity — plus EU energy reporting from 500 kW.
Read more →AI for Developer Tools Companies
Evaluation for code-facing features, benchmark honesty and unit economics — for buyers who will check.
Read more →AI for Telecommunications Operators
Network optimisation, fault root cause, churn and field operations — at the scale telecoms actually runs.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.