企业准备引入生成式 AI 时,往往会先看供应商品牌、数据处理协议和试点范围。这些因素都有意义,却只能回答局部问题。知名供应商仍需说明模型的训练来源和数据处理方式,数据处理协议也无法证明企业在某个业务场景中使用个人数据具有充分理由。至于试点,只要已经调用员工邮箱、客户资料或内部知识库,就可能发生受 GDPR 约束的个人数据处理。
企业最后需要回答的是一个连贯的问题:这个模型为什么可以被启用,本企业又为什么可以把它接入眼前的业务流程。前半句涉及训练来源、法律依据、模型是否匿名以及数据主体权利;后半句涉及具体目的、数据范围、访问权限、供应商安排、影响评估和运行控制。两部分由不同主体承担责任,同时又存在事实上的依赖关系。
2026 年 7 月 13 日,荷兰数据保护局(Autoriteit Persoonsgegevens,以下简称“荷兰 AP”)同时发布了两份生成式 AI 与 GDPR 材料。一份是面向开发者和模型启用方的《生成式 AI 与 AVG 指引》,另一份是供组织评估和记录具体部署活动的《生成式 AI 使用与 GDPR 辅助工具》。[1] 开发指引属于 AP 对 GDPR 的初步、暂定和非穷尽解释,主要讨论闭源生成式 AI 模型的开发和投入使用。部署工具说明它不能替代处理活动记录、数据保护影响评估或高残余风险下的事前咨询,适用范围也未覆盖《人工智能法》等其他法律。[2]
两份文件所涉及的法律依据、数据最小化、权限管理和影响评估,大多能够在 GDPR 和既有监管材料中找到来源。AP 的贡献体现在这些要求的组织方式上。它把模型开发、供应商采购和企业部署连接成一条证明路径,要求上游提供足以支持判断的材料,也要求下游结合自身环境重新作出决定。由此,生成式 AI 合规不宜继续被理解为某个产品自带的属性。它只在特定模型版本、特定用途、特定数据范围和特定控制条件下成立。

