欧盟人工智能法案 第 27 条 基本权利影响评估（FRIA）

章节结构（10）

1. 1. 一、适用性判定：我是不是必须做 FRIA

   第 27(1) 条的适用范围是限定的，先把判定写清楚再动手。义务落在**部署第 6(2) 条所指高风险 AI 系统**的以下主体身上：受公法管辖的机构，或提供公共服务的私营实体；以及附件 III 第 5 点 (b)、(c) 项所指高风险系统的部署者。使用附件 III 第 2 点所列领域的高风险系统属于明文除外。因此判定要回答三问：系统是否为第 6(2) 条意义上的高风险；本单位是否属于公法机构或提供公共服务的私营实体，或者所用系统是否落在附件 III 第 5 点 (b)、(c) 项；是否落入第 2 点的除外情形。若判定为不适用，把这一判定与理由留档同样有价值——它是客户问卷里"你们做 FRIA 了吗"的正式答复依据。另需注意第 27(2) 条：该义务针对**首次使用**；相似情形下可援引此前已做的 FRIA 或提供者已做的影响评估。

   需要附的证据

   • · 适用性判定记录（三问逐项，含判定人与日期）
   • · 系统的高风险归类依据（取自提供者的技术文档或使用说明）
   • · 本单位法律性质说明（公法机构 / 提供公共服务的私营实体 / 其他）
   • · 若援引既有评估：被援引评估的来源、版本与"相似情形"论证

   常见失分点

   • · 把 FRIA 当成所有高风险系统部署者的普遍义务，做了大量不必要的工作；
   • · 反过来：属于"提供公共服务的私营实体"却自认为是普通企业而未做；
   • · 援引提供者已做的影响评估，却拿不到该评估文本，也未论证情形相似；
   • · 判定不适用但未留档，客户尽调时无法自证。

2. 2. 二、部署者使用该系统的业务流程描述（第 27(1)(a) 条）

   第 27(1)(a) 条要求描述部署者按预期用途使用该高风险 AI 系统的业务流程。关键词是"按其预期用途"——先把提供者在使用说明中声明的预期用途抄录在此，再写本单位的实际流程，并明确指出两者是否一致。流程描述要落到决策链上：系统的输出进入哪个环节、谁看到、据以作出什么决定、该决定对个人产生什么后果、是否存在人工推翻的环节与实际推翻比例。同时写明系统之外的输入（人工判断、其他系统的评分、历史记录）如何与模型输出合并，因为基本权利影响往往产生于这个合并环节而非模型本身。若本单位的使用超出提供者声明的预期用途，须注意第 25(1)(c) 条：改变预期用途可能使部署者被视为提供者并承担提供者义务。

   需要附的证据

   • · 提供者使用说明中的预期用途原文摘录
   • · 本单位业务流程图（含系统输出的进入点与决策点）
   • · 决策链上各角色的职责与权限说明
   • · 人工推翻记录与推翻比例统计
   • · 预期用途一致性判定（若不一致：第 25(1)(c) 条影响分析）

   常见失分点

   • · 流程描述停在"系统给出建议供员工参考"，未写员工实际采纳率，评审人无法判断影响程度；
   • · 未抄录提供者声明的预期用途，因此无法证明使用未超范围；
   • · 忽略系统输出与其他评分合并的环节，遗漏了真正的影响来源；
   • · 实际已改变预期用途（如把内容审核模型用于员工绩效），却未做第 25 条分析。

3. 3. 三、使用的时间跨度与频率（第 27(1)(b) 条）

   第 27(1)(b) 条要求描述每一个高风险 AI 系统拟使用的时间跨度与频率。这一项看似琐碎，实际是后续风险量级判断的分母：每天处理 50 份申请与每天处理 50 万份申请，同一错误率的基本权利影响完全不同。写明：试点期与正式期的起止、每日/每月处理量级与峰值、覆盖的地域与用户群规模、是否 7×24 自动运行、以及计划的退出或复审节点。若是分阶段上线，把各阶段的量级分别列出，并说明每一阶段的扩量条件（例如"错误率低于 X 且申诉率低于 Y 方可扩至下一阶段"）——这类门禁条件是评审人认可"风险受控"的最有力证据之一。

   需要附的证据

   • · 使用时段与处理量的计划表（分阶段）
   • · 实际处理量统计（上线后按周或按月）
   • · 扩量门禁条件与达标证据
   • · 退出或暂停使用的触发条件与决策权限

   常见失分点

   • · 写"长期使用、按需调用"，等于没有给出任何量级信息；
   • · 只写计划量级，上线后从未回填实际量级，评估与现实脱节；
   • · 分阶段上线但没有扩量门禁，实际上是一次性全量；
   • · 缺少暂停机制，出问题时无人有权停机。

