文/麻策律师
在中国企业全球化路途上，正发生越来越多“针对”中国企业的数据合规处罚案例——其中，违规实施跨境数据传输最令中国出海企业头疼。
2025年5月2日，爱尔兰DPC就TikTok“违规向中国实施跨境数据传输”调查事项，宣布对TikTok罚款5.3亿欧元，并责令其采取纠正措施。
而在此前，2025 年 1 月 23 日，韩国个人信息保护委员会公布处罚决定，以未经授权将个人信息转移到海外为由，对违反韩国《个人信息保护法》的 Kakao Pay Co.，Ltd.、Apple Distribution International Limited 和 Alipay Singapore E-Commerce Private Limited 处以总计 83.75 亿韩元（约合 583 万美元）的罚款，其中受托处理者Alipay Singapore E-Commerce Private Limited被责令销毁未经同意利用用户信息构建的NSF评分计算模型。
而在更早的2025年1月16日，欧洲数字权利中心（noyb- European Center for Digital Rights）就TikTok、AliExpress、SHEIN、Temu、WeChat和xiaomi六家关联中国的企业，“违规”向中国传输数据的行为提起了GDPR 投诉。投诉称这些中国关联主体的相关运营公司“将个人数据传输到中华人民共和国，但是由于该国缺乏足够的数据保护水平，因此违反了GDPR关于跨境数据传输规则。"
“远程访问”式跨境传输
在复杂的跨境传输合规安排上，虽然本地化正成为越来越多出海企业的首选，但从已有的处罚案件来看，最重要的合规安排仍然是“人心中的成见”——基础概念的混淆不清导致认知失效。
例如，在爱尔兰TikTok案件中，TikTok坚持抗辩称“通过远程访问传输不受相关法律和惯例的约束”，爱尔兰DPC坚持认为这是一种错误理解。
EDPB在2023年版《关于跨境数据传输指南》中认为：“GDPR 没有对‘将个人数据传输到第三国或国际组织’的概念提供法律定义，这导致对源自法律的确切义务范围存在不确定性。”但是，EDPB在该版指南中已经明确从第三国进行远程访问（即使仅通过在屏幕上显示个人数据进行，例如为了故障排除或出于管理目的）的行为，视为跨境传输。
虽然爱尔兰TikTok案件的处罚事实可能限于2020年7月29日至2022年12月1日期间的违规行为有关，但直至2025年处罚前，TikTok仍然施以积极地抗辩，但在有明确指南条件下，其仍然以“通过远程访问传输不属跨境传输”的原因，着实令人捉摸不透。
除了“远程访问”式跨境传输，以下行为也仍然可构成跨境数据传输。
例如，为境外数据处理者开通账号供访问数据库、单纯将数据存储在云服务提供商提供的境外云服务器中、将数据直接存储在位于另一国家/地区的服务器或数据中心、境内控制者指示处理者向特定境外子处理者传输处理（不包括境内控制者的处理者独立委托境外子处理者处理）、通过电子邮件或邮寄方式将纸质（或手写）或电子文档或包含个人数据的任何类型的记录发送到其他国家/地区，境内公司使用境外母公司统一实施的人力资源服务时将境内员工数据上传至该服务系统中，等等。
值得注意的是，实施跨境传输行为的数据控制者或处理者没有特殊例外，即使其是法院司法机关，也难得豁免。根据欧盟判例（ Bindl 诉欧盟委员会 ，案件 T-354/22），2025 年 1 月，欧盟普通法院命令欧盟委员会向一德国公民支付 400 欧元的赔偿金，因为该法院在没有适当保护措施的情况下，将通过其网站上的“使用 Facebook 登录”选项注册网站会议的个人的 IP 地址非法传输到美国的 Meta 平台，这是欧盟法院首次对因违反国际数据传输规则而造成的非物质损害进行赔偿。
同样值得注意的是，并不是仅基于“同意”合法性基础的属于跨境数据传输，基于其它合法性基础的数据处理活动也可归入跨境数据传输，例如“基于合同”、“人力资源管理”、“根据法律法规”而实施的跨境数据传输行为。
我国《个人信息保护法》第二十三条规定了“个人信息处理者向其他个人信息处理者提供其处理的个人信息”，对“对外提供”行为进行了定性，该法第三章中，对个人信息跨境传输行为也使用了“提供”概念。笔者认为上述两者定义的内涵和性质完全不同，不能混用，将可能导致“基于合同”、“人力资源管理”、“根据法律法规”处理等其它合法性基础下的处理行为，
“跨境数据传输”的例外
虽然有很多示例说明何种行为构成跨境数据传输，但很多示例也从反面进行了跨境数据传输的排除。
比如，个人数据仅只是单纯地从境外国家进行路由中转的行为不属于跨境数据传输，英国ICO在其《A guide to international transfers》中明确对此行为进行了排除。但请注意，路由中转和在境外国家进行存储的行为的性质并不相同。例如，从中国发往美国收件人的电子邮件可能会通过爱尔兰进行路由中转，而美国的服务器不会访问或修改电子邮件的内容，此属于路由中转。
我国《促进和规范数据跨境流动规定》第四条规定：”数据处理者在境外收集和产生的个人信息传输至境内处理后向境外提供，处理过程中没有引入境内个人信息或者重要数据的，免予申报数据出境安全评估、订立个人信息出境标准合同、通过个人信息保护认证。”此条实质上就是针对跨境数据路由行为的明确，而可惜的是，此条是明确“免予”申报，而不是“无须”申报，两者似乎仍存一定差异。
与此类似的场景似乎还有很多，比如位于马来西亚的智能网联汽车销售商为其用户开启车联网认证时，将用户车辆VIN码上传至欧洲经济区进行验证后传回。位于泰国智能网联汽车用户使用数字车钥匙时通过欧洲经济区中的TSP云向车端下发开门指令。此类仅自动化过境的数据，如果不在境外云服务端进行保存或其它处理，则是否也可被认为属于非跨境数据处理行为？
另外，当欧盟境内数据控制者的员工海外出差时访问欧盟境内数据控制者服务端数据，或者中国企业的外派员工在欧洲经济区内进行智能网联汽车路测后将数据直接回传至中国（该企业在欧洲经济区没有企业处理者）的情况下，按理也不存在跨境数据传输行为。
“数据直采”行为的定性
“没有控制者或处理者向另一个控制者或处理者发送或提供数据”，即当数据用户主体直接向境外接收者披露和提供个人数据时（“数据直采”），也未涉及到跨境数据传输问题。
EDPB在2023年版《关于跨境数据传输指南》中也明确了数据直采的非跨境传输性质：“In addition, this second criterion cannot be considered as fulfilled when there is no controller orprocessor sending or making the data available (i.e. no "exporter") to another controller or processor,such as when data are disclosed directly by the data subjectis to the recipient.”
除此外，英国ICO以及韩国PIPC都对此类数据直采行为的定性进行了明确。
例如，韩国用户为了使用Google、Meta、AliExpress等海外服务，向海外企业提供姓名、住址、电话号码、电子邮件地址等个人信息，即外国企业直接收集韩国国内数据主体的个人信息时，不属于韩国《个人信息保护法》规定的个人信息“跨境数据转移”。
在中国“个人信息出境标准合同备案”中，我们常常发现，虽然境内处理者有意和境外处理者签署DPA，但苦于境内或境外一方，其实可能存在“没有签约主体”的情况，令人尴尬。笔者希望实施跨境数据的处理者，可以勇敢些，拒绝此类场景中，进一步的评估和备案行为。
笔者认为，之所以跨境数据传输需要受到更严格的国内法约束，核心原因并不是所谓的出于“数据主权”考虑，而是考虑到，在国家境内收集的个人信息在跨国转移到境外国家时可能无法得到与国内同等程度的保护的风险，境外数据处理行为并不受境内法规的管辖。
而之所以数据直采不属于跨境数据传输，是因为不论什么国家，均将域外数据处理者处理境内用户个人数据，直接认定作为国内个人信息保护法的规制对象。例如，我国《个人信息保护法》第三条第二款明确“在中华人民共和国境外处理中华人民共和国境内自然人个人信息的活动……也适用本法”，根本无须基于跨境数据逻辑进行监管。以上规定和GDPR的域外管辖逻辑完全一致。
之所以大部分研究人员，以及包括笔者在内的数据合规实务人员仍对“数据直采”行为存有些定性疑虑，核心原因仍然是中国从未有过对上述《个人信息保护法》第三条适用管辖条款的激活启用，所以将“数据直采”纳入跨境数据传输体系，似乎显得更加稳妥。
只可惜“落花有意，流水无情”，类似于无意在海外特定国家运营的DEEPSEEK一样，意大利等域外执法机构已经从监管层面开始，针地中国企业激活管辖条款了。
中国的全球数据监管解法，却还没有开始。
需要注意的是“数据直采的例外场景”是，如果境外控制者或处理者向境内直采用户数据后，再将所直采的数据“提供”给境外其他控制者或者处理者，则该境外控制者或处理者的行为却又将符合跨境数据传输行为。文首中韩国个人信息保护委员会针对Kakao Pay跨境数据处理的案件，就是明证。
进一步要不被绕进去的合规思路是，即使不属于跨境数据传输，但跨境数据处理行为仍然要确保符合中国以及各国规则。例如，基于同意的个人信息跨境需要实施单独同意，等等。
跨境数据行为的认定，一句咒语记住：“境内有‘人’，境内咱也有‘人’，中间有提供”。
声明：本文来自互联网法律匠，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
