Concept renderMost wearable AI devices contain one or more MEMS microphones, a low-power processor, a radio that sends audio to a phone or the cloud, a small lithium battery, flash storage, and a button with a recording light. The large AI model usually runs in the cloud, so data flow and consent design matter as much as the parts.
This guide is for teams building one. It looks inside the device: what each part does, which datasheet numbers matter, how audio reaches the AI model, and how to build consent into the hardware. Every sourced figure links to a vendor datasheet, a standards body or a government text listed below.
Sources read November 5, 2026. This is an engineering summary and not legal advice.
What is inside wearable AI devices?
Pendants, clips, pins, rings, glasses and earbuds look different. Inside, an audio-first AI wearable has the same short list of parts.
| Part | What it does | What you decide |
|---|---|---|
| Microphones | Capture speech. Many designs use one or more digital MEMS microphones. | How many, where the sound ports sit, and which digital interface the processor reads. |
| Processor | Runs wake detection, audio encoding, encryption, storage and the radio stack. | A small Bluetooth LE microcontroller, a Wi-Fi and Bluetooth chip, or a Linux system on chip. |
| Radio | Moves audio and commands to a phone, or straight to the cloud. | Bluetooth LE to a phone app, Wi-Fi, or cellular. Each one changes power, cost and certification work. |
| Storage | Holds recordings when the link drops, and the firmware image. | Flash size, from the hours you must buffer times the bitrate of your codec. |
| Battery and power | A small rechargeable lithium cell, a charger and usually a fuel gauge. | Cell size, charge method and the runtime you will print. |
| Controls and indicator | A record button, a mute control and a light that shows recording. | Who can see the light, and what signal drives it. |
| Other sensors | Optional: a motion sensor for tap or wear detection, or a camera on glasses. | Add one only if a feature needs it. Each adds power, data and privacy work. |
Two choices drive the rest: where the AI work happens, and how audio leaves the device. Settle both before anyone sizes the battery, because they set the processor, the radio and the power budget.
How do the microphones capture usable speech?
Many AI wearables use digital MEMS microphones. As a worked example, here is what the Infineon IM69D130 datasheet states, as of November 2026, at 1.8 V supply and 25 °C.
| Datasheet item | Value in the datasheet | What it means for a wearable |
|---|---|---|
| Output | PDM digital output | The processor must have a PDM input or a converter. Check this before you pick the chip. |
| Signal-to-noise ratio | 69 dB(A) at a 3.072 MHz clock; 64 dB(A) at 768 kHz, where the datasheet measures over a 20 Hz to 8 kHz bandwidth | A lower clock saves current and gives up some SNR and bandwidth. |
| Current | 980 µA typical at 3.072 MHz; 300 µA typical at 768 kHz; 25 µA typical in standby | The full-rate figure is a little over three times the low-rate figure. Pick the mode that matches the job. |
| Acoustic overload point | 130 dBSPL | Loud nearby sound, such as wind on the port, can still clip if the port design is poor. |
| Matching | Sensitivity tolerance of ±1 dB; phase matched within ±2° at 1 kHz | The datasheet says this matching matters for multi-microphone array and beamforming use. |
| Size | 4 mm x 3 mm x 1.2 mm package | Fits a pendant or clip. A ring leaves little room for the port. |
Source: Infineon IM69D130 datasheet, Tables 1 and 5 and the features list, as of November 2026.
The lesson is the trade between clock rate, noise and current. A device that waits for a wake word can run its mic in a low-power mode and switch up when speech starts. The datasheet lists a mode-switch time of up to 20 ms at ±0.5 dB sensitivity accuracy, as of November 2026, so the firmware must allow for that gap. Port placement in the real enclosure matters as much as the part number.
Which chip and radio carry an AI wearable assistant?
An AI wearable assistant has to wake, capture, encode, encrypt and send audio. The processor class sets how much it can do locally and how long the battery lasts. Two published parts show the range.
| Class | Example from the vendor page | Source |
|---|---|---|
| Small Bluetooth LE microcontroller | TI CC2340R5: Arm Cortex-M0+ at 48 MHz, up to 512 KB flash, up to 64 KB SRAM, Bluetooth Core 5.4 qualified, 5.3 mA receive, 5.1 mA transmit at 0 dBm, under 710 nA standby on the CC2340R52. | TI product page, as of November 2026 |
| Wi-Fi and Bluetooth microcontroller | Espressif ESP32-S3: dual-core Xtensa LX7 at up to 240 MHz, vector instructions, 512 KB internal SRAM, octal SPI flash and PSRAM support, 2.4 GHz Wi-Fi 802.11 b/g/n, Bluetooth 5 (LE), I2S, and an ultra-low-power core. | Espressif product page, as of November 2026 |
The small Bluetooth LE part draws very little in standby, and its SRAM of up to 64 KB leaves little room for audio buffers and an encoder. Test the full audio path on a prototype before you commit. The ESP32-S3 has more memory and Wi-Fi. Our MCU or Linux SoC decision guide compares the classes in detail.
Phone as the uplink
Many wearables send compressed audio over Bluetooth LE to a phone app, and the phone uploads it. The codec sets the data rate. Opus, defined in IETF RFC 6716, scales from 6 kbit/s narrowband speech to very high quality stereo music at 510 kbit/s, and encodes frames of 2.5 to 60 ms, as of November 2026 (RFC 6716). For comparison, raw 16 kHz, 16-bit mono audio is 256 kbit/s, which is 16,000 samples per second times 16 bits. The Bluetooth SIG says its LE Audio codec, LC3, gives high quality even at low data rates, as of November 2026 (Bluetooth SIG, LE Audio). Pick the codec and sample rate your speech-to-text model expects, and test accuracy at that setting.
Direct Wi-Fi or cellular upload
A device that uploads on its own works without the phone. It pays with more power draw, a data plan for cellular, and more radio testing. Choose it when users will often be away from their phone.
What runs on the device and what runs in the cloud?
A typical AI wearable splits the work. Small, always-on tasks stay on the device. Large models run in the cloud or on the phone.
| Task | On the device | In the cloud | What decides it |
|---|---|---|---|
| Record button, wake word | On the device. Espressif describes WakeNet as built for low-power embedded MCUs, with up to 5 wake words. | Nothing, unless a server checks the trigger again. | It must work with no link. |
| Voice activity and noise reduction | Usually on the device, so silence is not sent. | Optional cleanup. | Processor headroom and power. |
| Encoding and encryption | On the device. | Decrypt and decode at your endpoint. | Bitrate, link capacity and who holds the keys. |
| Speech to text | Possible for short commands or with a larger chip. | Common for long recordings and many languages. | Accuracy, memory, and whether audio may leave the device. |
| Summaries, answers, memory | Small models only, with a Linux-class chip or a phone. | Where large language models usually run. | Latency, cost per request and retention terms. |
| Long-term storage | A buffer until upload, then deleted on a schedule you set. | In the client cloud account, with a retention policy. | What you promise users about deletion. |
WakeNet details from the Espressif ESP-SR documentation, which lists 16 kHz, mono, signed 16-bit input with a 30 ms window, as of November 2026. The page gives no false-trigger or recognition-rate figures, so measure those on your own hardware.
Each task you move to the cloud adds a hop where audio can be stored or logged under another company's terms. Each task you keep on the device adds memory and power. For the model choice itself, see cloud LLM or on-device small model for a wearable.
How do you build privacy and consent into the hardware?
A wearable records people who did not buy it. Consent therefore has to be visible in the hardware, so that someone nearby can tell when the device is listening. The federal wiretap statute permits interception by a party to the conversation, or where one party has given prior consent, unless the purpose is a criminal or tortious act, as of November 2026 (18 U.S.C. 2511(2)(d)). The same sentence refers to the laws of any State, and state laws differ. Some states, such as California, require the consent of all parties to record a confidential communication, as of November 2026 (California Penal Code 632). Check each state where you will sell, with counsel.
| Design choice | Why it matters | How to verify it |
|---|---|---|
| Physical record control | The wearer starts and stops capture on purpose. | Pull the battery during a recording and check the file and state after power returns. |
| Recording light driven by the capture state | People nearby can see that the device is recording. A light only the wearer sees tells them nothing. | Test every path that starts the mic: button, wake word, app command, update. Check the light in daylight at speaking distance. |
| Push-to-record as the default | An always-listening mode keeps the mic on and raises the consent question for every conversation. | Document the default in the product spec and in the setup screens. |
| Short on-device retention | Less stored audio means less to lose if the device is lost. | Confirm deletion after a confirmed upload, and encrypt what stays on flash. |
| Keys and cloud region chosen by the client | The company selling the device decides where audio lives and who can decrypt it. | Trace one recording from mic to storage and list every service that touches it. |
These are engineering practices, and none is a legal safe harbor. Our article on mic kill switches versus software mute compares the two controls. For the full recording-device picture, see our AI recording wearable development page.
What should you check before you build one?
Two rule sets reach every AI wearable with a radio and a battery. Plan for both from the first design review.
Battery and shipping rules
US hazardous materials rules say each lithium cell or battery must be of a type proven to meet the criteria in part III, sub-section 38.3 of the UN Manual of Tests and Criteria, as of November 2026 (49 CFR 173.185(a)(1)). Paragraph (e) exempts prototypes shipped for testing and low production runs of up to 100 cells or batteries per year from the testing and record keeping requirements of paragraph (a). It sets packaging conditions instead, and paragraph (e)(7) bars those shipments from passenger-carrying aircraft and allows cargo-only aircraft only with prior approval from the PHMSA Associate Administrator. Our guide to shipping lithium battery device samples by air covers the options. Ask your cell supplier for its UN 38.3 records early. Buyers may also ask about IEC 62133-2, a paid standard; read its current edition with your lab.
Radio rules
FCC rules define an intentional radiator as a device that intentionally generates and emits radio frequency energy by radiation or induction, as of November 2026 (47 CFR 15.3). A wearable with Bluetooth, Wi-Fi or cellular is one. The same section separately defines an unintentional radiator, which generates radio frequency energy for use within the device but is not intended to emit it by radiation or induction. Ask your lab which rules apply to each part of the design. Decide early whether you use a pre-certified radio module or a chip-down design, because that choice shapes the test plan and the enclosure.
Questions for your hardware team
Take this list to your team or to any development partner.
- Where does each recording go, hop by hop, and which company operates each hop?
- Which of those hops can decrypt the audio, and who holds the keys?
- What starts the microphone, and does every one of those paths turn on the recording light?
- What still works when the phone or network is gone?
- How many hours of audio can the device buffer, at which codec and bitrate?
- Which battery cell is used, and does the cell supplier have UN 38.3 test records for it?
- Is the radio a pre-certified module or a chip-down design?
Questions about wearable AI devices
Do wearable AI devices record all the time?
It depends on the design. Push-to-record devices capture only after a button press. Wake-word devices keep a mic and detector running and record after the trigger. Some capture everything. Each mode changes battery life and the consent question, so choose the default on purpose and show it with a light.
Does an AI wearable need a phone?
Many designs send audio over Bluetooth LE to a phone app, which uploads it. Others add Wi-Fi or cellular. A direct link adds power draw, cost and radio testing.
Is it legal to record conversations with an AI wearable?
Federal law allows recording by a party to the conversation, or with one party's prior consent, unless the purpose is criminal or tortious, as of November 2026 (18 U.S.C. 2511(2)(d)). State laws differ, so check each state with counsel. This is not legal advice.
Can the AI model run fully on the wearable?
Small tasks can. A wake word engine such as Espressif WakeNet runs on a microcontroller, as of November 2026 (ESP-SR docs). Large language models usually run in the cloud or on a phone.
How could Duobay help with a wearable AI device?
Duobay develops custom AI hardware for US companies: electronics, firmware, enclosure and samples, with an optional app and backend in your own cloud account. You can exit at any gate, and you own the source files at every paid gate. Recording products default to a visible recording light. Tell us about your device.
If you are planning a wearable AI device and want the parts, data path and consent design worked out before tooling, tell us about your device.
Sources
All pages accessed November 5, 2026. Re-read them before you rely on any figure.
- Infineon, IM69D130 MEMS microphone datasheet, v1.0: https://www.infineon.com/dgdl/Infineon-IM69D130-DataSheet-v01_00-EN.pdf?fileId=5546d462602a9dc801607a0e46511a2e (accessed 2026-11-05)
- Espressif, ESP32-S3 product page: https://www.espressif.com/en/products/socs/esp32-s3 (accessed 2026-11-05)
- Texas Instruments, CC2340R5 product page: https://www.ti.com/product/CC2340R5 (accessed 2026-11-05)
- Espressif, ESP-SR WakeNet documentation: https://docs.espressif.com/projects/esp-sr/en/latest/esp32s3/wake_word_engine/README.html (accessed 2026-11-05)
- IETF, RFC 6716, Definition of the Opus Audio Codec: https://www.rfc-editor.org/rfc/rfc6716 (accessed 2026-11-05)
- Bluetooth SIG, LE Audio: https://www.bluetooth.com/learn-about-bluetooth/recent-enhancements/le-audio/ (accessed 2026-11-05)
- 18 U.S.C. 2511, Cornell Legal Information Institute reproduction: https://www.law.cornell.edu/uscode/text/18/2511 (accessed 2026-11-05)
- 49 CFR 173.185, Electronic Code of Federal Regulations (eCFR): https://www.ecfr.gov/current/title-49/subtitle-B/chapter-I/subchapter-C/part-173/subpart-E/section-173.185 (accessed 2026-11-05)
- 47 CFR 15.3, Electronic Code of Federal Regulations (eCFR): https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15/subpart-A/section-15.3 (accessed 2026-11-05)
- California Penal Code 632, California Legislative Information: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=PEN§ionNum=632 (accessed 2026-11-05)
Planning an AI recording wearable? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →