工具评测与对比约 5 分钟读完
“本地识别”和“云端识别”不是准确率高低的两个标签，而是两条不同的数据路径和故障路径。隐私评估的第一步不是问哪一个更安全，而是画出语音、文本和合成音频分别去了哪里。
先画完整数据流
至少标出：
- 麦克风原始音频在哪里采集；
- ASR 在本机还是服务端执行；
- 识别文本去哪里翻译；
- TTS 和声音克隆在哪里完成；
- 哪些日志、用量和角色配置被保存；
- 谁能访问这些系统。
本地 ASR 只改变第 2 项。若文本翻译和克隆音色仍需云端，它不能被写成“全离线直播翻译”。
ObsTrans/言播实际提供本地、Google 和在线实时等识别线路，具体可用项受会员和当前版本控制；本地模型需要先下载。正式产品隐私页说明，使用本地识别引擎时语音在本地完成识别、不上传服务器，同时翻译功能中的语音/文本与声音克隆样本会在相应功能中处理。选型必须按你实际开启的整条链路解释，不能只引用一个开关名称。
云端服务要看默认与可选项
Google Cloud Speech-to-Text 的数据使用 FAQ说明：未加入数据日志计划时，流式和同步端点在内存中处理音频，不存储客户数据；异步端点为了结果提取会暂存转写结果。另一个数据日志页面说明，默认不记录音频与转写，但项目可以主动加入数据日志计划。
Azure Speech 的隐私与安全说明则写明，实时语音转文字只在服务器内存处理，不静态存储；批量转写由客户指定音频与输出存储位置。
这些事实只描述对应云服务。若桌面软件先把音频传给自己的后端再转发，仍需单独核验中间层。不要用底层云厂商政策替代产品政策。
四个选择维度
| 维度 | 本地识别 | 云端识别 |
|---|---|---|
| 数据边界 | 原始语音可留在设备 | 原始语音需要传输到服务端 |
| 依赖 | 模型、驱动、本机 CPU/内存 | 网络、账号、服务可用性 |
| 更新 | 模型版本由客户端更新 | 服务可在云端更新 |
| 审计重点 | 本机日志、缓存、模型目录 | 传输、区域、保留、供应商链 |
这张表不宣布赢家。直播电脑已经同时跑 OBS、浏览器和特效时，本地识别可能增加资源竞争；网络质量差时，云端线路可能成为主要故障点。用工具验收流程对相同录音和相同时长做实测。
做一份最小隐私清单
向产品或服务提供方确认：
- 实时音频是否落盘；
- 文本、错误日志和请求元数据保存多久；
- 是否存在可选的数据训练/日志计划；
- 数据经过哪些服务商和区域；
- 账号注销后如何删除声音样本与配置；
- 本地模型是否需要联网授权；
- 故障日志是否包含原文或译文。
没有公开答案的项标“待确认”，不要自己补成“不会保存”。
按场景而不是全公司一刀切
公开商品讲解可以优先考虑质量和稳定性；未发布产品、供应链内部会议或含客户个人信息的环节应提高数据边界要求。最稳的做法是为内容分级，并为每级指定允许的识别线路。
ObsTrans 的多识别引擎让团队可以做这种选择，但它不能替代告知、授权、内部访问控制和当地法律评估。软件功能是技术选项，合规结论仍属于组织。
故障预案也属于选择
本地线路上线前要验证模型完整、首次启动和长时资源占用；云端线路要验证断网、重新登录和恢复行为。没有预案的“隐私更好”或“准确率更高”，都会在直播当天变成不可用。
常见问题
- 本地识别是不是等于整条翻译都离线？
- 不一定。本地 ASR 只说明语音转文字在设备上完成，后续文本翻译、TTS、登录和额度服务仍可能联网。必须按完整数据流核验。
- 云端识别一定会保存音频吗？
- 不能一概而论。Google 和 Azure 的实时服务官方文档都描述了特定默认处理方式，但第三方软件还可能经过自己的后端。应同时查看供应商与软件的隐私说明。
- 隐私要求高就一定选本地吗？
- 本地通常缩小语音传输范围，但还要考虑设备安全、日志、模型来源、翻译和合成是否上云，以及本机故障是否有可用替代线路。
关键词本地语音识别云端语音识别隐私直播翻译数据离线 ASR语音识别选型
