荷兰数据保护机构发布 FRIA 指南。本文提供完整中文翻译，并解读适用主体、基本权利风险链、FRIA 与 DPIA 的关系及部署者当前应开展的准备工作。

译者评论

2026 年 8 月 17 日，荷兰数据保护机构（AP）发布这份指南。它的价值不在于提出一套脱离《人工智能法案》（Artificial Intelligence Act，以下简称“AIA”）的新制度，而在于把第 27 条的抽象要求翻译成组织可以着手准备的工作框架：谁必须做、何时做、评估什么、采取什么措施，以及如何向市场监管机构报告。AP 官方文件页面

更重要的是，它揭示了欧盟人工智能监管中一个容易被忽视的变化：即使人工智能系统在投放市场时已经通过产品合规程序，部署者仍然需要对该系统在自身使用情境中产生的基本权利风险负责。

一、先分清三种规范层级

阅读这份指南时，必须区分法定义务、监管机构的说明和企业实施建议。

AP 的概览页面还宣布了一项全国试点，帮助参与组织使用欧洲 FRIA 报告模板并获得反馈。AP 明确表示，该试点不是审计、检查或执法程序。试点本身与本指南同样说明，监管机构希望组织在义务正式适用前积累实践经验。AP 官方概览

二、FRIA 构成产品风险治理与部署情境治理的双层结构

法定义务。 《人工智能法案》第 27 条适用于特定高风险人工智能系统的特定部署者：公法机构、提供公共服务的私营实体，以及附件 III 第 5(b)和(c)项涉及信用评估、信用评分、人寿保险和健康保险风险评估与定价的部署者。附件 III 第 2 项所列关键基础设施系统被明确排除在这一条的通常适用范围之外。

指南说明。 AP 给出的理由非常重要：产品监管通常首先关注提供者，但系统进入实际流程后，仍可能出现开发阶段无法预见的风险。一个依法投放市场的系统，不等于它在每一种使用情境中都不会损害基本权利。

评论判断。 这不是责任从提供者向部署者转移，而是两层责任相互补充：提供者依据第 9 条管理系统设计和产品层风险，并依据第 13 条向部署者提供必要信息；部署者则依据第 26、27 条处理系统进入本组织流程后产生的使用情境风险。因此，采购验收、合格评定或者供应商提供的风险文件，都不能替代部署者自己的情境化判断。FRIA 要回答的不是“这个模型一般安全吗”，而是以下问题：

• 本组织将把系统嵌入哪个流程、用于何种决定？
• 使用频率、持续时间和自动化程度会怎样改变风险？
• 谁会直接或间接受到影响？
• 哪些基本权利可能受到损害？
• 人工监督、投诉、纠正和持续监测能否真正发挥作用？

这一双层结构还延伸至后市场监管。AIA 第 82 条规定，即使高风险人工智能系统符合 AIA，如果市场监管机构认定其仍对健康、安全、基本权利或其他公共利益保护方面构成风险，也可以要求相关运营者采取适当措施。因此，从前端合格评定、部署者 FRIA 到后市场监管，AIA 本身就承认“产品合规”不能穷尽具体使用风险。AIA 现行合并文本

三、适用范围并不等于“所有高风险系统”

指南中的招聘示例特别有用。一家普通信息技术企业使用人工智能系统筛选求职者，该系统可能属于附件 III 所列高风险系统，但该企业并不因此当然负有第 27 条的 FRIA 义务，因为它不属于第 27 条规定的主体类别。

这是一项法定适用范围限制，不是对招聘系统基本权利风险的否定。指南也明确指出，相关企业仍然受到 AIA 第 26 条等部署者义务约束，并建议考虑开展 FRIA 或其他影响评估。

企业建议。 组织可以在人工智能系统清单中增加四项 FRIA 筛查字段：

1. 系统是否属于 AIA 第 6 条第 2 款和附件 III 所涉应用，并且不存在第 6 条第 3 款规定的非高风险排除情形？
2. 部署者是否属于第 27 条列明的主体？
3. 系统是否落入附件 III 第 2 项关键基础设施例外？
4. 是否属于首次使用，或者使用情境、对象、频率、用途或风险信息已经发生变化？

这四项筛查是本文提出的实施方法，并非第 27 条规定的固定表格。

四、FRIA 评估的不是抽象权利清单，而是一条完整的风险链

AP 将 FRIA 归纳为三项核心组成：使用情境、基本权利影响分析和适当措施。这三项内容应当连成一条可以核验的风险链：

