DSAR 请求量问题
GDPR 第 12 条要求组织在一个月内响应数据主体访问请求，对于复杂请求可以延长至两个月。一个月的时限是绝对的——没有宽限期，没有善意例外。未能遵守响应时间框架是独立可处罚的，无论其数据保护实践如何。
2024 年的主要数据保护机构执法行动——爱尔兰数据保护委员会对 LinkedIn 处以 3.1 亿欧元的罚款，因其在没有有效同意的情况下进行行为广告，以及对 Meta 处以 2.51 亿欧元的罚款，因未能及时通知数据泄露——显著提高了公众对数据主体权利的认识。在每次重大罚款之后，数据保护机构通常会进行配套的宣传活动，随着数据主体意识到他们有权利行使，DSAR 请求量也随之增加。
欧洲数据保护委员会在 2024 年的协调执法框架专注于访问权失败——直接针对 DSAR 响应的质量和及时性。无法证明其 DSAR 处理合规的组织面临更高的风险，因为欧洲数据保护委员会的执法重点转向访问权。
第三方 PII 问题
DSAR 响应准备有一个特定的复杂性，增加了手动工作的负担：第三方 PII。
当数据主体请求所有关于他们的个人数据时，组织必须提供这些信息。但关于数据主体的记录可能包含对其他个人的引用——提到其他客户的客户服务记录、包含其他员工联系信息的电子邮件线程、提到第三方的投诉记录。在向请求的数据主体提供这些记录时，会违反第三方的权利，暴露其个人数据。
合规的 DSAR 响应要求在发送之前审查响应包中的每个文档，以查找第三方 PII，并对这些引用进行匿名处理。对于每月有 300 个 DSAR 的电信公司来说，每个请求涉及 50 条服务记录和通信，这意味着每月需要审查 15,000 个文档以查找第三方 PII 引用——这仅仅是为了 DSAR 合规。
在第 12 条规定的一个月窗口内，进行如此规模的手动审查是不可行的。一个由三人组成的合规团队无法在履行其他义务的同时审查每月 15,000 个文档。唯一可扩展的方法是使用预设配置进行自动化批处理，以去除第三方 PII。
批处理架构
一个为去除第三方 PII 配置的“DSAR 响应”预设：该预设检测文档中的所有人名、联系信息和识别引用。它对所有检测到的引用应用匿名处理，除了那些明确属于请求的数据主体的引用（在批处理作业开始时通过姓名和账户号码识别）。记录中提到的其他客户、服务记录中提到的员工以及通信中提到的第三方在文档包组装之前都会被匿名处理，以便回应数据主体。
处理每个 DSAR 请求的 50 个文档只需几分钟，而不是几个小时。合规团队审查匿名输出的质量和边缘案例，而不是进行初步审查。DSAR 响应时间从几周减少到几天。
来源：