金诺法谈 | 数据流通常见场景下的数据处理法律关系识别与授权案例

广义的数据流通包含场外和场内的数据交易。但其实大量的数据流通发生在企业日常业务过程中，比如APP/小程序和内嵌SDK之间的数据交互，公共数据授权运营中的数据授权等。本文拟结合我国现有数据合规与个人信息保护相关法律与合规性要求，通过两个典型场景案例，分析数据流通过程中容易被忽视的数据处理法律关系识别以及相关授权问题，并提出一些可供参考的思路。

1.APP或小程序开发者与SDK提供商之间的数据交互场景之数据处理关系识别

在我们的实务过程中，经常发现APP或小程序开发者在内嵌SDK时，仅关注业务功能的实现，遗漏双方数据流通过程中各自法律地位和权利义务的要求，也更不会签署任何协议，导致产品开发完成后，潜藏着合规与安全隐患。

例如，公众点开小程序后，在需要触发实名认证过程时，弹出电子签名系统SDK的页面，公众此时输入个人姓名、身份证号、手机号、银行卡四要素信息。用户完成实名认证过程后，返回到小程序页面，继续进入下一步操作，如线上交易。

以上流程中，小程序开发者往往忽视梳理如下问题，未能识别各方法律关系：

例如，是哪一方收集了四要素信息，进行了怎样的处理，处理结果的流向如何。表面上看，是跳转到电子签名系统界面后，用户提供的四要素信息，电子签名系统完成实名认证后，将认证结果推送给小程序经营者。小程序经营者根据实名认证结果启动下一步个人信息处理环节。此时，会有一种理解，即电子签名系统收集了个人信息，电子签名系统是四要素信息的个人信息处理者；小程序开发者是后续线上交易环节的个人信息处理者。这样理解的话，小程序开发者和电子签名系统是两个独立的个人信息处理者。

但实际上，仔细分析，似乎还可以构建为另一种理解：是小程序运营者委托电子签名系统收集个人信息，委托其进行实名认证，最终交付实名认证结果给小程序运营者。这样解释的话，小程序运营者和电子签名系统之间是个人信息处理者和受托处理者的关系。这种理解的关键点在于，“收集”行为本身也是一种“处理”行为，也是可以委托开展的。

以上两种业务逻辑的不同直接导致了法律关系构建结果的不同，双方对个人信息主体的责任负担不同，电子签名系统对小程序开发者所需要履行的义务不同。

如果企业在系统开发过程中仔细甄别数据流和数据交互双方之间的法律角色，即可对双方法律关系进行有利于自己一方的设计，避免在后续出现法律风险时因为双方约定不明而产生纠纷，致使合作陷入僵局，相关方无从有效主张权利。

2.公共数据授权运营场景下的数据法律关系识别与授权问题

A公司自主研发并投资建设了一款“远程抄表系统”,对外向供水公司提供SaaS模式的远程抄表服务，收取抄表服务费。业务过程中，A公司系统后台汇集了大量业务数据，包括每一家住户的业主姓名、身份证号、门牌号、电话，用水和购水情况，以及按照供水公司的要求实现的统计类和分析类结果数据。A公司计划将这部分数据进行数据资产入表，未来进行数据交易。

笔者认为，以上场景下，如果没有特殊约定，A公司基于对外提供信息系统功能性服务的角色所收集的各类数据，应当天然归属于供水公司。从应然角度理解，该类数据应当属于供水公司的业务数据；如果入表，也应当入到供水公司的表内而非A公司表内。

第二步，站在供水公司的角度，其所收集的原始数据，以及分析、统计后形成的衍生数据，如计划入表，如何去识别数据，是否这些数据全部都是公共数据，入表前需要企业开展哪些合规工作，是企业面临的第二个问题。

笔者认为，这些数据首先包含大量的个人信息，例如，户主姓名、身份证号、门牌号、电话，用水和购水情况等细颗粒度的原始数据。此类数据如果计划入表和进行后期数据交易，应当对超过提供供水服务目的之外的处理目的和处理方式（特别是未来计划如何开发新的数据产品，衍生哪类新的数据服务），明确告知这些用户，并取得其同意。同时，宏观统计性数据，特别是上报水务主管部门的汇报类、分析类数据，则偏向于公共数据属性，需要按照公共数据授权运营的要求和程序来取得运营授权，并基于运营授权范围进行产品化设计和入表。如果当地政府尚无该行业范围内的公共数据授权运营管理办法，则建议公司针对具体运营的数据范围向行业主管部门提出申请和进行报备。

总之，在类似上述场景中，公司有必要通过以上两个渠道，确保在公共数据授权运营领域和场景下，首先识别数据处理法律关系和数据归属，然后进一步深入识别数据类型和数据属性，取得入表和后续运营与流通所需要的各项合法授权。