Guide
Usually yes, and the app is often vague about it, because "we take your privacy seriously" is easier to write than describing where the bytes go.
There are only three architectures. Once you can name them you can work out which one you are using in about two minutes, and the answer decides whether dictating anything sensitive is reasonable.
The model runs on your machine. Audio never leaves the device. Nothing to intercept, nothing to subpoena, works on a plane.
The tradeoff is real: local models are slower and less accurate than the hosted ones, and the good ones want several gigabytes of RAM. For quick notes this is fine. For long technical dictation with unusual vocabulary, most people notice the accuracy gap.
Audio goes from your machine straight to a transcription provider you chose, authenticated as you. The app vendor is not in the path at all. You get hosted accuracy and speed, and the only party who sees the audio is the provider whose terms you accepted directly.
This is usually the best real-world balance, and it has a property the others do not: the vendor cannot see your audio even if they want to, because it never reaches them. That is an architectural fact rather than a policy promise.
You talk, the app uploads the audio to the vendor's backend, the backend calls a provider, the text comes back. This is how most subscription dictation apps work, because it is how they bill you and how they keep the API key secret from you.
It is not automatically bad. It is just the one where a privacy claim rests entirely on trust, because your audio genuinely did land on someone else's machine, and you cannot verify what happened next.
Four checks, roughly in order of how quickly they settle it:
lsof -i while dictating, and look at who it connects to. A provider domain means category 2. The vendor's own domain means category 3.The gap to watch for: some apps are category 2 when you supply a key and quietly fall back to category 3 when you do not. The privacy page describes the first case. Users who never pasted a key are living in the second. If a tool works before you have configured anything, assume your audio is going through the vendor until you can prove otherwise.
It is a narrower promise than it sounds, and it is usually true in a technical sense that misses the point.
Storing and receiving are different things. Audio can be uploaded, held in memory or a temp file, sent onward to a provider, and deleted, and every word of "we never store your recordings" remains accurate. It still transited a machine you do not control, was decrypted there, and was retained for as long as that request took.
The question worth asking is not "do you store it" but "does it reach you at all". Those have very different answers and only one of them is verifiable from the outside.
Most dictation is not sensitive. If you are dictating a grocery list, none of this is worth ten minutes of your attention.
It matters when the content is covered by an obligation you did not personally choose: client work under an NDA, anything touching health or financial records, code from a private repo, legal matters, and internal discussions at a company with a security policy. In those cases "the vendor probably deletes it" is not a defensible answer, and the architecture is the answer.
Category 2, and deliberately so. You paste your own Groq key and the audio goes from your machine straight to Groq, on your account. It never touches a VoiceForge server, so there is nothing on our side to leak, sell, or train on. There is also a fully local mode if you would rather nothing left the machine at all.
That is the reason the app asks you for a key instead of just working. It is a real cost in setup, about a minute, and it buys a claim we can make architecturally instead of asking you to believe it.
The 10 fixes, free. Privacy is where the audio goes. This is the other half: making what comes out worth keeping.
No other email, ever.