📘 本文件为本笔记系列正文第 6 部分。主文件（前序与总览）含全系列索引：UL 3115 AI人工智能产品安全评估大纲学习笔记（前序） - 概述与总览
第九章：文档、生命周期与问责制【引述依据：39–49】
9.1 为什么把这三块放在一起
第 39–41 章讲"留下什么"，第 42–45 章讲"什么时候做什么"，第 46–49 章讲"谁签字负责"。三者是一根链条：
- 生命周期提供时间轴，定义在哪些节点必须做决定；
- 文档提供证据，证明这些决定确实做了、做对了；
- 问责提供主体，回答"如果证据不足，谁承担后果"。
这条链条解释了为什么标准的最后四章是问责制而不是技术要求——前面所有章节的要求，最终都要落在"某个具体的人签署了某个具体判断"上，否则整个体系不可执行。
💡 行业经验提示：很多团队把这三块当成"收尾工作"，等项目做完再补。结果是补出来的文档没有任何决策痕迹，只能写成"我们做了 X"的描述性材料，无法回答"为什么这样做""谁批准的""当时考虑过哪些替代方案"。文档的价值不在完整，而在能重建当时的决策过程。建议项目从第一天就按"决策日志"的方式记录，而不是事后回忆。
9.2 文档与报告的要求（第 40–41 章）
第 40 章（Key Considerations）提出四项原则：透明可及、全面覆盖、定期更新、合规与伦理，并引用 EU AI Act 第 11 条与附件 IV（技术文档要求）。
第 41 章把文档拆成六类，每类一条编号要求：
| 编号 | 文档类别 | 应包含的核心内容 | 常见缺陷 |
|---|---|---|---|
| R67 | 开发与设计文档 | 设计目标、架构选择、需求分解、权衡记录 | 只有最终方案，没有替代方案与取舍理由 |
| R68 | 数据采集与分析记录 | 来源、采集方法、清洗规则、质量评估、偏见检查 | 缺中间加工步骤，血缘断裂 |
| R69 | 测试与评价报告 | 测试计划、用例、结果、通过判据、覆盖率 | 只有结果没有判据，无法判断"算不算通过" |
| R70 | 合规与伦理评审文档 | 适用法规清单、符合性论证、伦理评审意见 | 只列法规名称，没有逐条符合性说明 |
| R71 | 部署与监控日志 | 部署配置、版本、监控指标、告警与处置记录 | 日志保留期短于追责需要 |
| R72 | 事件与响应文档 | 事件描述、影响范围、根因、纠正措施、回访 | 只记录事件不记录后续验证 |
这六类文档之间的关系不是并列，而是互相引用：R69 的测试判据来自 R67 的需求；R72 的根因分析会回溯到 R68 的数据与 R69 的测试缺口。因此文档管理的关键不是"六份都写"，而是六份之间能对上号。
💡 行业经验提示：六类文档最容易断链的地方是 R67 与 R69 之间——设计要求写了一套判据，测试报告用了另一套判据，两套都能自圆其说，但无法互相验证。行业里的低成本解法是给每条需求编一个 ID，测试用例必须引用需求 ID，报告必须汇总"每个需求 ID 的验证状态"。这一张追溯矩阵就能同时服务 R67、R69 和 R29（V 模型可追溯）。
9.3 生命周期管理（第 42–45 章）
第 42 章指出生命周期框架参照 ISO/IEC 5338（AI 系统生命周期过程）。第 43 章提出三项关键考量：持续监控与更新、适应性、退役规划。第 44 章给出方向性做法：定期评审、版本控制、干系人参与。
第 45 章把生命周期切成四个阶段，每阶段一条要求：
| 编号 | 阶段 | 主要控制点 | 证据形态 |
|---|---|---|---|
| R73 | 开发阶段 | 需求冻结、数据规格、模型选择依据、阶段评审 | 设计评审记录、数据规格书、选型论证 |
| R74 | 部署阶段 | 集成验证、放行准则、配置基线、回滚预案 | 放行检查表、配置清单、回滚演练记录 |
| R75 | 运维阶段 | 性能监控、漂移检测、变更管理、事件响应 | 监控报表、变更记录、事件台账 |
| R76 | 退役阶段 | 数据处理、风险缓解、干系人沟通、安全处置或再利用 | 退役计划、数据销毁证明、通知记录 |
R76 是最容易被整段跳过的部分：产品停服时，模型权重、训练数据、用户数据、日志、备份怎么处理，往往没有人负责。标准明确要求退役阶段也要做风险缓解与干系人沟通——因为停服本身就是一个风险事件，依赖该系统的用户会突然失去能力。
💡 行业经验提示：退役阶段最大的隐患是"模型权重与训练数据被遗忘在对象存储里"。行业里建议在部署阶段就把退役计划写出来（而不是等到要停服），至少明确三件事：数据保留多久、由谁批准销毁、销毁如何取证。这三件事在部署时写只需要一小时，在停服时想需要一个月。