What Happens to Your Voice Data? How to Audit a Transcription App Yourself

Most people never check where their dictation goes. They read a privacy policy, see the word "encrypted," and assume the best. But a privacy policy describes intent, and network traffic describes behavior. If you dictate anything sensitive, you can check the behavior yourself in an afternoon.

This guide walks through a practical audit you can run on any Mac transcription app: what to watch, which tools to use, how to read what you see, and which questions to send the vendor when the traffic raises more questions than it answers.

Why Look at Network Behavior, Not Just the Policy

Privacy policies are written to cover many products and situations, so they often use flexible words such as "may," "temporarily," and "to improve our services." Those words are not necessarily evasive, but they do not tell you what a specific app does with a specific recording on your Mac.

Network behavior is more concrete. During a transcription session, an app either opens connections or it does not. If it does, you can see the destination hostname, roughly how much data leaves, and when. That will not tell you everything (you cannot see what a server does after it receives data), but it tells you whether audio or text leaves your machine during the step you care about.

Two kinds of traffic are worth separating:

• Content traffic: audio or transcript text sent to a speech or language service.
• Telemetry traffic: analytics, crash reports, update checks, and license checks. These usually carry much less data, but they can still describe how and when you use an app.

What a Cloud Transcription Request Typically Carries

When an app uses a cloud speech service, it has to send audio somewhere. The request usually travels over HTTPS and includes the audio itself, encoded in a compressed format, plus metadata the service needs to authenticate and route the request. A simplified, illustrative example looks like this:

```bash

# Illustrative example only, not captured from any specific product

curl -X POST https://api.transcription-vendor.example/v1/transcribe \

-H "Authorization: Bearer <token>" \

-H "Content-Type: audio/ogg" \

-H "X-Client-Version: <app version>" \

--data-binary @dictation_chunk.ogg

```

Notice what can ride along with the audio: an account token, a client version, and often a device or session identifier. Encryption in transit protects that request from people on your network. It does not change the fact that the provider receives the audio and decides how long to keep it.

Audio is also large compared with telemetry. Even compressed, a few seconds of speech produces far more data than a typical analytics event, which is what makes content traffic easy to spot in the steps below.

A Five-Step Audit You Can Run Today

You do not need a lab. Use a short test recording with no sensitive content, and run each step with the app idle first so you know its background behavior.

1. Watch sent bytes in Activity Monitor. Open Activity Monitor, choose the Network tab, and find the app's process. Note its "Sent Bytes," start a dictation, speak for thirty seconds, and check again. A jump of hundreds of kilobytes or more during dictation suggests that something sizable, possibly audio, is leaving the machine; the later steps help confirm what. A flat line during transcription is a good sign.

2. Watch connections in Terminal. Run `nettop -p <process name>` or `lsof -i -P | grep <process name>` while you dictate. These built-in commands show which remote hosts the app is talking to. Note every hostname you do not recognize.

3. Watch DNS lookups. Run `sudo tcpdump -i en0 port 53 -l` before you start dictating (use your active network interface if it is not en0). Lookups for speech, analytics, or content-delivery domains during the session tell you which services the app contacts.

4. Block outbound traffic and see what breaks. Install an outbound firewall such as Little Snitch or LuLu. Deny the app's network access, then try to dictate. If transcription still works, the app can transcribe locally. That does not prove it stays local when the network is available, since some apps use a cloud service when they can and fall back to a local model offline, so pair this test with steps 1 to 3 run while connected. If transcription fails, the app depends on a network service for that step.

5. Inspect payloads with a proxy (optional). Tools such as mitmproxy or Charles Proxy can show request sizes and headers. Many apps use certificate pinning, which prevents interception; that is a security feature, not evidence of wrongdoing. Use steps 1 to 4 when a proxy cannot see inside the traffic.

Reading What You Find

Interpret results conservatively.

No meaningful connections during transcription while online, and transcription works with the network blocked. Together, these strongly suggest the speech step runs on your Mac. The vendor's documentation should say the same. Check separately where the finished text goes: sync services, integrations, or a cloud AI feature you might have turned on.

Large outbound transfers to a speech or AI domain during dictation. This shows that data left your Mac while you spoke, and the size and timing make audio or text a likely candidate, but traffic volume alone cannot prove what the payload contained. Confirm with step 4: if transcription stops working when the app's network access is blocked, the app depends on a remote service for that step. Then ask the vendor what it sends, and read the provider's retention and training terms before using it for sensitive content.

