“私密 AI 处理”究竟承诺了什么？创始人的隐私承诺核对表

一位创始人准备上线 AI 会议助手。产品经同意录音、生成纪要，并记住决定，供下次会议调用。模型供应商说推理运行在机密计算环境里，于是团队在首页写下“隐私保护贯穿产品设计”。但有人追问：转写文本会进入客服日志吗？受邀嘉宾能看到系统记住的决定吗？用户删除会议后，记忆是否一并消失？团队答不上来。

本文面向把敏感上下文交给 AI 处理的创始人和小团队，尤其是涉及声音、图像、文档或跨会话记忆的产品。核心判断是：隐私承诺必须覆盖每一条数据路径，能被逐项验证；不能把某个基础设施组件的特性，直接当成整个产品的形容词。 读完你可以拿到六阶段数据路径、一则完整的会议助手案例、一张可复用的核对表、四项故障演练和上线决策规则。这套方法适用于常规产品设计与供应商审查；医疗、金融、儿童数据等受监管情境仍需专门的法律和安全评估。

写这篇文章的契机是 Meta 2026 年 9 月发布的 AI 眼镜 Private Processing 工程说明。它分别解释了机密虚拟机、客户端远程证明、防定向路由和加密长期记忆，适合用来拆解“私密”到底指什么。但它是 Meta 对自身设计的陈述，不等于每次部署都经过独立审计；小团队也无须照搬整套基础设施。我们要问的是：某个机制具体证明了什么、哪些环节仍在保护范围外，以及产品对用户说的话能否得到支撑。

先把承诺写成能被证伪的一句话

“私密”可能表示允许用户退出、员工看不到内容、供应商不拿数据训练、回答完成后服务器不留数据、其他用户无法检索、服务不知道是谁发起请求，或者内容从未离开设备。这些是不同的命题。合在一个宣传词里，反而掩盖了用户需要知道的区别。

写承诺时，至少写清五件事：谁、哪类数据、哪种操作、在哪个环节、持续多久。例如，“云端推理期间，我们的支持人员无法读取原始会议音频”，范围就比“你的会议完全私密”明确。前一句可以对照架构、权限、日志和测试环境检查。若想说“AI 供应商永远看不到内容”，所需的技术保证远高于“我们限制员工访问转写文本”。

美国联邦贸易委员会的企业隐私与安全指引指出，企业要兑现对隐私作出的承诺，并根据所持数据采取适当的安全措施。这是美国监管语境，不是全球通用的法律结论；产品上的启示则很直接：如果界面让用户相信存在广泛保护，单个环节的有限保证无法替代它。首页、引导页、同意弹窗、销售话术、帮助文档和保留设置，都属于同一承诺的展示面。

可为每句话建立一张“承诺卡”：原文、覆盖的数据、覆盖的操作、排除的路径、证据负责人、测试方法、上次复核日期。如果连排除路径都填不出，就应缩小措辞，而不是把模糊限定语藏在隐私政策里。无法证伪的承诺，通常也无法放心发布。

先画出技术边界，再使用技术术语

可信执行环境（TEE）是一种受保护的计算边界。基于相关硬件建立的机密虚拟机（CVM），旨在限制宿主软件和运维人员在处理过程中看到的数据。远程证明则是在客户端发送敏感内容前，让远端系统提交关于硬件及运行软件状态的证据。IETF RFC 9334区分“提供证据的设备”“核验者”和“依据结果作决定的一方”：拿到证明，与决定是否信任，并非同一件事。

Meta 称，眼镜客户端会核对硬件签名和软件度量值，并与公开账本比对；校验失败就不发送上下文。它还描述了数据在机密虚拟机内处理、长期记忆使用用户提供的密钥加密。Google Cloud 的远程证明文档也解释了如何核验机密环境和输出可供依赖方使用的声明。这些资料帮助我们理解机制，不能据此推断任何使用“机密虚拟机”的应用都已做到端到端私密处理。

真正要画的是明文第一次出现在哪里、之后又去了哪里。它可能先在设备上，接着进入转写服务、模型调用、TEE 内部、外部工具回调、纪要数据库，最后出现在收件人的浏览器。CVM 能保护其中一段，却不自动保护其他同样接触内容的环节。供应商的架构图应标出每处明文边界，而不只是最安全的那个框。

远程证明同样有适用范围：在信任根和核验程序正确的前提下，它能为某个时点的受测工作负载是否符合既定策略提供证据。它不能证明录音已经获得在场者同意、模型回答准确、所有集成都安全，或保留期限合理。把它当作特定技术声明的强证据，而不是“产品值得信任”的同义词。

