发布背景与 SDM 方法论
2025 年 6 月 17 日，德国「联邦及各州独立数据保护监督机构会议」（Datenschutzkonferenz，简称 DSK）在柏林发布《开发和运营 AI 系统应采取的技术和组织措施指南（Version 1.0）》。该文件与同日通过的“自由与安全”决议一并公布，明确将欧盟《AI 法案》和《通用数据保护条例》中的核心原则向落地措施转化，力求在 AI 生命周期最早阶段就嵌入隐私保护要求。(datenschutzkonferenz-online.de)
这份指南之所以受到业界高度关注，关键在于它系统融入了德国数据保护监管长期积累的 Standard-Datenschutzmodell（SDM）。SDM 通过七大“保护目标”（如数据最小化、完整性、透明性、干预性等）把抽象的GDPR义务映射为可审计的技术与组织措施，是德国监管机构、公共部门乃至大型企业进行数据保护影响评估和系统审计的“通用底座”。在本指引第 1.4 节，DSK 将 SDM 明确定位为“把法律要求转化为具体 TOMs（技术与组织措施）的桥梁”，并特别指出 SDM 对欧盟人工智能法所述“合规性测试、数据治理与风险管理体系”具有天然兼容性。(bfdi.bund.de)
指引全文 28 页，围绕 设计（Design）—开发（Entwicklung）—部署（Einführung）—运营与监控（Betrieb & Monitoring） 四大生命周期，对每一阶段列举了与 SDM 七大保护目标逐一对应的控制要求，并附带实施示例。这是全球范围内第一个将Privacy by Design应用到AI生命周期的指南！
上音频介绍！
与其他国家指南的差异化价值
欧洲多国监管机构近两年密集发布 AI 合规指南，但德国版本的独特之处恰在 SDM-first 与 Privacy by Design-as-Code 的方法论。以法国 CNIL 为例，其 2025 年 2 月发布AI系列的指南同样强调数据最小化与知情权，但更偏重解释原则灵活适用；而 DSK 指南直接给出“原则—保障目标—措施”的映射挂关系，可被开发团队写入 CI/CD 流水线，形成可自动化验证的控制点。(cnil.fr)
此外，DSK 指南把 BSI IT-Grundschutz 的安全框架与 SDM 绑定，使隐私与信息安全要求在同一矩阵内实现“互操作”。这与英国 ICO 的“AI 风险工具包”或西班牙 AEPD 的“AI 沙盒”单独列出“安全控制”不同，体现了德国在合规工程学（Compliance Engineering）方面的系统思维。
附：全文翻译
人工智能系统的开发和运营中的技术和组织措施指南
版本 1.0
发布日期：2025 年 6 月
1. 数据保护法对人工智能系统的要求
在人工智能（AI）领域，通常会处理大量数据，包括个人数据。由于处理个人数据的范围以及潜在的高风险，数据保护对人工智能系统具有特别重要的意义。因此，数据保护应从一开始就应将“数据保护设计原则（Data protection by design）”纳入人工智能系统的开发和运营中。
本文件主要面向人工智能系统的制造商和开发人员，旨在为他们开发符合数据保护要求、可投入使用的 AI 系统提供指导。使用 AI 系统的负责人可以参考数据保护会议发布的指南《人工智能与数据保护》以及本文档，以考虑技术开发的可能性。
1.1 定义
在本文件中，“人工智能系统”是指一种机器辅助系统，它被设计为具有不同程度的自主运行能力，能够在投入运行后进行调整，并且可以根据输入数据推导出明确或隐含的目标，例如生成预测、内容、建议或决策，这些输出可能会影响物理或虚拟环境（参见欧盟人工智能法第 3 条第 1 款）。人工智能系统基于一个或多个 AI 模型。
在本文件中讨论的人工智能系统涵盖了从具有明确用途（例如用于医学应用中的模式识别）到具有通用用途的人工智能系统。不考虑那些绝对不涉及个人数据的人工智能系统，即在训练数据和应用中均不涉及个人数据（例如用于预测自然灾害的系统）。
从数据保护法的角度来看，重点在于如何保护自然人的权利和自由。与传统 IT 系统不同，人工智能系统的一个重要方面是 AI 模型的训练以及训练数据的使用。许多 AI 模型需要大量数据用于训练。收集这些数据集（例如通过网络爬虫、数据抓取）所涉及的数据保护法问题，不在本文讨论范围内。
将现有的 AI 模型或系统集成到新的人工智能系统中，无论是通过使用和专门化第三方的 AI 模型，还是通过接口集成，也不在本文讨论范围内。虽然本文中描述的许多方面也与此相关，但如果 AI 模型或系统与新应用并非出自同一主体，则会产生进一步的问题。
对于包含一个或多个 AI 系统或模型作为更大系统组件的应用程序或服务，本文中描述的方面也可能有所帮助。然而，对于整体评估，这些内容可能并不足够。
为了不超出本文范围，无法涉及单个 AI 算法。同样，对于具体应用领域、使用场景以及架构方面，也不进行讨论。只有当某些类型的 AI 算法对于数据保护法的详细评估有意义时，才会在本文中提及。
1.2 生命周期阶段的划分
人工智能系统在其开发和后续运营过程中会经历不同的阶段，这些阶段构成了AI生命周期。对于本文而言，将这些阶段划分为以下四个阶段：（1）设计，（2）开发，（3）嵌入和（4）运营和监控。以下将简要描述这些阶段并进行区分。此外，还将简要介绍这些阶段对于处理个人数据的重要性。需要注意的是，这些阶段对于不同的人工智能系统具有不同的相关性，并且阶段之间的过渡有时是渐进的。
（1）设计（包括数据选择、数据收集）
设计阶段主要包括为实施新的人工智能系统所做的规划和准备工作。目标是收集并结构化记录后续开发或技术实施所需的所有必要信息。首先，要收集系统应满足的要求。根据“数据保护设计原则”，在这一阶段也应考虑数据保护法问题。这包括提前规划技术和组织措施，以确保在所有生命周期阶段保护个人数据。
与传统 IT 系统相比，开发阶段中的训练通常需要大量的数据，即所谓的训练数据，以及测试和验证数据——其获取形式为原始数据，也是设计阶段的一部分。这些数据要么由责任主体自行收集，要么从现有数据源获取，例如公开可访问的数据档案。
（2）开发（数据预处理、训练和验证）
在定义了人工智能系统的要求并收集了训练、测试和验证所需的原始数据后，开始进行具体的技术实施。这包括实施所使用的 AI 算法以及随后使用训练数据对 AI 模型进行训练。
为了能够使用收集到的数据进行训练，这些数据可能需要进行预处理。这是一个将原始数据进行目的性和领域特定处理的过程，以便这些数据能够在训练过程中被 AI 算法处理，以满足 AI 模型的要求。如果原始数据具有个人相关性，但对要开发的 AI 模型并非必要，则应在此阶段通过应用适当措施将其移除。
在这一阶段，通过训练生成的 AI 模型也需要进行验证，这意味着需要检查其输出的质量是否符合预期的质量标准。质量标准可以是分类任务中的容错率，或者是生成性 AI 模型中对不期望输出的抑制。为此，除了使用验证数据检查 AI 模型的质量外，还应开发和应用测试程序，这些程序还应考虑 AI 模型的预期集成。
（3）部署（软件分发包括更新）
当 AI 系统的优化完成后，可以在生产环境中部署并使其对用户可用。
在这一阶段，必须根据具体应用场景进行必要的配置，这些配置应考虑数据保护友好的默认设置（“数据保护默认设置”）。
（4）运营和监控
在完成试点项目并进行必要的调整以确保系统能够正常运行后，AI 系统可以投入使用并进入生产运营。用户现在可以访问该系统，并根据定义的目的处理数据。
尽管已经进行了广泛的测试，但仍应定期进行重新检查，以评估输出的质量。
AI 系统也可以被设计为在运营中自主学习并相应调整其行为。为此，输入和输出数据以及用户对输出质量的反馈将被处理。这些数据可以流入 AI 模型的自动化更新，或者用于手动触发的延迟重新训练。这可能导致生命周期阶段需要重新进行。
1.3 法律原则
对于处理个人数据（定义：参见GDPR第 4 条第 2 款），适用 GDPR 及其规定的原则（参见 GDPR 第 5 条第 1 款），包括合法性、透明性、目的限制、数据最小化和准确性。根据 GDPR 第 5 条第 2 款，数据控制者负责遵守第 1 款的原则，并能够证明其遵守情况。
处理活动的目的必须事先确定，明确且合法，处理必须有法律依据，并且处理过程中产生的风险必须得到充分控制。开发和运营 AI 系统可能会由于处理的性质、范围和目的而对自然人的权利和自由带来高风险。在这种情况下，必须根据 GDPR 第 32 条采取适当的技术和组织措施，以确保达到与风险相称的保护水平。
如果某种处理活动预计会对自然人的权利和自由造成高风险，则必须根据 GDPR 第 35 条进行数据保护影响评估。
此外，数据控制者必须履行其根据 GDPR 第 13 条和第 14 条的信息义务，并确保数据主体能够行使他们的权利，特别是根据 GDPR 第 15 条的知情权、根据 GDPR 第 16 条的更正权、根据 GDPR 第 17 条的删除权以及根据 GDPR 第 22 条的不受自动化决策影响的权利。
根据 GDPR 第 4 条第 7 款，制造商和开发者通常是设计和开发阶段中个人数据处理的数据控制者。在部署和运营阶段，决定使用 AI 系统处理哪些个人数据以及用于何种目的的主体是数据控制者。这些阶段的数据控制者只能使用由制造商和开发者设计的、能够符合数据保护要求的 AI 系统或 AI 模型。
1.4 标准数据保护模型（SDM）
在实践中，GDPR 中的法律要求必须通过技术和组织措施来满足。标准数据保护模型（SDM）是一种基于统一保护目标的数据保护评估和审查方法。SDM 的系统和应用方式借鉴了联邦信息安全办公室（BSI）IT 基础保护的安全标准方法。
SDM 参考 GDPR，并提供适当的机制，将法律要求转化为技术和组织措施。为此，SDM 涵盖了GDPR 第 5 条以及第 32 条中的法律要求，并将其分配给以下保护目标：
数据最小化：处理的个人数据必须与目的相符且显著，并且限制在处理目的所必需的范围内。
可用性：必须确保对个人数据的访问，并且当需要时，系统可以执行其处理操作。
保密性：未经授权的人员不得访问个人数据。
完整性：个人数据保持未受损、完整、可追溯且最新。
可干预性：数据控制者必须始终能够干预从数据收集到数据删除的整个数据处理过程，除了实施数据主体的权利（如更正或删除权）外，还应执行监管机构的命令并解决或减轻数据保护违规行为。
透明性：一方面，透明性是为了满足 GDPR 第 5 条第 2 款的问责义务，另一方面是为了履行 GDPR 第 12 条、第 13 条和第 14 条的信息义务。
非关联性：个人数据不得用于除明确、合法且合法目的之外的其他目的进行收集、处理和使用。
需要注意的是，上述保护目标中有些可能会产生相互矛盾的要求。因此，在整体考虑时，需要平衡这些相互依赖的保护目标之间的关系。
保护目标主要用于整合和结构化抽象的法律要求，以便将这些要求转化为必要的具体技术和组织措施，以确保达到适当的保护水平。SDM 所属的参考措施目录可以帮助完成这一步骤。
以下将展示哪些技术和组织措施可以有助于满足通过保护目标系统化的数据保护要求。许多在传统 IT 系统中已经建立的技术和组织措施，可以在 SDM 的措施目录中以及 BSI 的 IT 基础保护建议中找到，这些措施也可以并且应该在人工智能系统的开发和运营中实施。
其中一些措施在处理大量个人数据时（这在开发人工智能系统中很常见）具有特别重要的意义。例如，加密机制和传统的 IT 安全方法（用于防止数据篡改，如数字签名、校验和和日志记录）至关重要。角色和权限概念以及带有保留和删除期限的删除概念也很重要。鉴于人工智能领域的快速发展，定期培训和继续教育也是迫切需要的。
以下所有讨论都集中在人工智能特定的要求和措施上。
2 人工智能系统的技术和组织要求
根据第 1.2 节中介绍的人工智能系统生命周期阶段，以下将根据保证目标对这些阶段进行分析并定义要求。需要注意的是，鉴于人工智能系统的广泛多样性，某些方面也可能属于其他阶段。
2.1 设计（包括数据选择、数据收集）
在设计阶段，主要做出关于未来人工智能系统的功能的决策。除了选择合适的架构、将要运行系统的 IT 基础设施以及使用的 AI 模型类型外，还应特别关注收集或选择用于训练 AI 模型以及验证和测试整个系统的数据。根据目的和所选 AI 系统的类型，可以使用个人数据、合成数据或匿名数据。
对于处理个人数据，需要有合法性基础。对于公开可访问的数据，希望使用这些数据集来训练其 AI 模型的控制者，除了需要合适的合法性基础外，还必须确保数据集的创建并非明显违法（例如，通过数据泄露）。为此，需要特别注意以下几点：数据来源应在数据集描述中注明，数据集并非通过犯罪行为创建（例如，来自暗网的泄露），并且没有公共程序将数据集的创建视为违法，且对数据集的合法性不存在任何疑问（例如，如果数据集包含数千人的精确位置信息，这些信息作为明文数据且未提供法律依据就被提供）。在选择和收集个人数据时，还必须采取适当的技术和组织措施，以确保达到适当的保护水平。以下将讨论针对各个保护目标的可能措施。
2.1.1 保护目标：透明性
为了确保可验证性，控制者应记录以下内容：
处理目的以及收集或进一步使用原始数据的法律依据。
训练是否需要处理个人数据？是否可以通过合成数据或匿名化数据实现 AI 系统的目标和目的？
在“数据集数据表”中描述的方法是一种标准化的数据集记录方式。如果数据集是从外部机构获取的，这些机构可以创建这种记录。在获取训练数据时，可以参考现有的信息。需要注意的是，如果数据集发生变化，记录必须更新，即使在后续阶段也是如此。记录应特别考虑以下方面：
a. 数据集的组成（数据类型（图像、视频、表格数据等）、数据类别（属性、类别等）、元数据等）。
b. 数据集的来源/出处（对于现有数据集：注明数据集的版本和日期以及数据集的链接；对于自行收集的数据集：详细描述收集方法，例如保存数据收集脚本，并在需要时提供）。
c. 收集的上下文（对于每个来源，注明收集方法、数据主体范围（例如公司 xy 的客户数据）以及数据收集的时间段）。
d. 收集数据的（原始）目的。
e. 记录的版本和最后更新时间。
对于计划中的 AI 系统：
a. 目标：AI 系统的目标和功能。
b. 系统架构（AI 系统应由哪些部分组成：预训练的 AI 模型？联邦学习架构？RAG？API？）。
c. 可能的 AI 算法选择以及将在开发阶段进行训练的算法。在开发阶段之前，通常不清楚哪种 AI 模型将被使用，因为这取决于性能评估的结果，而这些结果只有在开发阶段之后才能确定。尽管如此，至少定义一组符合处理目的和目标的 AI 算法仍然是一个好习惯。
d. 证明设计选择的实验。
实现其他保护目标的措施，以确保这些目标的可验证性（例如，数据最小化或完整性的措施）。
除了上述记录外，还需要澄清 AI 系统或 AI 模型的透明性问题。基于开源方法的 AI 系统可以提供更多的透明性。可解释的 AI 方法可以追溯 AI 系统如何得出结果，因此对数据主体以及制造商和开发人员都有帮助。此外，文档中的可视化可以帮助理解 AI 模型的工作原理。
2.1.2 保护目标：数据最小化
控制者必须在收集数据之前或进一步使用已收集数据之前确定 AI 系统的目的以及可能需要的数据。基于这些考虑，应定义数据收集的具体标准。需要注意的是，不应收集不必要的数据。为了确定必要的个人数据，应考虑以下方面：
系统设计：在定义 AI 系统的目标后，通常会有多种 AI 算法可供选择，这些算法需要不同数量的训练数据。如果一个 AI 系统可以在使用较少个人数据的情况下实现相同的功能并达到类似的性能，则应优先选择。即使控制着在开发阶段之后，通过进行足够的实验才能准确回答有关正在开发的 AI 系统性能的问题，但提前考虑可能的 AI 算法仍然是一个好习惯。这可以通过研究当前科学文献中的见解、开源社区的实践以及进行试点研究来帮助选择合适的 AI 系统。例如，联邦学习是一种技术措施，它允许在多个数据源上训练一个全局 AI 模型，而无需将本地数据合并或在参与机构之间共享。
数据量：数据点的数量必须根据 AI 系统的目标和所选 AI 算法进行合理化。数据的质量和数据集的代表性尤其重要。此外，过度的数据最小化可能会危及 AI 模型建模的完整性，即导致偏差。数据集中的历史深度和不同人群的代表性是需要考虑的因素，以确保准确性和防止歧视。进行小数据集的试点研究、逐步扩大数据集（如果需要）以及删除不再需要的数据是一种良好实践。
数据类别：AI 模型的决策应基于哪些数据类别，决策可能依赖于哪些因素（例如年龄、性别、面部图像、在社交网络中的活动）？使用特殊类别的个人数据（即GDPR“第 9 条数据”）需要进行审查和证明。应优先选择具有泛化特征的属性（例如，仅使用出生年份而不是完整的日期格式）。各种特征选择和降维技术可以帮助减少属性的维度。此外，应删除可能导致偏差和歧视的属性，除非这些属性对于处理是绝对必要的。控制着应注意，所谓的代理特征也可能间接指向敏感属性（例如，邮政编码作为来源的代理）。对于训练具有可接受误差的 AI 系统所需的理论数据量，应基于理论进行估计，以实现系统行为的预期目标。
数据类型：是否需要个人数据进行训练，或者可以使用合成数据或匿名化数据？需要注意数据的可重新识别性。使用增强数据可能是可行的，以在不需要新数据点的情况下增加数据集的多样性。
数据来源：数据是否可以从现有来源获取，还是需要为计划的目的重新收集？
2.1.3 保护目标：非关联性
如果法律禁止使用某些数据（例如，GDPR 第 9 条规定的特别敏感数据），而使用高度相关的替代变量，则构成关联。需要注意的是，即使这只是作为实际处理目的的中间结果，从表面上看似无关的个人数据中推导出直接数据也是不允许的。
2.1.4 保护目标：可干预性
在设计阶段，就必须采取措施实施数据主体的权利和监管机构的命令，这既涉及训练数据，也可能涉及 AI 模型。为此，必须定义一个内部流程。
对原始数据的可干预性：如果根据 GDPR 第 13 条或第 14 条需要向数据主体告知原始数据的收集，则必须在原始数据收集时间、数据主体告知时间以及 AI 模型训练时间之间定义一个合理的时间间隔，以便数据主体能够在训练之前行使他们的权利。不得收集明确反对将其内容用于构建训练数据集的网站的数据（例如，通过 robots.txt 或 ai.txt）。
确保数据主体权利的行使并不免除控制者选择对处理影响最小的方法的义务。
应通过数据管理系统和搜索功能（例如，大数据数据库）实施查找原始数据集中个人数据的措施。
对 AI 模型的可干预性：能够更好地使数据主体行使权利的 AI 模型应被优先选择。例如，一个 AI 模型在收到删除个人数据的请求时，如果能够更快地重新训练而不包括要删除的数据，并且能够达到足够的性能，则应被优先选择。在某些情况下，甚至可以直接在 AI 模型中识别个人数据并根据请求删除（例如，在支持向量机（SVM）中）。应检查诸如机器遗忘或 AI 模型微调（不包括要删除的数据）等技术是否在特定情况下有效。
2.1.5 保护目标：可用性
为了能够及时访问个人数据并进行处理，控制者应集成数据管理系统，例如大数据数据库。
2.1.6 保护目标：完整性
控制者通过特别关注数据的质量及其注释、数据来源的可信度以及数据集中存在的偏差来检查原始数据的准确性。为了识别可能的篡改和更改原始数据，可以在整个原始数据集或单个数据点上生成并存储哈希值。
对原始数据进行统计分析以及单独检查单个数据点是一个良好的实践。由此产生的见解对于开发阶段的预处理实施尤其重要。在这里，数据验证方法非常重要，这也可以通过检查数据来源是否可信来有助于防止数据投毒。
对数据分布进行详细研究以及进行试点研究（例如，研究 AI 模型在不同人群上的性能）是预防 AI 系统歧视的第一步。应实施措施以实现数据的代表性分布以及其他预防措施和缓解技术。
如果使用预训练的 AI 模型，需要注意后门投毒，这可能导致 AI 模型的意外输出。为此，控制者在进一步训练和使用这些模型之前，应检查预训练 AI 模型的可信度。
2.1.7 保护目标：保密性
AI 模型和系统可能会泄露用于训练的个人数据。攻击者可能会从 AI 模型或系统中提取个人数据。AI 系统也可能无意中向用户输出个人数据。其中一些原因是结构性的，与 AI 模型的构建方式有关，而其他原因则与 AI 模型的泛化不良或记忆化有关。一些通用的对策是隐私保护技术，如差分隐私，以及正则化技术，以改善 AI 模型的泛化能力。
2.2 开发（数据预处理、训练和验证）
在开发阶段，通常会对原始数据进行预处理，以生成用于特定领域知识建模的训练数据。这通常涉及数据过滤、数据转换、数据标注（即为数据添加附加信息）以及数据归一化。随后进行 AI 模型的训练以及相关的验证。为此，将使用三种类型的数据：训练数据、验证数据和测试数据。
在这一阶段，预处理、训练、验证和测试是相关的处理活动。从数据保护的角度来看，应特别注意以下几点：
选择和记录用于相应 AI 模型的 AI 算法。
实施第 2.1.4 节中提到的干预可能性。
为验证目的确定 AI 模型的目标值。
开发测试程序，以确保 AI 模型满足其预定目的。
为支持 GDPR 第 5 条第 2 款以及第 13 条和第 14 条的透明性和问责义务，控制者应有意识地决定 AI 系统的本地使用可能性或与制造商和开发人员的在线连接需求。
与上述相关：记录使用外部服务的情况，这些服务不在制造商和开发人员的直接控制之下，以及其潜在的连接，例如通过 API 连接到服务。
2.2.1 保护目标：透明性
负责训练的控制者应记录哪些机构处理了原始数据以构成训练数据。此外，还必须记录和说明用于处理训练数据的统计方法，以便实现 AI 模型或 AI 系统的预定目的。GDPR 第 5 条第 2 款要求对处理的准确性、存储限制和数据最小化进行举证。关于处理目的、数据接收者以及存储期限的信息义务也在 GDPR 第 13 条中规定。因此，基于从 GDPR 派生的透明性义务，这些义务也必须在训练过程中得到遵守。为了实现必要的透明性，仅记录所选择的机器学习方法被认为是不足够的。相反，更有意义的是在质量和可解释性方面建立 AI 系统的透明性。所选择的验证方法在这里创造了必要的透明性水平。
此外，还需要回答和记录以下与透明性相关的问题：数据在哪里进行预处理？数据存储在哪里？如何确保训练数据和训练结果（即 AI 模型）的完整性？训练在哪里进行，是否是分布式组织的？AI 模型在哪些系统上进行验证和测试？谁可以访问训练数据、验证数据和测试数据？谁可以访问 AI 模型及其所需的验证输出？由此产生的技术和组织措施也应记录下来，但将在随后的保证目标中再次提及。
2.2.2 保护目标：数据最小化
在预处理、训练和验证的背景下，数据最小化有两个方面特别需要注意。一方面，只能处理对于实现处理目的（即 AI 模型的预定功能）所必需的个人数据。另一方面，参与的 AI 系统只能获得其具体处理步骤所需的那些数据。特别是在“复合 AI 系统”（即并非作为单一整体设计，而是由独立的子系统组成的 AI 系统）中，这些组件是模块化和可重用的。因此，这些组件通常不仅可用于特定目的，而且可用于多种目的。这反过来又导致处理的数据不仅仅是为预期目的所必需的，而且是为了组件的技术运行。因此，对数据使用的必要性差异很大，这影响了模块化 AI 系统组件的选择。
控制者必须确保 AI 模型仅包含或能够再现对于实现目的所必需的个人数据。此外，控制者还应在训练过程中（并在使用过程中）提前假设所使用数据类别对 AI 模型行为的影响，并对其进行评估。
2.2.3 保护目标：非关联性
AI 系统非常适合进行关联。可以从所选择的训练数据中学习到更多的功能关系。图像、语言或文本中通常包含比预期目的更多的信息。例如，可以从面部图像中使用相同的训练材料对性别、种族、情绪或可能的疾病（如厌食症/肥胖症）进行分类。通过组合不同的数据集，可以在训练过程中建立联系，并学习到在原始训练数据集中并不直接明显的信息。因此，责任主体必须确保 AI 系统仅用于在设计阶段确定的目的。特别是要检查 AI 系统是否产生了意外的中间结果，或者是否对超出预定目的的查询提供了意外的答案。
2.2.4 保护目标：可干预性
如果 AI 系统本身或可能使用 AI 系统的场景属于 GDPR 第 22 条的适用范围，则制造商和开发人员必须提供干预可能性。这包括 AI 系统的输出可以被用户或人工审核员质疑，并且在可能的情况下，由他们进行追溯。为此，应提供相应的功能和输出选项。
2.2.5 保护目标：可用性
在开发阶段，AI 系统的可用性通常被不典型地定义。通常，训练过程可能持续数月，并且需要大量的计算资源和能源。在训练阶段，数据控制者无法访问 AI 模型本身，因为它在不断变化。因此，可用性不是由系统的快速可用性来定义的，而是由训练过程的可靠持续运行以及对故障（如故障或停电）的弹性来定义的。
因此，控制者应计划如何设计用于训练、验证和测试的系统，以确保无故障的开发。例如，应考虑组件的冗余设计、备份策略（针对过程所需的数据），或者在发生故障时尽可能无缝地切换到备用系统或组件。在前期，应通过确定架构、训练、验证和测试过程的方法以及数据量来确保有关总计算和存储需求的信息。随后，应采取措施以确保有足够的存储容量用于训练，以容忍在训练和验证阶段的故障。
2.2.6 保护目标：完整性
对于包括训练、验证和测试在内的处理过程，完整性的属性必须在两个方面得到保证。一方面，必须保证训练、验证和测试数据的完整性，即这些数据不得被篡改或导致输入的代表性不足。另一方面，还必须考虑训练完成的 AI 模型的完整性。该模型必须在训练、验证和测试完成后充分反映所需的输出，并且能够按照计划的质量标准实现输入到输出的映射。特别是对错误或罕见输入的鲁棒性有助于 AI 模型的可靠性或准确性。因此，责任主体必须采取措施，保护训练完成的 AI 模型参数以及训练、验证和测试数据免受篡改。
确保训练完成的 AI 模型完整性的措施可以包括原始数据的标准化和规范化以及其补充和错误纠正。识别或创建“带干扰信号的数据”，以测试和证明 AI 系统的鲁棒性，也是确保 AI 模型完整性的措施。此外，必须确保用于训练目的的数据在训练过程中不会同时用于验证或测试目的。
训练数据的完整性应从如下两个角度分析：首先，训练数据的不平衡分布可能会危及 AI 系统的完整性，其次，被篡改的训练数据可能会歪曲训练结果。两者都会导致无法实现预定目的的 AI 系统，因为会产生错误的输出。因此，控制者必须确保通过足够数量的训练数据实现足够完整的系统行为，这些数据能够充分代表所有可能的训练数据，以实现预期的处理目的。
此外，控制者还必须确保数据预处理是有目的的，使用相关数据，并且以正确的方式进行。在任何情况下，都必须排除 AI 模型使用未经授权篡改的数据进行训练的可能性。特别是数据投毒技术必须被有效防止。
2.2.7 保护目标：保密性
特别是对于生成性 AI 模型，已知它们可能会在某些情况下未经修改地输出训练数据。因此，制造商和开发人员需要检查所开发的 AI 模型是否容易受到随机用户行为或相应攻击的影响，并采取哪些对策。在训练过程中，可能会生成 AI 模型的中间版本，这些版本仍然容易受到此类攻击。根据风险评估的结果，处理过程可能仅在控制者的基础设施组件上执行，或者可以将处理过程分配给包括数据处理者在内的多方。对于计划中的 AI 模型的进一步训练或微调，应优先选择在使用的终端设备上进行本地处理。
在训练过程中可能会产生中间结果，这些结果具有个人相关性，要么是因为它们可以识别个人，要么是因为它们可能具有语义意义，从而可能无意中推断出被处理数据的个人的敏感信息。例如，一个用于预测注视方向的 AI 系统可能会产生眼睛、鼻子和嘴巴的确切坐标作为中间结果（即生物识别数据），这些数据在进一步处理后被转化为注视方向。因此，从技术上必须确保这些中间结果不会被长期存储，并且只有预先定义的人员群体出于预定目的才能访问这些中间结果。访问应被记录。
同样，控制者必须确保“need to know”原则得到保障。如果进行分布式训练，参与的基础设施组件只需要获取特定训练运行所需的那些数据。对于验证和测试也是如此。
2.3 部署（软件分发包括更新）
以下重点将放在控制者的最终使用上，当如第 1.1 节所述开发和应用由同一主体负责。人工智能系统的组件/功能也可以通过人工智能即服务（AI-as-a-Service）提供。关于保密性（第 2.3.7 节）的相关影响已在上述内容中提及。
在人工智能系统的软件分发意义上的部署通常不涉及用户。只有在这一阶段处理个人数据时，才会涉及数据保护相关性。在这种情况下，需要一个法律依据和目的限制。以下提到的措施在不确定或不清楚是否处理个人数据时也是有意义的。
2.3.1 保护目标：透明性
透明性不仅有助于履行法律义务，还有助于建立信任。为了实现这一保证目标，在引入阶段，应记录导致使用人工智能系统的基本决策，并使其可供数据主体查阅。为了避免危及其他保证目标，不应公开与信息安全相关的信息。
关于以下内容的配置和信息提供对于潜在的数据主体来说是重要的，因此应予以记录：
功能原理，特别是在自动化决策方面（GDPR 第 15 条第 1 款第 h 项），
人工干预的可能性，参见例如 GDPR 第 22 条，以及
数据主体的权利。
还应记录在嵌入阶段交付的、用于人工智能系统决策的元素。这些可以是例如神经网络的参数、用于推理的数据、信任指标（AI 对齐）或系统版本。同样重要的是记录哪些配置选项（“数据保护默认设置”）是总体上确定的，哪些可以由用户自行选择。
记录应以一种方式完成，使其尽可能易于非开发人员理解。出于风险评估的原因，建议责任主体使记录清晰且易于追溯。
2.3.2 保护目标：数据最小化
为了避免与其他保证目标产生冲突，应关注数据最小化的配置，例如，这不应与问责和证明义务相冲突。
在嵌入阶段，应仅提供特定使用目的/应用场景所需的数据。为了实施这一要求，应从适当的引入测试中获取信息并进行记录。
在此过程中，需要考虑人工智能系统中存在的个人数据以及与之一起分发的个人数据。可能需要区分人工智能系统中使用的人工智能算法类型（例如，参数化和非参数化人工智能算法）。需要考虑的是，这些不同类型的 AI 系统可能以不同的方式包含个人数据。
如果训练数据中包含个人数据，那么由此开发的参数化 AI 模型（例如，神经网络）本身也可能具有个人相关性。这些 AI 模型在运行时不需要训练数据，因此不应将其分发。相比之下，例如非参数化 AI 模型（例如，K-最近邻）必须在引入阶段与 AI 模型一起分发训练数据。没有训练数据，这样的 AI 模型将无法正常运行。
2.3.3-2.3.6 保护目标：非关联性、可干预性、可用性和完整性
对于人工智能系统的嵌入，没有发现任何特殊要求适用于这些保证目标，这些要求不适用于其他 IT 系统的引入（参见第 1.4 节）。
2.3.7 保护目标：保密性
如第 2.3.2 节所述，可能需要提供训练数据。这也涉及保密性问题。在这种情况下，需要考虑人工智能系统是如何提供给用户的。如果人工智能系统以集中式方式提供给用户，例如以 Web 应用程序的形式，那么在提供时，所需的个人数据只能传输到 Web 应用程序或相应的 Web 会话中。如果人工智能系统可能在用户的终端设备上离线运行，则这些个人数据可能需要分发到所有终端设备上。这导致对数据主体的保密性和数据最小化风险的评估不同。
上述影响也可能扩展到在训练过程中处理的个人数据，这些数据可能保留在 AI 模型中（例如，训练数据、AI 模型参数等）。在评估数据主体的风险时，还应考虑根据具体情况在大型语言模型（LLMs）中用于书面自然语言嵌入的标记化过程中使用的个人数据。为了防止在分发具有个人相关性的 AI 模型或系统时违反数据保护规定，应考虑在分发时使用加密等技术手段。
需要考虑的是，一个 AI 系统可能包含多个 AI 模型。根据应用领域，例如在 LLM 中，可能会使用不同的 AI 算法，因此不能一概而论地排除在各个 AI 模型中处理个人数据的可能性（例如，在文本到图像系统中）。
2.4 运营和监控
人工智能系统的最后一个生命周期阶段包括人工智能系统的生产使用、输入和输出的反馈以及用户对输出质量的反馈，用于进一步训练人工智能模型以及持续验证人工智能系统。以下要求和措施主要针对人工智能系统的制造商和开发人员，他们作为责任主体运营和进一步开发这些系统。此外，制造商和开发人员应实施这些要求和措施，以确保其人工智能系统的合规使用。
2.4.1 保护目标：透明性
对数据主体产生法律效力或以类似方式对其产生重大影响的决策，不得基于随机性（尽管可以基于概率）做出。因此，对于决策支持型 AI 系统，其输出的相关内容必须是确定性和可复制的。
已知的 AI 模型参数（例如，决策树）和 AI 系统输出的处理步骤必须以可追溯的方式进行记录。在第 2 阶段定义的测试，用于检查 AI 系统的正常运行，在发生变更和更新时必须重复进行，并记录结果以及由此产生的任何调整。
必须记录哪些数据被哪个 AI 系统处理，以及这些数据是否被用于进一步的训练。
2.4.2 保护目标：数据最小化
如果特定 AI 系统的输出包含的个人数据超出了预定目的所需的范围，则需要检查是否需要对 AI 系统进行调整，以确保其未来不再产生此类输出。例如，如果一个推荐系统根据确定的偏好输出理想的地块，对于潜在购买者来说，了解地块的所有者是谁以及获取卖方的联系方式是重要的。然而，卖方的居住地或生日等信息是无关紧要的。这些数据不应由此类推荐系统输出。如果在 AI 系统的使用过程中发现处理的数据不再（或从未）对于实现预定目的所必需，例如由于外部情况的变化，或者发现某些属性具有歧视性影响，则可能需要对相关的 AI 模型进行重新训练，使用相应减少的训练数据。在这种情况下，过时的 AI 模型随后必须被删除，除非存在记录义务或透明性要求。
处理个人输入或输出以用于进一步训练 AI 模型，这构成了一种目的变更的进一步处理，也必须符合 GDPR 的要求。如果输入和输出的反馈用于 AI 系统的质量改进，作为其学习能力的一部分，则应考虑对这些数据进行匿名化，例如通过数据缩减/聚合。对于这种处理，应设定与初始训练相似的标准。必要的措施可能包括伪匿名化或对相关 AI 模型的个人相关性进行事后检查。在反馈过程中，可以应用分布式训练（英语：联邦学习），以便只有单个基础设施组件处理各自的数据，并且不共享数据本身，而是共享由此产生的训练结果。
2.4.3 保护目标：非关联性
对于 AI 系统的运营和监控，没有发现任何特殊要求适用于这一保证目标，这些要求不适用于其他 IT 系统的运营和监控（参见第 1.4 节）。
2.4.4 保护目标：可干预性
决策支持：如果计划将 AI 系统用于决策支持，则技术措施可以促进基于人类的深入干预。例如，AI 系统可以保持在等待状态（“挂起”），直到根据人工控制启动进一步流程；可以规定固定的人工处理时间，以便在确认之前进行干预，以支持对输出的审查；或者也可以定期需要人工批准。此外，在 AI 系统中提供提示，表明输出并非完美，并且可能需要额外提供一个“不确定性因素”，以评估各自输出的可靠性，这将有所帮助。后者也可以直接在 AI 系统中使用，以便在特定值以上不输出结果。
数据主体权利：根据 GDPR 第 16 条、第 17 条和第 18 条的数据主体权利在 AI 模型和系统中特别重要，如果这些模型和系统并非匿名，则具体要求如下：
更正：应根据要求更正训练数据中的不准确个人数据，这特别适用于用于进一步训练的输入和输出。对于 AI 系统的不准确个人输出，也存在更正权。更正必须在输出进一步处理之前进行，并且必须通过适当的技术或组织措施防止不准确的输出，例如，在将输出提供给用户之前，在 AI 系统内对这些输出进行过滤并相应更正。
删除：如果根据 GDPR 第 17 条第 1 款需要删除，则需要对相关数据进行全面的技术删除。这包括输入和输出，特别是如果这些数据被用作训练数据，但也包括 AI 模型，如果该模型“包含”要删除的信息。通常至少可以这样假设，如果信息包含在使用的训练数据中，并且在 AI 模型的输出中存在。在这种情况下，必须定期重新训练新的 AI 模型，确保要删除的数据不再包含在训练数据中，或者现有的 AI 模型必须进行适当的再训练（英语：机器遗忘）。必须证明机器遗忘的成功，即无法再基于 AI 模型识别出训练数据中包含的数据。在删除之前，应使用适当的输入和输出过滤器作为临时解决方案。然而，这些缓解措施，特别是过滤器本身，并不构成删除。并非在每种情况下都有权删除个人数据，因为 GDPR 第 17 条第 2 款和第 3 款规定了限制和例外情况。
限制：根据 GDPR 第 4 条第 3 款，这是“对存储的个人数据进行标记，以限制其未来的处理”。对于训练数据和日志数据，应像处理传统数据一样处理这些数据。对于 AI 模型，可以参考删除部分的说明。可以应用适当的过滤器，以限制相应数据的处理，通过识别和阻止限制的输入和输出来实现。
对于具有高风险的 AI 系统，对风险降低措施的要求更高。在某些情况下，可能需要实施科学现状（例如机器遗忘），而不仅仅是技术现状，以实现可接受的风险水平。在特别高风险的情况下，这可能仍然不足，因此，例如，利益平衡可能会不利于 AI 系统的运营。
2.4.5 保护目标：可用性
对于 AI 系统的运营和监控，没有发现任何特殊要求适用于这一保证目标，这些要求不适用于其他 IT 系统的运营和监控（参见第 1.4 节）。
2.4.6 保护目标：完整性
知识领域的变化（例如，上下文的变化、法律法规的变化、技术变化、知识的增加）必须被识别，因为这些变化可能导致 AI 模型不再适当地代表变化后的知识领域。这可能会增加对数据主体权利和自由的风险。在这种情况下，必须采取适当的措施来应对这些变化，以确保完整性。在某些情况下，可能需要开发新的 AI 模型，使用更新的训练数据。
在第 2 阶段定义的质量要求必须定期评估。对于不断学习和适应的 AI 系统，必须特别关注其质量的持续维护。必须检测 AI 系统的突然和持续行为变化，并评估其对风险的影响。
应通过输入过滤器识别超出允许范围的输入，并导致明显的警告提示。此外，还应识别输入（由攻击者）被篡改，从而导致 AI 系统做出错误决策的情况（英语：逃避攻击）。
应定期进行风险评估，例如通过红队测试，特别是对于公开可用的 AI 系统。
反馈数据的完整性必须得到保证。必须防止通过篡改输入和输出或对用于进一步训练的输出质量的错误反馈进行攻击。特别是在分布式学习中，训练数据不被共享，可能难以确定整个数据的质量。在这种情况下，可以使用在第 1 阶段已经提到的措施。
2.4.7 保护目标：保密性
根据 AI 系统的使用目的，可能会产生不同的措施。例如，如果制造商和开发人员将 AI 系统提供给没有访问训练数据权限的人员，例如通过 API，必须防止训练数据的提取。如果 AI 模型本身具有个人相关性，则制造商和开发人员还必须采取措施防止模型提取。
在更新额外数据源时，例如在 RAG 系统中，每次都需要考虑那些可以访问 AI 系统的人是否也有权访问新的数据。
3 总结
总体而言，制造商和开发人员应在 AI 模型或系统的每个开发步骤中，从一开始就考虑数据最小化、可用性、保密性、完整性、可干预性、透明性和非关联性这七个保证目标。特别是考虑到通常需要大量数据用于开发以及 AI 系统的定期微调或更新，必须从一开始就遵守数据保护法，以保护自然人的权利和自由。
4 术语表
以下术语表涉及本文档中使用的术语。其目的是帮助读者更好地理解文本。因此，术语表部分采用了简化的表达方式，以便更容易理解文本中选定的方面。
AI-as-a-Service：AI-as-a-Service 指的是将 AI 模型和系统，甚至机器学习算法作为基于云的服务提供。
用户：用户是指使用 AI 系统的自然人。用户不一定是数据主体。
设计：设计主要包括为实施新 AI 系统所做的规划和准备工作，并作为结果描述开发要求。
开发：开发包括实施所使用的 AI 算法以及随后使用训练数据对 AI 模型进行训练。
联邦学习架构：联邦学习架构是一种 AI 系统架构变体的集合，其中多个设备在中央服务器的监督下共同训练一个 AI 模型，而无需共享各自的私有训练数据。
AI 算法：AI 算法是一种封闭的数学操作指令，用于解决 AI 领域的问题，并且可以在计算机程序中使用。
AI 模型：AI 模型是将 AI 算法应用于训练数据后产生的结果。它作为 AI 系统的一个组成部分，从输入中推导出结论以生成输出。AI 模型也可以被指定用于进一步的训练、微调或开发。（根据 EDSA 第 28/2024 号意见和 OECD 定义）
AI 系统：AI 系统是一个基于一个或多个 AI 模型的机器辅助系统，既可用于直接使用，也可用于集成到其他 AI 系统中。它被设计为具有不同程度的自主运行能力，并且可以在投入运行后进行调整。它从接收到的输入中推导出明确或隐含的目标，例如生成预测、内容、建议或决策，这些输出可能会影响物理或虚拟环境。（根据欧盟人工智能法第 3 条第 1 款和第 66 款）
配置：配置是对现有系统的调整，通常通过文件或数据库中的具体设置来实现。
AI 模型参数：AI 模型参数是 AI 模型内的可学习参数（例如，神经网络的权重）。这些参数通过将 AI 算法应用于训练数据来确定。
性能评估：根据预先设定的参数测量 AI 系统的性能。在评估 AI 系统的可靠性时，主要测量准确性、正确性和精确性，以及数据密度分布和与真实值的偏差等不同的模型依赖指标。除了技术性能外，公平性、可解释性、安全性、鲁棒性、数据保护、合法性或保护其他目标的指标也相关。
RAG（检索增强型生成）：RAG 是一种通过搜索功能为大型语言模型（LLM）提供与特定输入相关的额外信息的方法，这些信息来自一个数据池。
红队测试：应用手动或自动化方法，以检查语言模型是否会产生有害输出，并对其进行训练以避免此类输出。应用场景包括偏差检测、鲁棒性测试或合规性检查。该概念特别用于自学习 AI 系统。
原始数据：原始数据可以是在自身责任下收集的或从现有数据源获取的数据，这些数据可能未经修改。在用作训练数据之前，这些数据需要经过预处理。
反馈：这是一个过程，其中 AI 系统的输入或输出以及用户对输出质量的反馈被处理，以调整 AI 系统或其中包含的 AI 模型。
合成数据：合成数据是机器生成的数据，模仿真实数据并具有相同的相关属性，但不包含相同的信息。生成合成数据的一种方法是使用生成性 AI 系统。
测试数据：测试数据用于对 AI 模型或系统进行独立评估（评估），以确认该 AI 模型或系统在投入使用前的预期性能。（根据欧盟人工智能法第 3 条第 32 款）
训练数据：训练数据是从原始数据中提取的。训练数据是指用于训练 AI 模型的数据。根据所选的 AI 模型，这些数据将永久提供给 AI 模型，或者通过这些数据调整其 AI 模型参数。（根据欧盟人工智能法第 3 条第 29 款）
验证数据：验证数据在开发过程中用于评估 AI 模型并调整其非学习参数及其学习过程，以避免过拟合或欠拟合。验证数据通常从训练数据中提取，并且不用于训练。（根据欧盟人工智能法第 3 条第 30 款和第 31 款）
声明：本文来自那一片数据星辰，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