指南以招聘系统为例说明，风险不能只停留在“算法可能歧视女性”。评估还应继续追问：女性候选人是否更少获得面试机会，错误拒绝如何影响个人的生计保障，长期代表不足又如何影响女性群体乃至公共决策。这是一种从个人后果延伸到群体和社会后果的分析方法。

企业建议。 与其从一张泛化的基本权利清单开始，不如先绘制系统参与的决定流程，再逐项识别：输入信息、系统输出、人工介入点、决定作出者、申诉渠道、直接对象、关联人员和可能累积影响。这样更容易形成可验证的风险与控制对应关系。

五、FRIA 与 DPIA：可以复用，但不能替代

这是整份指南中最值得合规团队注意的部分。

法定义务。 GDPR 第 35 条要求控制者在可能对自然人的权利和自由造成高风险的个人数据处理活动开始前开展 DPIA。DPIA 关注的是拟议处理活动对个人数据保护的影响，包括处理的必要性、比例性、风险以及保障措施。GDPR 第 35 条官方文本

FRIA 的范围更宽。它可能涉及数据保护，也可能涉及不歧视、表达自由、受教育权、健康保护、社会保障、环境保护及其他相关基本权利。因此，一份充分的 DPIA 仍可能没有回答 FRIA 所要求的问题。

2026 年《Digital Omnibus on AI》修改后的现行第 27 条第 4 款明确允许部署者在 FRIA 中交叉引用 DPIA 的相关章节，或者将 DPIA 的相关部分纳入 FRIA；第 27 条第 5 款还要求未来模板在适当情况下支持这种复用。AIA 现行合并文本；《条例（EU）2026/1744》

因此，准确的关系不是“DPIA 和 FRIA 完全分开”，也不是“做过 DPIA 就不必做 FRIA”，而是：

企业建议。 可以建立一个共同的影响评估底座，统一记录系统、用途、流程、数据、受影响人员、风险、措施和责任人；再分别形成 DPIA 模块与 FRIA 模块。这样既能减少重复劳动，也能保持两项评估各自的法律判断和批准路径。

六、报告义务会改变组织保存证据的方式

法定义务。 第 27 条要求部署者在完成 FRIA 后，使用人工智能办公室制定的模板向市场监管机构通知评估结果。现行第 27 条第 3 款同时保留了与 AIA 第 46 条第 1 款相关的狭窄法定通知例外；因此，不宜把“所有情形均无例外地报告”写成绝对命题。

指南说明。 AP 强调，市场监管机构将关注基本权利风险评估以及相应的风险控制措施。欧洲模板仍在制定，FRIA 与 DPIA 如何在操作层面衔接也尚待进一步明确。

评论判断。 从监管可解释性和后续更新的角度，组织不宜只保留一份结论性报告。报告背后还应当能够解释：事实从何而来、风险如何确定、措施为何足够、谁作出判断、何时需要更新。

企业建议。 可以围绕下列材料建立 FRIA 证据包：

• 提供者的使用说明、预期用途和第 13 条信息；
• 系统在组织内部的流程图、版本和使用频率；
• 直接与间接受影响人群及相关基本权利的识别依据；
• 风险发生可能性和严重程度的判断记录；
• 人工监督人员、职责、培训、权限和升级机制；
• 投诉、纠正、监测、审计及事故处置安排；
• 使用情境或风险信息变化时触发更新的规则；
• 内外部利益相关方意见及组织对意见的处理结果。

这份证据包清单是实施建议，不是 AP 指南规定的封闭式法定材料清单。最终提交内容仍应以人工智能办公室的正式模板及主管机构要求为准。

还应区分两项容易混淆的义务：第 27 条第 3 款规定的是向市场监管机构通知 FRIA 结果；第 49 条第 3 款则对公共机关、欧盟机构等部署者规定了使用前在欧盟数据库登记自身及相关系统使用情况的独立义务。FRIA 结果通知不等于人工智能系统登记，两项义务的主体、对象和操作入口应分别核对。AIA 现行合并文本

七、多学科团队与外部参与：监管期待正在形成，但不能机械化

AP 建议由熟悉基本权利的法律人员、领域专家、人工智能专家和行为专家共同开展 FRIA，并建议邀请受影响群体代表、独立专家和社会组织等外部利益相关方参与。AIA 序言第 96 段也以建议性语言支持在适当情况下吸收相关利益相关方。

