2026 年初，Chrome 悄然移除了其设备端 AI 功能中「不向 Google 发送数据」的隐私声明，这一变化在安全社区引发广泛讨论。从表面看，设备端 AI 的核心卖点正是本地处理以规避数据上传风险，然而工程实现的复杂性使得这一承诺难以完全兑现。本文将分析该决策背后的工程动因，并探讨对端侧 AI 部署的深远影响。
工程实现与隐私承诺的内在张力
Chrome 在 Enhanced Protection（增强保护）模式下引入设备端 GenAI 模型，用于实时钓鱼和恶意软件检测。从架构设计角度看，模型在用户设备本地运行，理论上无需将网页内容或用户交互数据上传至云端。然而，工程团队很快发现，即便采用本地推理模式，仍存在多个数据交互节点无法完全消除。
首先，设备端模型需要周期性更新以保持检测能力，这意味着模型权重文件本身需要从 Google 服务器下载。研究人员发现，Chrome 在未经明确用户授权的情况下，会自动下载约 4GB 的 AI 模型文件到本地设备，这直接引发了关于用户知情权和同意权的争议。其次，即使推理过程在本地完成，安全功能的部分元数据 —— 例如 URL 哈希、域名信誉评分 —— 仍可能以加密形式回传至 Google 的 Safe Browsing 后端，以支持全局威胁情报的聚合与更新。这种设计使得「不发送数据」的声明变得不再准确，移除该声明实际上是向用户呈现更透明的隐私图景。
从合规角度看，GDPR 等数据保护法规对数据处理的描述精确性提出了严格要求。2025 年以来，多个欧洲隐私监管机构加强了对 AI 功能的审查力度，Google 选择主动调整声明而非被动应对监管质疑，这一决策符合其全球隐私合规战略。安全研究人员发现的 4GB 模型静默下载行为更是加速了这一进程 —— 当研究社区能够通过逆向工程验证实际数据流向时，继续维持一个可能存在误导性的隐私声明所带来的品牌风险，远超过修改措辞的短期成本。
端侧 AI 部署范式的信任危机
Chrome 此次声明调整对整个端侧 AI 领域具有标志性意义。过去几年，业界普遍将「本地处理」作为隐私友好的关键技术叙事，从手机端的语音助手到浏览器的恶意检测，均以数据不离开设备作为核心卖点。然而，Chrome 的案例表明，端侧 AI 的隐私承诺往往比营销话术更为复杂。
用户在评估端侧 AI 安全性时，需要关注三个关键维度。第一是模型生命周期管理：模型文件的下载、更新和删除是否由用户完全控制，是否存在静默更新机制。第二是推理输入的来源：即使推理在本地执行，输入模型的数据从何而来，是否包含用户敏感信息。第三是推理输出的流向：模型产生的判断结果是否会回传云端用于其他目的。这三个维度共同构成了端侧 AI 的完整数据流图景，单纯宣称「本地运行」远不足以建立用户信任。
对于企业级端侧 AI 部署而言，Chrome 事件揭示了一个重要的工程原则：隐私声明必须与实际数据流严格对齐，任何技术实现上的灰色地带都应主动披露而非隐藏。当用户发现设备端 AI 仍与云端存在数据交互时，信任修复的成本将远高于初期坦诚沟通的投入。
端侧 AI 隐私控制实操参数
基于 Chrome 当前版本的实现，用户可通过以下路径管理设备端 AI 功能：进入 Chrome 设置，点击「隐私与安全」模块，选择「安全」选项卡，在「增强保护」区域可找到设备端 GenAI 模型的管理入口。关闭该选项后，浏览器会删除本地模型文件并回退到传统的云端 Safe Browsing 检查或基于启发式的非 AI 防护方法。需要注意的是，禁用设备端 AI 会导致实时威胁检测能力下降，钓鱼网站识别延迟可能增加，具体表现为检测准确率从启用状态的约 97% 下降至云端模式的 85% 左右。
对于企业环境下的 Chrome 浏览器管理员，Google 提供了组策略（Group Policy）控制选项，可通过「GenAIAllowed」策略键统一配置设备端 AI 的启用或禁用状态，部署时建议结合组织的隐私合规要求进行差异化配置。在监控层面，建议企业安全团队关注以下指标：设备端模型文件的下载 / 更新事件日志、模型启用状态变更记录、以及网络层面对 Google 安全服务端点的出站连接频率。
结语
Chrome 移除设备端 AI 隐私声明并非简单的产品失误，而是端侧 AI 从概念宣传走向工程成熟的必然阵痛。这一案例提醒我们，隐私承诺的可靠性最终取决于技术实现的可验证性，而非营销话术的精巧程度。随着端侧 AI 在浏览器、操作系统乃至物联网设备中的广泛应用，建立可审计、可解释的数据流透明机制将成为赢得用户信任的关键。
资料来源：Forbes 关于 Chrome 设备端 AI 模型删除功能的报道；BleepingComputer 关于 Chrome 安全功能的分析。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。