欧盟人工智能法案 附件 IV 高风险 AI 系统技术文档

章节结构（11）

1. 1. 〇、高风险归类判定与文档适用范围（前置章节）

   附件 IV 本身不含这一章，但每一位评审人首先要确认的就是"你凭什么认为这是高风险系统、走的是哪条路径"。写明：系统落入第 6(1) 条（作为附件 I 所列欧盟协调立法产品的安全组件或本身即该产品，且需第三方合格评定）还是第 6(2) 条（附件 III 所列用例）；若属附件 III 用例但主张适用第 6(3) 条例外（不构成对自然人健康、安全或基本权利的重大风险），必须写下该评估的依据，并注意第 6(4) 条要求在投放市场或投入使用前登记该评估。同时标注适用日：经 AI Omnibus 推迟后，附件 III 路径的高风险规则自 2027-12-02 适用，附件 I 嵌入式路径自 2028-08-02 适用；技术文档的编制排期应按这两个日期倒推，而不是按 2026-08-02 的法案总体适用日。最后声明文档覆盖的系统名称、版本区间与形态（SDK、API、嵌入式固件），附件 IV 第 1 条后续各项都以此为基准。

   需要附的证据

   • · 高风险归类判定记录（第 6(1)/(2) 条路径与依据）
   • · 若主张第 6(3) 条例外：评估文件与第 6(4) 条登记记录
   • · 文档覆盖的系统版本区间声明
   • · 适用日倒排的合规排期表

   常见失分点

   • · 主张"不属于高风险"却未做第 6(3) 条评估、未做第 6(4) 条登记，等于既放弃了例外又没有履行高风险义务；
   • · 把附件 I 路径与附件 III 路径的适用日混用，导致排期错开八个月；
   • · 文档不写版本区间，后续任何一次模型更新都会让整份文档处于"是否仍然有效"的争议中。

2. 2. 一、系统总体描述（附件 IV 第 1 项）

   按附件 IV 第 1 项的八个子项逐项写：(a) 预期用途、提供者名称、版本号及其与既往版本的关系；(b) 系统如何与自身之外的硬件或软件（含其他 AI 系统）交互或可被用于交互；(c) 相关软件或固件版本以及版本更新的相关要求；(d) 投放市场或投入使用的全部形态（嵌入硬件的软件包、下载、API 等）；(e) 系统预期运行的硬件描述；(f) 若系统是产品的组成部分，展示外部特征、标识与内部布局的照片或图示；(g) 面向部署者的用户界面基本描述；(h) 面向部署者的使用说明（另见第 13 条使用说明章节）。"预期用途"是全篇最关键的一句话：它界定了后续风险管理、数据治理、准确性指标与上市后监测的边界，写得越含糊，后续每一章都无法收敛。同时明确写出"合理可预见的误用"，第 9 条的风险管理要求覆盖它。

   需要附的证据

   • · 预期用途声明与合理可预见误用清单
   • · 版本关系图（与前代版本的差异说明）
   • · 接口与集成文档（API 规格、SDK 文档、硬件接口）
   • · 交付形态清单与各形态的分发渠道
   • · 产品外观/内部布局照片或图示（若为产品组件）
   • · 面向部署者的用户界面截图

   常见失分点

   • · 预期用途写成营销语（"提升企业效率的智能助手"），无法据以判断系统是否被用在声明范围之外；
   • · 漏掉 (d) 项的交付形态，尤其是同一模型既走 API 又走私有化部署时；
   • · 合理可预见误用一栏空白或写"无"，第 9 条风险管理随之无法闭环；
   • · 版本关系只写版本号，不写与前代的实质差异，公告机构无法判断是否构成第 43(4) 条的实质性修改。