沿六个阶段追踪敏感数据

每项敏感功能都走一遍六阶段：采集、路由、计算、保留、暴露、删除。采集阶段说明数据属于谁、谁授权处理。主持人同意转写，并不等于所有参会者都已同意。路由阶段查服务能否看到账号身份、来源 IP、请求时间、负载长度或内容。计算阶段列出每个处理方，以及明文受什么边界保护。

保留阶段列出原始输入、生成结果、向量表示、长期记忆、备份、诊断数据和第三方日志，并分别写保留期限。暴露阶段列出谁能检索、导出、分享结果，未来的智能体又能执行什么动作。删除阶段测试用户的控制是否在承诺时间内清除覆盖范围内的副本；例外要讲明。若界面写“删除这场会议”，但检索向量和衍生记忆仍在，承诺就未通过测试。

这也解释了 Meta 2025 年对 WhatsApp Private Processing 的说明与后来眼镜设计的侧重点不同。前者强调用户可选择是否使用，以及针对一次性请求的无状态消息处理；眼镜方案明确讨论跨会话调用的加密持久记忆。一次性处理可以在会话结束时停止接触数据；长期助手则必须额外设计状态的生命周期。把同一个“私密处理”名称直接套用到两种产品上，会遮住最重要的风险变化。

每个阶段都问两遍：什么被技术手段阻止了？什么只是靠政策或流程限制？运维人员在密码学意义上无法解开 CVM 内存，与员工虽有权限但按规定不得查看，是不同保证。两者都可能有价值，却应支持不同的措辞。如果产品靠合同约束模型供应商，就如实说明，不要暗示这属于密码学保证。

内容隐私之外，还有身份与元数据

即使负载加密，仍可能留下足以识别生活规律的痕迹：请求时间、来源地址、账号标识、存储键以及反复访问的记录。Meta 的眼镜文章明确提出这个问题：如果运营方能把请求关联到特定账号，就可能把该用户流量导向被攻陷的节点。其设计使用匿名凭证和 Oblivious HTTP 中继来降低这种关联。

IETF RFC 9458 定义的 Oblivious HTTP把能看到客户端网络身份的中继，与能处理加密请求的网关分开。保护效果取决于各方不会串通以及具体部署方式；时间、大小和应用层线索也不一定全部消失。创始人无须为了诚实而立即部署 OHTTP。但如果产品声称“匿名使用 AI”，就要查自己的账号系统、分析 SDK、支付系统和请求日志是否还能把提示词对应到某个人。

除了内容清单，再建一份元数据清单。对会议助手，核查会议开始时间、参与者标识、邀请链接、转写大小、模型 token 用量和被检索记忆的标题是否存储。某些数据可能确实用于计费、防滥用和保障稳定性。这说明要写清用途、期限和访问权限，并不意味着它们“不可见”。如果无法抵御针对性路由或身份关联，承诺就应限定在内容保护层面。

产品整体边界比单个协议更重要。meeting_summary_created 这样的分析事件或许无害；如果同时附上会议主题、参会者邮箱和完整纪要，就可能把受保护的推理路径重新暴露。审核首页文案前，应先检查分析事件字段和可观测性数据的去向。

长期记忆是一项新的产品权限

无状态回答在请求结束时结束；跨会话记忆则新增四项义务：决定什么可保存、何时可被召回、谁能触发召回、用户如何更正或删除。Meta 描述了持久结果离开受保护环境前用用户提供的密钥加密。这展示了限制基础设施运营方读取存储内容的一种方法，却不能回答某条记忆是否该存在、旁观者是否同意、模型是否应在下一场合透露它。

看一个虚构产品“Roomnote”。主持人让它总结团队会议。一位嘉宾谈到自己可能换工作。模型觉得这与项目人员配置有关，于是把“Alex 可能离职”提炼为长期记忆。几周后，另一位主持人问“之前讨论过哪些风险”，系统便把这条记忆调出。再完美的静态加密也挡不住这次泄露：问题发生在已获授权的工作流怎样使用信息。

Roomnote 需要一项独立于录音同意的“记忆权限”。可行的默认做法是：纪要保留在原会议的可见范围内；不自动把关于个人的推断提升为全局记忆；可复用的团队决定由负责人确认；条件允许时让受影响者看到系统存了什么。每条记忆标出来源、可见范围、失效时间、更正负责人和可信度。“下月上线新的结账流程”或许可以成为团队记忆；对个人去留的推断就应严格收窄。

