On-device AI and cloud AI: where your voice notes go

On-device AI processes your data using models that run on your phone's own hardware, so the content never leaves it. Cloud AI sends your data to a server for processing. Most apps use a mix of the two, and almost none explain where the boundary sits.

This matters more for voice than for anything else you do on a phone. A voice note is not a sentence. It is your voice, the acoustics of the room, whoever else was talking, the twelve seconds of throat clearing before you got to the point, and the thing you said and then decided not to keep.

Text you can proofread. Audio captures what you did not mean to say.

One sentence, four separate steps

You tap a microphone and say: remind me to call the clinic about the results on Tuesday morning. It feels like one action. It is four, and each can run locally or remotely, independently of the others.

An app can transcribe locally and interpret in the cloud. It can do the reverse. It can send both away and still describe itself as private, quite truthfully, because the finished task ends up stored on your phone.

So the useful question is never does this app use AI. It is which of these four steps leave my phone, and what exactly is in the payload when they do.

What actually gets sent

This is where the detail matters, because the three common routes have very different exposure.

The middle row is worth dwelling on, because it is the most common design and the least understood. Your voice never leaves, which genuinely matters. But the transcript often travels with context so the model can resolve references, and that context can include the note you currently have open or the name of the project you are in.

An app that sends context should be able to tell you what is in it. If it cannot, nobody has thought carefully about the answer.

What on-device buys you

When transcription and interpretation both run locally, the audio and the text never exist on anyone else's hardware. There is no server log, no retention window, no subprocessor agreement, and no breach surface, because there is nothing at the other end to breach.

It also means the feature works on a plane, on the Underground, and in a country where you would rather not push your calendar through an unfamiliar network.

Apple has moved a lot of this capability onto the device. Speech recognition and small language models now run locally on supported iPhones, which is what turned a fully on-device path from an aspiration into something an app can actually ship.

What on-device costs

Being straight about the trade is part of the argument.

• Hardware floor. On-device models need recent silicon. Older iPhones cannot run them at all.
• Language coverage. Local models support far fewer languages than large server models, and support arrives unevenly.
• Capability ceiling. A model small enough to fit on a phone is less capable than one running on a rack of GPUs. Unusual phrasing is where you feel it.
• Storage and setup. Local models take space and often need a one-time download that can fail on a bad connection.
• Battery and heat. Sustained local inference costs more power than shipping a request to a server.

This is why nearly every app keeps a server path available. Keeping one is reasonable engineering. The question is whether the app tells you when it takes that path, or switches silently and lets you assume the best.

How to test an app yourself

You cannot read the source, but three checks get you most of the way.

Run it in Airplane Mode

Turn the network off and use the voice feature. Full success means both transcription and interpretation are local. Total failure means at least one stage needs a server.

Partial success is the interesting result. If your words appear as text but nothing becomes a task, you have found the boundary precisely: local speech, remote interpretation.

Read the Audio Data line on the label

Apple's privacy labels have a specific category for Audio Data and another for Other User Content. An app that uploads recordings is required to declare the first.

A voice-first app declaring neither is either fully on device or has filed carelessly. Either way you have learned something, and the Airplane Mode test will tell you which.

Look for named subprocessors

A privacy policy that names the specific companies in the chain is a much stronger signal than one referring to trusted partners. Naming a subprocessor is a commitment somebody can be held to. Trusted partners is a phrase that survives any change of vendor without an update.

How Clarity handles voice

On a supported Apple Intelligence iPhone with a supported language, both transcription and interpretation run entirely on device. Nothing is transmitted, and the feature keeps working with the network off.

When a local stage is unavailable, Clarity uses a disclosed fallback for that stage only, and only for a voice action you started. If local speech works but local interpretation does not, your audio stays on the phone and only the transcript travels. That is the middle row of the table above, and we would rather name it than let you assume the best case.

There is no background listening, no wake word, and no always-on microphone. Voice starts when you tap the microphone and stops when you tap stop.

The short version

Ask which of the four steps leave your phone. Test it with the network off. Read the Audio Data line. Check whether the policy names names.

An app that can answer all four clearly has thought about the problem. An app that answers none of them has probably not, and the marketing page is unlikely to be where you find out.