YYMuse
5. 运营期 · WorkKit

退役与数据销毁流程

法务 架构

为 AI 系统的退役设计预案,特别是数据销毁和用户告知

触发场景

每个 AI 系统都有退役的一天。可能因为更好的模型出现、业务下线、合规要求变更。退役不是收尾流程,是一个需要预先设计的阶段。

输入清单

  • 系统架构文档
  • 数据存储清单(所有涉及的数据位置)
  • 用户协议(关于数据处理的承诺)
  • 合规要求
提示词 基础版 / 进阶版
你是一位 AI 系统退役顾问。请帮我设计退役预案。

系统信息:
- 功能:{{FEATURE}}
- 用户规模:{{USER_COUNT}}
- 数据类型:{{DATA_TYPES}}
- 运行时间:{{RUNTIME}}

请设计:
1. **退役触发条件**:
   - 什么情况下会考虑退役?
   - 谁有退役决策权?
2. **数据销毁计划**:
   - 需要销毁哪些数据(训练数据、日志、用户数据)
   - 销毁方式和验证标准
   - 数据保留要求(是否有法规要求的保留期)
3. **用户告知方案**:
   - 告知时间和方式
   - 数据处理说明
   - 替代方案(如果有)
4. **知识传承**:
   - 系统经验总结
   - 可复用的评测集和流程
5. **时间表**:从决定退役到完全关闭的步骤和时间线

产出记录

将 AI 返回的结果填入下方模板,形成可追踪的项目文档。

退役与数据销毁预案

功能名称 用户规模

退役触发条件

触发条件 描述
更优替代方案出现 ___
业务下线 ___
合规要求变更 ___
成本不可持续 ___

数据销毁计划

数据类型 存储位置 销毁方式 验证标准
训练/微调数据 ___ ___ ___
用户交互日志 ___ ___ ___
提示词历史 ___ ___ ___
评测集 ___ ___ ___

用户告知方案

  • 提前告知时间:___ 天
  • 告知渠道:___
  • 替代方案:___

退役时间表

阶段 时间 动作
决策公告 T+0 ___
功能下线 T+___ ___
数据销毁 T+___ ___
销毁验证 T+___ ___

制定人 / 日期:___ / ___

查看填写示例
示例场景

【示例】退役预案——智能客服意图识别

功能名称:AI 意图识别路由 用户规模:日均 5000 来电

退役触发条件

触发条件 描述
更优替代方案出现 自研 NLP 模型达到同等准确率且成本更低
业务下线 客服中心改用统一智能体平台
合规要求变更 AI 监管要求超出当前架构能力
成本不可持续 月成本 > ¥10,000 且无法优化

数据销毁计划

数据类型 存储位置 销毁方式 验证标准
评测集(含用户数据) PostgreSQL DELETE + VACUUM 抽样查询返回 0 行
用户交互日志 OSS 对象存储 批量删除 文件列表为空
提示词历史 Git 仓库 仓库归档 仓库设为只读
监控数据 Grafana 数据保留 90 天后自动过期 仪表盘显示无数据

用户告知方案

  • 提前告知时间:30 天
  • 告知渠道:通话语音提示 + 官网公告 + 短信通知
  • 替代方案:恢复纯人工路由,平均等待时间增加约 15 秒

退役时间表

阶段 时间 动作
决策公告 T+0 通知所有利益相关方
功能下线 T+30 停止 AI 分类,恢复纯人工路由
数据销毁 T+60 按计划销毁各存储位置数据
销毁验证 T+75 安全团队抽检验证

制定人 / 日期:张明 / 2026-05-15

自检 Checklist

  • 是否覆盖了所有数据存储位置?
  • 数据销毁方式是否符合合规要求?
  • 用户告知是否提前足够时间?
  • 是否有知识传承计划?

衍生动作

  • 预案完成:纳入项目文档
  • 当前不需要:定期(每半年)回顾退役条件

作者 手记

退役预案听起来悲观,但它体现的是产品经理的系统性思考。一个没有退役预案的系统,就像一个没有遗嘱的人——不是不会发生,而是发生时所有人手忙脚乱。建议在设计阶段就写好退役预案,然后忘掉它——直到需要的那一天。

← 返回 运营期