流动中的数据价值挖掘 V．S． 隐私保护

— 数据拥有者的控制力数据自由流动中的价值挖掘能让AI更好地发挥价值，但同时，数据流动过程中不经节制的应用，也会带来数据隐私侵犯的隐患。最近多个金融大数据公司遭到立案调查，从数据源的角度来看，其中一个重要原因就是该类公司的爬虫对触达的数据未经授权进行存储或超出了约定的使用范围。

举例来说，如果有一个 App 声称帮助用户进行多个金融账户进行管理并综合呈现个人现金流等信息，为了帮助 App 呈现这些信息，用户就需要提供这些金融账户的访问权限。但如果在这个过程中 App 对个人银行账户内的所有信息都进行了抓取和存储，并将这些信息提炼出来的标签出售给第三方或利用标签开展新的业务。由于这些过程未对用户进行告知并获得许可，都是一种对数据使用权的滥用。
从当下的工程实践来看，解决挖掘和隐私的两难，可能目前最好的解决方法是给数据拥有方一个控制力，包括对数据收集的授权和收集后保存和使用的控制。国际上普遍进行的实践或者规范（如GDPR）都倾向于对个人拥有的数据及其数据的各种上下文环境进行准确的授权。

比如GDPR中就会要求第一方数据要明确“自己采集到了哪些数据”，当用户有了这个明目之后，应当有权来选择“保留哪些删除哪些”；在此基础之上，还比如会要求对数据处理方法作出明确问询和授权，“比如通过采集到的用户点赞的帖子的内容和类型来学习用户的兴趣爱好”；这些兴趣爱好作为标签，虽然不是原始数据，仍然需要用户进行逐一的明确授权。

当我们通过给予数据拥有方控制力的方式去平衡数据价值挖掘和隐私保护，在实践中又会出现一个新的挑战——如何在不侵犯个人隐私的前提下，获得个人的授权。

举个例子，比如在获得兴趣爱好标签授权的时候不太可能有用户可以预先对近乎无限多的兴趣爱好进行一一授权，一般的过程也是首先由数据挖掘方获得了某个标签，再针对这个标签进行问询。

我们在过去的工作实践中见过的最好的处理方法是首先对多达三到六百万常用的兴趣爱好做知识图，将这些兴趣爱好的包含关系或者关联性整理出来；之后再对各类兴趣爱好通过找到包含关系中处于包含当前爱好的比较泛化的那类爱好进行问询这样点到为止的方式来完成。

即便做到这样，虽然消耗了巨大的资源并且有很高的门槛，也很难说做到了完美，因此也就不难理解多数公司在应对GDPR或者相关合规的问题上面临着巨大的挑战这个事实。

数据拥有者的控制力如何赋予？数据拥有者控制力的核心意义在于让每个拥有者在挖掘和保护之间选择自己的平衡点。为了给拥有者控制力，第一步要讨论的是谁是数据的拥有者这个问题。

一般对于个人数据来说，无论是个人的身份识别信息或者生物统计信息这样对个人进行描述的数据，还是用户的行为信息（比如访问了哪些app，在app里面做了哪些事情）或者由这些行为信息所得到的新的标签这样的用户生成数据，都会认为拥有者是这个人本身。

尤其对于产生的标签数据来说，有些情况下认为由于标签是比如数据采集方进行学习而得来的因此拥有者是采集方这个想法也不应该是被广泛认同的。

围绕拥有方是产生数据的个体这条线去思考，在整个数据生命周期链条里面就存在对第一方数据的控制、第二三方的控制等不同的问题。

对于第一方来说，由于是数据的采集者，涉及的方面也是最多的。Facebook在2018年的F8上宣布一个针对给用户控制力的功能叫Clear History，里面描述的愿景基本理解为可以允许用户在采集，存储和使用三个方面给予控制力。

首先用户会看到Facebook从哪些合作方渠道获得了用户的什么样的数据（采集可见），之后允许用户决定是否可以在广告投放中进行使用（使用控制），再次允许用户对这些数据进行立即删除的操作（存储控制）。

这个功能听上去简单，但实际上对于一个正在运转的机构来说，要涉及到鉴别所有的数据来源、在复杂的数据流里面识别各类数据、以及对某个数据的所有存储位置进行控制这几方面能力。对于小机构来说资源和投入产出比肯定是不够的，对于大机构来说由于内部数据流太过复杂，为了实现它往往会需要做整个系统的重新设计和实现，代价也不言而喻。

举例来说，为了实现Clear History：首先为了在几万PB的数据仓库中甚至更大的冷存储中找到所需要控制的数据，就需要做整个数据集的语义识别（很多时候由于表单的schema并不统一，所以直接使用metadata很难准确的判断数据类型），这个过程类似给数据打标签。为了可以覆盖更多的存储点，会需要根据已经得到的数据标签对数据流进行端到端的识别。当所有的存储点识别完成后，为了实现功能中的实时删除，还需要在重新定义数据结构的基础上配合一个高吞吐量的中心管理系统。

这个过程协调了许多内部部门，消耗了大量的资源，耗时一年以上。不难看出，在企业间的数据流通中也存在潜在的类似挑战。