3. 3. 二、系统要素与开发过程的详细描述（附件 IV 第 2 项）

   这是附件 IV 最长的一项，八个子项：(a) 开发所采用的方法与步骤，包括是否使用了第三方预训练系统或工具以及如何使用、集成或修改；(b) 设计规格——系统与算法的总体逻辑、关键设计选择及其理由与假设（包括针对哪些人或人群使用的假设）、主要分类选择、系统优化目标与各参数的相关性、预期输出与输出质量描述、以及为满足第三章第 2 节要求所做技术权衡的决定；(c) 系统架构说明（软件组件如何相互构建或输入并整合进整体处理）与开发、训练、测试、验证所用的计算资源；(d) 数据要求，以数据表（datasheet）形式描述训练方法与技术、所用训练数据集的总体描述、来源、范围与主要特征、数据如何获得与选择、标注程序（如监督学习）、数据清洗方法（如离群点检测）；(e) 依第 14 条所需人工监督措施的评估，包括为便于部署者解读输出所需的技术措施评估（对应第 13(3)(d) 条）；(f) 若适用，预先确定的变更及为保证持续符合第三章第 2 节要求所采用技术方案的详细说明；(g) 所用验证与测试程序，包括验证与测试数据及其主要特征、用于衡量准确性与稳健性及其他要求的指标、潜在歧视性影响、以及带日期与责任人签署的测试日志与测试报告（含对 (f) 项预定变更的测试）；(h) 已部署的网络安全措施。子项 (d) 与 (g) 建议直接引用独立的数据卡与评测报告，但必须在此给出索引与摘要，不能只给一个内部链接。

   需要附的证据

   • · 开发方法说明与第三方预训练模型/工具的使用与修改记录
   • · 设计规格文档（含关键设计选择的理由与假设、权衡决定）
   • · 系统架构图与算力资源清单（训练/验证/测试各阶段）
   • · 数据卡/数据表（对应附件 IV 第 2(d) 项，见数据卡模板）
   • · 标注规则、标注人员培训与质检记录
   • · 验证与测试报告（含分组公平性指标、带日期与签署的测试日志）
   • · 预定变更说明（对应第 43(4) 条"不构成实质性修改"的范围）
   • · 网络安全措施说明与测试证据

   常见失分点

   • · (g) 项的测试日志没有日期与签署人，法条明文要求"dated and signed by the responsible persons"；
   • · "潜在歧视性影响"一栏缺失或只报总体指标，没有按受保护特征分组的结果与样本量；
   • · 基座模型来自第三方却未说明如何集成与修改，责任边界无法判定；
   • · (f) 项预定变更写得过宽（"模型将持续优化"），实际等于放弃了第 43(4) 条的保护，任何更新都可能被认定为实质性修改；
   • · 算力资源只写"使用 GPU 集群"，无法支撑第 2(c) 项的核查。

4. 4. 三、监控、运行与控制的详细信息（附件 IV 第 3 项）

   附件 IV 第 3 项要求写明：系统在性能上的能力与局限，包括对预期使用对象中特定人员或人群的准确度，以及相对于预期用途的总体预期准确度；鉴于预期用途可预见的非预期结果，以及对健康、安全、基本权利与歧视的风险来源；依第 14 条所需的人工监督措施，包括为便于部署者解读输出而采取的技术措施；以及对输入数据的规格要求（如适用）。这一项的核心是"诚实地写局限"：明确列出系统在哪些输入分布、哪些人群、哪些场景下表现下降，并把这些局限同步写进第 13 条使用说明，使部署者能据以设置人工监督。输入数据规格要写到可验证：语言、分辨率、采样率、数据新鲜度、前置处理要求、以及超出规格时系统的行为（拒绝、降级还是无提示输出）。

   需要附的证据

   • · 性能能力与局限说明（按人群/场景/输入分布分组）
   • · 分组准确度报告与置信区间
   • · 非预期结果清单与风险来源分析
   • · 输入数据规格表与超规格行为说明
   • · 面向部署者的输出可解读性技术措施说明（对应第 13(3)(d) 条）

   常见失分点

   • · 只报一个总体准确率，法条要求的"特定人员或人群的准确度"完全缺失；
   • · 局限章节写"在正常使用条件下表现良好"，实际等于未写；
   • · 技术文档里承认的局限没有出现在使用说明里，部署者因此无法设置有效的人工监督；
   • · 超出输入规格时系统静默输出结果，却未在文档中披露这一行为。

