On-Device vs Cloud vs Edge AI for Wearables: What Actually Runs on the Watch
Every AI wearable sold into Europe or North America makes an architectural choice that buyers inherit: how much intelligence runs on the device and how much depends on a cloud round-trip. That split determines battery life, latency, privacy exposure and what happens when the user walks into a basement with no signal. It also determines which compliance obligations land on your desk as importer. This article explains the decision points so you can specify the right architecture before tooling starts.
What genuinely runs on the watch
The on-device tier handles tasks where latency and privacy matter more than depth. Wake-word detection, gesture recognition, basic voice command parsing and cached responses all run locally on a low-power co-processor. These functions need no network and no account. An offline voice assistant of this kind is the baseline expectation for any wearable that claims to work without a phone.
What does not run locally, in most current designs, is open-ended language model inference. A watch thermal envelope and battery budget cannot sustain it. Buyers who receive a specification claiming full on-device LLM capability should ask for the power draw under continuous inference and the thermal throttling curve. If the supplier cannot produce both, the claim is marketing.
The cloud tier and its obligations
The cloud tier handles speech-to-text for long utterances, translation, summarisation and any function requiring a large model. This is where the architecture becomes a legal question rather than an engineering one. Voice audio leaving the device is personal data. The importer or brand owner is the data controller; the cloud provider is a processor. You need a privacy notice, a lawful basis, a retention schedule and a data processing agreement.
If you intend to ship with Google Play services or GMS, note that this is not licensed by default on any WingPhoenix build. You must license it yourself or specify an AOSP build. This is a common and expensive surprise at certification stage.
Specification checklist for the architecture split
| Decision point | On-device tier | Cloud tier |
|---|---|---|
| Typical functions | Wake word, gesture, cached commands | Translation, LLM inference, summarisation |
| Network dependency | None | Wi-Fi, cellular or paired phone |
| Privacy exposure | Audio stays on device | Audio or text leaves device; GDPR applies |
| Compliance documents | CE RED, FCC Part 15, UKCA on request | DPA, privacy notice, retention policy |
| Battery impact | Low, continuous | High during radio transmission |
| Failure mode | Degraded but usable | Feature unavailable offline |
Certification and document scope
Radio-equipped wearables require CE RED testing against EN 300 328, EN 301 489 and EN 62368-1, plus FCC Part 15 B/C. UKCA is available on request. RoHS 3, REACH SVHC screening and battery UN38.3 with SDS apply across the range. These are booked with an accredited laboratory per hardware revision, not held as blanket certificates. If your supplier claims a certificate covers a new revision without retesting, that is a red flag.
Skin-contact items such as rings require EN 1811 nickel release testing. Where a product is packaged for children, the toy scope (EN 71-1/-2/-3, EN 62115, Toy Safety Directive 2009/48/EC) is determined by the age grading printed on the packaging and must be booked per build. You cannot retroactively claim toy compliance for a product graded as a general wearable, nor the reverse.
Where an importer should push back
- Any claim of full on-device LLM inference without published power and thermal data.
- GMS or Google Play assumed to be licensed without a written licence.
- A single certificate presented as covering multiple hardware revisions.
- Cloud endpoints operated by the factory with no data processing agreement offered.
- Health or translation features described as diagnostic or certified.
- WEEE, BattG, DEEE/Triman, EORI and VAT obligations presented as the supplier's responsibility.
WingPhoenix builds across several form factors where this split matters: the companion robot, the AI glasses and the learning robot. Each carries different certification scope. Reviewing how we build and test before specifying helps you map QC gates to your own incoming inspection.
Commercial terms that follow the architecture
Firmware and app white-label starts at 2,000 units, which is the tier most buyers need if they want their own cloud endpoint and privacy notice rather than the factory default. Logo runs start at 500 units and custom packaging at 1,000. AI glasses open at 300 units; ring, education and companion models at 1,000. Samples ship in 3-5 days from stock or 7-15 days configured, with sample cost credited against mass production. Standard production is 25-35 days, education 30-40 days, and ODM tooling runs 12-20 weeks. Terms are EXW, FOB Shenzhen or DDP air and sea. Warranty is 12 months with 2 % free replacement parts.
Before you commit, decide the split explicitly: which functions must survive offline, which may depend on a network, and who operates the cloud endpoint. Then send the specification to our team with your target markets and volume, and we will return a document matrix mapped to the hardware revision you intend to certify.
Questions buyers ask
Can an on-device AI assistant work without a phone or internet connection?
Partially. Wake-word detection, basic command recognition and cached responses can run fully offline on the watch. Larger language model inference, translation and cloud-synced context require a paired phone or Wi-Fi/cellular connection.
Who is responsible for compliance if the AI assistant sends voice data to a cloud service?
The importer or brand owner is the data controller under GDPR and equivalent regimes. The hardware supplier provides the device and firmware; the cloud endpoint, privacy notice and data processing agreements sit with you unless contractually transferred.
Related: more on ai agents · buyer guides · customisation tiers