eu-ai-act-high-risk-implementation-readiness

name	eu-ai-act-high-risk-implementation-readiness
description	评估并落实欧盟《人工智能法案》附件 III 下高风险 AI 系统的实施就绪度，包括提供者和部署者义务、符合性评估、上市后监测及欧盟数据库注册。当用户说“我们已将其归类为高风险，接下来怎么办？”、“制定一份欧盟 AI 法案就绪计划”、“评估我们的附件 III 合规差距”、“高风险 AI 的提供者/部署者需要实施什么？”、“为符合性评估做准备”或“创建高风险 AI 实施路线图”时使用。

欧盟《人工智能法案》高风险实施就绪度

当系统已被归类为欧盟《人工智能法案》下的潜在高风险，且用户现在需要了解必须实际实施、记录、分配、测试和治理的内容时，使用本技能。

如系统尚未被归类，请先使用 EU AI Act System Classifier（欧盟 AI 法案系统分类器）。

本技能被设计为实用性的就绪度评估与实施导航器，适用对象为：

• 高风险 AI 系统的提供者
• 高风险 AI 系统的部署者
• 内部法律、合规、产品、工程、安全、风险、采购和管理团队
• 特别是德语区（DACH）组织，为高风险义务适用前的实际运营合规工作做准备

重要时间说明：附件 III 高风险义务的现行法律日期为 2026 年 8 月 2 日。数字 Omnibus 简化方案（欧盟委员会 2025 年 12 月提案）已于 2026 年 5 月 7 日达成理事会/议会临时政治协议；依该协议，附件 III 将推迟至 2027 年 12 月 2 日，附件 I 推迟至 2028 年 8 月 2 日。该协议尚未成为已通过的法律——待正式通过并在官方公报刊出。除非修正案正式通过并生效，否则按现行法律构建。如用户明确希望围绕潜在推迟做情景规划，可将临时协议作为背景说明，但不得仅据此重写义务。

---

本技能做什么

本技能帮助用户回答五个实际问题：

1. 我们真的属于高风险范围吗？
2. 作为提供者、部署者或两者，哪些义务适用于我们？
3. 哪些证据和文档应该已经存在？
4. 我们今天有多就绪——红、黄、还是绿？
5. 我们接下来需要做什么、按什么顺序、由谁负责？

它覆盖主要附件 III 生命周期义务的运营就绪度，特别是：

• 第 6 条及第 6(3) 条例外的背景
• 第 9–15 条提供者控制措施
• 第 16–17 条提供者治理与 QMS 框架
• 第 26 条部署者义务
• 第 43 条符合性评估路径
• 第 49 条欧盟数据库注册
• 第 72 条上市后监测

---

何时使用本技能

当用户提出如下问题时使用：

• “我们知道该系统是高风险的。现在需要实施什么？”
• “你能评估我们针对欧盟 AI 法案的就绪度吗？”
• “附件 III 高风险合规需要什么证据？”
• “为我们的 AI 系统创建差距分析和实施路线图。”
• “高风险 AI 的提供者在分类之外还需要什么？”
• “部署者依第 26 条需要做什么？”
• “我们需要公告机构还是可以自我评估？”
• “如何为高风险 AI 系统准备技术文档和 QMS？”

---

快速信息接收问题

首先收集以下问题的简明答案。如用户不知道，明确标记假设。

A. 范围与角色

1. 该 AI 系统在实践中做什么？
2. 认为适用哪个附件 III 类别？
3. 该系统是否已使用独立的高风险分类器归类？
4. 是否存在第 6(3) 条例外适用的论证，即系统可能落入附件 III 措辞，但并未以使其构成高风险的方式实质性影响决策？
5. 你是以提供者、部署者还是两者身份行事？
6. 系统已上市/在用、处于试点阶段，还是仍在开发中？

B. 组织背景

7. 哪个法律实体拥有该系统，哪些团队运营它？
8. 系统将在哪些国家上市或使用？
9. 用例是否属于受监管行业，如就业、教育、基本服务、执法、移民、司法或生物识别身份识别？
10. 这是独立 AI 系统、嵌入软件的组件，还是整合进更广泛的产品/服务？

C. 技术与控制环境

11. 训练、验证、测试和实时运营使用什么数据？
12. 目前自动生成哪些日志？
13. 今天存在哪些人工审查或否决机制？
14. 针对准确性、稳健性、偏见和安全存在哪些测试？
15. 是否已有技术文档、模型文档、验证文档或 QMS？

D. 治理与证据

