隐私与数据边界

如何为混合式 AI 路由选择做版本化记录

关注路由契约变化后,旧选择是否仍适用及其迁移、撤回与请求门禁;不重复解释首次同意界面的文案设计,也不保证法律合规。

审核状态: 内容已校验;中文稿供用户审核 · 2026-10-06 · Fact IDs: ARCH-02, PRIVACY-02

直接回答

对混合式 AI 功能,记忆用户路由选择时要绑定它实际描述的披露与行为,而不是只存一个 'cloudAllowed=true'。有用的记录要注明功能、路由策略版本、接收方类别、用途、数据类别、是否允许发送可选内容、用户选择,以及展示该选择的应用版本。如果产品区分“尚未询问”“已拒绝”“仅为此请求允许”和“为有限功能记住选择”,这些状态也应明确。存储记录只能证明应用写入了一项选择;它不能证明界面展示了什么、后来发送了哪些字段,或该流程满足了法律要求。 核心操作是比较当前路由契约与旧选择覆盖的契约。实质变化可能包括新增接收方、新用途、从仅发送所选片段扩大为发送整段对话、新增自动云端回退,或原本仅本地处理的任务改为设备外传输。此类变化不能静默沿用旧选择。如果只是修正文案但数据流不变,不一定要强迫用户重复点击;应由经审查的产品策略定义哪些变化具有实质影响,不能把每次版本号变化都变成弹窗。保留披露版本和 payload schema 的关联,便于后续审计。 把路由保存成有版本的记录,而不是散落在界面中的布尔开关。类型化记录可以包括 featureId、routeId、routeRevision、recipientClass、purposeRevision、payloadClassSet、disclosureRevision、choice 和时间戳。记录自身的 schema 版本要与产品路由版本分开。应用升级后遇到未知或缺失字段时,不得把它理解成已获许可。只有语义仍清晰的旧状态才能迁移;否则回到“需要重新确认”,在构造远端请求前显示当前选择页面。不要把用户提示词或文档正文写进同意记录来冒充证据。 持久化范围应保持狭窄。一次性确认只绑定某个请求 ID,并随请求结束。若产品提供记忆偏好,应绑定到被披露的具体功能、路由、payload 类别和用途,并让用户可以查看或撤回。撤回后应使相关记录失效并阻止新传输。还要决定排队任务如何处理:取消、暂停等待重新审查,或仅在用户可见契约明确允许时继续。重试时若接收方不同或上下文更大,就应视作新的路由决定。网络失败不是扩大路由范围的许可。 在 Android 上,小型类型化或键值记录可以放在 DataStore 等应用数据层,但存储 API 不定义同意语义。让单一权威组件拥有路由策略,并把状态提供给界面。请求组装前,先检查当前策略版本是否仍与已存选择匹配,且待发送字段未超出其范围;不匹配时应阻止请求并要求审阅。账号重置、应用数据恢复或策略迁移时,不要未经当前路由及披露版本核验就恢复旧授权。 测试状态转换,而不只是弹窗。使用合成 canary 字段,观察尚未选择、拒绝、撤回、路由版本变化、用途变化、payload 扩大、应用升级、进程重建、断网和重试时,是否有任何网络请求开始。对照界面披露、存储记录、请求目的地和序列化 payload。Google Play 指引说明披露与同意要求取决于数据和用户预期,Data safety 表单还必须反映应用及 SDK 的实际处理;这些页面是政策依据,并不替具体实现做法律判定。Cove 已发布的隐私边界也将用户内容与模型下载、Play 购买验证、newsletter 和可选崩溃报告分开,不能把它们统称为一个“云端同意”。 最终记录应说明测试了哪个版本,以及每种变化之后哪些选择仍有效。结果可以证明某个应用构建会在缺少匹配选择时阻止请求,但不能证明法律意义上的同意、所有传输都已披露,或某个应用具体存在该路由;后者还需检查实际代码和网络行为。

应用升级后,本地改写新增远端回退

用户此前选择本地改写。新版本新增一个可选远端服务,只有本地任务不可用时才会接收所选文本;旧版本还可能留有一条排队重试。

决策

把新增接收方与路由行为视作新版本,旧记录不得授权远端请求;发送所选文本之前先展示本次选择。

预期结果