4. 4. 四、可能受影响的自然人与群体类别（第 27(1)(c) 条）

   第 27(1)(c) 条要求识别在具体使用场景下可能受该系统使用影响的自然人与群体类别。注意"具体场景"这一限定：同一个简历筛选模型，用于校招与用于高管猎聘，受影响群体完全不同。建议按三层写：直接对象（申请人、用户、员工、患者）；间接受影响者（被拒者的家庭、被错误关联的第三方、内容被下架的创作者）；以及可能承受不成比例影响的群体（按年龄、性别、族裔或民族出身、残障、语言、移民身份、社会经济地位等维度）。第三层最容易被写空，也最容易被监管追问——即便无法获取受保护特征数据，也应说明用什么代理指标或定性方法来识别不成比例影响，以及这种替代方法本身的局限。

   需要附的证据

   • · 受影响群体识别表（三层结构，含识别方法）
   • · 群体规模估算与数据来源
   • · 不成比例影响的检测方法说明（含代理指标与其局限）
   • · 与受影响群体代表组织的沟通记录（若有）

   常见失分点

   • · 只写"本公司用户"，没有按可能承受不成比例影响的维度细分；
   • · 以"我们不收集族裔数据"为由完全跳过不成比例影响分析，而未给出任何替代方法；
   • · 间接受影响者一栏缺失，而这一栏往往是基本权利风险的真正来源；
   • · 群体规模凭印象估算，没有数据支撑。

5. 5. 五、可能对上述群体造成影响的具体损害风险（第 27(1)(d) 条）

   第 27(1)(d) 条要求识别可能对第 (c) 项所识别人群造成影响的具体损害风险，并明确要求**考虑提供者依第 13 条提供的信息**。这是本模板与普通风险评估最大的区别：你必须先读透使用说明里关于系统能力、局限、已知不准确情形、预期准确度与输入规格的内容，再据以推导本场景下的损害。写法建议逐条列出：受影响权利（《欧盟基本权利宪章》项下的非歧视、隐私与数据保护、表达与信息自由、有效救济与公正审判、人的尊严、劳动者权利、儿童权利等）→ 本场景下的具体损害情形（写成一句可核查的事实陈述）→ 触发该损害的技术或流程原因 → 可能性与严重性评级 → 是否可逆。若提供者提供的信息不足以支撑该评估，把缺口写下来并记录已向提供者提出的问询——第 25(4) 条与第 26 条为部署者获取必要信息提供了依据。

   需要附的证据

   • · 损害风险登记表（权利—场景—成因—可能性—严重性—可逆性）
   • · 提供者使用说明中相关段落的摘录与解读记录
   • · 向提供者提出的信息问询与答复
   • · 本场景下的偏差或错误率实测数据（若可获取）
   • · 类似系统的既往事件或执法案例参考

   常见失分点

   • · 完全没有引用提供者依第 13 条提供的信息，法条对此有明文要求；
   • · 损害写成抽象权利名称（"可能影响隐私权"），没有具体到可核查的情形；
   • · 只列了系统出错时的损害，忽略系统"正常工作"时仍可能造成的结构性影响；
   • · 提供者信息不足却未留下问询记录，事后无法说明已尽合理努力。