5. 5. 四、性能指标适当性说明（附件 IV 第 4 项）

   附件 IV 第 4 项只有一句话——"对该特定 AI 系统性能指标适当性的说明"——但它恰恰是最容易被敷衍的一项。要回答的是：为什么选用这几个指标来衡量本系统在预期用途下的表现？把指标与预期用途的失败模式挂钩：若错误接受的代价远高于错误拒绝（如安全筛查），则仅报准确率不适当，应报召回率/漏检率并说明阈值选择；若类别高度不平衡，说明为何 F1 或 AUC-PR 优于准确率；若输出是生成式文本，说明所选的事实性、有害性、拒答率等指标如何对应到具体危害。同时说明评测集的构造：来源、规模、与训练集的隔离方式、是否覆盖第 3 项所列的弱势人群，以及评测集本身的局限。指标与阈值一旦写入本节，就会成为上市后监测（第 72 条）与严重事件判定（第 73 条）的基线，因此不要写成无法持续测量的指标。

   需要附的证据

   • · 指标选择理由说明（指标—失败模式—危害后果三列对照）
   • · 评测集说明（来源、规模、与训练集隔离证据、分组覆盖）
   • · 阈值选择的依据与敏感性分析
   • · 指标的持续测量方案（与上市后监测挂接）

   常见失分点

   • · 本项只写"采用业界通行指标"，未说明为何适用于本系统的预期用途；
   • · 评测集与训练集存在泄漏（同源采样、去重不彻底），使所有指标失去意义；
   • · 选了漂亮但与危害无关的指标（如生成任务只报 BLEU），评审人会直接质疑；
   • · 写进来的指标在生产环境无法持续采集，上市后监测随即断链。

6. 6. 五、风险管理体系的详细描述（附件 IV 第 5 项，对应第 9 条）

   附件 IV 第 5 项要求按第 9 条详细描述风险管理体系。第 9 条的要求是一个贯穿全生命周期、持续迭代、需要定期系统性复核的过程，而不是一次性文档。本节应写明：风险识别与分析的方法（覆盖按预期用途使用时的已知与合理可预见风险，以及合理可预见误用下的风险）；风险估计与评价（含上市后监测数据反馈回来的新风险）；所采取的风险管理措施及其优先级逻辑——先通过设计与开发消除或降低、再采取适当的缓解与控制措施、最后向部署者提供信息与培训；残余风险的判定与沟通方式；测试如何用于确认措施有效（包括真实条件下的测试）；以及对未成年人等弱势群体的特别考量。把风险条目与第 2、3、4 项的具体设计选择、局限与指标一一对应，使评审人可以顺着一条风险追到一项措施再追到一次测试。

   需要附的证据

   • · 风险登记表（风险—措施—验证—残余风险—复核日期）
   • · 风险管理体系程序文件与其在质量管理体系中的位置
   • · 措施有效性测试报告（含真实条件下测试的记录）
   • · 残余风险沟通材料（写入使用说明的部分）
   • · 定期复核记录与上市后监测数据回流的证据

   常见失分点

   • · 风险管理做成一次性文档，没有复核记录，不符合第 9 条"持续迭代"的性质；
   • · 风险清单只覆盖安全风险，未覆盖基本权利与歧视风险；
   • · 措施优先级颠倒：能通过设计消除的风险，却以"在使用说明中提示"了事；
   • · 残余风险在技术文档里承认，却没有传递到部署者手上的使用说明中。