Small connections to analytics or crash-reporting domains. This is telemetry. It may not include audio, but it can include usage details. Check whether the app lets you turn it off.

Connections you cannot identify. Look up the domain owner, then ask the vendor. A good vendor can tell you which service each domain belongs to.

Retention, Sub-Processors, and Your Obligations

Network behavior tells you whether data leaves. Contracts and policies tell you what happens next. Three questions matter most.

How long is audio kept? Look for a retention period stated in days, not just "temporarily." Ask whether backups follow the same schedule.

Is my data used to train or improve models? Some providers let you choose. Wispr Flow's privacy page, for example, says users decide whether their dictation data can be used to train or improve its models.^[1] Check the default and how to change it.

Who else processes it? Under the GDPR, a processor "shall not engage another processor without prior specific or general written authorisation of the controller."^[2] Under HIPAA, a business associate is a party that "creates, receives, maintains, or transmits protected health information" on behalf of a covered entity,^[3] and a covered entity must document satisfactory assurances from a business associate "through a written contract or other written agreement."^[4] If you handle personal or health data, a transcription vendor that receives your audio falls into these categories, and so may the services it relies on.

How Local Transcription Changes the Audit

The architectural difference is simple. A cloud app records audio, sends it to a remote service, and receives text. A local app loads a speech model on your Mac and produces text without sending the audio anywhere for that step.

That makes the audit easier, because there is less to trace. If an app transcribes with its network access blocked, and shows no audio-sized transfers while connected, you have direct evidence for the local claim rather than only a promise. You still need to check the rest of the workflow: where transcripts are saved, whether a sync service copies them, whether you have enabled any cloud AI feature, and what update or license checks the app makes.

Auditory runs speech recognition on the Mac, and after you install the models you want to use, it can transcribe without an active internet connection. Run steps 1 to 4 above on it, or on any app you are considering, to check the behavior yourself, both offline and while connected.

Frequently Asked Questions

Does encryption protect my audio during cloud transcription?

TLS protects audio in transit between your Mac and the server. It does not control what happens after the server receives it, including retention, internal access, and sub-processors. Encryption in transit is necessary but not sufficient.

Can I use cloud transcription and still meet HIPAA requirements?

A covered entity that lets a vendor handle protected health information needs a business associate agreement with that vendor.^[4] Many consumer transcription apps do not offer one. Check before dictating any patient information.

How accurate is on-device transcription compared with cloud services?

It depends on the model, your hardware, your audio, and the cloud service. The only reliable comparison is your own: run the same recording through both and count corrections. Our guide to measuring word error rate shows how.

Will an outbound firewall break other features?

It can. Update checks, license activation, and cloud features need network access. Block the app only for the test, then restore the access you need.

Making the Switch: What to Demand From Your Transcription Stack

Cloud transcription can be reasonable for non-sensitive content when you have read the provider's retention and training terms. For medical, legal, financial, or source-protected material, a local speech step removes one party from the chain.

Before adopting any transcription tool, ask:

• Where does my audio go during processing? Accept "it stays on your device" or a specific, named service and region.
• Who are your sub-processors? Ask for a written, current list.
• What is your retention period? Ask for days, not adjectives.
• Can I delete stored audio and metadata on demand? Ask for the documented process.

The metric to start tracking this week is simple: outbound connections during a transcription session. Run step 2 during your next dictation. If the answer is more than zero, you now know which services to ask about. For a broader look at how local and cloud processing differ for sensitive work, read our article on where cloud transcription liability sits.

References

[1] Wispr Flow, Privacy. https://wisprflow.ai/privacy

[2] GDPR Article 28, Processor. https://gdpr-info.eu/art-28-gdpr/

[3] 45 CFR 160.103, Definitions (Cornell Legal Information Institute). https://www.law.cornell.edu/cfr/text/45/160.103

[4] 45 CFR 164.502, Uses and disclosures of protected health information (Cornell Legal Information Institute). https://www.law.cornell.edu/cfr/text/45/164.502

[5] GDPR Article 83, General conditions for imposing administrative fines. https://gdpr-info.eu/art-83-gdpr/

[6] 45 CFR 164.404, Notification to individuals (Cornell Legal Information Institute). https://www.law.cornell.edu/cfr/text/45/164.404