直接回答
数据保留策略比“删除”按钮更具体。它说明保留哪些数据类别、出于什么产品目的、何时过期或响应用户动作，以及哪些派生副本要随源数据处理。PRIVACY-01 和 ANDROID-PRIVACY-01 支持记录本地存储和用户控制，却不规定统一保留时长，也不证明某个应用的清理行为。用户保存结果要与临时张量、缩略图缓存、搜索索引、崩溃诊断和模型文件区分；它们可能有不同负责人和清理触发点。 从代码和存储检查建立数据类别清单。每类记录来源、位置、创建事件、用途、所有者、用户是否可见，以及是否复制到数据库、文件、缓存、日志、备份、导出或派生索引。不能只列数据库表：临时文件、缩略图、操作队列和支持包中的结果也可能继续保存。如果某个类别在受测构建里没有实现，就如实标为不存在，不要照抄通用清单。 定义保留触发事件，而非猜天数。事件可以是用户明确删除、临时任务完成、草稿过期、退出账号、重置应用或产品配置的清理任务。适用事件取决于功能和用户预期；本文不规定法律期限。要说明保存结果是否一直保留到用户删除、不完整任务何时清理，以及界面如何告知。如果策略没有实现，标为未解决，不能把设想写成当前行为。 把派生数据映射回来源。转录可能产生摘要、向量、缩略图、语言元数据或失败记录。删除转录时，应测试所有可能泄露内容或保留关联关系的派生数据。缓存模型不是用户创作内容；用户删除一条结果时，除非产品明确这么定义，否则不能顺手清掉模型。反过来也不能假设删除一张历史卡片就移除了源文件和备份。 用合成金丝雀测试保留策略。创建可唯一搜索的测试数据，执行正常完成、取消、重置、适用时退出账号和过期事件，再检查数据库、文件、临时目录、队列、本地索引、导出文件夹和备份恢复路径。每个触发后搜索金丝雀。还要测试清理期间进程死亡和重试，避免部分清除却显示为完成。报告记录设备与 Android 版本，因为平台存储和备份行为可能不同。 本地删除要与远端删除分开。如果有路径曾传输内容，设备端清理不能抹除服务器副本。记录接收方及独立删除方式，只描述核实过的结果。Android 备份或设备迁移可能恢复配置范围内的数据；团队应检查真实备份规则和恢复结果，不能从应用私有目录推断保留政策。账号或分析标识符也可能与转录有不同生命周期。 面向用户的状态应清楚。用户要能区分已保存内容和临时处理状态，知道重置会删什么，并了解缓存或下载模型是否排除在外。如果“清除数据”实际会删不同类别或可能毁掉用户工作，就不要只用一个含糊标签。保留测试还要检查预览、确认、适用时撤销和清理后空状态。不要超出存储系统和实现证据，承诺安全擦除。 最终矩阵应包含数据类别、用途、负责人、位置、保留触发、派生副本、备份/导出路径、用户控制、清理测试和未决限制。可以说某个合成金丝雀在某动作后未出现在已检查位置；不能推导统一保留天数、取证层面彻底清除、法律合规或未观察服务器副本已删除。新增功能、缓存、分析 SDK 或备份策略变化后要复审。保留是可测试的生命周期契约，不是一个猜出来的全局时长。
用户删除一条结果但保留源录音
用户希望删除生成摘要，同时保留原始录音和另一条已保存笔记。应用还存有临时处理数据和派生搜索项，因此团队要区分哪些记录应过期，哪些内容必须保留。
决策
将每种数据及其派生副本映射到保留触发，再用合成金丝雀删除并检查各存储位置。
预期结果
测试报告明确哪些数据被删除或保留，不声称备份或服务器副本也已清除。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- PRIVACY-01：数据存储与用户控制须分开说明
- ANDROID-PRIVACY-01：应用需核实完整数据访问边界
隐私声明需要数据清单和流量证据；“本地模型”标签本身不是证明。
实施流程
- 盘点数据类别和存储位置. 从实现追踪已保存输入、生成结果、临时缓冲、缓存、索引、日志、队列、导出和备份范围。
- 分配用途与保留触发. 对每类说明产品用途、负责人、过期或用户动作、可见控制；无已实现策略时标为未知并记录证据来源。
- 将派生记录映射到来源. 列出可能泄露内容或保留关联的摘要、缩略图、向量、元数据及失败记录，并标明来源关系。
- 执行金丝雀删除与过期测试. 生成合成标记，触发删除、重置、取消和清理重试，再检查各存储区与备份恢复后的残留。
- 复查用户提示和例外. 检查确认、预览、空状态、模型缓存范围和远端删除路径，并标记未验证的取证或服务器行为。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每类数据都有用途、负责人、位置、保留触发、派生副本和用户控制状态。
- 每个动作后用合成金丝雀检查主数据和派生数据，包括清理中断及备份范围。
- 不编造保留天数，不承诺安全擦除、法律合规或未观察到的远端删除。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 用户保存结果 | 按明确产品规则或用户动作保留 | 必须与临时处理状态和派生副本区分。 |
| 临时推理数据 | 在已说明的任务边界过期或清理 | 需测试取消、进程死亡和清理重试。 |
| 模型或应用缓存 | 使用独立缓存策略管理 | 清除缓存不能静默删除无关用户内容。 |
需要避免的失败模式
- 只盘点数据库表
- 以删除可见卡片代表清除派生数据
- 推测备份或远端副本也已删除
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
离线 AI 应用应保留用户数据多少天？
本文不规定统一时长。应根据数据类别、产品用途、用户预期、实际实现及适用审核确定，不能凭空编天数，并记录负责人、复核版本、例外理由和下一次审查日期。
删除历史卡片会自动删除所有相关副本吗？
不会自动保证。要用合成金丝雀检查源文件、派生索引、缩略图、队列、导出、备份及任何远端接收方，并记录测试构建、位置、重启后的结果和未覆盖的恢复路径。
本地删除能清除已经发送到服务器的副本吗？
不能仅靠本地操作做到。要识别每个接收方并测试单独的删除机制，只报告经过核实的副本、回执、保留状态、测试日期与结果。