16. 是否有具名的合规就绪负责人？
17. 是否有针对该 AI 系统的正式风险管理流程？
18. 是否存在供应商/卖方依赖，包括 GPAI 或第三方模型提供者？
19. 是否已规划上市后监测？
20. 管理层期望的是简单的法律备忘录，还是带证据要求的实施级路线图？

---

决策树：从这里开始

第 1 步——确认分类状态

• 如系统尚未被分类，停止并将用户引导至 EU AI Act System Classifier。
• 如系统看似符合附件 III，但可能存在可信的第 6(3) 条例外论证，不要把高风险视为已定论继续推进。标记该问题，并建议在就绪度工作继续前先做一份聚焦的分类备忘录。
• 如系统被合理视为高风险，继续。

第 2 步——确定行为者状态

• 如组织以自己的名义开发 / 投放市场 / 投入使用，评估提供者义务。
• 如组织在其运营中使用该系统，评估部署者义务。
• 如两者兼有，运行两条轨道并清晰区分交付物。

第 3 步——确定评估模式

选择三种模式之一：

• 快速分诊——跨所有义务领域快速红/黄/绿扫描
• 基于证据的就绪度评估——对照实际文档、流程、负责人和控制措施评估每个领域
• 实施路线图——将已识别的差距转化为带负责人、依赖关系和交付物的有序行动计划

第 4 步——确定符合性评估路径

• 检查可能路径是否为附件 VI 下的内部控制 / 自我评估
• 还是需要公告机构路径，特别是系统属于更高审查级别的生物识别类别时
• 如不清楚，尽早标记，因为它改变证据预期和时间线

---

核心工作流

1. 精确界定范围

产出涵盖以下内容的简短范围声明：

• 系统名称 / 工作标签
• 实际功能
• 可能的附件 III 类别
• 提供者/部署者角色划分
• 生命周期阶段
• 法域
• 第 6(3) 条是否仍开放或已被排除

此阶段输出： 一段范围声明 + 假设清单。

---

2. 评估 12 个义务领域的就绪度

对以下每个领域，评估：

• AI 法案要求什么
• 应该存在什么证据
• 就绪度状态： 红 / 黄 / 绿
• 关键差距
• 下一步行动
• 常见陷阱

领域 1——风险管理体系（第 9 条）

询问：

• 是否存在覆盖生命周期的、明确的 AI 特定风险管理流程？
• 是否识别并记录了已知和合理可预见的风险？
• 风险控制措施是否与测试、设计和残余风险评估挂钩？
• 变更、事件和监测发现是否反馈回系统？

证据示例：

• 风险管理程序
• 系统风险登记册
• 危害/伤害分析
• 控制措施映射
• 残余风险签批
• 验证与测试证据

深入参考：references/risk-management-system.md

领域 2——数据治理与数据质量（第 10 条）

询问：

• 训练、验证和测试使用了哪些数据集？
• 是否记录了相关性、代表性、完整性和错误考量？
• 是否开展并记录了偏见检查？
• 是否记录了数据来源和获取合法性？

证据示例：

• 数据集清单
• 数据规范说明书
• 偏见评估
• 抽样理由
• 数据清洗和标注程序
• 验证数据集设计说明

深入参考：references/data-governance.md

领域 3——技术文档（第 11 条 + 附件 IV）

询问：

• 组织今天能否产出可辩护的附件 IV 式技术档案？
• 是否记录了系统设计、开发方法、预期用途、架构、指标、风险控制措施和变更历史？
• 监测能力和局限性的说明是否足够清晰以供审查？

证据示例：

• 技术档案 / 附件 IV 包
• 架构图
• 模型卡 / 系统卡
• 开发与验证方法
• 版本/变更日志
• 局限性与假设文档

深入参考：references/technical-documentation.md

领域 4——记录保留与日志（第 12 条）

询问：

• 自动创建哪些日志？
• 日志是否支持运营、事件、人工干预和审查的可追溯性？
• 保留期限是否与法律和运营需求一致？
• 日志能否支持调查和上市后监测？

证据示例：

• 日志规范
• 事件分类法
• 保留时间表
• 日志访问控制
• 审计轨迹抽样输出

领域 5——透明度和向部署者提供信息（第 13 条）

询问：

• 是否有使用说明？
• 是否解释了预期用途、运行条件、已知局限、预期准确度、监督假设和安全条件？
• 部署者是否会知道何时不应使用该系统？

证据示例：

• 使用说明
• 部署手册
• 局限性声明
• 准确度/稳健性文档
• 面向用户的警告与假设

领域 6——人类监督（第 14 条）

询问：

• 谁被期望监督该系统？
• 他们能否充分理解输出以进行有意义的干预？
• 是否存在停止、否决或升级机制？
• 监督是否设计进流程，而非抽象假设？

