Eu Ai Act Fria

---
name: eu-ai-act-fria
description: 评估依据《欧盟 AI 法案》第 27 条是否需要对特定高风险 AI 部署进行基本权利影响评估（FRIA），并构建或起草该评估。涵盖部署者范围门槛（公共机构和提供公共服务的私营实体）、受影响群体映射、《宪章》权利分析、相称性、保障措施评估、剩余风险、DPIA/FRIA 互动、第 27 条第 3 款下的通知，以及 DACH（德国、奥地利、瑞士）特定考量。当被问及 FRIA 义务、第 27 条范围、基本权利与 AI 或部署者评估义务时使用。
---

# 基本权利影响评估（FRIA）——欧盟 AI 法案第 27 条

评估部署者是否必须依据《欧盟 AI 法案》第 27 条进行基本权利影响评估（FRIA），并在系统投入使用前为特定高风险 AI 用例构建该评估。

**重要提示：** 本技能支持结构化的法律合规工作流。它**不**替代法律判断。FRIA 本质上具有情境性，绝不应被当作打勾式的例行公事。始终明确识别假设、开放问题和有争议的解释。

**开始之前：** 如果您**尚未**确认该系统是**高风险 AI 系统**，请先使用**欧盟 AI 法案系统分类器**。第 27 条仅在**高风险 AI 系统**的语境下适用，且仅适用于**部分部署者**。

## FRIA 工作流

按顺序遵循此流程。不要跳过范围问题。

### 第 1 步——确认门槛问题：这是高风险 AI 系统吗？

第 27 条仅在预期用途涉及 AI 法案意义上的**高风险 AI 系统**时适用。

检查：
1. 该系统是否已依附录 III 被归类为高风险，或被归类为产品安全高风险系统？
2. 部署者希望使用它的具体用例是什么？
3. 分析是否与具体部署语境挂钩，而非仅抽象地针对该工具？

**如高风险地位尚未确认：** 在此停止，先使用**欧盟 AI 法案系统分类器**。

### 第 2 步——范围：该部署者是否实际需要进行 FRIA？

这是最重要的门槛步骤。

第 27 条**不**适用于所有高风险 AI 的部署者。它适用于以下部署者：
- **公法管辖的机构**，或
- **提供公共服务的私营实体**，包括银行、保险和医疗保健服务等语境。

仔细评估：
1. 该实体是公共机关、市政府、部委、机构、公立大学、法定机构，还是其他公法管辖的机构？
2. 如为私营：它是否在相关语境中提供**公共服务**，而非仅提供私营商业工具？
3. 该实体是否作为**部署者**行事（依其权限使用系统），而非仅作为提供者/进口商/分销商？
4. 该用例是否是部署者自身的运营使用，而非他人假设的下游使用？

**如为"否"：** 记录第 27 条 FRIA 对该部署者非强制，同时第 26 条下的单独部署者义务仍可能适用。

**如为"是"：** 继续。

### 第 3 步——时机：FRIA 必须何时完成？

FRIA 必须：
- 在**首次将高风险 AI 系统投入**用于特定用例**之前**进行，
- 在系统、其目的或其使用语境发生**重大变化**时再次进行，且
- 在**具体部署语境/用例**层面进行，而非仅对每套系统抽象地一次。

检查：
1. 该系统是否已针对此用例上线？
2. 这是新部署、试点、采购还是运营扩展？
3. 是否有任何实质性变化：模型、数据、用户群体、决策逻辑、人工监督、地理、目的或集成？
4. 是否存在需要单独或模块化 FRIA 的多个用例？

### 第 4 步——精确定义用例和运营语境

第 27 条第 2 款要求 FRIA 以部署者的实际流程为依据。

记录：
- 系统和提供者的名称
- 高风险资格和法律依据
- 系统将被用于的业务/行政流程
- 使用目的和预期输出
- 受系统影响的决策点
- 涉及的人工行为者
- 个人是否会遭受不利影响、被拒绝访问、差别待遇、监视或被排斥

如流程描述含糊，FRIA 将很薄弱。推动运营层面的具体性。

### 第 5 步——映射受影响的人、群体和所涉权利

第 27 条第 2 款明确要求部署者识别**可能受影响的自然人及群体类别**。

映射：
1. 直接受影响的个人
2. 间接受影响的群体
3. 弱势群体或结构性不利群体
4. 对抗结果能力有限的人
5. 系统影响劳动力决策或监控时的员工/劳动者