这不意味着每一项 FRIA 都必须组织同样规模的外部咨询。更合理的做法，是根据决定的重要程度、影响人数、弱势人群参与程度、损害严重性和不可逆性确定参与范围。

对于社会救助、教育机会、医疗服务、执法、移民、信用和保险等可能显著影响个人生活机会的系统，仅由技术、采购或法务团队内部评估，往往难以充分识别实际影响。外部参与的意义，不只是程序上的“征求意见”，而是校正组织自身可能看不到的事实和风险假设。

八、现在可以做什么

经《条例（EU）2026/1744》调整后，AIA 第三章第 1至3节关于附件 III 高风险系统的要求自 2027 年 12 月 2 日起适用。AP 的立场是，组织不应等到该日期临近才第一次尝试 FRIA。

在正式欧洲模板发布前，组织可以先完成五项准备工作：

1. 建立人工智能系统及部署者角色清单，完成 FRIA 适用范围筛查；
2. 为可能适用的系统绘制使用情境和决定流程；
3. 梳理现有 DPIA、IAMA、HUDERIA、供应商评估和投诉材料中可以复用的内容；
4. 明确人工监督、投诉处理、监测和更新责任；
5. 选择一个高影响使用场景开展试评估，检验组织是否能够形成完整证据链。

上述安排属于提前准备建议，不改变第 27 条的适用条件，也不意味着试评估必须向监管机构提交。

结语

FRIA 最值得关注的地方，是它把基本权利保护从一项抽象原则，转化为部署者必须在具体使用情境中回答的问题。

组织需要形成可核验的依据，说明的不只是“供应商说系统合规”，也不只是“我们已经做过 DPIA”，而是：在本组织的流程中，面对这些具体的人和群体，我们识别了哪些基本权利风险，采取了哪些能够实际运行的措施，并准备在情境变化时重新评估。

这正是 FRIA 与一般人工智能风险说明之间最实质的区别。

指南全文翻译

原题：Aan de slag met de FRIA

发布：2026 年 8 月 17 日

目录

引言

保护基本权利是《人工智能法案》（Artificial Intelligence Act，以下简称“AIA”）的主要目标之一。¹ AIA 为高风险人工智能系统的提供者和部署者²规定了多项要求，由此也可以看出这一目标。³ 其中一项重要要求，是开展基本权利影响评估（Fundamental Rights Impact Assessment，以下简称“FRIA”）并就其结果进行报告。⁴

FRIA 是对高风险人工智能系统在具体使用情境中可能给基本权利带来的风险所作的评估，同时还要说明组织将如何应对这些风险。指南在此概括称，政府机构以及提供公共服务的组织必须开展 FRIA；其后“FRIA 概览”还列明了信用评估、信用评分以及人寿保险或健康保险风险评估与定价系统的特定部署者。

荷兰数据保护机构（Autoriteit Persoonsgegevens，AP）作为算法和人工智能（AI）领域的协调监管机构，参与 AIA 监管工作的筹备。荷兰政府拟指定 AP 负责监管 AIA 附件 III 所列大多数高风险人工智能系统。因此，AP 也在为监督 FRIA 义务的履行作准备。

2026 年，AP 正在制定指导材料并开展宣传，说明政府机构及其他组织如何有效开展 FRIA，以及应当如何报告。AP 的工作将与目前正在制定的欧洲指南相衔接。

本文件是“基本权利与人工智能”系列出版物的第一份文件。作为首份文件，它从总体上向组织介绍 AIA 所规定的 FRIA 要求及其预期内容。⁵

FRIA 概览

AIA 下的 FRIA 要求具有五项主要特征

1. FRIA 是下列主体应当履行的要求：

• 公法机构（以下简称“政府机构”）；
• 提供公共服务的私营组织；
• 作出信用评估决定或者确定信用评分的人工智能系统部署者；
• 确定人寿保险或健康保险风险及定价的人工智能系统部署者。

1. 在部署 AIA 附件 III 所指的高风险人工智能系统时，适用 FRIA 要求。⁶
2. FRIA 必须在首次使用人工智能系统之前开展；在使用人工智能系统的过程中，如果相关情况发生变化或者原有信息不再是最新信息，则必须更新 FRIA。
3. FRIA 要求评估具体使用情境中可能受到影响的所有相关基本权利，并说明组织将采取哪些适当措施应对这些风险。
4. FRIA 包含报告义务：组织应当使用一份模板，向相关市场监管机构提交 FRIA 结果。⁷ 该模板目前由欧洲人工智能办公室在欧洲层面制定，AP 也参与其中。⁸

