An On-Device Speech Pipeline That Discards Audio

Speech data is the hardest category of personal information to protect, and most companies building voice features get the architecture wrong before they write a line of privacy policy. I've spent the better part of a decade around speech pipelines, first at a company doing wake-word detection for a smart speaker nobody's heard of anymore, and the lesson that stuck with me is boring but true: the privacy claim lives or dies at the microphone buffer. Get the signal path wrong and you end up shipping something recoverable while telling users it isn't. Get it right and you can say, with a straight face, that content never left the phone, and mean it.

Apple, Google, and a handful of smaller voice AI vendors have all built versions of this pipeline, for wake-word detection, on-device dictation, Live Translate, Recorder's summarization. The engineering converges across companies because the constraints are identical: limited compute, a battery that customers actually notice draining, a signal that's both high-bandwidth and deeply personal, and a legal department that gets nervous every time "audio" and "server" appear in the same sentence.

The signal path, stage by stage

Raw PCM audio at 16kHz mono, the standard rate for speech processing, runs about 32 kilobytes per second per channel. Small by any modern storage measure, but also the single most dangerous artifact in the whole chain, because raw audio inverts cleanly back into a waveform a human being can listen to and recognize. Everything downstream should get progressively harder to reverse, and the whole point of the design is to move from recoverable to not-recoverable as early as the architecture allows.

The first real checkpoint is feature extraction, usually a mel-filterbank or MFCC transform, sometimes a learned front-end in newer models. It's lossy on purpose. Phase information gets thrown away, and the frequency spectrum gets compressed into something tuned for phonetic discrimination rather than fidelity. A lot of teams treat this transform as the privacy boundary, which understates the risk: neural vocoders can partially invert mel-spectrograms back toward intelligible speech; I've seen demos of this that are uncomfortably good. The real boundary sits a layer or two deeper, after the acoustic encoder has folded the features into a hidden representation built for one narrow task, keyword spotting, intent classification, something that was never optimized to reconstruct general audio in the first place.

Once you're past that hidden representation, transcription should happen entirely on-device, using something like Apple's on-device Siri recognizer or Google's on-device Gboard dictation, both of which lean on compact conformer or RNN-transducer models that fit in a few hundred megabytes and run comfortably inside a phone's neural processing unit power budget. The transcript is the second most dangerous artifact in the pipeline, arguably worse than raw audio in aggregate, because it's directly searchable. So the same rule applies again: don't let it outlive the task, and don't let it leave the device unless the user asked for something, cloud search indexing, say, that genuinely requires it.

What's actually safe to transmit

Most speech features eventually need to do something with the text: pull an intent, fill a slot, write a summary, fire off an action. This is the point where a team has to decide what, if anything, crosses the device boundary. And this is also where I've watched otherwise careful engineers talk themselves into a bad decision.

The tempting move is a semantic embedding, stripped of lexical content, a fixed-length vector that's supposed to carry intent without carrying the words. It sounds clean, but sentence embedding models built on architectures like BERT or Sentence-T5 were never designed to resist inversion, and academic work on embedding inversion attacks has shown you can reconstruct large chunks of the original text from the vector alone, especially for short utterances, if you have access to the embedding model itself. "We only send embeddings" is a claim that needs footnotes, defensible only if the embedding model has actually been evaluated for inversion resistance, or if you're injecting differential privacy noise at generation time, which buys you a bounded guarantee at the cost of some accuracy.

The safer path, and the one Apple has described publicly for things like Siri suggestions and proactive intelligence, is to send nothing at all: open the app, set the timer, draft the reply, all inside local context that never touches a socket. When server compute is genuinely required, an LLM summarizing a long voice memo, something too heavy for the NPU, the design question shifts to what partial signal makes the trip. A task category, a duration estimate, a confidence score. That leaks a fraction of what continuous text or audio would.

Proving a negative

Claiming nothing left the phone is the easy part. Proving it is where the actual work is, and it's where most companies' marketing quietly stops matching their engineering.

Three methods exist to demonstrate this, and none of them work in isolation. The first is network traffic analysis, done internally as QA or externally by researchers who reverse-engineer the app. Apple has lived under exactly this kind of scrutiny for years; independent researchers have used Wireshark and mitmproxy to capture what Siri and dictation actually send over the wire, and the fact that this kind of audit is even possible is itself part of what makes the trust claim credible. If a company's story doesn't survive a packet capture, the story is false. There's no softer way to put that.

The second is a code audit, static and dynamic both, someone checking that the code path handling audio never calls a networking function. Harder to do credibly from outside a company, since compiled binaries can be obfuscated and this takes real reverse-engineering skill, but it's exactly the kind of engagement third-party security firms get hired for now, especially after 2019, when it came out that contractors were listening to snippets of Siri and Alexa recordings for quality review. Apple and Amazon both changed the practice after the public reaction, which tells you something about how these audits actually move behavior.

The third method is the one almost nobody bothers with: hardware-level attestation, cryptographic proof that a specific signed build ran on the device and that the sandboxed process handling audio had zero network entitlement at the OS level. iOS's App Sandbox already makes this technically enforceable; an app without network entitlement literally cannot open a socket, no matter what the code claims to do. Making that enforcement visible and checkable to a skeptical outsider, instead of asking everyone to just trust Apple's word for it, remains unsolved.

Why this is harder than it looks

None of this comes free. On-device ASR models are smaller and less accurate than their cloud counterparts, full stop; published comparisons consistently show a gap in word error rate, worse in noisy rooms, worse for accented speech, though the gap has closed a lot as phone NPUs got faster and compression tricks like quantization and distillation matured. There's a real cost to going fully local. Anyone telling you on-device performance now matches cloud performance across every condition is selling something.

There's a second, quieter problem hiding inside the phrase "we discard it." Discarding audio after processing does nothing about the buffering that happens before processing. Most pipelines keep a rolling few seconds of raw audio in memory just to catch wake words or handle false starts, and that buffer, brief as it is, sits in RAM as a raw audio artifact, exposed to anything with sufficient memory access on a compromised device. I don't think most privacy write-ups even mention this. A serious design has to say exactly how long that buffer lives, whether it's encrypted at rest in memory, and whether it survives a crash dump, because crash logs have quietly been one of the worst leak vectors in this entire space for years.

"On-device" doesn't guarantee "never transmitted," and conflating the two is where marketing copy gets loose. A feature can run entirely on-device and still ship a transcript, a summary, or some derived signal afterward, the processing claim and the transmission claim are separate promises. A privacy claim worth trusting has to specify, stage by stage, exactly where processing happens and exactly what, if anything, crosses the network. Anything less reassures people without actually surviving an audit.

The standard this sets

Speech might be the most re-identifiable, most revealing data type a phone collects, arguably more exposing than location history, since tone and word choice and content together give away health status, mood, relationships, in ways a GPS trace never does. Building a pipeline that actually discards audio and transcripts, and can defend that claim under hostile inspection, is achievable with hardware that already exists. Apple, Google, and smaller players building on models like Whisper have all shown pieces of this running in production, at scale, today.

The difference between the companies that get this right and the ones that don't shows up the second somebody opens Wireshark.