然后识别**《欧盟基本权利宪章》**下哪些**基本权利**在现实中处于风险之中，在相关时包括：
- 人的尊严
- 私生活受尊重
- 个人数据保护
- 不受歧视
- 男女平等
- 儿童权利
- 表达与信息自由
- 经营自由
- 消费者保护
- 良好行政权
- 有效救济和公平审判权
- 无罪推定和辩护权
- 视语境而定的医疗相关权利和社会保护

→ 详细的权利目录和示例，阅读 references/fundamental-rights-catalogue.md。

### 第 6 步——评估具体的损害风险

第 27 条第 2 款要求识别**可能影响**所识别的人/群体的**具体损害风险**。

对每项相关权利和受影响群体评估：
- 可能发生什么损害？
- 通过什么机制？
- 谁承担负担？
- 损害是暂时还是持久？
- 能否逆转或补救？
- 受影响者甚至会知道系统对结果有贡献吗？

使用结构化评估，涵盖：
- 影响发生的**可能性**
- 影响发生时的**严重性**
- **可逆性** / 补救或撤销损害的能力
- **规模** / 受影响人数
- 运营目标与权利影响之间的**相称性**
- 为此目的使用 AI 的**必要性**

→ 评分方法和决策框架，阅读 references/fria-methodology.md。

### 第 7 步——评估保障措施、人工监督和数据质量措施

第 27 条第 2 款要求描述：
- **人工监督措施**，以及
- 风险显现时要采取的措施，
- 另外，对第 26 条第 3 款第(a)项下的部署者，确保遵守相关**数据质量**要求的措施。

检查现有保障措施，例如：
- 不利决定前的人工审查
- 升级阈值和否决权
- 明确的角色分配和问责
- 日志记录和可追溯性
- 输入数据的质量检查
- 偏见/错误监控
- 用户培训和操作说明
- 投诉机制和救济途径
- 事件响应和停止使用程序
- 采购控制和提供者的合同承诺

问题不在于保障措施是否纸面上存在，而在于它是否**对此特定风险有效**。

### 第 8 步——确定剩余风险、相称性和放行/不放行建议

在计入保障措施后，评估**剩余风险**。

问：
1. 在具体语境中，对权利的干预是否正当、必要且相称？
2. 是否有侵入权利程度更低的替代方案？
3. 弱势群体是否暴露于不成比例的负担？
4. 监督和投诉机制是否足够有力，足以捕捉现实世界的失败？
5. 使用应继续、仅在附条件下继续，还是应在缓解措施实施前不继续？

这是核心判断部分。不要因为控制存在就自动批准。解释推理。

### 第 9 步——第 27 条第 3 款下的通知分析

如 FRIA 识别出对自然人或群体的权利构成**具体风险**，部署者必须通知相关的**市场监督机构**。

如风险涉及个人数据处理且在数据保护法下具有相关性，部署者还必须通知主管的**数据保护机构**。

检查：
1. FRIA 是否识别出具体风险，而不仅仅是一般的抽象可能性？
2. 相关成员国和行业中的哪个机构具有管辖权？
3. 该事项是否也触发 GDPR 分析、协商或单独的监管接触？
4. 应通知什么、附什么证据、在什么阶段？

→ 机构映射和通知结构，阅读 references/notification-requirements.md。

### 第 10 步——检查合并 FRIA + DPIA 是否适当

依第 27 条第 4 款，在相关时，FRIA 可以与 GDPR 第 35 条数据保护影响评估（DPIA）**一起**进行。

不要盲目合并。首先确定：
- 是否处理个人数据？
- 依 GDPR 第 35 条是否独立需要 DPIA？
- 主要风险是否仅为隐私/数据保护风险，还是更广泛的权利风险？
- 联合结构是会提高连贯性，还是会模糊更广泛的基本权利分析？

**关键点：** DPIA 和 FRIA 有重叠，但它们不是同一件事。FRIA 超越数据保护，延伸到更广泛的《宪章》权利、程序公正、可及性、平等和救济。

→ 重叠与整合指引，阅读 references/dpia-fria-interaction.md。

### 第 11 步——在相关时添加 DACH 叠加

如部署在德国、奥地利或瑞士，考虑当地治理和宪法叠加。

特别是在德国，评估：
- 与**《基本法》（Grundgesetz）**在《欧盟宪章》之外的额外分析视角互动
- **BfDI** 或 **Landesdatenschutzbehörden** 的权限
- **BNetzA** 或行业特定监督机构的潜在角色
- 公共采购影响（例如，规格、透明度、评标阶段治理）
- 员工受影响时的 **BetrVG** 劳资委员会参与权
- 相称性、平等待遇和裁量记录等行政法原则

→ DACH 特定分析，阅读 references/dach-specific.md。

## 快速问题集