任务保持本地、等待用户决定,或仅发送获准字段;升级和重试都不会静默传输旧内容。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来,结论才可复核:

  • ARCH-02:混合架构可以让不同任务走本地或远端,但必须明确路由规则和传输数据。
  • PRIVACY-02:Cove 已发布的隐私边界区分用户内容、模型下载、Play 购买验证、newsletter 和可选崩溃报告;它们不是同一种路由或同一项同意。

隐私声明需要数据清单和流量证据;“本地模型”标签本身不是证明。

实施流程

Record the consent schema revision alongside the route and payload fixtures, then compare these artifacts against the outcomes of revocation and upgrade tests. This alignment ensures that each captured choice corresponds with the precise documentation and verification evidence already gathered.

  1. 定义路由契约. 为每个功能版本化记录接收方类别、用途、payload 字段、触发条件、本地替代路径、重试行为和披露文案。区分数据流变化与纯文案修改。
  2. 创建版本化选择记录. 保存功能与路由身份、策略和披露版本、适用范围、选择状态,必要时绑定请求。记录 schema 迁移与路由策略版本分开。
  3. 在组装请求前设门禁. 序列化之前比较当前路由及拟发送字段与存储选择。未知版本、缺失范围、已拒绝或已撤回都要阻止传输并回到审阅流程。
  4. 处理升级、队列和撤回. 定义策略变化、数据恢复、账号重置、断网和用户撤回后如何处理排队请求与记忆偏好。重试时不得扩大接收方或 payload。
  5. 核实披露与实际网络流量. 用合成 canary 测试未选择、允许、拒绝、撤回、策略迁移、路由变化和失败分支,对照展示文本、保存版本、目的地和 payload。

验收标准

  • 每项记忆选择都记录其覆盖的路由、接收方类别、用途、数据范围和披露版本。
  • 实质性的接收方、用途或 payload 变化不能复用超范围选择,也不能在重新审阅前发送请求。
  • 拒绝和撤回按既定策略阻止新请求或排队传输,合成 canary 测试确认这一行为。

决策对照表

维度选择或证据解读方式
选择记录 schema 版本描述持久化字段及其迁移格式记录结构变化时更新;它本身不改变路由会发送的数据。
路由策略版本描述接收方、用途、触发条件和 payload 范围实质行为变化可能使旧选择失效,需要展示新披露或重新选择。
应用构建版本标识发布的软件构建可用于追溯,但版本增加本身既不能证明路由改变,也不能证明旧选择仍有效。

需要避免的失败模式

  • 只保存 `cloudAllowed=true`,没有记录它针对哪个功能、接收方、用途和数据字段。
  • 把所有文案编辑都当成同意失效,或反过来让新增接收方、用途和更大 payload 自动继承旧决定。

Avoid releasing on the basis of reusing consent after any scope change, and refrain from transferring before an upgrade review. Restrict approval statements to the evidence that has actually been recorded, keeping the boundary references ARCH-02 and PRIVACY-02 as the sole identifiers cited.

最小复现记录

层级记录内容
设备厂商、型号、芯片、内存档位、操作系统版本
软件应用版本和 Git 提交号
模型系列、变体、版本、格式、文件长度、摘要、量化方式
运行时名称、版本、请求后端及实际后端证据
工作负载样例版本、输入摘要、提示词摘要、输出策略
结果完成、失败、取消、回退及保护隐私的诊断信息

发布检查表

  • ☐ 主要搜索问题已回答,且没有未经支持的数字。
  • ☐ 所有模型文件和运行时版本均已固定。
  • ☐ 代表性任务和失败处理策略均有说明。
  • ☐ 生命周期、取消、清理和回退均已测试。
  • ☐ 用户内容与网络边界均有说明。
  • ☐ 结论只适用于被记录的配置。
  • ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题

每次修改披露文案都要重新询问吗?

未必。应制定经过审查的实质性变化规则。接收方、用途、payload 范围或路由行为变化,与不改变数据流的文字修订并不相同。

保存了“允许”值能证明用户看到披露了吗?

不能。它只证明应用存储了某个值。披露版本、选择交互、实际路由和 payload 都应分别保留证据并进行测试。

远端请求失败时,能直接沿用本地路由的旧选择吗?

不能。旧选择只覆盖当时披露的功能、接收方、用途和数据范围。远端失败不授予扩大路由或重试权限;应重新核对当前策略、请求字段及用户选择,必要时暂停并重新披露。