哪些主体负有开展并报告 FRIA 的义务？

图 1｜FRIA 义务适用于特定组织与特定人工智能系统的组合

政府机构和提供公共服务的私营组织在使用高风险人工智能系统时，必须开展 FRIA，但关键基础设施所使用的系统除外。⁹ 因此，在 AIA 语境下，FRIA 是一项特别规定。产品监管通常主要针对产品提供者，但 AIA 也将责任赋予部署者。原因在于，人工智能系统投入使用时可能出现开发阶段无法预见的风险。换言之，即使某个人工智能系统依法投放市场，在特定情境中使用时仍可能无意间对个人或群体的基本权利造成不利影响。

具体而言，FRIA 义务涉及以下类型的部署者：

• 公法机构。 包括部委、市政府和省政府等政府机构，也包括具有公法基础的组织，例如某些独立行政机构。
• 提供公共服务的私营实体。 指提供具有公共性质、并与公共利益任务相联系的服务的私营实体，例如教育、医疗、社会服务、住房和司法行政等领域的相关组织。¹⁰
• 使用人工智能系统评估信用状况或确定信用评分的部署者，¹¹以及使用人工智能系统评估风险并确定人寿保险或健康保险价格的部署者。¹² 其中包括银行和保险公司等机构。

这些组织何时必须满足 FRIA 要求？

FRIA 对 AIA 附件 III 所列人工智能系统及其应用具有强制性。¹³ 组织应当在部署人工智能系统之前开展 FRIA 并报告其结果。¹⁴ 在人工智能系统的使用期间，组织应当在必要时更新 FRIA。¹⁵

使用人工智能系统提供公共服务时须开展 FRIA 的应用领域和指定系统总览

示例

以下三个示例用于说明 FRIA 要求何时适用。所有示例均假定相关系统构成人工智能系统。

示例 1

X 市政府希望将社会救助申请的处理和决定自动化。为此，市政府拟使用一个名为“UitkeringSelect”的人工智能系统。该系统用于自动评估申请，并就是否应当认定申请人有权领取社会救助金向公务人员提出建议。X 市政府在部署该系统时是否必须满足 FRIA 要求？

1. “UitkeringSelect”是否属于高风险人工智能系统？

是。该人工智能系统评估某人是否有资格领取政府福利，从而决定个人在多大程度上能够获得和使用一项基本服务；本例中的基本服务即社会救助金。¹⁷

1. X 市政府是否属于 FRIA 要求适用的组织？

是。市政府属于政府机构，因而是 AIA 第 27 条所指的一类部署者。

结论： X 市政府必须在首次部署“UitkeringSelect”之前，就该系统满足 FRIA 要求。

示例 2

“De Carrousel”小学由一家基金会运营。学校希望使用“MaatWerk”人工智能系统评价学生的学习成果，并据此为每名学生制定个性化学习方案。该方案还将决定学生小学毕业后获得的升学建议。“De Carrousel”是否必须满足 FRIA 要求？

1. “MaatWerk”是否属于高风险人工智能系统？

是。该人工智能系统用于在教育情境中评价学习成果。¹⁸

1. “De Carrousel”是否属于 FRIA 要求适用的组织？

是。“De Carrousel”小学是提供公共服务（本例中为教育）的私营实体，因而是 AIA 第 27 条所指的一类部署者。

结论： “De Carrousel”小学必须在首次部署“MaatWerk”之前，就该系统满足 FRIA 要求。

示例 3

一家大型信息技术企业希望使用“EasySelect”人工智能系统筛选求职者。该系统具有筛选功能，可通过分析简历判断求职者是否可能适合相关职位，随后向雇主展示人工智能系统选出的候选人。该企业是否必须满足 FRIA 要求？

1. “EasySelect”是否属于高风险人工智能系统？

是。该人工智能系统用于选拔候选人。¹⁹

1. 该企业是否属于 FRIA 要求适用的组织？

否。该企业既不是公法机构，也不是提供公共服务的私营组织；它不作出信用评估或信用评分决定，也不是人寿保险或健康保险的提供者。

结论： 该企业无须满足 FRIA 要求。²⁰

FRIA（报告）应当包含哪些内容？

FRIA 是在高风险人工智能系统投入具体情境使用时，对该系统可能给个人和群体的基本权利带来的影响所作的评估。此外，FRIA 还应说明组织将如何应对这些风险。