Apple 的 Private Cloud Compute 安全指南把对个人数据的无状态处理列为核心要求。它提供了另一种设计目标：回答后不再让服务器访问数据，可以简化隐私承诺的一部分；需要长期记忆的助手，则必须另写状态生命周期。两种做法都不会自动解决同意或后续分享问题。

留下验证证据，同时避免日志泄密

隐私承诺必须经得起日常运维。团队需要排查故障、滥用和延迟，但如果原始敏感内容进入链路追踪，就又多出一条访问路径。设定“可观测性预算”：必需的指标是什么、哪些字段绝不能记录、何时才允许采样真实内容、临时例外由谁批准、多久自动失效。带有已知测试短语的合成转写，可帮助发现误记日志的问题，而无须使用真实客户内容。

证据要和承诺阶段对应。TEE 声明需要远程证明策略及失败测试；保留声明需要数据存储清单、删除测试和备份说明；访问声明需要角色核对及越权尝试；“不用于训练”需要供应商协议和账号配置检查；“无人查看”需要把客服与滥用处理路径写清。重复供应商的宣传语，不是验证。

Meta 描述了公开、由第三方见证的 CVM 镜像账本，并计划在安全研究计划下提供二进制文件与文档。Apple 的发布透明度文档也解释了类似原则：设备只接受度量值已写入只追加日志的软件，研究者可以检查版本。要分清两类证据：日志能帮助证明哪些代码被批准运行；要证明代码及周边产品行为都符合宽泛的隐私承诺，还需威胁建模和独立测试。

NIST 的隐私框架是自愿使用的风险管理工具，不是认证标章。对创始人的价值在于：先辨认数据处理活动、参与方和风险，再判断某个保护措施解决了什么问题。可以借用其“当前状态与目标状态”思路：如果今天的删除工作仍靠人工，就如实记录，让上线文案符合现状。

用 Roomnote 做一次完整核对

假设 Roomnote 先把音频送到云端语音转写 API，再把转写交给提供机密推理的 AI 服务，最后把纪要放进普通数据库，供共享工作区访问。团队想说“会议始终私密，连我们也看不到”。这句话甚至无需渗透测试就站不住：转写商可能收到原始音频，工作区管理员可能看到纪要，团队员工也可能有数据库权限。机密推理只覆盖其中一段。

把口号改成用户能理解、且可以验证的描述：“只有所选工作区的成员可以打开保存的纪要。我们把音频交给转写服务商，把转写交给 AI 服务商处理；纪要保留到有权限的工作区成员将其删除。”如果事实如此，这句话比一个笼统形容词更有用。若 AI 服务确实提供机密推理，可另加技术说明：它保护转写在哪个处理阶段，是否有独立远程证明。不要把说明放在使读者误以为音频和存储纪要也享有同等保证的位置。

接着演练故障。工程师为排查转写失败，开启一小时请求体日志。界面却仍写“只有工作区成员能访问会议内容”。如果运维人员能读到该日志，那么在这段时间承诺就是假的。发布流程应让矛盾显现：禁止生产环境开启该开关、改用脱敏的合成数据，或者先调整承诺并取得相应同意。这里需要的是产品决定，而不是寻找法律脚注。

再让客户删除一场会议。原始录音没了，但摘要向量仍留在检索索引，另一张表里的精选记忆也没删。若用户理解的“删除会议”包含这些衍生数据，删除测试就必须判失败。要么实现关联删除，要么把界面措辞缩小，并清楚提供单独删除记忆的选择。请未参与实现的人解释按钮含义；团队内部的数据模型不能替用户决定他理解了什么。

上线前填写这张隐私承诺核对表

把下表放进产品评审，每次只针对一个敏感功能、一个准确的公开表述填写。“未知”是需要处理的结果；空白不是批准。

再附一条简短发布记录：功能版本、承诺版本、供应商配置、测试日期、审查人、已知排除项和下次复核负责人。更换模型、工具、记忆库，添加分析事件或分享功能时，都重新打开记录。隐私承诺应描述用户现在用到的系统，而不是最初设计稿。

这张表比正式的隐私影响评估小得多。两个人也能在工作会上填完。如果答案涉及受监管数据或格外脆弱的人群，就应在此处引入合格的隐私和安全专家。表格用于把问题引向正确的决策，不是合规徽章。

