一句话总结：Regulation (EU) 2024/1689 第 11(1) 条要求高风险 AI 系统的技术文档在投放市场或投入使用之前编制完成并持续保持更新，最低内容就是附件四的九节：一般描述、要素与开发过程、监测与功能控制、性能指标适用性、风险管理体系、生命周期变更记录、协调标准清单、符合性声明副本、上市后监测计划。九节里最容易写残的是第 2 节——它有 (a)~(h) 八个子项；第 7 节最容易被误读——无协调标准时不是"留空"，而是必须详述替代方案并列出所采用的其他相关标准与技术规范。文档保存期 10 年（第 18(1) 条）。
一、九节的全貌
| 节 | 内容 | 关键点 |
|---|---|---|
| 1 | 系统一般描述 | 预期用途、提供者名称、版本关系、软硬件交互、投放形态、界面与说明书 |
| 2 | 要素与开发过程详述 | 八个子项，见第二节 |
| 3 | 监测、功能与控制 | 能力与局限、精度、可预见非预期结果、人工监督、输入数据规格 |
| 4 | 性能指标适用性 | 为什么这些指标适合这个系统 |
| 5 | 风险管理体系 | 对应第 9 条的连续迭代过程 |
| 6 | 生命周期变更记录 | 提供者对系统做过的相关变更 |
| 7 | 协调标准 | 全文/部分适用清单；无则写替代方案 |
| 8 | 符合性声明副本 | 第 47 条 DoC 的副本 |
| 9 | 上市后监测 | 评价系统上市后性能的安排，含第 72(3) 条监测计划 |
注意第 9 节与第 72(3) 条是同一个东西的两处出现：第 72(3) 条明确"上市后监测计划应作为附件四所称技术文档的一部分"。写文档时不要把它当成两份文件。
二、第 1 节：一般描述里的八个落点
附件四第 1 点列了 (a)~(h)，其中三项在实务中最容易被含糊处理：
- (a) 版本关系：不是写"v2.3"，而是写该版本与此前版本的关系。这句话决定了改动是否需要重新评定。
- (d) 投放形态：须描述系统投放或投入使用的全部形式——嵌入硬件的软件包、下载、API 等。同一系统多种形态要逐个写。
- (f) 产品内的组件：若系统是产品的组件，须提供显示产品外部特征、标记与内部布局的照片或图示。
三、第 2 节：八个子项，四个最常被漏
第 2 点是"要素与开发过程的详细描述"，实际有八个子项：
| 子项 | 内容 |
|---|---|
| (a) | 开发方法与步骤，含是否使用第三方预训练系统或工具、如何使用/集成/修改 |
| (b) | 设计规格：系统与算法的一般逻辑、关键设计选择及理由与假设、主要分类选择、优化目标与各参数相关性、预期输出与输出质量、为符合第三章第 2 节所做的技术取舍 |
| (c) | 系统架构：软件组件如何相互构建/输入并集成为整体处理；开发、训练、测试、验证所用的算力资源 |
| (d) | 数据要求：以 datasheet 形式描述训练方法与技术、所用训练数据集（来源、范围、主要特征）、获取与选择方式、标注程序、清洗方法（如离群值检测） |
| (e) | 按第 14 条评估所需的人工监督措施，含按 13(3)(d) 便于部署者解释输出的技术措施 |
| (f) | 预定的系统与性能变更，以及为保证持续符合第三章第 2 节所采用的技术方案 |
| (g) | 验证与测试程序：所用验证/测试数据及主要特征、衡量精度/稳健性/其他要求与潜在歧视影响的指标、带日期与责任人签署的测试日志与测试报告（含 (f) 所述预定变更） |
| (h) | 已实施的网络安全措施 |
漏得最多的是 (e)、(f)、(g)、(h)。其中 (g) 的"带日期与责任人签署"是一个形式要件——没有签署的测试报告，在公告机构眼里等于没有测试记录。