Adding AI to a hardware product is worth doing when a rule you could write by hand cannot capture the judgment your product needs — recognizing an object, separating a real event from noise, predicting a failure from a messy signal. If a threshold and a few if-statements would do the job, they will be cheaper, faster, and far easier to certify. When you genuinely need a model, the two decisions that drive everything else are where the model runs and where the training data comes from. Both are architecture decisions, and both are much harder to change after the enclosure and the electronics are fixed.

First, the Honest Question: Do You Actually Need It?

A lot of "AI-powered" hardware is a marketing label on ordinary signal processing. That is not a scandal, but confusing the two leads teams to over-specify a processor, over-collect data, and add months of schedule for no functional gain.

A useful test: describe the decision your product must make, then try to write the rule. If you can write it in a paragraph and it holds up against the edge cases you can think of, implement the rule. If every attempt produces a rule with a dozen exceptions that still fails on real-world inputs, you have a problem where learning from examples earns its cost. Deciding this before hardware selection is one of the highest-leverage moments in the whole project, and it belongs in the requirements work described in our guide to writing a product requirements document.

The Architecture Decision: Where Does the Model Run?

There are three viable places, and the tradeoffs are concrete.

On the Device (Edge Inference)

The model runs on the product's own processor. This gives you sub-100-millisecond response, no dependence on connectivity, no per-inference cloud cost, and a strong privacy story — raw audio or video never leaves the device. The price is compute: a quantized model has to fit in the memory and power budget you have. Small keyword spotting, vibration classification, and simple vision tasks run comfortably on modern microcontrollers with a neural accelerator; anything involving high-resolution video or a language model does not.

In the Cloud

The device sends data up and gets an answer back. You can use large models, change them whenever you want, and ship hardware that is cheap and simple. You inherit latency, a hard dependency on connectivity, a recurring bill that scales with usage, and a privacy conversation with every enterprise buyer. Our breakdown of IoT cloud infrastructure cost covers how those recurring numbers behave as a fleet grows.

Split (Hybrid)

The most common production answer. A small, cheap detector on the device decides when something interesting is happening, and only those moments go to the cloud for the expensive analysis. This cuts bandwidth and cloud cost dramatically while keeping the device responsive. It also complicates your firmware, your protocol, and your test matrix — the failure modes of a two-tier system are less obvious than either extreme.

Whichever you pick, it constrains your compute platform. Reviewing this alongside microcontroller vs embedded Linux and how to choose a microcontroller prevents the expensive discovery that your chosen part cannot host the model you need.

The Real Asset Is the Data

Teams reliably underestimate this. A model is only as good as the examples it learned from, and for a physical product those examples usually do not exist yet — nobody has published a dataset of your specific sensor, mounted in your specific way, seeing your specific customers' conditions.

That means data collection is a project of its own, with a real budget:

  • Instrumented prototypes deployed early with the production sensor and mounting, because data from a breadboard rig with a different sensor rarely transfers.
  • Labeling, which is slow, tedious, and frequently the largest line item in the AI portion of the budget.
  • Deliberate coverage of edge cases — the dirty lens, the unusual accent, the vibration from a nearby machine. Models fail at the margins, and the margins are what customers notice.
  • A path for field data to flow back, with consent, so the model improves after launch instead of freezing at launch quality.

Design the pipeline before you build the model. Every serious AI hardware program spends more effort on data plumbing than on model architecture.

A Model Is Not Code — It Ages

Firmware you ship keeps behaving the same way for years. A model degrades, because the world it was trained on drifts: you change a supplier's sensor, customers use the product in a context you never sampled, an acoustic environment shifts. Planning for this means budgeting for a monitoring path that tells you accuracy is slipping, a retraining cycle, and an update mechanism that can ship a new model to fielded units — which in turn means OTA updates are a hard requirement, not a nice-to-have. It also means version control over models and datasets, so you can reproduce and explain the behavior of any unit in the field. That traceability turns into a documentation requirement in regulated categories.

Pricing the Smart Feature

Honest ranges, in USD, for the AI-specific portion of a hardware program:

  • A narrow classifier on existing sensor data — anomaly detection on vibration, a wake word, a simple state classifier — is typically a low-tens-of-thousands engineering effort when usable data already exists, and considerably more when it does not.
  • Embedded vision with a purpose-built dataset generally runs into the high tens or low hundreds of thousands once data collection, labeling, model work, and on-device optimization are counted.
  • Cloud-side analytics on fleet data is mostly a data-engineering cost plus a recurring compute bill that scales with usage.

Add the ongoing cost of retraining and monitoring, which does not stop. Comparing these figures against our overview of the cost to develop a new product keeps the AI portion in proportion to the rest of the program. A common and sensible strategy is to ship the first generation with deterministic logic while quietly collecting data, then release the learned feature once the dataset justifies it.

Regulation and Claims

Two constraints bite in practice. First, any diagnostic or treatment-related claim can put your product into medical device territory regardless of how it is built — see software as a medical device. Second, marketing claims about accuracy have to be substantiated, and "AI-powered" language attracts scrutiny from regulators and from buyers alike. Where a model informs consequential decisions, you will also be asked how it was validated and what its failure modes are. This section is educational only; a regulatory professional should assess your specific claims.

Where This Genuinely Pays Off

The strongest cases in physical products are inference on data the product already collects: detecting an impending failure from motor current or vibration, classifying a state that a threshold cannot separate, or personalizing behavior to one user over time. Our article on predictive maintenance from product data walks through the pattern that most often converts sensor data into a feature customers pay for.

Projects House builds the whole stack for AI-enabled hardware — sensor selection, embedded inference, data pipeline, cloud, and app — and will tell you plainly when a rule-based implementation is the better engineering answer. If you are weighing a smart feature for a physical product, describe it through our contact form and we will scope what it would actually take.