要保护语音隐私，既要检查音频的处理路径，也要了解由它生成的文本最终去了哪里。
语音消息的转写和翻译可以在设备上完成，也可能依赖其他服务。因此，仅仅提供这些功能，并不意味着端到端加密遭到破坏。关键问题是：为了完成这项处理，谁或哪个系统能够访问可理解的内容？
原始音频文件、转写文本、译文和备份是四个不同的对象。保护了其中一个，并不能证明其余对象也受到保护。
区分三种处理路径
| 路径 | 信任边界 | 关键问题 |
|---|---|---|
| 完全本地处理 | 设备及运行处理任务的软件 | 音频或文本是否离开设备？ |
| 普通云端处理 | 处理服务及其基础设施 | 接收哪些内容，保留多久？ |
| 具有特殊保护措施的云端处理 | 所声称的设计、硬件及其验证机制 | 公开了哪些技术保障、评估结果和限制？ |
仅凭“在服务器上处理”这句话，无法确定运营方具体有哪些访问权限；有些方案会使用受保护的环境。反过来，“私密 AI”之类的名称本身也不是充分的证据。实际架构和使用条件必须清楚明确。
本地转写真的可行吗？
可以。WhatsApp 在语音消息转写功能的官方介绍中表示，文本是在设备上生成的。这个例子说明，不能把所有转写功能都视为云端处理；请检查自己所用版本的功能可用性、支持语言和设置。
在翻译方面，Google ML Kit 文档也介绍了设备端文本处理。语言模型可能需要先下载；下载模型需要联网，本身并不意味着待翻译的文本会被发送出去。翻译质量也应结合你使用的语言和场景来评估。
这些只是架构示例，并不能证明每个使用“本地”一词的应用都有相同的行为。
生成的文本会留在哪里？
即使处理在本地完成，输出也可能进入历史记录、设备搜索、通知、剪贴板或备份。评估一项功能时，不要只问“音频在哪里处理？”，还要问“新生成的文本存在哪里，谁能看到？”
如果把文本再发送给联系人，也需要单独检查这条发送路径。在处理完成后加密输出，并不能撤销某个服务此前已经访问过输入内容这一事实。同样，删除原始音频，也不保证删除了所有文本副本。
这是一幅概念图，并非经过验证的 Livara 语音处理路径技术图。
启用功能前，先问这六个问题
- 在哪里处理？ 在设备上、即时通讯服务的服务器上，还是由其他提供商处理？
- 发送哪些数据？ 完整音频、选定片段、文本，还是仅仅发送模型下载请求？
- 谁能访问？ 运营方、承包商、人工审核人员，还是仅限某个特定的技术环境？
- 保留政策是什么？ 输入或输出是否用于错误报告、模型改进或训练？用户有哪些选择？
- 如何删除和恢复输出？ 请分别检查历史记录、备份、已连接的设备和导出文件。
- 有哪些证据？ 标明版本的文档、独立评估和可复现的测试，比宣传性评分更有价值。
对于工作内容或他人的声音，还要检查是否取得同意，以及是否符合组织规定。获准收听一条语音，并不一定意味着获准把它交给任何其他处理服务。
如何在不泄露信息的情况下测试？
使用你自己为测试录制的非敏感音频文件。本地模型准备就绪后，功能能在离线状态下运行，可能是本地处理的一个迹象；但仅凭这一点，不能证明应用之后不会发送数据。离线状态下无法运行，也不能单独证明它会上传明文内容。
把观察结果与产品文档进行对照。如果答案不明确，就不要为敏感语音开启处理功能，或者只使用必要的非敏感部分。若要做更全面的判断，请参阅安全即时通讯应用选择清单。
关于 Livara，可以得出什么结论？
Livara 安全页面介绍了私密聊天中语音消息的保护方式。但不能据此判断是否存在转写功能、某项 AI 功能在哪里处理，或其保留政策是什么。如果你使用这样的功能，请单独查看该功能及相应版本的说明；本文不为它提供虚构的评分或测试结果。
此外，发送元数据，例如路由信息，与音频内容并不相同。语音内容保密，并不意味着通信完全匿名。
常见问题
转写会让原始消息的加密失效吗？
不会自动失效。本地处理可以在不把内容发送给中间方的情况下完成。如果你主动把内容交给其他服务，那么针对此次处理，信任范围就会扩大。
转写文本出错了怎么办？
涉及姓名、数字、敏感指令或重要决策时，不要只依赖自动生成的文本。条件允许时，请与原始音频核对，并向发送者确认；转写错误与加密是两回事。
离线可用能充分证明隐私得到保护吗？
不能。离线测试只是一项有限的观察，不能代替对后续发送、存储、设置和文档的检查。