一、两份文件连接了模型开发和企业部署
开发指引处理模型为什么能够被合法开发并投入使用。个人数据的收集、整理、训练、微调和模型启用属于不同处理活动,需要分别判断目的、法律依据、必要性、数据类别、权利保障和技术组织措施。训练完成也不会当然结束个人数据问题。模型如果仍可能包含或显现与个人有关的信息,启用模型仍可能构成个人数据处理。[3]
部署工具处理某个组织能否在自己的业务环境中使用生成式 AI。工具先检查企业的第30条处理活动记录、个人数据与系统地图、实际权限和云服务安排,随后进入具体目的、可解释性、从设计入手的隐私保护、默认隐私保护、数据最小化、保存期限与供应商角色,最后讨论影响评估、错误输出、自动化决策和周期复评。[4] 这个顺序表明,模型功能只是部署判断中的一部分。企业原有的数据治理基础会直接决定系统能否被妥善控制。
上游模型经过合法训练,并不能说明企业有理由让它读取全部员工邮箱和客户档案。企业即使严格限制了本地权限,也仍需了解模型训练来源、模型是否匿名以及供应商如何协助处理数据主体请求。开发者负责形成和提供模型层证据,部署者则要独立判断这些材料能否支持本企业的启用决定。上游责任并未转移给客户,上游事实却会进入客户的法律判断。
这组文件由此解决了 AI 供应链中的一个长期断点。很多企业过去把供应商尽调和场景评估分成两套流程:采购部门确认合同和认证,业务与隐私团队再评价具体使用。两套流程之间如果没有证据传递,场景评估就只能依赖供应商的概括性承诺。AP 要求企业把模型来源、训练法律依据、测试结果和权利安排带入自己的部署档案,使问责能够沿供应链继续运行。
二、上游训练为什么会进入下游的上线判断
这项要求建立在 EDPB 2024 年第28号意见的判断结构上。EDPB 将模型定性留给个案判断,监管机构需要结合具体模型和具体手段,评估以合理可能采用的方式能否提取训练个人数据,或者通过查询获得与训练数据主体有关的信息。参数难以直接阅读,只能说明模型与数据库采用了不同的信息组织方式,无法单独证明模型已经匿名。[5]
沿着这一标准,模型启用可能出现几种不同情况。模型已经适当匿名,后续运行也不处理个人数据时,开发阶段的违法处理原则上不会影响这一后续活动。模型尚未匿名而开发过程合法时,使用方仍需为启用和具体应用建立自身的第6条法律依据。模型尚未匿名,使用方又已经知道或在合理情况下应当怀疑训练违法时,上游问题会进入后续法律依据、利益衡量和监管纠正措施的分析。[6] 这些情况不能被压缩成“训练违法会污染模型”或“模型交付后客户无需关心训练”两句结论,模型状态、开发过程、下游活动和使用方的认知都要纳入个案判断。
荷兰 AP 把这套法理落实为模型使用方的调查动作。AP 认为,使用方需要在启用前评价模型是否被合法开发,并保留实际完成评价的证明。对于闭源且尚未匿名的模型,调查范围包括训练数据来源、既有监管或司法判断、合同安排、数据主体权利协助、模型测试和开发者影响评估中识别的风险。第三方开发和知名品牌都不能免去这项独立判断。[7]
调查义务有其合理边界。采购企业没有能力逐条复核数十亿条训练数据,完整公开源数据也可能暴露新的个人数据和商业秘密。AP 因此强调由开发者提供足够证据,使使用方能够形成合理信赖。可索取的材料包括按训练数据集编制的合法性说明,说明数据来源、类别、取得方式、法律依据及特殊类别数据例外;还包括训练过程和防止不当复现的措施、正当利益评估、模型测试方法及影响评估发现的风险。[8]
这类材料与普通软件采购中的数据处理协议、信息安全附件和认证报告并不相同。数据处理协议用于分配特定处理活动中的义务,无法反向证明训练来源和模型状态;安全认证能够说明组织具备某些控制能力,也无法单独证明训练数据处理具有第6条法律依据。AP 还建议使用方查看通用目的人工智能模型是否符合《人工智能法》及欧盟《通用目的人工智能模型实践守则》,并参考有关标准或合格评定。这些材料可以帮助评价模型治理质量,GDPR 下的目的、法律依据、权利保障和必要性仍须另行成立。[9]
供应商透明度由此开始影响模型能否进入企业市场。部署方承担 GDPR 第5条第2款和第24条规定的问责责任,关键事实长期不可知会使其难以证明处理合规。法律并未正式倒置举证责任,企业却不能一面选择无法说明关键问题的供应商,一面以供应商不透明解释自身为何缺少证明。对高风险场景而言,证据不足可能直接导致暂停采购或限制使用。
荷兰 AP 在欧洲监管材料中的位置也需要准确把握。EDPB 第28号意见提供模型匿名性、正当利益和违法开发影响后续处理的法理基础。EDPB 支持专家库的大语言模型风险报告对服务架构、攻击方法、风险矩阵和持续监测展开得更细,但它属于外部专家成果,并非 EDPB 正式立场。法国 CNIL 在模型状态测试、训练数据记忆验证和模型层权利补救方面更深入,德国 DSK 的文件则对技术组织措施、检索增强生成权限、漂移、日志和机器遗忘有更系统的处理。[10]
德国 DSK 2024 年指南和巴伐利亚州监管机构的 52 项清单,也早已涉及用途、个人数据必要性、供应商是否复用输入输出、模型版本、影响评估、测试、权限和日志。[11] 荷兰 AP 的推进集中在责任衔接上,它把这些分散要求排成一条从组织基础、供应商证据、实际数据访问到上线决定和运行复评的工作顺序。
模型是否包含个人数据的欧洲讨论需要按照时间顺序理解。汉堡数据保护机构在 2024 年 7 月发布论纲,认为大语言模型本身不存储 GDPR 意义上的个人数据,模型层通常不承载数据主体权利,并明确将文件定位为推动讨论的材料。EDPB 随后于同年 12 月通过第28号意见,为欧洲监管协调确立共同判断尺度:模型不能被当然视为匿名,监管机构应结合具体模型和合理可能采用的手段,评价能否识别训练数据主体或通过查询提取相关个人数据;开发阶段的违法处理也可能影响后续部署,模型已经适当匿名的情形除外。汉堡论纲因此适合用来说明 EDPB 意见形成前的争论背景。EDPB 意见公布后,欧盟监管分析应以这套个案判断标准为共同起点,荷兰 AP 目前的立场也沿着这一标准展开。[12]
三、企业需要审查模型进入组织后的实际状态
企业的 AI 审批经常围绕供应商品牌、产品功能和合同条款展开。AP 部署工具关注的是更完整的组合:模型、数据、权限、目的、人员、供应商安排和运行环境共同构成的部署状态。工具第一章从处理活动记录、个人数据地图、授权管理和云服务安排开始,原因也很直接。企业如果不知道个人数据位于哪些系统、由哪些角色访问,也不知道原有处理会怎样被 AI 触达,就无法证明新的访问符合目的限定和数据最小化。[13]
这一问题在企业搜索、检索增强生成和内部知识助手中表现得最明显。员工过去可能有权打开多个共享文件夹,但仍需知道文件位置并逐层查找。生成式 AI 接入以后,一次自然语言提问就可能完成跨库检索、概括和信息重组。访问权限在形式上没有增加,个人数据被发现和利用的能力却明显增强。企业过去积累的过宽授权会迅速转化为现实暴露,因此 AP 要求重新检查授权政策、动态权限和每一类文件访问的必要性。[14]
数据地图也需要覆盖模型运行产生的新处理环节。部署工具要求组织掌握输入、输出、元数据、诊断数据和遥测数据的存储位置及保存期限,并查明供应商能否将这些信息用于产品改进或再次训练。提示词、检索上下文、日志、反馈、评测样本、长期记忆和工具调用可能由不同主体保存,也可能适用不同目的和期限。只画业务数据库中的传统字段,已经不足以反映生成式 AI 的真实处理链路。[15]
目的限定在这里具有实际筛选作用。AP 明确指出,“帮助员工”或“提高效率”过于宽泛,无法说明系统准备解决哪个具体问题,也无法据此确定必要的数据范围。目的需要落到特定任务、使用人员、输入信息和输出用途,企业还要防止系统被扩展到原先未评估的场景。目的越宽,系统越容易取得大量文件访问权,影响评估也越难判断哪些处理具有必要性。[16]
供应商安排同样要进入这一部署状态。企业应当了解各方属于处理者、共同控制者还是独立控制者,约定数据主体权利协助、进一步处理、再次训练、数据安全和变更通知。供应商没有提供保存期限或无法让客户调整设置,并不会减轻部署方的 GDPR 责任。AP 直接指出,这种缺乏透明度和控制能力的情况可能阻碍系统使用。[17]
在完成上述事实梳理之后,数据保护影响评估才有充分基础。AP 提醒,试点同样可能处理个人数据,通用或参考影响评估也不能代替组织对自身目的、数据、权限和环境作出的评价。是否必须实施评估,仍要根据 GDPR 第35条的触发条件判断,不能把所有生成式 AI 项目一概而论;评估后仍存在高残余风险时,第36条事前咨询会成为上线前的程序门槛。[18]
影响评估在内部流程中的权重比是否填写模板更重要。项目已经锁定供应商和技术架构后再补文件,隐私团队通常只能提出缓解措施,很难改变系统范围。一套有效流程需要允许评估得出限制上线、调整架构或暂停的结论,并提前约定相应条件。数据和权限无法画清、供应商缺少关键证据、保存和再次训练不可控、高残余风险尚未解决,都可能构成暂停理由。AP 没有使用“停止条件”这一法定概念,这里是对其问题链的企业治理转化。
这里涉及 GDPR 第22条语境下的“有意义的人类介入”。它与《人工智能法》第14条规定的“人类监督”存在功能交叉,法律依据和适用条件并不相同。生成式 AI 参与招聘、员工评价、信贷、保险、医疗或公共服务决定时,流程末端保留确认按钮并不足够。复核者需要理解系统的能力和错误模式,拥有必要的上下文和审查时间,并有权修改、拒绝或偏离模型输出。AP 特别指出,时间越少,人类介入越难具备实质意义。[19] 监督效果还会受到岗位培训、处理时限、界面信息、绩效指标和升级机制的共同影响。企业如果把速度和采纳率设为主要考核指标,制度文件中的“由人作出最终决定”很可能无法真实运行。
四、上线决定需要随系统变化重新评估
传统软件审批往往以产品为单位,生成式 AI 更适合采用配置和版本视角。同一产品从普通对话扩展到检索增强生成、企业搜索、长期记忆或智能体工具调用后,访问的数据、权限和处理后果都会改变;模型升级也可能改变记忆、复现、过滤和工具调用能力;供应商如果调整输入输出再利用、数据驻留、保存期限或子处理者,原有判断的事实基础同样会发生变化。
AP 把周期复评列为部署工具的最后一个独立环节,要求组织将复评纳入日常经营,指定负责人员,并持续检查处理目的、个人数据、系统和保存期限是否仍与原决定一致。[20] 因而,企业批准的内容应当写得足够具体,包括模型和系统版本、业务目的、数据源、访问角色、供应商条件、人类复核要求和使用限制。批准文件如果只写“允许使用某供应商的生成式 AI”,后续很难判断哪一次变化已经超出原评估范围。
复评既可以定期开展,也应当由事件触发。需要重点关注的变化包括模型版本升级、增加新的检索数据源或工具、扩大文件库和用户权限、用途转向个人评价或决定、供应商修改再次训练和保存安排,以及出现越权访问、错误归因、训练数据复现或数据主体请求无法处理等事件。这些事项是根据 AP 的周期复评要求作出的实务展开,并非 AP 给出的封闭清单。
企业内部的证据文件也应围绕同一项决定相互连接。场景卡记录目的、必要性、使用人员、个人数据类别和禁止用途;供应商模型证据包保存训练来源、法律依据、数据清理、模型状态测试、数据再利用和权利协助信息;数据与权限地图呈现文件、应用、检索数据源和角色访问;场景化影响评估记录风险、措施、残余风险和上线结论;人类介入规程明确复核信息、时间、权限、升级与申诉;变更登记簿负责记录哪些事实已经使原决定需要重开。
这几类材料之间需要能够相互追溯。场景卡确定数据地图的范围,数据地图验证目的所需的访问,供应商证据成为影响评估的事实输入,影响评估再决定上线条件和人类复核要求,变更登记簿负责监测这些条件是否仍然成立。文件如果彼此独立,企业仍然只能证明填过表,无法说明当时基于哪些事实作出了决定。
责任分配也应随之调整。业务和产品负责人需要说明目的及必要性,采购与法务负责取得供应商证据和合同权利,安全、信息技术和数据治理团队确认真实访问范围及技术控制,隐私团队和数据保护官评价法律依据、影响评估和残余风险,系统负责人最终签收上线条件并负责触发复评。全部材料如果都由隐私团队代为填写,事实责任和决定责任就没有进入业务流程,问责仍然停留在文书层面。
五、这套证明结构会逐步改变模型采购
荷兰 AP 的材料还显示,生成式 AI 合规正在形成一套证据基础设施。模型是否容易被企业采购,会越来越多地取决于供应商能否交付训练来源分类、法律依据、数据清理、模型状态测试、权利协助、保存与再次利用安排,以及随版本更新的变更信息。功能、价格和安全表现仍然重要,证据交付能力会成为受监管行业和大型组织选择供应商时的额外条件。
企业采购合同的重点也会相应变化。责任分配和赔偿条款之外,企业还需要获得持续的信息权、必要的验证机制、数据主体权利协助、重大变更通知和退出能力。供应商提供的资料如果只能支持签约时的判断,却不会随模型版本和处理方式更新,企业很快会失去继续使用的证明基础。
监管核查也会因此更加具体。监管机构可以继续依据数据最小化、目的限定和问责原则提出问题,同时要求企业说明系统实际访问哪些文件、为什么需要这些访问、供应商保存哪些遥测信息、影响评估使用了哪些上游材料、谁批准了残余风险,以及版本变化后何时重新评价。抽象原则由此被转化为可以检查的组织事实。
证据要求也可能带来市场集中风险。大型供应商更有资源制作复杂的合规材料,小型开发者则可能因证明成本被挡在企业市场之外。较好的方向是形成可复用、分层、能够保护商业秘密的模型证明标准,减少每个客户重复发放问卷的成本。AP 在开发指引中也提到,需要更加集中和易于访问的模型来源与质量信息,并引用阿姆斯特丹市的相关项目作为示例。[21]
这两份文件最终推动的是一种更具体的上线判断。企业需要说明,在当前模型和系统版本下,为了已经确定的目的,由特定人员访问限定的数据源,并在既定保存、供应商和人类复核条件下运行,系统可以投入使用。关键条件发生变化后,原结论需要重新评价。供应商的合规说明由此成为企业判断的起点,企业自己的部署记录则构成最终能够接受监管核查的证明。
---
尾注
[1] 荷兰 AP 于 2026 年 7 月 13 日同时发布开发指引和部署工具,见 AP 官方发布页。
[2] 开发指引的初步、暂定、非穷尽性质及闭源模型范围,见 AP《Handreiking generatieve AI en de AVG》管理摘要和范围说明;部署工具的非穷尽、不替代数据保护影响评估、不覆盖《人工智能法》以及不讨论部署法律依据等边界,见 部署工具官方页面及该工具文件内页 2。
[3] AP 开发指引关于收集、整理、训练和启用分活动判断,以及非匿名模型启用仍涉及个人数据处理的分析,见该指引第 3 章,尤其文件内页 10—20。
[4] AP 部署工具三阶段结构见文件内页 2—3,分别处理组织基础、具体系统选择以及实际部署和持续使用。
[5] 关于人工智能模型匿名性不能预设、需要评价提取和查询识别可能性的标准,见 EDPB 第28/2024号意见,尤其第 38—43 段。
[6] 关于开发阶段违法处理与后续处理的不同情形,见 EDPB 第28/2024号意见的场景分析,尤其第 126、129、135 段。本文对不同情况的归纳用于解释判断结构,不属于监管文件中的固定分类。
[7] AP 关于模型使用方独立保证合法性、调查训练来源和已知违法问题的分析,见开发指引第 3.2 节,文件内页 18—19。
[8] AP 列举的训练集合法性说明、训练过程、正当利益评估、影响评估风险和测试信息,见开发指引文件内页 19。
[9] AP 将通用目的人工智能模型的《人工智能法》要求、欧盟《通用目的人工智能模型实践守则》、相关标准或合格评定作为启用评价的可能信息来源;这些材料不替代 GDPR 法律依据与权利分析。
[10] EDPB 支持专家库的大语言模型风险报告及项目性质见 EDPB 项目页;模型状态与权利问题参见 CNIL 模型 GDPR 状态分析、CNIL 数据主体权利指南及 DSK 2025 年人工智能系统技术组织措施指南。
[11] 参见 DSK 2024 年人工智能与数据保护指南。BayLDA 52 项清单在本文中仅作为监管检查结构的比较材料。
[12] 汉堡数据保护机构于 2024 年 7 月 15 日发布《关于大语言模型个人数据属性的汉堡论纲》,并将其定位为推动专业讨论的文件。EDPB 于 2024 年 12 月 17 日通过、18 日公布第28/2024号意见;EDPB 官方说明,该意见应爱尔兰数据保护机构请求制定,目的在于推动欧洲范围的监管协调。本文将汉堡论纲作为 EDPB 共同立场形成前的历史材料,不作为与第28号意见并列的现行欧盟监管立场。
[13] AP 部署工具第 1 章,文件内页 4—8。
[14] AP 部署工具第 1.3 节及第 2.4 节,文件内页 6、14—15。本文关于过宽权限转化为现实暴露的分析属于企业治理归纳。
[15] AP 部署工具第 2.5—2.6 节,文件内页 16—20。
[16] AP 部署工具第 2.1 节,文件内页 9—10。
[17] AP 部署工具第 2.5—2.6 节,文件内页 16—20。
[18] AP 部署工具第 3.1 节,文件内页 21—22。是否必须开展数据保护影响评估,仍须依据 GDPR 第35条的具体触发条件判断。
[19] AP 部署工具第 3.2—3.3 节,文件内页 23—25;GDPR 第22条是否适用仍取决于具体决定及其法律或类似重大影响。AP 对应文件的官方英文标题使用 Meaningful Human Intervention。《人工智能法》第14条使用的 Human Oversight 是范围和适用条件不同的制度概念。
[20] AP 部署工具第 3.4 节,文件内页 26—27。
[21] AP 开发指引在讨论模型选择时提出,需要更集中、可访问的模型来源与质量信息,并以阿姆斯特丹市的模型信息项目作为示例,见文件内页 19。
---
附录|《生成式 AI 使用与 GDPR 辅助工具》全文翻译
原文:荷兰个人数据保护局(AP),Hulpmiddel inzet generatieve AI & de AVG,2026 年 7 月,共 28 页。
以下为非官方中文翻译。为便于回查,译文保留原文件的章节、核验项编号、勾选选项和脚注。原 PDF 中用于填写的空白栏统一改为“填写说明”。
生成式 AI 使用与 GDPR 辅助工具
生成式人工智能(生成式 AI)是一种能够生成新数据的 AI。当前最流行的应用能够生成文本和图像,人们已经无法再从成品本身看出它们由 AI 生成。
生成式 AI 可能处理个人数据。只要发生个人数据处理,《通用数据保护条例》(GDPR)就适用。荷兰个人数据保护局(AP)建议组织研究能否在不使用个人数据的情况下使用生成式 AI。
如何使用这份辅助工具?
借助这份辅助工具,您可以将 GDPR 的规范纳入考虑,并说明本组织如何落实这些规范。1 它还可以帮助您根据本组织使用生成式 AI 所产生的风险,采取适当的技术和组织措施。2
越来越多的组织正在考虑使用生成式 AI,但并非总能充分考虑其给数据主体和组织自身带来的风险。因此,AP 发布了这份《生成式 AI 使用与 GDPR 辅助工具》。借助这份工具,您可以依据 GDPR 的规范,评估本组织是否愿意、是否有能力以及是否可以合法使用生成式 AI。它还可为生成式 AI 的实施和投入使用提供帮助。
在采购、实施和使用生成式 AI 之前使用这份工具,可以帮助本组织更好地符合从设计入手的隐私保护和默认隐私保护要求。3 这份工具尤其适用于希望让生成式 AI 应用访问组织现有文件或数据的组织,但在其他情况下也同样具有参考价值。
这份工具只讨论生成式 AI 的使用,不适用于自行开发生成式 AI 模型的组织。有关生成式 AI 模型开发的更多信息,请参阅 AP 的《生成式 AI 与 GDPR 指引》。这份工具也不讨论其他相关法律提出的要求,例如《人工智能法案》。4
请安排隐私专业人员、信息技术专家以及希望使用生成式 AI 的业务部门代表共同填写本文件。组织是否设有数据保护官?如有,应及时让数据保护官参与整个过程。5
这份工具包括什么?
本工具分为三章:
- 组织在决定使用生成式 AI 之前需要完成的步骤;
- 选择具体生成式 AI 系统时需要完成的步骤;
- 实际使用生成式 AI 时需要完成的步骤。
在实践中,第二章和第三章的部分步骤可能重叠。
每一步都配有若干陈述。对于每项陈述,您需要勾选是否已经满足相应要求,并作出说明。为了履行问责义务,说明理由不可缺少。6
请注意:这份工具并不穷尽所有要求,也不能替代数据保护影响评估(DPIA)。本组织仍可能需要开展 DPIA。7 此外,还必须将相应处理活动纳入处理活动记录。8
因此,仅仅填完本文件并不足以证明组织已经遵守 GDPR。它可以为合规工作提供支持,例如作为 DPIA 的附件。本文件讨论的是组织在开始使用生成式 AI 之前必须完成的步骤。
这份工具以 AP 最近就生成式 AI 事先咨询所出具的意见为基础。9 该意见全文已经公开。由于该次事先咨询没有讨论个人数据处理的法律依据,本工具也不涉及这一问题。
目录
- 为生成式 AI 做好组织准备:夯实基础(第 4 页)
1.1 处理活动记录(第 4 页)
1.2 已处理个人数据概览(第 5 页)
1.3 授权管理(第 6 页)
1.4 云环境中的处理活动(第 7 页)
- 选择具体的生成式 AI 系统(第 9 页)
2.1 使用生成式 AI 的目的(第 9 页)
2.2 生成式 AI 系统的可解释性(第 11 页)
2.3 从设计入手的隐私保护和默认隐私保护(第 12 页)
2.4 数据最小化(第 14 页)
2.5 存储限制(第 16 页)
2.6 与参与处理的相关方作出约定(第 18 页)
- 使用生成式 AI(第 21 页)
3.1 开展 DPIA(第 21 页)
3.2 回答不正确或不符合预期的风险(第 23 页)
3.3 自动化决策(第 24 页)
3.4 定期重新评估生成式 AI 的使用(第 26 页)
1. 为生成式 AI 做好组织准备:夯实基础
本章讨论以下步骤:
1.1 处理活动记录;
1.2 已处理个人数据概览;
1.3 授权管理;
1.4 生成式 AI 对云环境中处理活动的影响。
组织在使用生成式 AI 之前,必须先夯实基础。这意味着组织已经事先采取充分的技术和组织措施保护个人数据。
本章列出了夯实这项基础时最重要的关注点,但并不穷尽所有要求。因此,还应考虑《人工智能法案》等其他相关法律。
1.1 处理活动记录
处理活动记录可以呈现本组织内的全部处理活动。10 借助这份总体概览,您可以看到哪些处理活动可能受到生成式 AI 使用的影响,从而更好地评估影响并合法使用生成式 AI。因此,AP 建议组织在使用生成式 AI 之前检查处理活动记录,在必要时予以更新,并以此为基础评估生成式 AI 对现有处理活动的影响。
1.1.a 本组织已经建立符合 GDPR 第 30 条要求的处理活动记录
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织如何符合 GDPR 第 30 条的要求,例如处理活动记录保存在哪里。
1.1.b 处理活动记录能够使本组织清楚了解哪些处理活动可能受到生成式 AI 使用的影响
- [ ] 符合
- [ ] 不符合
填写说明: 请根据本组织拟使用生成式 AI 的目的,说明哪些处理活动可能受到影响。
1.2 已处理个人数据概览
除本组织处理活动的总体情况外,您还需要更详细地掌握本组织处理的各类个人数据,以及用于处理这些数据的系统或应用。已处理个人数据概览有助于组织合法使用生成式 AI。编制这份概览往往需要投入大量时间和精力,尤其是在组织尚未做好相关基础工作的情况下。
请注意:如果生成式 AI 系统将访问本组织现有文件或数据的全部或一部分,这一步尤其重要。
1.2.a 本组织已经查明所处理的个人数据类别,以及处理这些数据所使用的应用或系统
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织处理哪些类别的个人数据,以及使用哪些应用或系统处理这些数据。如果本组织处理的个人数据种类很多,可以另行制作概览文件并在此引用。
1.2.b 本组织能够确保个人数据只在已经查明的场所和系统中处理
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织如何保证个人数据不会在其他场所或系统中处理。例如,如何防止通过电子邮件处理个人数据?
1.3 授权管理
如果考虑让生成式 AI 系统访问本组织现有的文件或数据,就必须进行授权管理。根据数据最小化原则,并非每一名员工都可以访问本组织内的全部个人数据或其他数据,通过生成式 AI 系统访问时也不例外。因此,应确保访问权限与员工的岗位职责相匹配。
请注意:如果生成式 AI 系统能够访问与用户相同的文件,这一步尤其重要。
1.3.a 本组织已经制定授权管理政策
- [ ] 符合
- [ ] 不符合
填写说明: 请简要说明本组织的授权管理政策。
1.3.b 本组织在实际工作中落实授权管理政策
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织如何实际落实授权管理政策,并说明所使用的应用或系统中是否存在动态授权,以及如何管理这些授权。
1.4 云环境中的处理活动
一些生成式 AI 系统属于更大规模在线服务生态的一部分。例如,组织可以在已经使用的云环境中增加生成式 AI 系统。
组织必须了解云环境内的处理活动,包括全部或部分由供应商实施的处理活动。这是 GDPR 规定的义务,11 在现有环境中增加新的处理活动时尤其重要。使用生成式 AI 系统可能提高现有处理活动的风险。
请注意:只有在本组织使用供应商提供的在线服务或其他服务时,本步骤才适用。
1.4.a 本组织已经与云环境供应商签订数据处理协议
- [ ] 符合
- [ ] 不适用(生成式 AI 系统不属于云环境的一部分)
- [ ] 不符合
填写说明: 请说明数据处理协议中的主要约定,以及协议保存在哪里。
1.4.b 本组织已经评估使用生成式 AI 系统时是否需要修改标准数据处理协议
- [ ] 符合
- [ ] 不适用(生成式 AI 系统不属于云环境的一部分)
- [ ] 不符合
填写说明: 请说明数据处理协议是否已经根据本组织的具体情况作出调整,或者本组织是否使用标准数据处理协议。
1.4.c 本组织已经考虑荷兰中央政府统一云政策及其配套的《云使用风险权衡实施框架》
- [ ] 符合
- [ ] 不适用(本组织不是政府机构)
- [ ] 不符合
填写说明: 请说明本组织如何考虑荷兰中央政府统一云政策(Rijksbrede cloudbeleid)及其配套的《云使用风险权衡实施框架》(Implementatiekader risicoafweging cloudgebruik)。
2. 选择具体的生成式 AI 系统
组织夯实基础后,可以进一步考虑希望、有能力且可以合法使用哪一个生成式 AI 系统。从一开始就必须明确纳入 GDPR 的规范和义务。生成式 AI 系统的固有功能往往难以关闭,而选择另一个系统时可能根本无须关闭相同功能。每个系统各有利弊,对数据主体权利和自由造成的影响也不同。12
本章问题对于选择具体的生成式 AI 系统十分重要。在实践中,本章步骤可能与下一章关于实际使用生成式 AI 的步骤重叠。AP 强调,组织正在使用某一供应商的其他服务,并不足以成为继续选择该供应商 AI 系统的理由。
本章讨论以下步骤:
2.1 使用生成式 AI 的目的;
2.2 生成式 AI 系统的可解释性;
2.3 从设计入手的隐私保护和默认隐私保护;
2.4 数据最小化;
2.5 存储限制;
2.6 与参与处理的相关方作出的约定。
2.1 使用生成式 AI 的目的
本组织使用生成式 AI 的目的与具体系统的选择密切相关。因此,应事先确定本组织准备将生成式 AI 用于什么目的。
本组织通过生成式 AI 系统处理个人数据时——实践中经常如此——必须遵守 GDPR 的各项原则。13 其中包括:个人数据只能为特定、明确且合法的目的而处理,即目的限制原则。14 使用生成式 AI 系统本身不能成为目的,系统必须用于解决一个具体问题。
根据目的限制原则,生成式 AI 系统只能用于实现事先确定的目的。该目的必须具体、明确。15 这意味着目的已经被清楚记录,表述不能过于宽泛。目的不清楚或者表述过度技术化,都可能导致处理活动违法。
因此,应清楚说明生成式 AI 使用的目的、背景和性质。这样既有助于遵守 GDPR,也有助于维持数据主体的信任。
2.1.a 本组织已经确定拟使用生成式 AI 所要实现的具体、明确目的
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织准备将生成式 AI 用于什么目的。目的必须具体、明确。“为员工提供支持”或“提高某项流程的效率”等过于笼统的表述不符合目的限制原则。例如,生成式 AI 将为本组织解决哪一个具体问题?
2.1.b 本组织已经说明生成式 AI 如何帮助实现已确定的目的
- [ ] 符合
- [ ] 不符合
填写说明: 请说明使用生成式 AI 对实现既定目的具有何种附加价值。
2.1.c 本组织能够防止生成式 AI 被用于其他目的
- [ ] 符合
- [ ] 不符合
填写说明: 请说明如何防止员工将生成式 AI 用于事先确定范围以外的其他目的,例如是否采取了相应措施,以及是否制定了生成式 AI 内部使用政策。
2.2 生成式 AI 系统的可解释性
可解释性是透明原则的一部分。合法开发和使用生成式 AI 都需要透明度。16 如果不能以清楚、易懂的方式与数据主体沟通,个人数据处理就不具有合法性。
重建生成式 AI 系统的推理过程可能十分困难,在技术上甚至不可能。生成式 AI 系统采用不同技术,因此可解释程度也存在差异。
如果计划在决策流程中使用生成式 AI,选择具体系统时就必须考虑该系统在相应场景中能够提供何种程度的透明度。
请注意:如果本组织属于行政机关,这一步尤其重要。在决策流程中使用生成式 AI,可能使组织更难遵守行政管理的一般原则,特别是决定说明理由的原则。
2.2.a 本组织在选择具体的生成式 AI 系统时已经考虑其可解释程度
- [ ] 符合
- [ ] 不符合
填写说明: 请结合使用目的和本组织的具体情况,说明本组织要求生成式 AI 系统达到何种可解释程度。例如,本组织是否研究过重建生成式 AI 系统推理过程的技术方法或其他方法?
2.3 从设计入手的隐私保护和默认隐私保护
从设计入手的隐私保护(privacy by design),是指从服务或产品设计之初就将隐私和数据保护要求纳入其中。默认隐私保护(privacy by default),是指产品的默认设置能够提供最高程度的隐私保护。
GDPR 要求组织落实从设计入手的隐私保护和默认隐私保护。17 选择生成式 AI 系统等具体处理手段时同样适用这项要求。18 因此,在选择生成式 AI 系统时,应当考虑其设计是否已经纳入隐私和数据保护要求,默认设置是否能够提供最高程度的隐私保护。
选择生成式 AI 系统时,还应考虑输出过滤器和实时输入过滤器等降低风险的功能。输出过滤器能够降低模型生成不当答案或个人数据、特殊类别个人数据的风险。实时输入过滤器能够在用户输入个人数据时发出警告。
2.3.a 本组织在选择生成式 AI 系统时已经考虑从设计入手的隐私保护
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织在选择具体 AI 系统时如何考虑从设计入手的隐私保护。例如,应考虑现有技术水平、实施成本、处理的性质、范围、背景和目的,以及处理活动给自然人权利和自由带来风险的可能性和严重程度。19
2.3.b 本组织在选择生成式 AI 系统时已经考虑默认隐私保护
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织如何考虑默认隐私保护。生成式 AI 系统的默认设置是否已经尽可能有利于保护隐私?例如,该系统是否默认可以访问用户的数据和文件?
2.3.c 本组织在选择生成式 AI 系统时已经考虑能够加强个人数据保护的功能
- [ ] 符合
- [ ] 不符合
填写说明: 请说明生成式 AI 系统具备哪些隐私保护功能,以及这些功能如何影响本组织对具体系统的选择,例如输出过滤器和输入过滤器。
2.4 数据最小化
数据最小化原则要求本组织只在绝对必要时处理个人数据。某项处理是否必要,应当根据使用生成式 AI 系统所要实现的具体目的进行判断。
一些集成式生成式 AI 系统能够访问用户有权访问的全部文件。如果生成式 AI 系统能够访问本组织内的全部数据,组织很难符合数据最小化原则,因为这些数据不太可能全部为实现具体目的所必需。
组织可以在处理开始前确定生成式 AI 系统能够访问哪些个人数据或其他数据,以落实数据最小化。例如,可以阻止系统访问电子邮件、聊天等文件或应用,也可以明确用户可以向系统输入哪些类别的个人数据。
请注意:如果生成式 AI 系统能够访问本组织现有文件的全部或一部分,这一步尤其重要。
2.4.a 本组织已经对生成式 AI 系统作出设置,使其只能访问实现使用目的所必需的文件和应用
- [ ] 符合
- [ ] 不符合
填写说明: 请说明生成式 AI 系统能否访问用户有权访问的全部或部分文件和应用。本组织是否已经将访问范围限制在实现使用目的所必需的文件和应用?
2.4.b 本组织能够说明允许生成式 AI 系统访问特定文件和应用时所作的权衡
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织围绕数据最小化原则所作的权衡。生成式 AI 系统为什么需要访问特定文件和应用?请按文件或应用类别,分别说明访问的必要性。
2.4.c 本组织已经制定政策,规定用户可以向生成式 AI 系统输入哪些类别的个人数据
- [ ] 符合
- [ ] 不符合
填写说明: 请说明内部政策是否已经规定哪些类别的个人数据可以通过生成式 AI 处理,哪些类别不得处理。
2.5 存储限制
根据存储限制原则,本组织保存通过生成式 AI 系统处理的个人数据,不得超过实现具体目的所必需的期限。
对此,同样应当从处理目的出发,而非从所使用的工具出发。因此,应当根据处理目的确定个人数据的保存期限。仅仅因为保存数据有利于生成式 AI 系统运行就予以保留,很容易构成违法处理。
本组织必须完整了解生成式 AI 系统所处理各类个人数据的存储位置和保存期限,并拥有足够的控制能力。除输入和输出外,这些个人数据类别还可能包括元数据、诊断数据和遥测数据。
即使生成式 AI 系统的供应商没有清楚说明保存期限,或者不允许组织调整保存期限,本组织仍有义务遵守 GDPR。这可能构成使用该生成式 AI 系统的障碍。
2.5.a 本组织了解生成式 AI 系统所处理各类个人数据的存储位置,并对其拥有足够的控制能力
- [ ] 符合
- [ ] 不符合
填写说明: 请说明生成式 AI 系统的供应商如何披露这些存储位置,各类个人数据分别存储在哪里,以及本组织如何控制个人数据在这些位置的存储。
2.5.b 本组织了解生成式 AI 系统所处理各类个人数据的保存期限,并对其拥有足够的控制能力
- [ ] 符合
- [ ] 不符合
填写说明: 请说明不同类别个人数据的保存期限、生成式 AI 系统供应商如何向本组织披露这些期限,以及本组织能否控制保存期限的长短。
2.5.c 本组织已经尽可能减少存储位置的数量
- [ ] 符合
- [ ] 不符合
填写说明: 请说明如何确保生成式 AI 系统所处理的个人数据不会存储在超出必要范围的更多位置,以及本组织为尽可能减少存储位置采取了哪些措施。
2.5.d 本组织已经尽可能缩短保存期限
- [ ] 符合
- [ ] 不符合
填写说明: 请说明如何确保生成式 AI 系统所处理的个人数据不会被保存超过必要期限,以及本组织为尽可能缩短保存期限采取了哪些措施。
2.6 与参与处理的相关方作出约定
作为生成式 AI 系统的采购和使用方,本组织在很大程度上依赖供应商提供有关个人数据处理的信息。因此,与供应商及可能参与处理的其他第三方作出约定十分重要。例如,组织在保障数据主体隐私权利时,部分依赖供应商的配合。
个人数据被处理时,数据主体依据 GDPR 享有多项权利,包括获得信息、访问和更正的权利。作为控制者,本组织必须能够保障这些权利的行使,而这又依赖供应商提供的透明度。
如果缺少这种透明度,本组织就无法履行为数据主体行使权利提供便利的义务。因此,应当与生成式 AI 系统的供应商及参与处理的其他相关方作出充分约定,同时查明各方角色:它们是单独或共同控制者,还是处理者?20
第三方如果构成处理者,本组织必须与其签订数据处理协议。GDPR 要求控制者保障处理系统和个人数据达到适当的安全水平。
2.6.a 本组织已经查明生成式 AI 系统供应商等参与处理的相关方在个人数据处理中的角色
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织调查了哪些第三方,以及它们依据 GDPR 构成处理者,还是单独或共同控制者。
2.6.b 本组织已经查明第三方在保障数据主体行使权利方面承担的角色,并与其作出适当约定
- [ ] 符合
- [ ] 不符合
填写说明: 请说明哪些第三方参与保障数据主体行使权利,并说明本组织与构成单独或共同控制者、处理者的第三方作出了哪些约定,尤其应说明数据处理协议中载明的约定。
2.6.c 本组织已经与供应商签订符合此前所确定控制者和处理者角色的适当协议
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织与第三方就协助数据主体行使权利作出了哪些约定。如果供应商属于处理者,请说明是否签订了数据处理协议;如果构成共同控制,还应说明各方作出了哪些约定。
2.6.d 本组织已经就共享给第三方的个人数据如何被处理或进一步处理作出约定,包括共享给生成式 AI 系统供应商的数据
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织与参与处理的相关方就通过生成式 AI 系统共享的个人数据如何被处理或进一步处理作出了哪些约定。本组织是否已经明确这些个人数据向第三方共享的目的?
2.6.e 本组织已经与生成式 AI 系统供应商等参与处理的相关方约定,能否将个人数据用于生成式 AI 系统的训练或进一步训练
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织与参与处理的相关方就个人数据的处理或进一步处理作出了哪些约定。例如,这些相关方能否将本组织共享的数据用于训练自己的模型?
2.6.f 本组织已经与参与处理的相关方就生成式 AI 系统的安全作出约定
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织与参与处理的相关方就适当安全水平作出的约定。例如,本组织是否与供应商约定安全标准,以保护生成式 AI 系统所处理的个人数据?
3. 使用生成式 AI
组织选定希望且有能力使用的生成式 AI 系统后,还应考虑正式使用前、使用期间和使用后需要注意的问题。应当事先识别使用风险,并定期重新评估,以便采取适当措施。
本章讨论以下步骤:
3.1 对准备使用的系统开展 DPIA;
3.2 回答不正确或不符合预期的风险;
3.3 自动化决策;
3.4 定期重新评估生成式 AI 的使用。
3.1 开展 DPIA
数据保护影响评估(DPIA)有助于本组织在处理开始前识别个人数据处理对数据主体基本权利和自由造成的风险,从而采取适当措施降低这些风险。
本组织应当自行判断具体处理活动是否必须开展 DPIA,并根据 GDPR 规定的因素作出判断。例如,在个人数据处理中使用生成式 AI 等新技术时,可能需要开展 DPIA。生成式 AI 试点同样可能处理个人数据,因此也需要开展 DPIA。有关 DPIA 义务的更多信息,请参阅 AP 网站。21
如果必须开展 DPIA,本组织应当自行完成。仅仅援引其他组织编制的一般性 DPIA,也称参考 DPIA,并不足够。DPIA 完成后如果识别出高剩余风险,本组织有义务根据 GDPR 第 36 条向 AP 申请事先咨询。
3.1.a 本组织已在使用生成式 AI 之前开展 DPIA
- [ ] 符合
- [ ] 不符合
填写说明: 请说明为什么已在生成式 AI 试点或正式使用之前开展 DPIA,或者为什么没有开展。
3.1.b 本组织已就 DPIA 征求数据保护官(DPO)的意见
- [ ] 符合
- [ ] 不适用(本组织没有 DPO)
- [ ] 不符合
填写说明: 请简要说明 DPO 的意见。
3.1.c DPIA 没有发现高剩余风险
- [ ] 符合
- [ ] 不适用(未开展 DPIA)
- [ ] 不符合
填写说明: 请说明 DPIA 识别出哪些风险,以及本组织将采取哪些措施降低这些风险。
3.1.d DPIA 显示存在高剩余风险,并且本组织已经向 AP 申请事先咨询[^22]
- [ ] 符合
- [ ] 不适用(DPIA 没有发现高剩余风险)
- [ ] 不符合
填写说明: 请说明涉及哪些高剩余风险。
3.2 回答不正确或不符合预期的风险
本组织必须防止处理不正确或不符合预期的个人数据。这意味着应当采取适当措施,及时删除或更正不准确的个人数据。准确性原则在其中具有重要作用。
生成式 AI 的使用可能由于多种原因与准确性原则发生冲突。生成式 AI 系统并不总能给出正确答案。系统并不依据对世界的认识进行“推理”,其工作方式是预测哪些词语最适合特定语境。因此,错误答案乍看之下也可能符合逻辑或者具有说服力。训练数据中的错误也可能导致生成式 AI 系统重复不正确信息。
准备使用生成式 AI 的组织必须处理系统生成不正确或不符合预期个人数据的风险。因此,应当评估风险,并使员工认识到这种局限,避免盲目信赖生成式 AI 系统的输出。用户还必须拥有足够的知识和时间,对输出进行批判性审查。这与《人工智能法案》中的 AI 素养概念有关。有关 AI 素养的更多信息,请参阅 AP 网站。23
3.2.a 本组织已经采取措施,使员工认识到系统生成的回答可能不正确或不符合预期
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织采取了哪些措施,使员工认识系统生成的回答可能不正确或不符合预期,例如培训、工作坊或其他风险意识措施。
3.2.b 本组织已经采取补充措施,防止不正确或不符合预期的回答给数据主体造成影响
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织采取了哪些补充措施,防止系统生成的不正确或不符合预期的回答给数据主体造成影响,例如输入和输出过滤器,以及对生成式 AI 系统默认设置的调整。
3.3 自动化决策
在涉及针对个体数据主体作出决定的业务或其他流程中使用生成式 AI 系统,可能形成自动化决策。因此,组织必须考虑如何设置有意义的人类介入。原则上,禁止在没有有意义人类介入的情况下完全通过自动化方式作出决定,法律规定的例外情形除外。24
因此,应当检查使用生成式 AI 的工作流程是否涉及针对个人作出决定。如果涉及,就存在自动化决策风险,需要采取补充措施。例如,可以制定明确的生成式 AI 使用规则,确保人工判断仍然具有决定性作用。
应鼓励用户批判性审查系统输出,不要主要依据输出作出涉及数据主体的决定。同时,应确保用户充分了解生成式 AI 系统的运行方式,并有权偏离系统输出。员工可用于审查的时间越少,人类介入就越难具有实际意义。有关这一主题的更多信息,请参阅《有意义的人类介入实务要点》。25
3.3.a 本组织能够确保在涉及数据主体的决策中,人的判断仍然具有决定性作用
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织采取了哪些保障措施,确保人在涉及数据主体的决策中仍然发挥决定性作用。例如,相关政策或流程是否规定员工可以在多大程度上偏离 AI 系统输出,以及员工有多少时间审查系统输出?
3.3.b 本组织已经确保员工充分了解生成式 AI 系统,包括其技术运行方式、社会、伦理和实践层面的因素,以及使用风险
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织采取了哪些措施、步骤或决定,使员工充分了解生成式 AI 系统,例如理论和实务培训、进修课程和工作坊。本组织如何确保新员工获得这些知识,又如何安排定期复训?
3.4 定期重新评估生成式 AI 的使用
生成式 AI 系统经常深度嵌入工作流程和其他系统,因此能够访问大量数据。与此同时,个人数据处理会不断发生变化。例如,组织可能增加新的处理活动或个人数据,现有处理活动也可能改变。
为了持续、合法且负责任地使用生成式 AI,必须定期重新评估。如果不作定期评估,生成式 AI 系统可能逐渐超出最初确定的边界,例如改变所处理的个人数据、使用目的或保存期限。
应将生成式 AI 使用的定期重新评估固定纳入业务流程。这样,即使本组织使用系统的方式发生变化,GDPR 合规安排仍能与实际使用情况保持一致。
3.4.a 本组织已经制定生成式 AI 系统定期评估政策
- [ ] 符合
- [ ] 不符合
填写说明: 请说明定期评估的具体安排。定期评估的一项重要内容,是查明生成式 AI 系统的使用影响哪些处理活动。可以为此查阅处理活动记录。
3.4.b 该政策已经融入日常经营管理,并成为其中的固定组成部分
- [ ] 符合
- [ ] 不符合
填写说明: 请说明该政策如何融入日常经营管理。政策是否只停留在纸面上,还是已经得到实际执行?
3.4.c 本组织已经指定负责进一步细化、执行和监督该政策的人员
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织指定哪些人员负责进一步细化、执行和监督生成式 AI 系统定期评估政策,并解释为何选择这些人员以及如何作出选择。
3.4.d 本组织已经采取措施,推动形成以持续改进和监督生成式 AI 系统为常态的组织文化
- [ ] 符合
- [ ] 不符合
填写说明: 请说明本组织采取了哪些措施,推动形成以持续改进和监督生成式 AI 系统为常态的组织文化。还应检查工作环境是否允许员工提出问题、作出建设性批评并从错误中学习。
脚注
〔注1〕 参见 GDPR 第 5 条。
〔注2〕 参见 GDPR 第 24 条和第 32 条。
〔注3〕 参见 GDPR 第 25 条。
〔注4〕 欧洲议会和欧盟理事会 2024 年 6 月 13 日通过的《欧洲议会和理事会(欧盟)2024/1689 号条例》,关于制定统一的人工智能规则。
〔注5〕 参见 GDPR 第 38 条第 1 款。
〔注6〕 参见 GDPR 第 5 条第 2 款和第 24 条。
〔注7〕 参见 GDPR 第 35 条。
〔注8〕 参见 GDPR 第 30 条。
〔注9〕 参见 GDPR 第 36 条。
〔注10〕 参见 GDPR 第 30 条。
〔注11〕 其中包括 GDPR 第 24 条。
〔注12〕 例如,与由本组织自行开发和管理的生成式 AI 系统相比,如果生成式 AI 系统向供应商共享个人数据,并由供应商将其用于进一步训练 AI 模型,它对数据主体隐私的影响更大。
〔注13〕 参见 GDPR 第 5 条。
〔注14〕 GDPR 第 5 条第 1 款 b 项。
〔注15〕 GDPR 第 5 条第 1 款 b 项。
〔注16〕 GDPR 第 5 条第 1 款。
〔注17〕 GDPR 第 25 条。
〔注18〕 GDPR 第 25 条第 1 款。
〔注19〕 GDPR 第 25 条第 1 款。
〔注20〕 有关控制者与处理者区别的更多信息,参见 AP 网站:控制者与处理者。
〔注21〕 有关 DPIA 义务的更多信息,参见 AP 网站:数据保护影响评估(DPIA)。
〔注22〕 参见 GDPR 第 36 条。
〔注23〕 有关 AI 素养原则的更多信息,参见 AP 网站:AI 素养。
〔注24〕 GDPR 第 22 条第 2 款规定了该项禁令的例外情形。
〔注25〕 参见 AP 文件:有意义的人类介入实务要点。
---
荷兰个人数据保护局
邮政信箱 93374
2509 AJ 海牙
荷兰个人数据保护局是个人数据领域的独立监管机构,致力于在数字世界中保护人们。
说明:本文件为公众号渲染试稿,建议在浏览器中打开后复制渲染结果,再粘贴到公众号编辑器。