| 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 系统时适用。
检查：
- 该系统是否已依附录 III 被归类为高风险，或被归类为产品安全高风险系统？
- 部署者希望使用它的具体用例是什么？
- 分析是否与具体部署语境挂钩，而非仅抽象地针对该工具？
如高风险地位尚未确认： 在此停止，先使用欧盟 AI 法案系统分类器。
第 2 步——范围：该部署者是否实际需要进行 FRIA？
这是最重要的门槛步骤。
第 27 条不适用于所有高风险 AI 的部署者。它适用于以下部署者：
- 公法管辖的机构，或
- 提供公共服务的私营实体，包括银行、保险和医疗保健服务等语境。
仔细评估：
- 该实体是公共机关、市政府、部委、机构、公立大学、法定机构，还是其他公法管辖的机构？
- 如为私营：它是否在相关语境中提供公共服务，而非仅提供私营商业工具？
- 该实体是否作为部署者行事（依其权限使用系统），而非仅作为提供者/进口商/分销商？
- 该用例是否是部署者自身的运营使用，而非他人假设的下游使用？
如为"否"： 记录第 27 条 FRIA 对该部署者非强制，同时第 26 条下的单独部署者义务仍可能适用。
如为"是"： 继续。
第 3 步——时机：FRIA 必须何时完成？
FRIA 必须：
- 在首次将高风险 AI 系统投入用于特定用例之前进行，
- 在系统、其目的或其使用语境发生重大变化时再次进行，且
- 在具体部署语境/用例层面进行，而非仅对每套系统抽象地一次。
检查：
- 该系统是否已针对此用例上线？
- 这是新部署、试点、采购还是运营扩展？
- 是否有任何实质性变化：模型、数据、用户群体、决策逻辑、人工监督、地理、目的或集成？
- 是否存在需要单独或模块化 FRIA 的多个用例？
第 4 步——精确定义用例和运营语境
第 27 条第 2 款要求 FRIA 以部署者的实际流程为依据。
记录：
- 系统和提供者的名称
- 高风险资格和法律依据
- 系统将被用于的业务/行政流程
- 使用目的和预期输出
- 受系统影响的决策点
- 涉及的人工行为者
- 个人是否会遭受不利影响、被拒绝访问、差别待遇、监视或被排斥
如流程描述含糊，FRIA 将很薄弱。推动运营层面的具体性。
第 5 步——映射受影响的人、群体和所涉权利
第 27 条第 2 款明确要求部署者识别可能受影响的自然人及群体类别。
映射：
- 直接受影响的个人
- 间接受影响的群体
- 弱势群体或结构性不利群体
- 对抗结果能力有限的人
- 系统影响劳动力决策或监控时的员工/劳动者
然后识别**《欧盟基本权利宪章》下哪些基本权利**在现实中处于风险之中，在相关时包括：
- 人的尊严
- 私生活受尊重
- 个人数据保护
- 不受歧视
- 男女平等
- 儿童权利
- 表达与信息自由
- 经营自由
- 消费者保护
- 良好行政权
- 有效救济和公平审判权
- 无罪推定和辩护权
- 视语境而定的医疗相关权利和社会保护
→ 详细的权利目录和示例，阅读 references/fundamental-rights-catalogue.md。
第 6 步——评估具体的损害风险
第 27 条第 2 款要求识别可能影响所识别的人/群体的具体损害风险。
对每项相关权利和受影响群体评估：
- 可能发生什么损害？
- 通过什么机制？
- 谁承担负担？
- 损害是暂时还是持久？
- 能否逆转或补救？
- 受影响者甚至会知道系统对结果有贡献吗？
使用结构化评估，涵盖：
- 影响发生的可能性
- 影响发生时的严重性
- 可逆性 / 补救或撤销损害的能力
- 规模 / 受影响人数
- 运营目标与权利影响之间的相称性
- 为此目的使用 AI 的必要性
→ 评分方法和决策框架，阅读 references/fria-methodology.md。
第 7 步——评估保障措施、人工监督和数据质量措施
第 27 条第 2 款要求描述：
- 人工监督措施，以及
- 风险显现时要采取的措施，
- 另外，对第 26 条第 3 款第(a)项下的部署者，确保遵守相关数据质量要求的措施。
检查现有保障措施，例如：
- 不利决定前的人工审查
- 升级阈值和否决权
- 明确的角色分配和问责
- 日志记录和可追溯性
- 输入数据的质量检查
- 偏见/错误监控
- 用户培训和操作说明
- 投诉机制和救济途径
- 事件响应和停止使用程序
- 采购控制和提供者的合同承诺
问题不在于保障措施是否纸面上存在，而在于它是否对此特定风险有效。
第 8 步——确定剩余风险、相称性和放行/不放行建议
在计入保障措施后，评估剩余风险。
问：
- 在具体语境中，对权利的干预是否正当、必要且相称？
- 是否有侵入权利程度更低的替代方案？
- 弱势群体是否暴露于不成比例的负担？
- 监督和投诉机制是否足够有力，足以捕捉现实世界的失败？
- 使用应继续、仅在附条件下继续，还是应在缓解措施实施前不继续？
这是核心判断部分。不要因为控制存在就自动批准。解释推理。
第 9 步——第 27 条第 3 款下的通知分析
如 FRIA 识别出对自然人或群体的权利构成具体风险，部署者必须通知相关的市场监督机构。
如风险涉及个人数据处理且在数据保护法下具有相关性，部署者还必须通知主管的数据保护机构。
检查：
- FRIA 是否识别出具体风险，而不仅仅是一般的抽象可能性？
- 相关成员国和行业中的哪个机构具有管辖权？
- 该事项是否也触发 GDPR 分析、协商或单独的监管接触？
- 应通知什么、附什么证据、在什么阶段？
→ 机构映射和通知结构，阅读 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 之前的受理阶段使用这些问题：
系统与范围
- 该 AI 系统是什么，是否已被确认为高风险？
- 该部署者的确切用例是什么？
- 部署者是公共机构还是提供公共服务的私营实体？
- 该实体是否作为部署者行事，而非仅作为提供者？
运营语境
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 工作应产出以下交付物：
-
FRIA 范围备忘录——对第 27 条是否适用的简短认定，包括部署者地位、高风险地位、用例边界、时机，以及 FRIA 是否强制。
-
FRIA 报告 / 草稿 FRIA——涵盖第 27 条第 2 款要素的结构化评估：流程描述、预期使用期间/频率、受影响群体、所涉权利、具体损害风险、监督措施、缓解/治理措施、剩余风险和通知分析。
-
权利影响矩阵——实用的表格，映射受影响群体、相关权利、风险机制、固有风险、现有保障措施、剩余风险和所需行动。
-
管理层简报——面向领导层的一页决定说明，解释部署是否可以继续、在什么条件下，以及上线前必须发生什么。
-
通知包（如需要）——致市场监督机构以及（在相关时）主管数据保护机构的通知草稿。
→ 模板和示例措辞，阅读 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 条提供结构化工作流支持。它不构成法律意见。某实体是否属于公法管辖的机构、私营公共服务提供者，或某具体风险是否需要通知，可能取决于国家法律、行业规则、采购结构和监督实践。分析应由合格律师审查，尤其是在部署、机构接触或高影响运营决定之前。