7. 7. 六、生命周期内的相关变更描述（附件 IV 第 6 项）

   附件 IV 第 6 项要求描述提供者在系统生命周期中所做的相关变更。这一项在实务上就是一张变更台账，必须能回答三个问题：改了什么、何时改的、是否构成第 43(4) 条意义上的实质性修改（构成的须重新进行合格评定）。台账字段建议包括：变更编号、日期、变更类型（模型权重、训练数据、推理参数、阈值、前后处理、UI、部署环境）、变更原因（缺陷修复、性能优化、监管要求、上市后监测发现）、是否落在第 2(f) 项已声明的预定变更范围内、影响评估结论、是否重做验证测试、审批人。注意法条明文：对上市后持续学习的系统，提供者在初次合格评定时已预先确定并写入附件 IV 第 2(f) 项的变更，不构成实质性修改——这正是把 (f) 项写扎实的商业价值所在。

   需要附的证据

   • · 变更台账（字段如上，含审批人与日期）
   • · 实质性修改判定记录（逐项对照第 43(4) 条）
   • · 变更对应的回归测试报告
   • · 与第 2(f) 项预定变更范围的对照说明
   • · 触发重新合格评定的变更及公告机构沟通记录

   常见失分点

   • · 用 Git 提交历史代替变更台账，无法体现实质性修改判定与审批；
   • · 模型权重更新未入账，只记录了代码变更；
   • · 每次变更都判定"非实质性"，却拿不出第 2(f) 项的预定变更范围作依据；
   • · 变更后未重做验证测试，技术文档中的指标与在跑的系统对不上。

8. 8. 七、所适用协调标准清单与替代方案（附件 IV 第 7 项）

   附件 IV 第 7 项要求列出全部或部分适用的、其索引已在《欧盟官方公报》公布的协调标准；若未适用此类协调标准，则要详细说明为满足第三章第 2 节要求所采用的解决方案，并列出所适用的其他相关标准与技术规范。实务上，本法项下的协调标准尚未全部发布，因此大多数企业会走"未适用协调标准 + 详细说明替代方案"的路径。这条路径要写成一张逐条映射表：第 9 条至第 15 条的每一项要求 → 本系统采用的解决方案 → 所参照的其他标准（例如 ISO/IEC 42001 人工智能管理体系、ISO/IEC 23894 人工智能风险管理、ISO/IEC 42005 人工智能系统影响评估、ISO/IEC 27001 信息安全管理体系、NIST AI RMF）→ 证据位置。必须明确：引用这些标准不产生符合性推定（只有《官方公报》公布的协调标准才有），它们只是用来论证解决方案的充分性。

   需要附的证据

   • · 第 9–15 条逐条要求与解决方案映射表
   • · 所参照标准的版本号与适用范围说明
   • · 若已有协调标准：适用范围（全部/部分）与偏离说明
   • · 第三方认证证书（如 ISO/IEC 42001、ISO/IEC 27001）及其审核范围

   常见失分点

   • · 把 ISO/IEC 42001 证书当作符合性推定，写成"已符合欧盟人工智能法案"——认证范围与法案要求并不等同；
   • · 映射表只写标准名称，不写具体条款与证据位置，无法核查；
   • · 认证证书的审核范围（scope statement）未覆盖本技术文档所述系统；
   • · 未说明为何未适用某项已发布的协调标准。

9. 9. 八、欧盟符合性声明副本（附件 IV 第 8 项，对应第 47 条与附件 V）

   附件 IV 第 8 项要求附上第 47 条所述欧盟符合性声明的副本。声明本身的内容由附件 V 规定：系统名称与类型及可识别可追溯的附加标识；提供者（或其授权代表）的名称与地址；声明由提供者独自负责出具的陈述；系统符合本条例以及（如适用）其他要求出具欧盟符合性声明的欧盟法的陈述；涉及个人数据处理时，声明该系统符合条例 (EU) 2016/679、(EU) 2018/1725 与指令 (EU) 2016/680 的陈述；所使用的相关协调标准或其他共同规范的引用；如适用，公告机构名称与识别号、所执行合格评定程序的描述以及所颁发证书的标识；出具地点与日期、签署人姓名与职务、以及其代表或代为签署的对象与签名。注意第 5 项不是形式条款：它要求企业在出具声明时就已经能证明 GDPR 合规，因此本模板与 DPIA、TIA 两份文件必须同时到位。

   需要附的证据

   • · 已签署的欧盟符合性声明（按附件 V 八项逐项核对）
   • · 签署人授权文件（证明其有权代表提供者签署）
   • · 公告机构证书（如走附件 VII 路径）
   • · 支撑第 5 项个人数据合规陈述的 DPIA、TIA 与传输机制文件索引
   • · CE 标识加贴位置与方式的记录（第 48 条）

   常见失分点

   • · 声明里写了个人数据合规陈述，但公司拿不出 DPIA 与传输机制文件；
   • · 签署人无授权文件，或签署人已离职而声明未更新；
   • · 协调标准引用栏留空，同时附件 IV 第 7 项也未写替代方案；
   • · 系统版本更新后未重新出具声明，声明所述版本与在售版本不一致。