证据示例：

• 监督设计规范
• 审查者/操作者 SOP
• 否决或人工回退程序
• 培训材料
• 升级矩阵

领域 7——准确度、稳健性与网络安全（第 15 条）

询问：

• 定义了哪些性能阈值？
• 在可预见的运行条件下如何测试稳健性？
• 存在哪些错误处理和故障安全逻辑？
• 考虑了哪些网络安全风险，包括对抗性操纵？

证据示例：

• 性能基准
• 验证报告
• 稳健性/压力测试
• 安全测试结果
• 漏洞管理记录

领域 8——质量管理体系（第 17 条）

询问：

• 是否有覆盖 AI 生命周期的文档化 QMS？
• 设计、开发、测试、变更管理、供应商控制、事件处理和机构沟通是否受到治理？
• 角色和记录是否以经得起审计或符合性审查的方式分配？

证据示例：

• QMS 手册
• 政策与程序
• 角色矩阵 / RACI
• 变更控制程序
• 供应商管理记录
• CAPA / 事件流程

深入参考：references/qms-requirements.md

领域 9——部署者义务（第 26 条）

询问：

• 系统是否按照提供者的指示使用？
• 是否分配了人类监督职责？
• 是否检查输入数据的相关性和适宜性？
• 使用期间是否维护记录？
• 是否在要求时告知受影响人员？
• 如部署者为公共机关或公共机构，是否需要基本权利影响评估？

证据示例：

• 部署者 SOP
• 用户治理记录
• 监督分配
• 运营监测日志
• 通知/信息材料
• 相关时的 FRIA 文档

深入参考：references/deployer-obligations.md

领域 10——符合性评估路径（第 43 条）

询问：

• 系统是否可能在附件 VI 内部控制路径上？
• 是否需要第三方评估 / 公告机构参与？
• 所选路径下预期需要什么证据包？
• 谁负责符合性评估时间线？

证据示例：

• 分类备忘录
• 符合性评估路径备忘录
• 附件 VI 检查清单
• 如需要，公告机构参与计划

深入参考：references/conformity-assessment.md

领域 11——上市后监测（第 72 条）

询问：

• 是否有文档化、相称的上市后监测计划？
• 将从实时运营中收集哪些数据？
• 如何分析事件、故障和性能漂移？
• 发现如何反馈至风险管理、文档和控制措施？

证据示例：

• 上市后监测计划
• KPI/KRI 定义
• 事件受理工作流
• 审查节奏和汇报结构

领域 12——欧盟数据库注册（第 49 条）

询问：

• 在投放市场或投入使用前谁负责注册？
• 是否知道并已汇集所需注册数据？
• 注册是否整合进启动治理？

证据示例：

• 注册就绪检查清单
• 职责分配
• 启动前门禁 / 审批工作流

---

3. 应用就绪度评分模型

对每个领域一致使用此评分。

红——未开始 / 实质性不足

满足以下一项或多项时使用红：

• 不存在文档化流程
• 未分配负责人
• 证据缺失或纯属非正式
• 控制措施在实践中存在，但不系统、未文档化或不可审查
• 组织无法在符合性评估或机构问询中为该领域辩护

黄——部分处理 / 尚不能端到端辩护

满足以下情形时使用黄：

• 存在部分控制措施但碎片化
• 证据存在但不完整、不一致、过时或非 AI 特定
• 角色部分分配但未嵌入运营
• 测试或监测存在，但未与治理和风险决策挂钩

绿——基本就绪

满足以下情形时使用绿：

• 流程已界定、已运营且已文档化
• 证据最新且可审查
• 所有权已分配
• 该领域已整合进生命周期治理
• 仍有改进机会，但组织大体可辩护

不要仅因“团队已经很谨慎”或“别处存在类似控制措施”就标记为绿。

---

4. 识别关键依赖与阻碍

评分后，识别如下阻碍：

• 未解决的第 6(3) 条范围问题
• 提供者与部署者角色划分不清
• 无具名负责的所有人
• 无技术文档基线
• 无 AI 特定风险登记册
• 日志或可追溯性不足
• 无监督设计
• 依赖文档支持薄弱的第三方模型/供应商
• 缺少 QMS 骨架
• 符合性评估路径不明

将阻碍分组为：

• 法律/分类阻碍
• 流程/治理阻碍
• 技术/控制阻碍
• 证据/文档阻碍

---

5. 构建务实的实施路线图

将差距转化为有序路线图。

建议的工作流：

