“一案双查”是一个非常经典的行业术语，一般是说办一个案子时得查另一方面的问题。比如，在侦办网络违法犯罪案件的同时，对涉案网络服务提供者法定网络安全义务履行情况进行监督检查。
GDPR用的也是同一个套路，拔出萝卜带出泥！当用户投诉A事项是，D P A们可以查出企业遵守G D P R的其他问题，并一并做出处罚。
就在这起meta案件中，法院确认了一个穿透力的执法逻辑：GDPR下的投诉调查不是只能处理投诉人的个案纠纷，监管机构可以沿着个案发现的事实，追查背后的系统性违规，并据此作出面向全体用户的纠正命令。
2026年5月21日，爱尔兰高等法院法官Siobhán Phelan驳回了Meta Platforms Ireland Limited针对爱尔兰数据保护委员会DPC的司法审查请求。
案件源于一名Facebook用户在2018年7月提出的数据访问投诉。该用户要求访问Meta通过其Facebook账户处理的个人数据，Meta向其提供了在线下载工具，但投诉人认为Meta仍有部分个人数据未被提供，尤其是存储在Meta后端数据仓库“Hive”中的数据。
DPC在2025年10月形成草案决定，拟认定Meta违反GDPR第12条、第15条和第20条，并拟采取多项纠正措施，包括谴责、影响Meta一般数据访问实践的合规命令，以及总额3.6亿至4.3亿欧元的行政罚款。
需要准确说明的是，截至爱尔兰高等法院判决时，DPC仍处于草案决定阶段，最终命令和最终罚款尚未作出；但法院已经确认DPC在投诉调查中处理系统性问题的权限基础并不违法。
Meta挑战DPC的核心理由，是DPC将一项个人投诉扩张成了实质上的“自行启动调查”（own-volition inquiry）。Meta认为，投诉人的请求至多只能引发围绕该用户本人访问请求的处理程序，DPC如果要审查Meta面向数百万用户的一般数据访问实践，应当另行启动独立调查程序。DPC则主张，在已经发现潜在侵权的情况下，监管机构不仅有权，而且有义务在确定适当纠正措施时考虑系统性影响。
法院最终支持DPC。
Phelan法官认为，GDPR与爱尔兰《2018年数据保护法》的制度架构并不要求监管机构只能在自行调查中处理系统性问题。法院特别指出，投诉调查可以合法处理事实中浮现的系统性问题，并可能导致系统范围的纠正措施；这不会把投诉调查变成自行调查，而是体现DPC在发现侵权后确保GDPR有效执行的总体职责。
本案最值得关注的，并非“Meta是否真的会被罚4.3亿欧元”这一结果问题，而是DPC调查范围的边界问题。Meta试图建立一条程序上的防线：投诉调查只能解决投诉事项，自行调查才能处理系统性问题。若这一逻辑成立，大型平台面对个体投诉时，只需要修复投诉人本人的权利请求，即可避免监管机构借个案进入更深层的数据架构和产品机制。
爱尔兰高等法院没有接受这一切割。法院的推理起点是GDPR赋予监管机构的公共执法职责。GDPR第57条第1款(f)项要求监管机构处理数据主体投诉，并“在适当范围内”调查投诉事项；第58条则赋予监管机构调查权、纠正权和罚款权。条文并未说，投诉调查中的监管权力天然低于自行调查，也未规定监管机构发现系统性违规后必须另起炉灶。
这意味着，投诉事项只是监管程序的入口，不是监管事实的天花板。一个用户投诉说“我没有拿到完整数据”，监管机构在核查过程中发现企业的访问工具本身无法覆盖某类后端数据，或者企业将大量数据排除在访问响应之外，监管机构当然可以把调查延伸至该机制对其他用户的影响。否则，GDPR的投诉机制将被降格为私法争议处理机制，而不是公共执法入口。
这一点与GDPR第77条的数据主体投诉权相互衔接。第77条赋予数据主体向监管机构投诉的权利，并不要求投诉人证明企业对所有用户都构成违法。个人只需提出其认为个人数据处理违反GDPR的事实基础，监管机构便可以在调查中判断该事实是否反映更广泛的合规缺陷。投诉人的个案权利与监管机构的公共执法权，在这里不是彼此排斥，而是前后衔接。
欧洲法院在C-416/23 Österreichische Datenschutzbehörde案中关于投诉处理的立场，也能解释本案背后的制度逻辑。该案涉及监管机构能否仅因投诉数量多而认定请求“过度”。欧洲法院指出，Article 57(4)下的“request”包括GDPR第57条第1款(f)项和第77条第1款下的投诉，并且请求不能仅因特定期间内数量较多而被认定为“excessive”，监管机构还须证明请求人存在滥用意图。这虽然不是Meta案的同一问题，但它反映了同一价值判断：GDPR对投诉权的保护不能被程序便利性轻易压缩。
因此，Meta案确认的是一种“一案多查”的监管路径。所谓“一案”，是个人权利投诉；所谓“多查”，不是监管机构任意扩大事项，而是在投诉事实揭示系统性风险时，沿着同一数据处理机制、同一产品设计、同一后端架构继续审查。对大型平台而言，个体投诉不再只是客服工单，也不只是法务部门的单点争议，而可能成为监管机构打开全局数据治理结构的钥匙。
Hive数据是本案的技术核心。根据报道，投诉人认为Meta在一个被称为“Hive”的数字仓库中仍保留了未向其提供的个人数据。Hive不是用户在Facebook前端界面中直接看到的资料页面，也不是用户点击“下载你的信息”时自然理解的数据包，而是Meta后端用于存储和管理用户数据的数据仓库。
这类数据的第一个特点，是后端性。用户可以通过前端界面看到帖子、照片、好友、互动记录等信息，但大型平台真正的数据处理往往发生在后端系统中，包括日志、标签、推断、关联标识、设备信息、广告交互记录、风控信号和系统生成的衍生数据。前端工具呈现的是平台选择展示给用户的数据视图，不必然等同于平台实际处理的全部个人数据。
第二个特点，是集合性。Hive式数据仓库往往不是为单个用户的权利请求而设计，而是服务于产品分析、广告系统、推荐系统、安全风控和运营决策。它的表结构、字段命名、数据关联方式和保留逻辑，通常以内部工程效率为中心，而不是以“某个用户能否理解并行使权利”为中心。正因如此，当用户要求访问“我的全部个人数据”时，企业经常面临一个尴尬局面：数据确实存在，但它不在用户可理解、可导出的权利行使接口中。
第三个特点，是解释性压力。EDPB在第01/2022号访问权指南中明确指出，访问权的总体目标，是向个人提供“sufficient, transparent and easily accessible information”，使其能够知晓并核验处理的合法性。如果企业仅向用户提供一组高度压缩或前端筛选后的数据包，却把后端系统中的关键处理记录排除在外，用户实际上无法判断企业到底如何处理其个人数据，更无法进一步行使更正、删除、限制处理或反对处理等权利。
第四个特点，是可携权与访问权的交叉。本案DPC草案决定拟认定Meta违反GDPR第20条数据可携权。第20条关注的是数据主体以结构化、常用、机器可读格式接收其提供给控制者的个人数据，并在条件满足时将其传输给另一控制者。Hive数据未必全部落入可携权范围，但它与第15条访问权高度相关。对于平台企业而言，访问权要求回答“你处理了我哪些个人数据”，可携权进一步要求在特定条件下以可迁移格式交付部分数据。二者共同挑战的是平台将数据锁在内部系统中的能力。
本案由此提出一个非常具体的合规命题：企业不能用系统架构定义权利边界。GDPR第15条第3款规定，控制者应提供“a copy of the personal data undergoing processing”。这句话的重点不在“前端可见”，也不在“用户能否自行下载”，而在“正在被处理的个人数据”。只要后端Hive系统中的数据能够识别或关联到特定用户，并且仍在被Meta处理，它就可能落入访问权审查范围。
用户行权在本案中不是外围议题，而是整个案件的起点。GDPR第12条要求控制者以透明、易懂和易于访问的方式促进数据主体行权；第15条赋予访问权；第20条赋予可携权。DPC拟认定Meta同时违反这三项规定，说明问题并不只是“有没有给用户一个下载按钮”，而是下载按钮是否真实覆盖了用户依法有权获得的数据范围。
EDPB访问权指南对这一点说得很直接：控制者必须根据数据结构检索其所有IT系统和非IT归档系统中的个人数据，并且在数据量大、处理复杂时建立与复杂性相适应的机制。指南使用的表述是，控制者“will have to search for personal data throughout all IT systems and non-IT filing systems”。这正好击中了Hive问题的核心：平台不能把访问权接口只做在前端产品层，却让后端仓库成为权利行使的盲区。
从用户角度看，访问权不是为了满足好奇心，而是其他权利的基础设施。用户只有知道平台到底持有哪些数据、以什么目的处理、向谁披露、保留多久，才可能判断是否要求更正、删除、限制处理、反对处理，或者投诉监管机构。EDPB也强调，访问权的实际目标，是让数据主体控制自己的个人数据，并便利其行使其他权利。
从企业角度看，本案要求重新理解“行权产品化”。很多平台把数据访问工具设计成用户体验功能，例如“下载你的信息”“导出你的资料”。但GDPR语境下，这些工具首先是法定义务的履行通道。工具可以分层、可以解释、可以引导用户缩小请求范围，但不能把企业内部不易整理、不愿披露或难以解释的数据排除在法定访问权之外。
这也解释了为什么DPC的纠正措施可能不限于投诉人本人。如果Meta的数据访问工具设计对所有用户均采取同一逻辑，那么一个用户没有拿到Hive数据，并不是单点错误，而是访问权履行机制的系统性缺陷。监管机构要求企业整改整体数据访问实践，就不是越权，而是对同一违法机制进行结构性修复。
企业还应注意，行权响应的“完整性”并不等同于无限制披露。GDPR第15条第4款允许考虑他人权利和自由，第12条第5款也允许在请求明显无根据或过度时采取限制措施。但这些限制必须被严格解释。EDPB指南指出，Article 15(4)通常不应导致完全拒绝请求，而应尽可能通过遮蔽或删减受影响部分来处理。因此，企业不能把商业秘密、系统复杂、数据量大作为一揽子拒绝访问的理由。
声明：本文来自麻策的备忘录，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