6. 6. 六、人工监督措施的实施情况（第 27(1)(e) 条）

   第 27(1)(e) 条要求描述**按使用说明**实施人工监督措施的情况。这不是重复提供者在第 14 条下的设计，而是回答"你实际怎么落地的"。写明：被指派行使监督的人员及其岗位、依第 26(2) 条应具备的必要能力、培训与授权（法条要求部署者赋予其必要的支持与权限）；监督环节在流程中的位置与可用时间；监督者能看到什么信息（输出、置信度、影响因素、是否有解释）；推翻输出的操作路径与记录方式；对自动化偏见（过度信任系统输出）的防范措施；以及监督有效性的度量（推翻率、复核时长、抽样复核的一致性）。若使用说明要求的监督条件在本单位无法满足（例如要求双人复核而实际只有一人），必须写明并给出补偿措施，而不是默认忽略。

   需要附的证据

   • · 监督岗位说明书与授权文件
   • · 监督人员培训记录与能力评估
   • · 监督界面截图（监督者实际能看到的信息）
   • · 推翻操作的记录样本与推翻率统计
   • · 自动化偏见防范措施说明（如强制独立判断、随机盲测）
   • · 监督有效性度量报告

   常见失分点

   • · 监督者每份材料只有数秒处理时间，"人工监督"在时间上不可能成立；
   • · 监督者看不到置信度或影响因素，只能看到最终结论，无从判断是否应推翻；
   • · 推翻率长期为零却未被当作异常调查——这通常是自动化偏见的信号；
   • · 使用说明要求的监督条件未满足，文档中却不提。

7. 7. 七、风险成真时的应对措施、内部治理与投诉机制（第 27(1)(f) 条）

   第 27(1)(f) 条要求写明风险成真时拟采取的措施，**包括内部治理安排与投诉机制**。分三块写。应对措施：分级响应（暂停单个决策 / 暂停某一群体 / 暂停系统）、各级触发阈值与决策权限、对已作出错误决定的纠正与补救（重新审查、撤销、赔偿）、以及对外沟通口径。内部治理：谁对本系统的使用负最终责任、跨部门评审机制、与风险管理和信息安全的接口、升级路径与时限。投诉机制：个人如何知道自己受到该系统影响（与第 26(11) 条的告知义务衔接）、投诉入口与可用语言、受理与答复时限、投诉是否能触发人工复核、投诉数据如何回流到系统改进。同时写明第 26(5) 条的监测义务与第 26(5) 条第二款情形下暂停使用并告知提供者与市场监管机关的安排，以及第 73 条严重事件报告的衔接判据。

   需要附的证据

   • · 分级响应预案（触发阈值、动作、决策权限、时限）
   • · 内部治理架构图与责任分配表（RACI）
   • · 面向受影响个人的告知文本（第 26(11) 条）与展示位置
   • · 投诉受理流程、台账与答复时长统计
   • · 错误决定的纠正与补救记录样本
   • · 暂停使用与通知提供者/市场监管机关的流程与联系人

   常见失分点

   • · 投诉机制只给一个通用客服邮箱，个人根本不知道自己是被 AI 系统处理的；
   • · 没有人有权暂停系统，预案里最高动作是"上报"；
   • · 已作出的错误决定无回溯纠正机制，只承诺"今后改进"；
   • · 第 26(11) 条告知义务被忽略，导致整个投诉机制在事实上不可达。

8. 8. 八、与 GDPR 数据保护影响评估的衔接（第 27(4) 条）

   第 27(4) 条已被条例 (EU) 2026/1744（AI Omnibus）第 1(13)(a) 条替换，现行文本是：本条项下的任一义务若已通过依条例 (EU) 2016/679 第 35 条或指令 (EU) 2016/680 第 27 条所做的数据保护影响评估得到满足，则部署者在进行第 27(1) 条所指基本权利影响评估时，**可以交叉引用该数据保护影响评估的相关章节，或者将其相关部分并入基本权利影响评估**。修订前的表述是"基本权利影响评估补充该数据保护影响评估"，引用旧表述会被识别为未跟进修订。同时注意第 27(5) 条也被一并替换：人工智能办公室开发的问卷模板应当在相关情形下给部署者提供依第 27(4) 条交叉引用 DPIA 相关章节、或将其相关部分并入 FRIA 的可能。实务上这条修订是减负而非免责：交叉引用只对"DPIA 确已覆盖"的部分成立，未覆盖的部分仍须在 FRIA 中写足。DPIA 覆盖的是个人数据处理带来的风险，FRIA 覆盖的是系统使用对基本权利的影响，两者重叠但不重合。做法是做一张对照表：第 27(1) 条 (a)–(f) 六项要素 → DPIA 中已覆盖的对应章节（精确到章节号，以便真正构成"交叉引用"）→ 尚未覆盖需在 FRIA 中补足的内容。典型的"DPIA 未覆盖"部分包括：不涉及个人数据的基本权利影响（如表达自由、信息获取）、使用频率与时长、对间接受影响群体的分析、以及内部治理与投诉机制的具体安排。把两份文件交叉引用清楚，比各写各的更省工，也更经得起追问。

   需要附的证据

   • · FRIA 六项要素与 DPIA 章节的对照表
   • · DPIA 文件索引（版本号与日期）
   • · 两份文件结论一致性核对记录
   • · 仅在 FRIA 中覆盖的增量内容清单

   常见失分点

   • · 直接把 DPIA 改个标题当 FRIA 提交，六项要素中的 (b)、(f) 通常明显缺失；
   • · 两份文件对同一风险给出不同等级或不同结论；
   • · 对照表只写"见 DPIA"，未写具体章节号，无法核查；
   • · 误以为做了 FRIA 就无需做 DPIA——第 27(4) 条只允许 FRIA 引用 DPIA 已覆盖的部分，DPIA 本身的义务来自 GDPR 第 35 条，不因做了 FRIA 而消失；
   • · 援引第 27(4) 条整段引用 DPIA，但 DPIA 里根本没有 (b)(c)(f) 三项对应内容，交叉引用落空。

