发言人 : 李昳婧，小米公司 数据隐私法务
大家好，我叫李昳婧，来自小米公司。我今天分享的主题是《通用数据保护条例》 也即GDPR的合规与实践。作为一部旨在于保护个人信息的法律，GDPR对全球隐私整改的推动力是空前的，即使不是数据隐私领域的从业者，对GDPR可能也不陌生。比如，今年5月25日GDPR生效前10天内，一位经常使用海外服务的用户，就收到了12家公司通知它更新隐私政策的邮件，其中有10封邮件直接提到GDPR。
GDPR对在场观众朋友的影响就更大了，今天大会一半的主题都聚焦数据保护与安全。还记得去年第一届实务大会上，20位嘉宾中选题是数据隐私合规的只有两三个，其中就包括我们小米的朱玲凤律师。小米始终重视个人信息的保护，所以这次大会我们很执着地坚持数据隐私这个主题。我的出席表示了小米对用户隐私的重视，但我的发言仅代表个人观点。接下来我会分享下GDPR合规与实践中的一点点思考，先对GDPR概况做简单说明，然后从公司业务中常见的收集、分享两个需求场景，谈下如何落实GDPR的保护原则。抛砖引玉，欢迎大家多提宝贵意见。
作为欧盟统一立法，GDPR具有直接效力，可以说是现行数据保护水平最高的法律。GDPR引人关注的原因，一句话概括就是：罚得多，管得宽，管得严。
罚得多体现在：严重违反GDPR的情况下，罚款最高可达集团上财年全球营收总额4%或两千万欧元。
管得宽体现在：
首先，在适用范围上，即使企业在欧盟没有实体，只要为欧盟地区用户提供产品和服务收集、处理用户数据了，也会受到GDPR的管辖。举个例子，一个公司开发一款统计打点的sdk，放在开放平台供开发者接入，如果被集成用于向欧盟用户提供服务，GDPR需要适用。
其次，个人信息的范围更宽了，与已识别或可识别的自然人相关的任何数据。具体来说，可分为身份及鉴别信息，服务内容信息，服务产生的记录如点击行为、浏览记录等信息。一些设备相关信息也可能属于个人信息，例如cookie/ip/imei/日志等。
管得严体现在：设立更多的监管事项，提出了更高的透明度要求。比如
ü 新增隐私保护原则
ü 增加设计隐私和默认隐私原则： 设计产品时从隐私角度考虑，默认情况下仅只有某个特定处理目的所必要的个人数据被处理。
ü 隐私影响评价(PIA) ：当处理可能对用户权利和自由带来高风险时，处理前评估处理可能带来的影响
ü 新增被遗忘权和数据可携带权等
ü 要求企业设立数据保护官（DPO），由拥有数据保护方面法律和实践知识的人去担任DPO处理隐私问题。
ü 强化对未成年人的保护。
ü 用户同意更难获得了，对于依赖用户同意作出的处理，同意应当是自愿给出的，明显区分其他事项、明确而坚定的。同时企业应当提供撤回同意的方式，撤回同意还应当和用户给出同意一样简单。
ü 一些必须告知用户的内容，需要以修订更新隐私政策对方式予以公开。
ü 数据泄露后，需要在72小时内报告监管机关以及不应延迟地通知受影响的个人。
这一页列举了个人信息的处理原则。重点强调两点原则，最小必要原则和可问责原则。
最小必要原则指个人数据的收集/处理应当是为了实现数据处理目的而适当、相关和必要的。举个例子，一款仅根据所在城市提供天气展示服务的应用，其实没有必要读取用户GPS权限获取精确地理位置，苹果手机的天气功能，就采取了由用户手动选择地区，不默认读取精确位置权限的实践。
可问责原则指控制者有责任遵守上述所有原则，并对此提供证明，这意味着企业需要充分践行GDPR原则要求，否则如无法提供充分合规证明，可能会承担不利的后果。
以下从公司业务常见的两个需求场景与大家分享下合规思路及实践。
首先是数据收集场景：
业务计划新开发一款APP，希望收集用户生日信息，需要法务评估风险，隐私影响评估可以按照以下五步进行：识别法律风险——核实法律要求—明确合规难点——梳理处理思路——出具应对方案。
第一步，识别法律风险：
收集生日信息是不是只要弹窗告知用户获得用户同意即可？一般情况下，生日信息由年月日构成，如果收集的生日包括年份，那就意味着企业具备了知悉用户年龄的能力，进而需要对识别出的未成年用户提供保护。但目前多数企业针对未成年人保护原则，应对策略往往是在隐私政策中陈述：“我们不收集未成年人信息、不针对未成年人提供服务”。此种情况下，如果企业新增采集带有年份的生日信息，企业不能规避对于未成年人的保护责任，否则隐私政策存在自相矛盾之处。
第二步，核实法律要求：
GDPR规定：“当儿童不满16周岁，只有当对儿童具有父母监护责任的主体同意或授权，此类处理才是合法的。”即收集未成年人的信息需要获得其监护人的同意。
“对于年满13周岁的情形，成员国的法律可以降低年龄要求。”即各成员国对于未成年人年龄的规定可能不同。
“控制者应当采取合理的努力，结合技术可行性，确保此类情形中对儿童具有父母监护责任的主体已经授权或同意。”即对于确保上述合规的责任需要企业去担负。
第三步，明确合规难点：
① 如何获得未成年人监护人的同意，如何确保做出同意的人是监护人，而不是其他没有能力、身份不适格的人做出的同意？GDPR没有给出机制，只是赋予协会以及其它代表某类控制者或处理者的实体给出行为准则的权力，但目前还未见明确规范。
② 各成员国年龄线可能不同。如果企业是一套服务销往欧盟成员国中多个国家，在设定机制时需要选择一个合适的年龄界线。如果年龄线较高，可能会加重合规成本，如果年龄线较低，可能会导致在某些国家不合规。
③ 企业如何做算尽到合理努力？
第四步，梳理处理思路：
① 核实对生日信息需求的合理必要性。
业务反馈产品需要维持用户粘性，为了提供关怀类的运营活动需要收集生日，那么其实月日即可满足，砍掉年份，收集不包括年份的年龄，即可不给企业增加不必要的合规负担。
如果业务说开发的是运动类APP，年龄会影响卡路里值等数据的计算，那么可以询问业务，能否不收集未成年人信息，不为未成年人提供服务，同时根据数据最小化原则，针对16周岁以上的用户提供服务，如果只收集年龄段也可以提供服务，那么尽可能不要收集精确的年龄信息。
上述处理思路，从法律角度是对合理必要原则、数据最小化原则的实践，从商业角度，本质上是需求收益和合规成本的平衡，在合规成本较高的情况下，需求收益较低时可能需要为合规让路
② 什么情况必须要做合规。
首先，产品目标群体就是针对儿童的，如儿童手表、儿童频道，业务与儿童强相关，很难用不收集用户年龄的表述来规避合规责任。
比如最近youtube的例子，2018年4月，由23家团体组成的联盟组织向美国联邦贸易委员会提交一项投诉，称YouTube收集未满13岁用户的个人数据并据此推送广告，涉及非法牟利。YouTube主站尚未建立有效审查过滤未满13岁儿童用户的机制，其服务协议称不意图为13岁以下用户提供服务，如果用户低于13岁请不要使用其服务。但投诉youtube的联盟认为，YouTube 在通过服务条款逃避法律责任，虽然称仅为年满13岁的用户提供服务，但网站上可以看到大量儿童内容，儿童直播是最受欢迎的内容之一。
因此对于此类情况，未成年人用户的保护是企业逃不开的一种责任，那么确定哪些用户是未成年人的机制建立非常关键。
其次，产品已经收集了年龄信息，知悉有存量未成年人用户，该部分数据的收集是不合规状态，需要补充机制追加授权。
第五步，出具应对方案：
一种是回避式的方法，例如Twitter，在2018年5月25日GDPR生效当天，基于用户的出生日期暂停所有注册时未满13周岁用户的账户。
应对式的方案，参考美国FTC给出的指引和一些行业惯例，目前有以下四大类：
方案一：监护人签署同意书，即由监护人签署同意书，通过传真、邮箱或电子扫描方式邮寄给公司。这种方案企业实践成本最小，避免过度收集信息，企业某种程度上避免直接验证的工作，由给出同意的主体来对给出的承诺负责。但存在的问题是，做出同意的人是不是法律上适格的监护人，企业仅接受同意书是否属于尽到充分义务？
方案二：提问父母。使父母与专业人员拨打免费电话/视频会议
使父母回答一系列以知识为基础的、对于父母之外的人很难回答的具有挑战的问题。这种方案存在的问题是建立在公司对儿童有充分的了解，时间成本较高。
方案三：审核证明文件
如，让监护人使用信用卡、借记卡或其他在线支付系统等可以向账户持有人提供每笔单独交易的通知的系统。这种方案实践中可以是指定账户由该确认人在特定时间内完成一笔小额支付，借助银行体系，证实该确认动作是具有民事行为能力的成年人完成的动作，避免第一种方案中做出的同意是未成年人进行的操作。
类似的实践包括，由监护人手持驾驶证拍照上传，通过人脸识别技术进行对比。
再如，让父母提供政府颁发的可在数据库中查询的ID复印件，更直接地，要求提供能够证明亲子关系的文件，完成认证程序后删除认证记录。
这种方案的优势是明确是成年人在做出同意的行为，但应该注意避免采用过度侵犯式的方式，例如直接收集信用卡的详情，或者验证后未立即删除，反而触犯了GDPR数据最小化原则的要求。
方案四：和一些供应商合作。
需求催生产业。企业可以和一些能够提供父母同意供应商（如儿童保护在线Child guard online）合作，完成验证环节。 一种比较不错的实践是微软，采用了同意书+信用卡支付的方式。
总之，具体采取什么方案需要针对公司业务场景，结合可用到的资源，在不触犯GDPR原则的前提下完成闭环，充分尽到企业可尽的义务。
第二个业务场景是数据披露，业务运行过程中不可避免与第三方进行数据往来，一方面产品和平台不是孤岛，需要丰富的业务场景以吸引用户提升用户体验，有时用户也希望能将一些个人信息直接授权给第三方公司，更便利地享受一些服务，GDPR的宗旨之一也是推动用户数据的自由流通。
这里存在一个问题是：数据分享给第三方时，企业需要做什么，是否获得用户授权即可规避分享环节中存在的风险？GDPR本身没有对此明确规定，处于留白状态。
最近曝光的FB与剑桥公司的案例比较典型，FB其实做出了用户授权，但作为数据开放平台的FB，2014年授权分享管理存在漏洞，第三方应用可以在用户同意时，拿到其好友联系名单，同时也能拿到好友的详细信息，这其实不是新闻所提到的数据泄露问题，而是FB未承担好平台管理责任，也不符合GDPR倡导的设计隐私原则，即在产品设计时未充分考虑用户隐私，毕竟用户通讯录好友的详细信息，本身也是用户好友的个人信息，分享时不应当是无限制的。
FB更新后的隐私政策，变化在标红处。限定了分享内容：即仅包括名单但不包括好友的其他信息；明确己方和接收方的责任，告知用户接收方收集的信息不受FB隐私政策的约束；加强平台的控制性，下一个版本将限制分享的内容，并明确了分享周期，如果用户在三个月没有使用开发者应用，FB将取消该接收方对用户数据的访问权。
一般的分享过程需要关注以下几点：
分享前：
1.核查接收者保护水平，数据接收方是否能为所在地区用户提供符合当地要求的法律保护水平？
2.与接收者签订数据保护协议，增强对接收者使用数据的限制，要求享有审计权。
3.明确数据分享情况
如分享方式，是开放接口调用，还是限制性调用，还是直接数据复制及存储；
如分享频率（或者接收方的数据访问调取频率）：是每日每周每个月？访问频率是否偏离正常调取逻辑，如果异常是否采取应对机制。
其他要明确的还包括保留时长、存储地点、安全机制、删除机制等。
分享时：
1.明确分享内容
2.记录用户授权动作和内容
3.在授权范围内分享数据
4.明确平台中立身份
分享后
1.定期审计和巡查数据访问调取的安全运转
2.配合实现用户权利，进行通知。
3.提供允许用户撤销的机制
一个不错的实践是支付宝目前的授权管理。
世界杯期间竞猜时，第三方提供的彩票服务需要用户授权一些信息，比如产品界面上明确了授权内容，要求用户确认支付宝的用户授权协议（其中明确了中立支付宝是中立第三方的身份），平台记录了用户授权的动作。
授权期间方面，用户可以在设置-账号管理-账号授权中查看授权过的内容和状态。支付宝比较贴心的做法是将授权时间和活动期间保持一致，即一个月（对比其他产品的授权，一般默认是一年），这也是设计隐私原则的体现。
用户撤销权利方面，支付宝提供了撤销的选择。芝麻信用做得更进一步，在授权界面明确提示了用户解除授权对用户产生的影响，并给出了建议：用户在停止服务后再解除授权。
GDPR本身是很新的法规，还有很多留白之处，但也是个很好的契机，让我们在实践中更好地思考如何保护用户隐私。
声明：本文来自网络法实务圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