10. 10. 九、上市后性能评估体系与监测计划（附件 IV 第 9 项，对应第 72 条）

    附件 IV 第 9 项要求详细描述依第 72 条对系统上市后阶段性能进行评估的体系，包括第 72(3) 条所述的上市后监测计划。注意第 72(3) 条已被条例 (EU) 2026/1744（AI Omnibus）第 1(30) 条整条替换：现行文本仍明确该计划是技术文档的一部分，但删除了原先"由委员会以实施法案规定计划模板与要素清单（原定 2026 年 2 月 2 日前通过）"的授权，改为"委员会在充分考虑人工智能委员会意见的基础上，应当在 2027 年 9 月 2 日前就上市后监测计划通过指南（含模板）"。因此不要再按"等实施法案模板"排期；在该指南发布前，本节应自行写清：监测数据的来源与采集方式（部署者反馈、日志、投诉、事件、抽样复核）、监测指标与阈值（与第 4 项指标一致）、数据分析频率与责任人、发现性能下降或新风险时的触发与处置路径、与风险管理体系（第 9 条）的回流机制、以及与严重事件报告（第 73 条）的衔接判据。同时写明第 12 条日志留存安排如何支撑监测：留存期限、可访问范围、以及在部署者侧与提供者侧的分工。

    需要附的证据

    • · 上市后监测计划（数据来源、指标、阈值、频率、责任人）
    • · 监测数据采集的技术实现说明与日志留存配置
    • · 最近若干期监测报告与趋势分析
    • · 监测发现回流至风险管理与变更台账的记录
    • · 严重事件判定与升级判据（与第 73 条衔接）
    • · 与部署者的数据共享与反馈协议条款

    常见失分点

    • · 监测计划写了但从未产出过一份监测报告，体系形同虚设；
    • · 监测指标与附件 IV 第 4 项的指标不一致，趋势无法与上市前基线对比；
    • · 日志留存期限短于监测周期，事后无法复盘；
    • · 未与部署者约定数据反馈，提供者实际上拿不到任何运行数据；
    • · 监测发现的问题没有回流到第 9 条风险管理与第 6 项变更台账，形成闭环断点。

11. 11. 十、文档留存、语言与调阅安排

    技术文档不是写完即止的交付物，还要能被"随时取出"。本节写明：文档保存主体与地点（提供者、欧盟授权代表各持有哪些内容）、保存期限与起算点、版本与访问控制、以及市场监管机关依第 74(12) 条要求全面访问文档以及训练、验证、测试数据集（必要时通过 API 或其他远程技术手段）时的响应流程与时限。另需说明第 74(13) 条的源代码访问条件——仅在访问源代码为评估符合性所必需、且基于数据与文档的测试或审计程序已用尽或证明不足这两项条件同时满足、并经合理请求时。语言方面，写明文档以何种语言维护、向哪一成员国主管机关提交时提供何种语言版本、以及翻译件与原件不一致时以何者为准。第三国提供者还须写明欧盟授权代表（第 22 条）持有文档副本的安排。

    需要附的证据

    • · 文档保存与版本控制说明（系统、权限、备份）
    • · 欧盟授权代表委任书及其持有文档范围的约定
    • · 监管调阅响应流程（联系人、时限、可提供的访问方式）
    • · 语言版本清单与翻译准确性核对记录
    • · 远程访问（API）能力的技术说明与访问日志

    常见失分点

    • · 文档分散在多个团队的私有空间，监管要求提供时无法在合理时间内汇总；
    • · 欧盟授权代表只签了委任书，手上没有任何文档副本；
    • · 只有中文版本，向成员国机关提交时临时翻译，术语前后不一致；
    • · 未预先设计训练/验证/测试数据集的受控访问方式，面对第 74(12) 条请求时陷入被动。