# Eu AI Act High Risk Implementation Readiness

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

- Skill: `cslawyer1985/eu-ai-act-high-risk-implementation-readiness` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/eu-ai-act-high-risk-implementation-readiness`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/eu-ai-act-high-risk-implementation-readiness/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/eu-ai-act-high-risk-implementation-readiness

---


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

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

如系统**尚未**被归类，请先使用 **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) 条例外可能适用、涉及生物识别或行业特定问题、或符合性评估路径选择不明时，用户应咨询合格法律顾问和相关技术利益相关方核验立场。

---

## 良好样态

本技能的强结果不仅仅是“一份合规备忘录”。它是：
- 清晰的范围立场
- 按义务领域的可辩护就绪度评分
- 具体的证据清单
- 分优先级的实施路线图
- 具名所有权
- 通往符合性评估、部署就绪和持续监测的务实路径

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