CNIL发布首批关于将GDPR适用于人工智能系统开发的建议，旨在帮助从业者兼顾创新与尊重个人权利。
人工智能系统的设计者与开发者常向CNIL反映，GDPR在模型训练等环节执行困难。
“GDPR阻碍欧洲人工智能创新”是误解。必须认识到，训练数据集可能包含“个人数据”，即真实个人的信息。使用这些数据会给个人带来风险，必须在尊重其权利与自由，特别是隐私权的前提下开发人工智能系统。
除本摘要外，CNIL另行提供《核查清单》供相关从业者查看（本公众号此前完整翻译过，在2024年发布了八个指南（本公众号均进行了全文翻译，一键直达），在今年巴黎AI行动峰会上发布了两个指南（本公众号全文翻译，一键直达）、合法利益更新版本一键直达，最后三个指南待更新，请关注本公众号）
适用范围
适用的人工智能系统
本建议适用于开发过程中涉及个人数据处理的人工智能系统（法律框架详，见核查清单1，本公众译文直达）。系统训练通常需要大规模使用自然人信息，即“个人数据”。
适用对象包括：
基于机器学习（machine learning）的系统；
开发阶段已确定用途的系统，以及可支撑多种应用的通用目的人工智能（general purpose AI）；
一次性训练或持续学习的系统，例如通过使用数据持续改进。
适用阶段
本建议仅聚焦开发阶段，不包括部署阶段。开发阶段指系统上线前的全部准备步骤：系统设计、数据集构建和模型训练。
与欧盟人工智能法的关系
本建议已纳入2024年夏季通过的欧盟人工智能法（RIA）。当开发系统使用个人数据时，GDPR与AI法同时适用，CNIL据此在数据保护层面提供补充指引。
第1步：为人工智能系统设定明确目的
原则
利用个人数据开发人工智能系统必须设定“目的”（finalité），即清晰、具体且合法的目标，以限定可使用的训练数据范围，避免存储和处理不必要的数据。
该目标必须在项目定义阶段确定或设定。它还必须明确，即为已知且易于理解。最后，它必须合法，即与机构的职责相符。
有时有人认为，确定处理目的的要求与人工智能的训练不兼容，因为人工智能可能会发展出未预见的特征。CNIL 认为情况并非如此，确定处理目的的要求应根据人工智能的具体情境进行调整，但绝不能因此而消失，以下示例即证明了这一点。
实践
三种典型场景：
1. 已知明确操作用途
在这种情况下，目的在开发与部署阶段保持一致。
示例：某机构建立了一个由正在运行的列车车厢照片组成的数据库，即照片中有人，以训练一个算法用于测量车站站台上列车的客流量和乘客数量。开发阶段的目的根据已确定的用途是明确、合法且具体的。
然而，当您开发通用人工智能系统 ，该系统可在不同环境和应用中使用，或当您的系统是为科学研究目的开发时，情况则更为复杂。
2. 通用目的人工智能
示例：某机构可能会建立一个用于训练图像分类模型（人物、车辆、食物等）的数据库，并将其公开访问，而在模型开发过程中并未预设任何具体的操作用途。
您不能将目的定义得过于笼统，例如“人工智能系统的开发与改进”。您需要更具体，并且应当指明：
所开发系统的“类型”，例如语言模型的开发大型计算机视觉系统，或生成图像、视频、声音、计算机代码等的生成式人工智能系统；
技术上可实现的功能和能力。
良好实践：
您可以进一步明确所追求的目标，例如通过确定：
最具可预见风险的能力；
设计上排除的功能；
人工智能系统的使用条件：已知的解决方案使用案例以及使用方式（模型的开源发布、商业化、以 SaaS 形式提供）或通过 API 等方式。
3. 针对为科学研究目的开发的人工智能系统
示例：开发一个用于概念验证的人工智能系统，以证明机器学习的稳健性，可以被视为出于科学研究目的需要较少训练数据的科学方法，并计划将其作为出版物进行记录。
鉴于在工作初期难以精确定义目标，您可以设定一个较为宽泛的目标。随着项目的推进，您可以提供补充信息以进一步明确该目标。
第2步：明确您的法律角色
原则
若您在人工智能系统开发过程中使用个人数据，则必须依据 GDPR 界定自身角色。您可能是：
数据控制者（Controller）：您决定处理目的与手段，即决定“为何”以及“如何”使用个人数据。若与其他机构共同决定上述要素，则构成共同控制者，并需通过合同等方式划分各自义务。
数据处理者（Processor）：您代表数据控制者处理数据。此时，控制者须确保您遵守 GDPR，且您只能按其指示处理数据；法律要求双方签订数据处理协议。
实践
欧盟《人工智能法》还定义了以下角色：
AI 系统提供者（Provider）：开发或委托开发 AI 系统，并以自身名义或品牌将其投放市场或投入使用的自然人或法人，无论是有偿还是无偿；
进口商、分销商及用户/部署者（Deployers）。
具体责任需个案分析。例如：
若您作为 AI 系统提供者主动开发系统，并为自身目的自行筛选并构建训练数据集，则您通常被视为数据控制者。
若您与其他控制者共同构建训练数据集，并为共同确定的目的处理数据，则可能成为共同控制者。
若您作为 AI 系统提供者为客户开发系统，则： – 若客户决定处理目的及全部技术手段，您为客户的数据处理者； – 若客户仅给出目标，而您独立设计技术方案，则您为数据控制者。
您作为 AI 系统提供者，可委托第三方按您的具体指令收集并处理数据；该第三方即为您委任的数据处理者。例如，服务提供商需要为人工智能系统供应商建立一个训练数据库，而供应商明确指示其如何构建数据库的情况。
后续指引：
若您为数据控制者，后续所有步骤均直接适用于您，您须确保全面履行相关义务。
若您为数据处理者，则主要义务包括：
确认已签订符合法规的数据处理协议；
严格遵守数据控制者的指示，不得将个人数据用于其他目的；
严格落实所处理数据的安全措施；
自行评估 GDPR 合规情况，并在发现问题时及时通知数据控制者。
第3步：确立处理个人数据的“法律依据”
原则
开发含个人数据的AI系统必须有GDPR所列6项法律依据之一：同意、合同履行、法定义务、重大利益、公共利益任务、合法利益。
依据不同，义务与数据主体权利亦不同。
实践
确定适当的法律依据
您需要考虑最适合您情况的法律依据。
如果您直接从个人处收集数据，且他们可以自由接受或拒绝而不受损害（例如放弃服务），则同意通常是最合适的法律依据。根据法律，同意必须是自由的、具体的、知情的且明确的。
然而，在实际操作中，获取同意往往是不可能的。例如，当您收集在线可访问的数据或重新使用开放数据库（开源）时，且与相关人员没有直接接触，通常其他法律依据会更适用：
私营部门
应分析其是否符合基于合法利益的条件。为此，他们必须证明满足以下三个条件：
追求的利益是合法的 ，即合法、明确且真实；
必须能够证明个人数据确实是系统训练所必需的，因为不可能仅使用与自然人无关的数据或匿名数据；
使用这些个人数据不得对个人隐私造成“过度侵害”。这需要根据具体情况评估，取决于所使用数据所揭示的信息，这些信息可能具有不同程度的私密性或敏感性，以及数据的使用方式；
公共部门
应核实该处理是否属于其依据法律文本（例如法律、法令等）规定的公共利益任务范围内，并且是否以相关且适当的方式促进该任务。
例如，数字监管专业中心（PEReN）基于此依据被授权二次使用公开可获取的数据，以进行实验，特别是旨在设计用于监管在线平台运营商的技术工具。
合同和法定义务的法律依据可以在更为例外的情况下使用 ，如果您能够证明您的处理是为履行合同或合同前措施，或为履行您所承担的（足够具体的）法定义务所必需。
使用合法利益
合法利益是开发人工智能系统最常用的法律依据之一，尤其是私营机构。利益指的是数据控制者或第三方从人工智能系统开发中获得的收益.
使用合法利益作为依据需满足三个条件：
1. 追求的利益必须是合法的
所追求的利益必须符合法律规定（包括除 GDPR 外的其他法规，如 AI法），且需以足够清晰和明确的方式确定。该利益必须与您的职责和活动相关。
以下利益原则上被视为合法 ：进行科学研究工作、促进公众获取某些信息、提供用户辅助的对话代理服务、开发用于检测欺诈内容和行为的人工智能系统等。
商业利益构成合法利益，前提是不违反法律且处理是必要且相称的。
2. 处理必须是必要的
所追求的利益不能通过对隐私侵扰较小的方式实现，且系统开发确实是实现既定目标所必需的。因此，处理的必要性应结合最小化原则进行审查（参见“第五步：最小化个人数据”）。
3. 数据的使用并未对个人隐私造成“过度侵犯”
数据控制者必须权衡其视角下预期的处理收益与对相关个人的影响。如有必要，应采取保障措施以限制这些风险，保护个人的权利和自由。
应考虑的个人合理预期
数据的使用不应令个人感到意外。在您希望依赖合法利益作为处理数据的法律依据时，需考虑多个因素：
对于从个人处收集的数据 ：您与个人之间的关系、情境、服务性质、隐私设置，以及数据处理是否仅限于向个人提供的服务或用于整体服务的改进；
关于互联网上发布数据的再利用 ：数据的公开可访问性、来源网站的背景和性质（社交网络、在线论坛、数据集发布网站等）、发布类型以及相关人员与机构之间的关系。如果您未排除对设置了限制的网站（使用条款、robots.txt 文件、验证码）的收集，处理将无法符合相关人员的合理预期。
注意 ：个人可能意识到他们在线发布的某些数据可能会被第三方查看、收集和再利用。然而，他们不能在所有情况下以及针对所有可在线访问的关于他们的数据类型都抱有这种预期。
限制处理影响的保障措施
保障措施可以限制个人数据的收集或保存，确保个人对其数据的控制，限制使用阶段的风险等。它们必须根据开发阶段的风险进行调整。因此，您需要确定在您的情况下最相关的保障措施。例如，可以包括：
计划在短时间内对收集的数据进行匿名化，或者在无法匿名化时进行假名化；
采取措施以限制记忆风险，减少对人工智能模型的提取或复述的可能性
实施事先的自由反对权；
规定对训练数据库中数据的自由删除权；
采取措施以便在个人行使其权利时能够识别其身份；
便于通知权利并广泛传播数据库或模型的更新等信息。
第3步补充：针对数据抓取的保障措施
原则
数据采集（或称网页抓取）本身并不违反《通用数据保护条例》（GDPR）。如果您是私人机构，可以基于合法依据进行此类操作。在实施适当保障措施的前提下，基于合法利益。
实践
遵守最小化原则
为此，您必须：
提前明确您的需求 ：在开始收集之前，必须清楚决定哪些类别的数据是有用的。
不得收集超出必要范围的数据：必须排除某些类别数据的收集，通过过滤或排除某些类型的网站，特别是敏感数据 ，如果其收集与所进行的处理无关。
删除无用数据：如果错误地收集了不相关的数据，必须立即删除。
尊重拒绝自动收集的网站：不得从通过技术保护措施（如验证码或 robots.txt 文件）反对内容抓取的网站收集数据。
尊重合理预期
您必须考虑数据的公开可访问性、来源网站的性质（社交网络、在线论坛等）、发布类型（例如在自由访问的博客上发布的文章或受限发布的内容）等因素。
此外，当网站通过技术手段（如验证码或 robots.txt 文件）反对其内容被抓取时，抓取行为不符合个人的合理预期。
额外保障措施
您可以根据人工智能系统的预期用途实施额外措施根据处理所带来的风险，可能需要实施一项或多项这些措施：
建立默认排除名单，排除包含特别敏感数据的网站（如健康论坛等）；
排除通过技术或法律手段（例如使用条款）反对其内容被抓取的网站；
限制收集仅限于公开可自由访问的数据（无需创建账户），且数据主体已意识到其公开性质；
尽可能广泛地告知数据主体（在线文章、社交媒体账户等）；
设定反对权应为自由裁量且事先行使，在收集前实施，并在模型训练前给予合理期限；
在数据收集后立即对数据进行匿名化或假名化，并防止通过个人标识符进行任何数据交叉比对。
第4步：核查可否复用已有个人数据
原则
如果您打算重新使用个人数据库，必须确保其合法性。这取决于数据的收集方式和数据来源。作为数据控制者，您需要：
实践
规则将根据具体情况而定。
供应商重新使用其自己已收集的数据
您可能希望将最初收集的数据用于其他目的。在这种情况下，如果您未预先告知相关人员并获得其同意，您必须确认该新用途与最初目的兼容 ，除非您已获得相关人员的授权（他们已同意）或法律文本的授权（例如法律、法令等）。
您需要进行“兼容性测试”，该测试应考虑：
最初目的与为训练人工智能系统而建立数据库的目的之间是否存在关联 ;
收集个人数据的具体情境；
数据的类型和性质；
对相关人员可能产生的后果；
适当保障措施的存在（例如，数据的假名化）。
注意： 如果您希望将数据重新用于统计生产或科学研究目的，则该处理被视为与最初目的兼容。 因此，在这种情况下无需进行兼容性测试。
供应商再次使用公开可获取的数据（开源）
在这种情况下，您必须确保不会再次使用明显非法构建的数据库（例如，来源于数据泄露）。 必须进行逐案分析。
CNIL 建议再次使用者核实并记录（例如，在数据保护影响评估中）以下内容：
数据集说明中已明确其来源；
数据集的建立或发布并非明显源自犯罪或违法行为，也未因主管机关的判决或处罚而被要求删除或禁止继续使用；
不存在明显迹象表明数据集本身不合法，尤其是应确保数据收集条件已得到充分记录；
数据集不含敏感个人数据（如健康数据、政治观点）或犯罪记录；若含有此类数据，则应进行额外核查，以确保处理行为合法。
发布数据库的机构应确保该发布符合《通用数据保护条例》（GDPR），并对此负责。相反，您无需核实构建和传播数据库的机构是否遵守了GDPR规定的所有义务：CNIL 认为，上述四项核查通常足以允许将该数据库用于人工智能系统的训练，前提是遵守 CNIL 的其他建议。如果您收到的信息，特别是来自数据库中数据主体的反馈，揭示所用数据库的合法性存在问题，您则需进一步调查。
供应商再次使用从第三方（数据经纪人等）获得的数据
对于分享个人数据的第三方，有时会获得报酬，存在两种情况。
一种情况是第三方为了构建用于人工智能系统训练的数据库而收集数据。其必须确保数据传输处理符合GDPR的要求（明确且合法的目的定义、合法依据的要求、告知数据主体并管理其权利行使等）。
另一种情况是第三方最初并非为该目的收集数据。 此时，必须确保数据传输的目的与收集数据时所依据的目的兼容。 因此，需进行上述所述的“兼容性测试”。
数据再次利用者则有多项义务：
他必须确保自己没有在重复使用明显非法的数据库，需进行与上述部分所述相同的核查。建议数据初始持有者与再次利用者之间签订协议，以便于进行这些核查。
除了这些核查外，他还必须确保自己在处理这些数据时符合GDPR。
第5步：最小化使用的个人数据
原则
收集和使用的个人数据必须适当、相关且限于实现既定目标所必需的范围内 ：这就是数据最小化原则 。当处理敏感数据（涉及健康、性生活、宗教或政治观点等数据）时，您必须严格遵守并应用该原则。
实践
应采用的方法
您应优先选择能够以使用尽可能少的个人数据达到预期结果（或同等效果）的技术。特别是，深度学习的使用不应成为常规做法。
所选用的训练协议可以采取例如限制数据访问仅限授权人员，或仅允许访问加密数据。
严格必要数据的选择
最小化原则并不禁止训练算法涉及大量数据，但意味着：
事先进行思考，仅使用对系统开发有用的个人数据；并
随后实施技术手段，仅收集这些数据。
设计选择的有效性
为了验证设计选择，建议作为良好实践：
进行试点研究 ，即进行小规模实验。为此可以使用虚构的、合成的、匿名化的数据；
咨询伦理委员会（或“伦理负责人”）。该委员会必须确保伦理问题以及个人权利和自由保护问题得到充分考虑。它可以对组织的全部或部分项目、工具、产品等可能涉及伦理问题的事项提出意见。
数据收集的组织
您必须确保所收集的数据与所追求的目标相关。强烈建议采取以下几个步骤：
数据清洗 ：此步骤使您能够构建高质量的训练基础，从而通过减少不一致性来增强数据的完整性和相关性，并降低训练成本。
相关数据识别：此步骤旨在优化系统性能，同时避免欠拟合和过拟合。实际上，它使您能够确保某些对目标任务无用的类别或分类未被包含，不同关注类别之间的比例保持平衡等。该程序还旨在识别对训练无关的数据（这些数据应从数据库中删除）。
实施
从设计阶段即纳入个人数据保护原则的措施 ：此步骤使您能够对数据进行转换（如泛化和/或随机化措施、数据匿名化等），以限制对个人的影响。
数据的跟踪与更新：最小化措施可能随着时间推移而失效。实际上，所收集的数据可能因数据的潜在偏移而失去其准确性、相关性、适当性和有限性。更新这些内容或技术的发展。因此，您需要定期进行分析，以确保所建立数据库的持续监控。
用于开发人工智能系统的数据文档 ：这使您能够确保所使用数据集的可追溯性，而数据集的大规模可能会使这一点变得困难。您必须根据数据库的变更及时更新该文档。CNIL 提供了一份文档模板。
第6步：设定数据保留期限
原则
个人数据不能被无限期保存。根据GDPR，您必须确定一个期限，届时数据应被删除，或在某些情况下进行归档。 您应根据处理这些数据的目的确定保存期限 。
实践
您必须为用于人工智能系统开发的数据设定保存期限。 :
在开发阶段 ：数据保存应事先规划并随时间进行跟踪。相关人员应被告知数据的保存期限（例如在信息说明中）。
用于产品维护或改进 ：当数据不再需要供负责人工智能系统开发的人员日常使用时，原则上应予以删除。但如果实施了保障措施（如隔离支持、仅限授权人员访问等），数据可以保留用于产品维护或改进。
注意 ：保留训练数据可以进行审计并有助于衡量某些偏差。在这些情况下，延长数据保留期限是合理的，除非保留关于数据的一般信息已足够（例如，在文档部分中对所提模型的文档，或关于数据统计分布的信息）。此类保留应限于必要数据，并配合加强的安全措施。
第7步：信息告知
原则
您必须告知相关人员，使其了解其数据将被如何使用（为何、如何、以何种方式），并能够行使其权利（反对权、访问权、更正权等）。
信息义务适用于直接从相关人员处收集的数据（在提供服务、与自愿参与者签订合同等情况下）或间接收集的数据，特别是通过网络爬取（web scraping）方式。
实践
确保信息的可及性
您必须确保信息易于获取 ：
可在收集数据的表单、预录语音消息等渠道提供“一对一”告知；
同时把“面向公众”的整体信息以隐私声明形式发布在官网。
建议在告知个人数据收集与模型训练之间保持一个合理的时间间隔 ，因为一旦模型训练完成，个人行使其权利将变得困难。
确保信息的可理解性
您必须确保信息简明清晰。人工智能系统的复杂性不应妨碍相关人员对信息的正确理解。
建议通过图示等方式详细说明数据在训练过程中的使用方式、所开发的人工智能系统的运行机制，以及应区分的训练数据库、人工智能模型和模型输出。
注意 ：信息可以出现在数据卡、模型卡或系统卡（AI 数据集 、 模型和系统卡 ）中，但必须在这些文档中清晰体现。
在一对一告知与面向公众告知之间进行选择
信息原则上进行一对一告知，但GDPR规定了例外情况 ：
关于处理的全部信息已向相关人员提供（例如，由第三方提供）。
该信息要求付出不成比例的努力 ，需考虑所需付出的努力（缺乏联系方式、数据陈旧等）以及对隐私权的侵害程度。特别是在通过网络爬取（web scraping）收集假名化数据时，个别通知通常是不成比例的，因为找到联系人的方式可能需要收集更多或更具识别性的额外数据。
在后一种情况下，您可以仅在您的网站上发布一份完整的面向公众通知 。
注意 ：AI法第53 条规定，通用目的人工智能模型的供应者必须根据人工智能办公室提供的模板，完成一份用于训练人工智能系统内容的公开摘要。该摘要可作为数据来源的通用信息。
需披露的具体信息
您通常需要提供GDPR第13条和第14条规定的全部信息。对于人工智能系统的开发，需要考虑一些特殊情况。
有关数据来源的信息
关于信息来源存在特殊困难。需区分两种情况：
如果您处理的来源数量有限 ：原则上，应逐一列出具体来源。这尤其适用于对有限数量的网站进行抓取。
如果您使用了众多来源 ，您可以仅限于指出来源类别，特别是一些主要或典型来源的名称。这适用于从大量来源进行采集的情况。
注意：如果受 GDPR 约束的数据集或人工智能模型被重复使用，CNIL 建议提供联系方式，以便联系数据控制者从其处获取数据，尤其是当数据集或模型对相关人员构成重大风险时。
告知个人无法识别其身份
在这种情况下，您必须告知个人无法识别其身份，包括无法响应其权利行使请求 （GDPR 第11 条）。CNIL 建议，如有可能，应向希望行使权利的个人提供可能有助于其身份识别的补充信息。
受 GDPR 约束的人工智能模型的特殊情况
当您的人工智能模型或系统受 GDPR 约束时，CNIL 建议明确说明通过仅操作人工智能模型从训练数据集中提取个人数据的风险性质 ，采取的限制这些风险的措施以及如果这些风险发生时的救济机制。
第8步：保障数据主体权利
原则
个人应能够行使其权利（访问权、更正权、删除权、限制处理权、数据可携带权），针对训练数据库及人工智能模型本身，前提是该模型不被视为匿名。
您必须实施的解决方案应切实可行且相称。人工智能系统固有的困难（如在大型数据库中识别自然人，尤其是在模型中识别等）并不妨碍找到适当的应对措施。
CNIL 建议：在向数据主体反馈处理结果时，应明确告知其请求的后续步骤，尤其是在对数据集的修改无法立即体现在已训练模型中的情况下。
实践
识别相关人员的困难
如果您能够证明在训练数据库或模型中无法识别相关人员 ，则在回应权利行使请求时应予以说明。您无需仅为能够回应权利行使而收集额外的个人数据。
当 GDPR 适用于该模型时 ，可区分两种情况：
在某些情况下，模型中存在个人数据是显而易见的（某些人工智能模型设计用于输出个人数据）；
在其他情况下，您可以证明无法识别模型中的个人。目前的技术水平通常不允许识别模型中存储的某个人的所有个人数据。
然而，个人可以提供额外的个人数据 ，以帮助在数据库或模型中找到他们（例如，一张图片或一个化名）。CNIL 建议提前预见这些困难，并告知个人可能帮助他们搜索的额外信息。
特别是关于模型：
如果您仍然拥有训练集，识别其中的个人对于验证模型是否可能存储了相关数据是有意义的；
如果没有，所使用的数据类型可以帮助您预见可能被存储的类别，并便于尝试识别该个人。在生成式人工智能模型的情况下，可以建立
模型内部查询程序 。
关于访问权
在训练数据库的情况下访问权允许任何人免费获得其相关的所有处理数据的副本。此类信息披露不得侵犯他人的权利和自由（其他相关人员的权利、知识产权、数据库持有人的商业秘密等）。
当个人行使其访问权时，您必须提供GDPR要求的所有信息 。相关人员尤其应：
能够识别其数据的具体接收者 ；
了解数据的来源 ，当数据不是直接从他们本人收集时（例如：数据经纪人）。
当数据不是直接从相关人员处收集时 （例如，通过数据经纪人传输）， 访问权允许获取关于其来源的所有“可用”信息。
在受《通用数据保护条例》（RGPD）约束的人工智能模型情况下
可能出现两种情况：
如果您识别出相关人员并发现其数据已被模型存储，您必须向该人员确认。您应将调查结果传达给相关人员，包括对于生成式人工智能系统，包含其个人数据的输出内容。
如果您无法验证记忆的存在，CNIL 建议您告知相关人员，模型中可能已记忆了涉及其的训练数据。在这种情况下，应提供
额外信息：模型的接收者、保存期限或确定保存期限的标准、可对模型行使的权利以及如果您不是设计者，则模型的来源。
更正权、删除权和反对权
在某些条件下，个人有权更正其数据、要求删除其数据，并基于自身理由反对其数据的处理，无论是在训练数据库中还是在模型中。
对人工智能模型行使权利并非绝对。所采取的以下措施的比例应根据数据的敏感性及其泄露所带来的风险而定。或披露将对个人造成影响，并损害机构的经营自由。
默认情况下，行使模型权利需要对其进行重新训练 ，前提是您仍然拥有训练数据。重新训练可以定期进行，以同时处理多项权利行使请求，且根据请求的复杂性和数量，完成时间最长可达三个月 。相关人员应被告知预计的时间期限。必须向模型用户提供更新版本，并通过合同方式要求其仅使用定期更新的版本。
如果您证明重新训练不成比例，建议实施其他类型的措施，如对人工智能系统应用的过滤器 ，将模型封装起来，前提是您证明这些措施足够有效且稳健。
建议在可能的情况下，采用通用规则来检测和假名化相关的个人数据，而不是使用黑名单。
注意 ：仍建议对训练数据进行匿名化，或确保其人工智能模型是匿名的。
最后，GDPR 规定，数据控制者应向每个接收个人数据的接收方通知任何数据的更正或删除，除非此类通知不可能或需要不成比例的努力。使用 API 或下载追踪措施可以促进此类通知。您可以通过例如再利用许可，规定再利用者承担传播权利行使效果的合同义务。
权利行使请求的例外情况
当请求明显无理或过度，法国或欧洲法律排除行使一项或多项权利，或处理是出于统计、科学研究或历史研究目的时，您可以豁免行使这些权利。
第9步：保障人工智能系统安全
原则
GDPR要求数据控制者实施安全措施：包括基础设施的规划和规模调整、权限管理、备份管理以及物理安全等方面。
人工智能系统必须进行风险分析，特别关注其软件开发、训练数据库的构建与管理以及维护。
法国国家信息与自由委员会（CNIL）建议进行数据保护影响评估（DPIA），以记录安全措施（参见“进行数据保护影响评估”）。
安全措施示例
| 确保训练数据的机密性和完整性 | 在整个生命周期内，核实训练数据及其注释来源的可靠性、质量和完整性记录日志并管理数据集的版本尽可能使用虚拟或合成数据（用于安全测试、集成、某些审计等）对备份和通信进行加密在数据未公开发布时，控制对数据的访问对数据进行匿名化或假名化对敏感数据集进行隔离通过组织措施防止对数据的控制丧失 |
| 确保人工智能系统的性能和完整性 | 在系统设计选择中考虑数据保护，努力实现数据最小化（参见“数据最小化”部分）使用开发工具、库、预训练模型经过验证。特别注意系统中是否存在后门（backdoors）优先使用经过验证的导入和保存格式（例如 safetensors）使用受控、可复现且易于部署的开发环境实施持续开发和集成程序记录系统设计及其运行方式、所需硬件设备、已实施的保护措施等通过内部或第三方进行安全审计，特别是对人工智能系统实施常见攻击（参见“人工智能系统状态”） |
| 预见系统的运行方式 | 向用户告知系统在实验室及预期使用环境中的局限性安排提供信息，使用户能够解读结果预设系统停止的可能性通过过滤器控制人工智能的输出，采用强化学习基于人类反馈的强化学习（RLHF），或通过数字水印（ watermarking ）技术 |
信息系统的一般安全措施
人工智能系统的功能通常在很大程度上依赖于所使用的模型，但目前最可能的风险集中在系统的其他组件上（如备份、接口和通信）。因此，攻击者利用软件漏洞访问训练数据可能比进行成员推断攻击更为容易。
因此，您必须确保信息系统安全措施的正确实施。这些措施及其应对的风险在 CNIL 关于个人数据安全的指南中有详细描述 。
第10步：分析AI模型受GDPR约束的状态
原则
人工智能模型是对用于训练其基础数据特征的统计表示。大量学术研究已证明，在某些情况下，这种表示足够精细，可能导致训练数据的泄露。正如 EDPB 第28/2024 号意见中所述，基于个人数据训练的人工智能模型大多数情况下应被视为受GDPR约束。
为了确定您的模型是否受GDPR约束（即是否可被视为匿名），您需要对其状态进行分析。该分析旨在利用合理可能使用的手段 （尤其是重新识别攻击测试）提取个人数据。
实践
确定GDPR是否适用于某个模型应遵循哪些步骤？
下图明确了确定GDPR是否适用于您的模型，或该模型是否可被视为匿名的流程。
何时对模型进行重新识别攻击测试？
一系列指标可以帮助您确定是否有必要对您的模型进行训练数据的重新识别攻击：
关于训练数据：
如果数据具有识别性和精确性，数据集中的数据是异质的、稀缺的或重复的；
关于模型架构：如果参数数量与训练数据量之间存在较高比例，存在过拟合风险，或在训练过程中缺乏隐私保障（如差分隐私等）；
关于模型的功能和用途：
如果目标是生成与训练数据相似的数据（例如，在生成式人工智能中生成内容），或者类似模型已成功遭受重新识别攻击。
确定某一系统是否适用GDPR应遵循哪些步骤？
如果对您的模型状态的分析得出该模型不能被视为匿名，您可以通过将其封装在一个人工智能系统中来降低重新识别个人的可能性实施强有力的措施以防止其被提取。
在某些情况下，这些措施必须通过对系统进行系统性攻击测试来验证，可能使系统的使用不再适用GDPR。这些措施可以包括（但不一定充分）：
使模型的访问或检索变得不可能，实施系统访问限制，限制模型的精确度或过滤模型输出，安全措施（见“人工智能系统安全”部分）。
下图明确了您需要实施的确定步骤：
第11 步：在标注阶段遵守《通用数据保护条例》（GDPR）原则
原则
标注是指为每条数据分配一个描述，称为“标签”，作为模型训练处理、分类或根据这些信息区分数据的“真实情况”（ground truth）。
实践
实施数据最小化原则
您的数据标注应仅限于模型训练和预期功能所必需且相关的内容。它可以涉及与人工智能系统功能间接相关的数据如果对性能的影响已被证明（通过经验或理论）或足够合理。标注还可以包括有助于性能测量、错误纠正或偏差评估的上下文信息（天气、日期、时间等）。
该原则适用于来自先前收集、购买、开放数据库下载或第三方提供的注释。如果技术上不可行，您必须能够证明您已尽力使用最相关的注释数据集，并删除不相关的注释。
注释也应仅限于模型训练所必需的内容。因此，“最小化我使用的个人数据”部分的建议同样适用。
确保准确性原则
您进行的注释必须准确、客观，并尽可能保持最新。否则，系统可能会复制这些注释，导致输出结果不准确、贬损或歧视。
基于敏感数据的标注
“敏感”标注指包含GDPR第9 条所定义的敏感数据的标注，即使其所参考的训练数据本身并非敏感数据。根据同一条款，原则上禁止进行“敏感”标注。
然而，您可以利用例外情况，例如在医疗数据收集过程中开展健康研究项目，通过遵守参考方法论的合规承诺（《信息与自由法》第66 条）或获得 CNIL 授权。在此情况下，您必须采取特殊措施：
根据客观且事实性的标准进行标注（例如，皮肤颜色指像素颜色而非族裔来源），仅限于数据中包含的信息，不进行解释，增强标注数据的安全性，并评估再现风险。
注意 ：应尽可能避免使用敏感数据，如有可能，应以合成数据替代。
告知个人
除了“告知个人”部分提及的强制性信息外，CNIL 建议作为良好实践传达以下内容：
标注的目的（例如，识别图像中的人物）；
若标注工作由第三方执行，则注明该机构名称，以及在与数据控制者签订的合同中，针对可能令人不适的数据所遵循的社会责任准则；
注释阶段采取的安全措施。
如果注释可能在数据泄露时对个人产生影响，或其数据在训练数据库中占有重要比例，CNIL 建议在可能的情况下事后通知相关人员注释结果。
关于注释权利的行使，详见“确保权利行使”部分。
重点：进行数据保护影响评估（DPIA）
原则
数据保护影响评估是一种方法，帮助您绘制和评估处理个人数据对数据保护的风险，并制定行动计划，将风险降低到可接受的水平。它尤其会促使您确定保护数据的安全措施。
实践
为人工智能系统开发进行DPIA
强烈建议在开发您的人工智能系统时进行DPIA，特别是在满足以下两个标准时：
收集敏感数据；
大规模收集个人数据；
收集弱势群体（未成年人、残障人士等）的数据；
数据集被交叉或合并；
当实施新的技术解决方案或进行创新性使用时。
此外，如果存在重大风险（例如：数据误用、数据泄露或歧视），即使未满足前述两个标准，也必须进行数据保护影响评估。
为协助进行DPIA，CNIL 提供了专用的开源软件 PIA。
欧盟人工智能法中引入的风险标准
CNIL 认为，对于欧盟人工智能法所指的涉及个人数据的高风险系统开发，原则上需要进行数据保护影响评估。
注意：数据保护影响评估的实施可以基于人工智能法要求的文档，但前提是该文档包含GDPR第35 条规定的内容。
数据保护影响评估的范围
根据人工智能系统的目标，人工智能系统提供者面临两种情况（参见“为人工智能系统定义目标（目的）”）。
您清楚地知道您的人工智能系统的实际使用目的
建议对整个生命周期进行一项全面的数据保护影响评估，包括开发和部署阶段。请注意，如果您不是人工智能系统的使用者/部署者，部署阶段的数据保护影响评估责任将由使用者/部署者承担（尽管他们可以基于您提供的DPIA模型进行）。
如果您开发的是通用目的人工智能系统
您只能在开发阶段进行数据保护影响评估，该DPIA必须提供给您的人工智能用户，以便他们进行自己的分析。
在数据保护影响评估中需考虑的与人工智能相关的风险
基于人工智能系统的个人数据处理存在特定风险，您必须加以考虑：
与可能从人工智能系统中提取的数据隐私相关的风险；
与训练数据库中数据被滥用相关的风险（包括有权访问的员工滥用或数据泄露情况下的风险）；
由开发过程中引入的人工智能系统偏见导致的自动歧视风险；
生成式人工智能系统可能产生关于真实人物的虚假错误内容的风险；
当使用该系统的代理无法在实际条件下验证其性能，或无法在不受不利影响（例如因层级压力）的情况下做出与系统输出相反的决策时，存在自动化决策的风险；
用户对其在线可访问数据失去控制的风险；
与人工智能系统特有的已知攻击相关的风险（例如，数据投毒攻击）；
与系统部署相关的系统性和严重伦理风险。
根据DPIA结果应采取的措施
一旦确定风险等级，您的DPIA应包括一系列旨在降低风险并将其维持在可接受水平的措施，例如：
安全措施（例如， 同态加密或使用安全执行环境）；
最小化措施（例如使用合成数据）；
匿名化或假名化措施（例如差分隐私）；
从开发阶段起采取数据保护措施（例如联邦学习）) ;
便于个人行使权利或寻求救济的措施（例如机器去学习技术、人工智能系统输出的可解释性和可追溯性措施等）；
审计和验证措施（例如模拟攻击）。
还可以采取其他更通用的措施：组织措施（对训练数据库的访问进行管理和限制，防止对人工智能系统进行修改等）、治理措施（设立伦理委员会等）、操作追踪或内部文档措施（信息章程等）。