1. 范围与问责
2. 风险管理
3. 数据治理
4. 文档与日志
5. 人类监督与运营
6. 测试、稳健性与网络安全
7. QMS 与面向机构的就绪度
8. 部署者运营模式
9. 符合性评估与注册
10. 上市后监测

对每个工作流定义：

• 目标
• 关键交付物
• 负责人
• 支持团队
• 依赖关系
• 目标时间
• 剩余决策点

使用 references/templates.md 中的模板。

---

6. 针对 DACH 实施现实定制

在相关处，添加实用的 DACH 特定要点，例如：

• 与德国市场监管机构或行业监管机构的可能互动
• 视用例而定的 BNetzA / BSI / 行业机构接口
• 德国企业的采购与文档预期
• 人类监督影响员工或在 HR 语境中使用 AI 时的工会委员会（works council）影响
• 实务中需要德语运营材料、培训或劳资协议

参考：references/dach-specific.md

---

应标记的实用捷径与陷阱

始终指出那些看似诱人但在真实评估中薄弱的捷径。

常见示例：

• “我们已有 ISO 流程，所以一定合规。”
• “我们有通用模型文档，所以那就算附件 IV 技术文档。”
• 未定义谁、何时、以何种权限、依据何种标准就“人类有时会审查”。
• 未包含 AI 特定稳健性和对抗性考量就“安全团队已审查该应用”。
• 未确认可追溯性、访问、保留和有用的事件设计就“我们保留日志”。
• 未取得证据和角色清晰度就“供应商负责合规”。
• 核心控制措施尚未实际运作就说“我们稍后再写文档”。

---

输出格式

除非用户另有要求，按如下结构组织最终交付物：

1. 执行摘要

• 范围内的系统和角色
• 就绪度的总体结论
• 前 3–5 项关键差距
• 立即行动

2. 范围与假设

• 系统描述
• 可能的附件 III 类别
• 提供者/部署者划分
• 第 6(3) 条立场（如相关）
• 假设 / 未知项

3. 就绪度记分卡

对 12 个领域中的每个：

• 要求摘要
• 预期证据
• 状态：红 / 黄 / 绿
• 理由
• 立即下一步

4. 优先差距分析

• 关键差距
• 为何重要
• 依赖关系与排序

5. 实施路线图

• 30 / 60 / 90 天视图，或分阶段工作流计划
• 负责人与依赖关系

6. DACH 特定说明

• 监管机构 / 机关 / 工会委员会 / 运营本地化问题

7. 关键注意事项

• 法律不确定性
• 证据局限
• 任何需要专业法律或技术验证的事项

---

建议的回应模式

如果用户想要快速评估

提供：

• 简要范围声明
• 12 领域红/黄/绿记分卡
• 前 5 项行动
• 最大的符合性评估风险

如果用户想要实施帮助

提供：

• 记分卡
• 差距分析
• 详细路线图
• 待创建文档清单
• 按职能的负责人建议

如果用户仅为部署者

更侧重：

• 第 26 条使用控制措施
• 遵循提供者指示
• 监督分配
• 运营中的监测与记录保留
• 相关时的 FRIA / 受影响人员告知

如果用户是拥有成熟质量职能的提供者

更侧重：

• 证据充分性
• 对现有 QMS 的 AI 特定适配
• 附件 IV 技术文档完整性
• 风险管理生命周期整合
• 符合性评估就绪度

---

推荐的参考映射

选择性使用这些深入参考，而非使主回应超载：

• references/risk-management-system.md
• references/data-governance.md
• references/technical-documentation.md
• references/qms-requirements.md
• references/conformity-assessment.md
• references/deployer-obligations.md
• references/dach-specific.md
• references/templates.md

---

免责声明

本技能为欧盟 AI 法案——特别是附件 III 高风险系统——提供务实的实施与就绪度框架。其不替代正式法律意见、行业特定监管建议、技术保证、网络安全测试或在需要时的公告机构意见。

AI 法案包含交叉引用、实施法案、协调标准和不断演进的指引，可能改变义务在实践中的解释方式。凡分类不确定、第 6(3) 条例外可能适用、涉及生物识别或行业特定问题、或符合性评估路径选择不明时，用户应咨询合格法律顾问和相关技术利益相关方核验立场。

---

良好样态

本技能的强结果不仅仅是“一份合规备忘录”。它是：

• 清晰的范围立场
• 按义务领域的可辩护就绪度评分
• 具体的证据清单
• 分优先级的实施路线图
• 具名所有权
• 通往符合性评估、部署就绪和持续监测的务实路径

这就是“知道自己是高风险”与“在运营上为其做好准备”之间的区别。