端侧 AI · 隐私
本地与混合 AI 的同意状态怎么审计
从用户选择追踪到路由、payload、撤销和公开说明。
主查询：端侧 AI 同意审计 · 核验：2026-09-16 · 事实卡：ARCH-02, PRIVACY-02
先给结论
本地与混合 AI 的同意状态审计必须严格限定在用户已经给出的选择之内，只能从用户实际的选择开始追到系统内部的路由、payload、撤销机制以及对外的公开说明，外部观察不能用来推断未由用户做出的同意。也就是说，审计所能依据的全部内容都必须落在用户已经显式表达的选择与公开材料上，任何来自运行环境的间接信号都不足以构成新的同意事实。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- consent 状态记录
- 路由与 payload 抓取
- 撤销测试
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
要把这一过程落到可核验的层面，需要把审计工作组织为一系列相互对照的记录：consent 状态记录反映用户当下的授权内容，路由与 payload 抓取对应系统在实际处理请求时所走的路径与携带的数据，撤销测试则检验用户撤回选择后系统是否能被观察到的停止行为，三类证据必须在同一时间窗内对齐比对，只有这样才能把“同意”与“实际行为”绑在同一份记录上。
- 列数据类型
- 列全部目标域名
- 映射请求字段
- 飞行模式走完整流程
- 恢复网络后抓包
- 同步更新公开说明
最容易写错的地方
- 使用过期 consent
- 决策前先传输
常见的错误模式有两类，必须把发布结论限制在已有记录之内：使用过期 consent，即系统继续沿用已经失效或被撤销的用户选择；决策前先传输，即在用户选择尚未确定之前，相关数据就已经离开本地进入处理环节。这两类问题只有在上述记录中确实存在相应证据时才能作为结论提出，任何超出已有记录的判断都不应进入发布文本。事实卡边界：ARCH-02、PRIVACY-02。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。