因此，拟使用特定高风险人工智能系统的组织必须识别个人及群体面临的基本权利风险，并据此采取措施预防和缓解这些风险。²¹ 组织可以利用此前针对同一系统开展的基本权利影响评估所形成的信息，²²也可以利用提供者开展的其他影响评估。²³

开展 FRIA 时，《欧盟基本权利宪章》具有适用性和约束力。因此，FRIA 必须涵盖组织使用人工智能系统的情境中所有相关的基本权利，例如数据保护、不歧视、表达自由、受教育权、健康保护、环境保护和社会保障。²⁴

AIA 列出了 FRIA 必须包含的若干要素。这些要素可以归纳为三项核心组成：²⁵

图 2｜FRIA 的核心组成

1. 使用情境说明；
2. 对个人和群体的基本权利影响分析；
3. 用于预防和缓解风险的适当措施。

FRIA 核心组成 1：使用情境

识别相关流程和预期用途

FRIA 必须识别组织将在何种流程中使用人工智能系统。只有明确该系统将在实践中用于何处、以何种方式使用，才能妥善评估其对基本权利的影响。说明相关流程还有助于具体确定风险可能在何处发生，从而防止分析过于抽象，并使现实的风险分析成为可能。

希望使用高风险人工智能系统的组织，必须按照提供者确定的预期用途使用该系统。²⁶ 组织应当检查其在上述流程中使用系统的方式是否处于该预期用途范围内。例如，如果系统是为辅助决策而开发的，组织就必须明确说明，这种使用方式为何与组织为具体使用情境设计的流程相一致。

识别人工智能系统的使用期间和使用频率

FRIA 还必须明确系统将在多长期间内、以何种频率使用。例如，系统是连续一年用于每一份社会救助申请，还是每月使用一次以测量学生的学习成果？与较低频率的使用相比，长期、每日使用可能使风险发生的可能性和影响更大。明确人工智能系统的使用期间和频率，还有助于确定适当的风险缓解措施，例如对人工智能系统进行监测和定期审计。

FRIA 核心组成 2：基本权利影响分析

受影响的个人和群体

组织必须识别使用人工智能系统时可能直接或间接受到影响的个人和群体类别，并特别关注可能更加脆弱或者遭受负面影响风险更高的弱势人群。²⁷ 这一步旨在准确识别风险可能落在谁身上，以便在影响与风险分析以及制定适当措施时充分考虑这些风险。

影响分析不仅涉及直接相关人员，还涉及范围更广的相关人员。直接相关人员包括人工智能系统对其作出评估或为涉及其本人的决定提供支持的人，例如申请社会救助的人。使用人工智能系统的组织的工作人员，也可能是直接相关人员。间接相关人员虽然不是系统直接评估的对象，但会受到系统结果或系统使用方式的影响。例如，社会救助申请遭拒的受益人子女也会受到影响。

可能更加脆弱或遭受负面影响风险更高的群体，包括依赖社会福利的低收入人群，也包括少数群体和受保护群体，例如基于种族、族裔、性别或残障而受到保护的群体。

具体损害风险（风险分析）

FRIA 的一个关键组成部分，是识别人工智能系统可能给已经确定的个人和群体带来的具体损害风险，并使这些风险具体化。这里所说的风险，是损害发生的可能性与损害严重程度（影响）的组合。²⁸ 因此，FRIA 评估不能只考虑某种问题是否可能发生，还必须考虑其发生的可能性有多大，以及给基本权利造成的后果有多严重。²⁹ 损害的可能性与严重程度的组合越高，风险缓解措施就必须越有力。

对每一类已经确定的个人和群体，都沿着损害的可能性和影响这两个维度进行评估，才能使基本权利受侵害的风险具体化。为妥善完成这项工作，参与 FRIA 的人员必须具备相关专业知识。

FRIA 核心组成 3：适当措施

说明人工监督措施

希望使用人工智能系统的组织必须在 FRIA 流程中说明对系统实施的人工监督。这种监督应当按照提供者为相关人工智能系统编制的使用说明实施。因此，部署人工智能系统的组织必须说明将如何实施必要的人工监督。

相关问题包括：

• 提供者在该人工智能系统的使用说明中规定了哪些人工监督要求？
• 组织将如何落实这些要求？
• 哪些基本权利风险能够得到应对，哪些风险不能得到完全应对？
• 组织中的哪些人员负责人工监督？这些人员是否具备履行该职责所需的能力、培训和权限？³¹

说明风险缓解措施

部署者应当在 FRIA 流程中说明为下列目的采取的措施：