在起草 FRIA 之前的受理阶段使用这些问题：

**系统与范围**
1. 该 AI 系统是什么，是否已被确认为**高风险**？
2. 该部署者的确切**用例**是什么？
3. 部署者是**公共机构**还是**提供公共服务的私营实体**？
4. 该实体是否作为**部署者**行事，而非仅作为提供者？

**运营语境**
5. 系统将用于哪个流程或决策工作流？
6. 系统生成什么输出，实践中如何使用？
7. 系统将多频繁地使用、在什么时间段内、以什么规模？
8. 系统周围的人工决策者或审查者是谁？

**受影响的人与权利**
9. 哪些人或群体可能直接或间接受影响？
10. 是否涉及弱势群体、儿童、患者、客户、福利申请人、求职者或员工？
11. 哪些基本权利可能被现实地干预？
12. 每个关键群体最坏的可能损害是什么？

**保障措施与治理**
13. 实际运营中存在什么人工监督措施？
14. 存在什么投诉、上诉或救济机制？
15. 系统产生错误、偏见或不利结果时会发生什么？
16. 是否有数据质量控制、日志、审计或监控流程？

**DPIA / 通知 / 变更**
17. 是否处理个人数据，DPIA 是否已完成或计划中？
18. 使用是否已经开始，还是该评估仍在部署前？
19. 自上次评估以来是否有重大变化？
20. FRIA 是否识别出可能需要通知的**具体风险**？

如关键答案缺失，说明假设并将其识别为阻断项或法律风险缺口。

## 参考文件

在评估过程中按需加载：

| 文件 | 何时阅读 |
|------|-------------|
| references/fundamental-rights-catalogue.md | 映射所涉权利——《宪章》权利、AI 实际影响示例 |
| references/fria-methodology.md | 运行评估——评分、相称性、剩余风险、决策逻辑 |
| references/dpia-fria-interaction.md | 确定是否/如何将 FRIA 与 GDPR DPIA 合并 |
| references/notification-requirements.md | 确定是否需要通知以及如何构建 |
| references/dach-specific.md | 德国/奥地利/瑞士叠加——机构、采购、劳资委员会、宪法视角 |
| references/templates.md | 产出实用成果——FRIA 报告、矩阵、通知、管理层简报 |

## 输出格式

每次 FRIA 工作应产出以下交付物：

1. **FRIA 范围备忘录**——对第 27 条是否适用的简短认定，包括部署者地位、高风险地位、用例边界、时机，以及 FRIA 是否强制。

2. **FRIA 报告 / 草稿 FRIA**——涵盖第 27 条第 2 款要素的结构化评估：流程描述、预期使用期间/频率、受影响群体、所涉权利、具体损害风险、监督措施、缓解/治理措施、剩余风险和通知分析。

3. **权利影响矩阵**——实用的表格，映射受影响群体、相关权利、风险机制、固有风险、现有保障措施、剩余风险和所需行动。

4. **管理层简报**——面向领导层的一页决定说明，解释部署是否可以继续、在什么条件下，以及上线前必须发生什么。

5. **通知包（如需要）**——致市场监督机构以及（在相关时）主管数据保护机构的通知草稿。

→ 模板和示例措辞，阅读 references/templates.md。

## 关键合规说明

- **这是部署者义务，而非提供者义务。**
- **并非所有部署者都在范围内。** 门槛问题是部署者是否为公共机构或提供公共服务的私营实体。
- **FRIA 是用例特定的。** 如系统在实质性不同的语境中使用，一个系统可能需要多份 FRIA。
- **不要将 FRIA 与 DPIA 混淆。** DPIA 可能覆盖部分相同领域，但很少能单独足够。
- **当前时间线：** 依现行法律，第 27 条义务目前计划自 **2026 年 8 月 2 日** 起适用。数字综合（Digital Omnibus）简化包（2025 年 12 月委员会提案）于 2026 年 5 月 7 日推进至理事会/议会的临时政治协议；依该协议，附录 III 高风险义务（包括第 27 条 FRIA 触发）将移至 **2027 年 12 月 2 日**。该协议**尚未成为已通过的法律**——待正式通过并在《官方公报》公布。除非且直到修正案被正式通过并生效，适用已颁布的法律。

## 免责声明

本技能为《欧盟条例 (EU) 2024/1689》（欧盟 AI 法案）第 27 条提供结构化工作流支持。它不构成法律意见。某实体是否属于公法管辖的机构、私营公共服务提供者，或某具体风险是否需要通知，可能取决于国家法律、行业规则、采购结构和监督实践。分析应由合格律师审查，尤其是在部署、机构接触或高影响运营决定之前。