发布文案前做四项故障演练

远程证明失败。 客户端无法验证预期工作负载时，会在发送内容前停止，还是悄悄转向普通端点？如果声称“机密处理”，通常应采用前者，除非用户知情并主动选择另一模式。记录实际失败行为，而不只是理想架构图。RFC 9334为何区分证据和依赖方策略，在此很直观。 供应商增加处理环节。 推理供应商在宣传的受保护环境之外，加入审核或调试服务。你的核对表能发现新的明文路径吗？检查变更通知、数据处理条款和实际生效配置。新安排未必不可接受，但文案可能需要调整。 记忆跨越可见范围。 后续提示让助手检索了另一场会议的细节，而两场会议的访问名单不同。用两个工作区、两位参与者和一个被撤权的成员测试。记忆即使加密正确，也可能被返回给错误的人。每次改动记忆或分享机制，都重跑检索授权测试。 删除留下回声。 删掉一条记录后，按实际清除周期检查备份、向量、缓存回答、客服工单和分析事件。合理的保留例外要用用户能理解的话说明。若备份要过一段时间才过期，就不要承诺即时彻底清除；说明真实窗口，并在等待期限制访问。

某项演练失败，不必然意味着整个功能不能做；但必须修补重大缺口、缩小承诺，或推迟发布。产品完全可以诚实地说明：传输加密、限制员工访问、数据保留 30 天，同时继续改进更强的架构。信任来自边界准确、控制可预测。

什么时候值得采用机密计算

机密计算会带来实打实的工程和运维工作：集成远程证明、维护软件度量策略、密钥释放、硬件兼容、性能测试、无法看原始负载时的调试、校验失败后的恢复。当核心风险来自宿主运营方或被攻陷的宿主机，而且其余数据路径也能维持相同保证时，它可能值得投入。若主要问题是过度采集、分享范围过大、永久保留，或录音提示让用户误解，先上 TEE 可能抓错了重点。

采用三种上线结论。发布：每阶段有负责人，表述与测试行为一致，例外清楚。限缩：确有有用的保护，但某条路径仍较弱；例如先提供一次性摘要，再考虑长期记忆。暂缓承诺：关键处理方、日志、检索权限或删除路径仍未知。暂缓文案不等于停止所有开发，而是暂时不要求用户相信尚未证实的话。

Meta 的工程说明有值得学习之处，但不是通用施工图：它把受保护计算、身份隔离、软件版本透明和持久加密状态当成不同要求。创始人在自己的产品规模上也应这样分开。最有价值的第一步往往很普通：别记录提示词，缩短保留时间，收紧访问权限，明确录音同意，实际测试删除。只有当高级密码学能降低这些措施解决不了的、已经指明的风险时，再考虑投入。

这套方法不能证明什么

这是一种审查产品承诺的方法，不是对 Meta、Apple、Google 或任何供应商的安全审计。一手工程资料可以说明公开的设计和机制，不能证明每次部署、每个客户端版本、每个第三方集成和组织流程都完美运行。远程证明与透明日志能提升特定威胁模型下的可核验性，但硬件、核验策略、源码与二进制的一致性、客户端完整性和侧信道仍是问题。TEE 之外，同意、分享和保留仍由你的产品负责。

Roomnote 案例完全虚构。文中没有把任何用户、客户、事故、测试成绩或使用量冒充 YBuild 的真实数据。法律与行业义务因地区和用途而异；这里的 FTC 与 NIST 资料用于指导产品承诺和风险梳理，不构成针对某个业务的法律意见。涉及健康记录、未成年人、职场监控或金融决策时，上线前还要补充专业审查及当地要求。

可长期执行的做法很朴素：先写出用户会看到的那句话，再追踪它覆盖的每一条数据路径，测试最薄弱环节，直到句子和系统实际行为一致。产品一变，重新核对。这样，“私密”才会从页面气氛变成具体、可验证的承诺。

参考资料

1. Meta Engineering，Bringing Private Processing to Meta AI Glasses（2026）。
2. Meta Engineering，Building Private Processing for AI tools on WhatsApp（2025）。
3. Apple Security Research，Private Cloud Compute Security Guide。
4. Apple Security Research，Release Transparency。
5. Google Cloud，Google Cloud Attestation。
6. IETF，RFC 9334: RATS Architecture。
7. IETF，RFC 9458: Oblivious HTTP。
8. NIST，Privacy Framework。
9. 美国联邦贸易委员会，企业隐私与安全指引。