Does Dictate store my audio?

No. Audio frames are relayed frame-by-frame to the recognition model and are never decoded, recorded or written to disk. Only usage metadata is persisted.

What metadata do you keep?

Session id, audio duration in milliseconds, frame count, sample rate, upstream key id and timestamps. This is the minimum needed to enforce quota and investigate abuse.

Do you train models on my audio or transcripts?

No. Neither audio nor transcripts are used for training.

Speech-to-Text Privacy: What Actually Gets Stored

"We do not store your audio" is a claim every speech-to-text vendor makes, and most of them mean something slightly different. Here is what it means here, what is still kept, and what to ask any provider before you send a client's voice over the wire.

Dictate Team 2026-10-12 6 min read Questions? Contact us

Audio is not the only thing that can identify someone

Start by being precise about what the promise covers. Voice recordings are biometric-adjacent data in most jurisdictions, which is exactly why the audio is the thing worth being strict about. But a transcript can be just as identifying: names, addresses, account numbers and medical details come out of speech all the time.

So a credible privacy claim has to cover both the audio and the text, and it has to say what happens to each one. Here is the short version for Dictate, and then the general framework for evaluating anyone else.

What Dictate does with audio

Nothing durable. The flow is:

You send a binary audio frame of 100-200 ms.
Dictate assigns the upstream sequence number and forwards the bytes to the recognition model.
Recognition text comes back and is relayed to you.
When the session closes, the audio is gone. It was never decoded into a buffer, never written to disk, never recorded.

There is no queue of pending recordings, no failed-session retry pile, no "temporary" file with a cleanup job behind it. The claim is easy to keep true because the system is built so that there is nowhere for audio to accumulate.

What Dictate does keep, and why

Usage metadata, because quota billing is impossible without it:

session_id        duration_ms      frame_count
sample_rate       upstream_key_id  created_at / updated_at

duration_ms is the billing unit. It is summed per billing period and compared against the plan's included time.
frame_count lets us reconcile relayed bytes against billed duration, which is how a client that under-reports gets caught.
session_id ties a websocket session to its usage row.
created_at / updated_at are needed to reset quota at the period boundary and to answer support tickets.

None of this contains content. No transcript text, no audio, no filenames. You can read the full list in the Privacy Policy.

Training: a separate question from storage

"We do not store your data" and "we do not train on your data" are different promises, and a provider can honour the first while quietly violating the second. Training does not require permanent storage - a dataset can be used, then deleted.

For Dictate, neither your audio nor your transcripts are used for training, by us or as part of any arrangement with the recognition provider. This is stated separately in the Terms of Service so it does not have to be inferred from the retention policy.

The upstream model is a third party - plan for it

Dictate relays to the Volcano Engine Doubao streaming speech recognition model (bigmodel) through the Volcano Engine Open Speech Platform. Your audio reaches that model in order to be transcribed. If you have contractual obligations that require knowing your sub-processors, that chain is part of your answer - it is disclosed in the Privacy Policy and covered by the Data Processing Addendum for business customers.

The honest framing: a relay removes your need to hold a billable credential and removes the storage surface on your side. It does not make the recognition model disappear. If your compliance regime forbids a particular sub-processor, a relay is the wrong abstraction and you want a direct integration instead.

Six questions to ask any speech-to-text vendor

Use this list on the call, including with us.

Is audio written to disk in any state, including error and retry paths? "Only on failure" is still storage.
What exactly is persisted about a session? Ask for the field list. If transcript text is stored, you need a retention period and a deletion path.
Is my audio or transcript used for training, yours or a sub-processor's? Ask for it in the contract, not in the privacy policy prose.
Who are the sub-processors, and how do I get notified when that list changes?
Who is the data controller and who is the processor? This determines who answers a data subject access request, and it is the question most often left ambiguous.
Can I get a DPA, and does it survive a model or provider change? A promise in marketing copy does not survive a re-architecture; a clause might.

What you still have to do yourself

No vendor can do this part for you:

Tell your users. If your app transcribes microphone input, say so, before the first frame, not in a policy nobody reads.
Get consent where you need it. Recording other people - call participants, meeting attendees - is your legal obligation, not the vendor's.
Enforce the acceptable-use boundary. Transcription is dual-use. The Acceptable Use Policy covers the six prohibited categories, how to report at report@dictate.top, response timelines and the appeal route.
Know your data residency. Where the underlying model is hosted determines where your audio physically transits. Ask.

Summary

Dictate relays audio frame-by-frame and never writes it down. It persists usage metadata - session id, duration, frame count, sample rate, key id, timestamps - because quota cannot be billed without it, and that metadata contains no content. Nothing is used for training. The recognition model itself is a named third party, and that disclosure is deliberate rather than buried.