• 预防和/或降低已经识别的风险；
• 应对已经识别的风险在人工智能系统实际使用中确实发生的情况。

拟采取的措施至少应当包括内部安排和投诉程序，以便及时、有效地发现和处理人工智能系统使用中产生的问题。这对于逆转和/或防止可能持续发生的损害十分必要。组织还应当说明如何监测人工智能系统的使用，例如采用预警机制和定期审计。

组织应当如何开展 FRIA 并进行报告？

FRIA 报告方法

欧洲人工智能办公室目前正在制定一份模板，组织向相关人工智能市场监管机构提交 FRIA 报告时必须使用该模板。因此，该模板也会指明 FRIA 流程必须产出的必要成果。

与现有工具的关系

针对特定行业或领域的现有影响评估工具，可以为开展全部或部分 FRIA 流程提供支持。例如，荷兰的“人权与算法影响评估”（Impact Assessment Mensenrechten en Algoritmes，IAMA）³²和欧洲委员会的 HUDERIA 模型，³³以及组织自行开发且不依赖特定模型的工具。

就具体领域而言，还可以考虑使用针对特定基本权利的工具，例如不歧视或儿童权利方面的工具。当人工智能系统的使用情境要求特别关注某项权利时，这类工具尤其有用。这些工具可以支持组织开展 FRIA 流程；组织随后通过 FRIA 模板向相关市场监管机构报告该流程的结果。

选择 FRIA 辅助工具时，重要的是确保相关工具与 AIA 规定的 FRIA 核心组成充分衔接，并与报告模板要求提交的信息相一致。相关市场监管机构将主要关注最终报告中的基本权利风险评估及其相应的风险控制措施。

向市场监管机构报告的义务

完成 FRIA 后，组织应当按照 AIA 第 27 条第 5 款所指的 FRIA 报告模板，将评估结果提交给相关市场监管机构。³⁴³⁵ 图 3 对 FRIA 流程作了概括，其中包括报告环节以及可能的反馈。

图 3｜FRIA 流程示意图

开展过程中，应邀请相关利益相关方参与，例如风险群体的权益代表、社会组织和独立专家；还可以使用 IAMA、HUDERIA 或组织自行开发的工具等现有工具作为支持。

FRIA 是对 DPIA 的补充

如果个人数据处理可能给数据主体的数据保护权带来高风险，组织³⁷必须在处理个人数据之前开展数据保护影响评估（Data Protection Impact Assessment，DPIA）。³⁶ 例如，对个人方面进行系统、全面的评价，大规模处理特殊类别个人数据，大规模处理刑事数据，或者在公共可进入区域对人员进行大规模系统监测时，可能存在这种情形。

这一义务也适用于许多人工智能系统的部署。但是，DPIA 不能替代 FRIA。如果相关人工智能系统适用 FRIA 要求，组织在这类情形下仍然必须评估其他基本权利。

DPIA 与 FRIA 的相同点和不同点

两种评估存在重叠，但也有实质性差异。两者都涉及基本权利，并且都必须在部署系统或处理个人数据之前开展。

DPIA 聚焦个人数据处理对个人数据保护以及数据主体权利和自由产生的风险；FRIA 则进一步评估具体人工智能使用情境中所有相关基本权利。即使某个人工智能系统依据 AIA 不属于高风险人工智能系统，只要系统中的个人数据处理可能给自然人的权利和自由带来高风险，也可能必须开展 DPIA。与此相对，FRIA 义务仅适用于 AIA 第 27 条列明的特定部署者，包括公法机构、提供公共服务的私营实体，以及附件 III 第 5(b)、5(c)项所涉信用评估、信用评分和人寿保险或健康保险风险评估及定价系统的部署者。⁴⁰

另一项差异是，FRIA 必须在首次部署人工智能系统之前向监管机构报告，而 DPIA 原则上没有此项义务。³⁸

实践中的并行适用

在实践中，组织可能既要依据《通用数据保护条例》（AVG）编制 DPIA，也要依据 AIA 编制 FRIA。如何在实践中处理两者的并行适用，避免组织重复劳动，仍有待进一步明确。FRIA 报告模板的制定工作将进一步考虑这一问题。

关于荷兰数据保护机构

荷兰数据保护机构是个人数据领域的独立监管机构，致力于在数字世界中保护人们。

Autoriteit Persoonsgegevens

Postbus 93374

2509 AJ Den Haag

autoriteitpersoonsgegevens.nl

脚注