9. 9. 九、向市场监管机关通知评估结果（第 27(3) 条）

   第 27(3) 条要求评估完成后，部署者应将结果通知市场监管机关，并在通知时提交第 27(5) 条所指模板的填报件；第 46(1) 条所述情形下的部署者可免于该通知义务。第 27(5) 条（经条例 (EU) 2026/1744 第 1(13)(b) 条替换）规定由人工智能办公室开发问卷模板（可含自动化工具）以简化部署者的合规工作，并要求该模板在相关情形下让部署者可以依第 27(4) 条交叉引用数据保护影响评估的相关章节或并入其相关部分。本节记录：所在成员国的市场监管机关识别与联系方式（第 74 条项下由各成员国指定，涉及执法、边境管理、司法与民主等附件 III 第 1、6、7、8 点用途时，成员国指定的可能是数据保护监管机构）；通知的时点、渠道、提交内容与回执；若援引第 46(1) 条豁免，写明依据。截至本版语料复核日，人工智能办公室问卷模板的可用状态与具体格式请在通知前直接向所在成员国主管机关或人工智能办公室确认，不要按传闻格式准备。

   需要附的证据

   • · 所在成员国市场监管机关的识别记录与联系方式
   • · 通知提交记录与回执（含日期与提交渠道）
   • · 提交的模板填报件副本
   • · 若援引第 46(1) 条豁免：依据与内部批准记录

   常见失分点

   • · 做完 FRIA 但从未通知市场监管机关，第 27(3) 条义务落空；
   • · 搞错主管机关（附件 III 若干用途下可能是数据保护机构而非通用市场监管机关）；
   • · 按未经确认的模板格式准备材料，导致被退回重报；
   • · 通知无回执留存，事后无法证明已履行。

10. 10. 十、更新触发与再评估（第 27(2) 条）

    第 27(2) 条规定：若在使用过程中部署者认为第 27(1) 条所列任一要素已发生变化或不再是最新的，应采取必要步骤更新相关信息。把"变化"写成可监测的触发条件：提供者发布新版本或更新使用说明；使用量级或覆盖人群显著变化；业务流程改动（新增决策点、人工环节缩短）；出现新的损害类型或投诉集中；监督人员或授权发生变动；相关法律或监管指引更新；系统被用于新的地域或语言环境。每次更新记录触发原因、变化内容、是否需要重新通知市场监管机关，以及是否需要同步更新 DPIA。建议把 FRIA 的有效性检查挂进部署者自身的变更管理流程与供应商版本升级流程，否则更新义务在实践中几乎必然被遗忘。

    需要附的证据

    • · 更新触发条件清单与监测责任人
    • · 版本历史（版本、日期、触发、变更摘要、批准人）
    • · 供应商版本升级通知的接收与处理记录
    • · 更新后是否重新通知市场监管机关的判定与记录

    常见失分点

    • · FRIA 停留在上线当天的版本，供应商已升级三次而文档未动；
    • · 更新触发条件里没有"提供者更新使用说明"这一条，而这是最常见的触发；
    • · 更新后未判断是否需要重新通知，默认不通知；
    • · FRIA 与 DPIA 各自更新，结论逐渐分叉。