Local vs cloud speech recognition: choose by data flow

“Local” and “cloud” are not accuracy tiers. They are different data paths and failure paths. A privacy review should begin by drawing where audio, text, and synthesized speech travel.

Draw the whole path

Mark at least:

1. where raw microphone audio is captured;
2. where ASR executes;
3. where recognised text is translated;
4. where TTS and voice cloning execute;
5. which logs, usage records, and role settings are stored;
6. who can access each system.

Local ASR changes only item two. If translation and cloned-voice synthesis remain online, calling the whole workflow “offline live translation” is inaccurate.

ObsTrans offers local, Google, and online real-time recognition paths, subject to current edition and entitlement; local operation requires the model to be downloaded. The product privacy notice states that local recognition processes speech locally without uploading it, while speech/text used for translation and samples used for voice cloning are processed for those functions. Describe the path you actually enable, not the label on one selector.

Read cloud defaults and opt-ins separately

Google Cloud Speech-to-Text’s official data usage FAQ says streaming and synchronous endpoints process audio in memory and do not store customer data when the project is not enrolled in data logging. It describes separate temporary transcript storage for asynchronous recognition. Google’s data logging page says audio and transcripts are not logged by default, but a project can opt in.

Azure Speech’s privacy and security documentation says real-time speech-to-text processes audio in server memory without storage at rest, while batch transcription uses customer-specified storage for input and output.

Those facts describe the cloud services themselves. If a desktop application relays audio through its own backend, that middle layer needs its own review. A hyperscaler policy cannot substitute for the product policy.

Four decision dimensions

Dimension	Local recognition	Cloud recognition
Data boundary	Raw speech can remain on device	Raw speech must be transmitted
Dependency	Models, drivers, CPU and memory	Network, account and service availability
Updating	Client controls model delivery	Service can update centrally
Audit focus	Local logs, caches, model files	Transit, region, retention and subprocessors

The table does not declare a winner. A production machine already running OBS, browsers, and effects may face local contention; an unstable network may make cloud recognition the dominant risk. Use the same recording and session length from the tool evaluation protocol.

A minimum privacy questionnaire

Ask the product or service owner:

• Is real-time audio written to storage?
• How long are text, errors, and request metadata retained?
• Is training or enhanced logging opt-in?
• Which services and regions process the data?
• How are voice samples and settings deleted after account closure?
• Does a local model require online authorization?
• Can diagnostic logs contain source or translated text?

Mark unpublished answers as unknown. Do not convert silence into “not stored.”

Choose by content class

Public product explanation may prioritise quality and operational stability. Unreleased products, supplier meetings, or sessions containing customer personal information deserve a tighter boundary. Classify content and specify allowed recognition routes per class instead of forcing one company-wide answer.

Multiple engines in ObsTrans make that technical choice possible. They do not replace notice, consent, internal access control, or jurisdiction-specific legal review.

A fallback is part of the choice

For local operation, test model readiness, cold start, and full-session resource use. For cloud operation, test network loss, reauthentication, and recovery. A route that is private or accurate but has no tested failure path is not production-ready.