百度田梅：智能网联汽车数据及个人信息合规困境

作者：田梅

作者：田梅 百度交易及合规法律部资深法律顾问

本文系田梅在2021数据与个人信息合规论坛汽车行业分会场上的演讲内容，Acelaw法培学苑进行了不改变原意的编辑、整理。

大家好，我是田梅，来自百度交易及合规法律部，目前服务于百度的智能驾驶事业群，为其提供日常的法律支持。百度智能驾驶事业群的业务领域主要包括自动驾驶、智能交通、车载导航地图等应用、车载信息系统及其安全防护，因此我们非常关注智能网联汽车及相关领域的数据立法和合规动态。感谢主办方给我们这次机会进行主题发言，和法律界的同行们共同就汽车行业的数据相关问题进行讨论。

我本次发言的题目是《智能网联汽车数据合规困境》，主要分享我们对相关数据类型的认识，以及目前工作中遇到的一些合规困境，最后会简单说一下我们的建议。

一智能网联汽车数据类型

先来看一下我们目前认为的智能网联汽车可能收集或产生的数据类型。

首先是车辆相关的数据，包括车辆各部件的数据，如发动机、电动机、变速箱、座椅配置、灯光配置等数据，还有自动驾驶相关硬件软件的数据，车辆外部的数据，例如路面标牌、行人的数据。带有车载导航功能的车辆，还涉及 GPS定位数据，车辆轨迹数据，以及服务于自动驾驶功能的高精度地图，或称测绘类数据。

另一大类是跟用户相关的数据。用户使用车辆时主动提供或产生的数据，包括用户使用车机系统中各种功能而产生的数据。比如用户提供的手机号等身份信息、使用车载娱乐信息系统时产生的行为信息、使用语音控制功能发出的语音指令、使用面部识别或者是疲劳监控功能时被采集的面部图像信息。我们认为，这两类数据存在一定的重叠。车辆禁止状态下产生的数据是十分有限的，只有由用户使用才会产生数据。以上应当算作是用户数据。

目前有些车辆都已经具备了IOT的功能，它会实现一个多端的互联，可能因为为了实现车与家中智能设备、汽车与手机互相控制，而共享传输数据并产生新的数据的情况，这种情况是否会对数据的这种分类分级产生影响，或者是否会对数据的权属确定产生影响，还有待进一步的讨论。

二实操层面合规困境举例

针对以上提到的，我们大致可以识别出数据合规的具体领域，包括测绘安全、个人信息、数据传输安全。

01 测绘合规

首先是测绘合规方面的困境，众所周知，服务于自动驾驶的地图精度超过一般的电子导航地图，是不符合目前的监管要求的，因此仍处于测试阶段，不能商业化使用。目前是允许测试地图进行审图的，但是审图的流程和标准需要一事一议，对于企业来说时间和物质成本都是比较高的。

此外，高于一般电子导航地图精度的数据，或者是一般电子导航地图没有的数据元素，在目前的智能驾驶汽车上有较多的可用空间。例如利用车道线数据来辅助驾驶，这些数据并非完整的地图数据，是否也需要进行审图？是否有相应的流程支持？如果不需要的话或者是没有相关的流程，那么该类功能仍可能存在潜在的违法风险。这对自动驾驶技术的发展和相关产品的商业化将造成一定的阻碍。

02 个人信息合规

我们再从个人信息的角度看一下。首先，目前没有专门针对汽车行业的个人信息收集、使用、存储、共享等数据全生命周期的相关法规和标准，合规工作就没有一个明确的指引。在指导产品做设计的时候，我们作为企业的法务也经常左右为难，一边是企业的商业利益，一边是合规风险，该如何权衡呢？

目前针对手机端移动应用程序的执法是比较频繁的，各监管机关都出台了一些细化的标准，比如我们熟知的网信办的191号文，工信部164和337号文，以及四部委前一阵子发布的常见类型移动互联网应用程序必要个人信息范围规定，虽然有一些九龙治水，但对于移动应用程序的合规设计还是有较好的指引。但在我们智能汽车领域却没有类似的文件，或者是监管标准。我们在日常工作中就经常要问自己，我们应该遵循哪些原则来指导产品的个人信息合规设计，是否应当按照移动互联网应用程序的相关规定来做合规设计呢？

如果将来出台的针对智能网联的特殊规定，是否会和移动应用程序的相关规定，或者是国家的推荐性标准，个人信息安全规范中的内容有不相一致的地方？如果不一致的话，怎么从产品技术的角度保证将来能够迭代？如果做不到的话，我们现在是否应该喊停？和手机移动应用程序的开发周期相比，汽车行业的产品诞生周期都会比较长，此时设计的车机系统可能计划上市是在一年之后，比较难判断未来的合规标准。

此外，汽车行业更关注产品系统的稳定性和安全性，频繁的迭代不是汽车行业的通常做法，届时可能没有办法像移动应用程序那样整改得那么快，并且迭代可能也需要多方的参与进行技术调整或确认。一方的合规问题可能需要其他多方的配合，才能达到整改机关要求的标准，因此总的来说整改难度是比较大的。

另一个问题是关于合规主体确定的问题，汽车产品是由主机厂和许多供应商共同完成的，参与方众多。在个人信息合规方面也同样涉及这些主体，包括主机厂和他们的销售公司，他们有车主的信息、车机供应商、车机内线的功能或者是应用的供应商，进入车机控制的各种零部件的供应商，软硬件集成供应商。用户在使用特定功能时，这些供应商就可能会采集用户的个人信息以提供服务。

目前比较明确的是车机系统内的独立应用的合规主体，应当就是应用的运营方，用户感知到的服务也是由其提供的。比如车机内的百度地图，这个产品的个人信息的合规责任主体就应当是由百度地图的运营方来承担，类似手机移动应用程序合规的情况。实际上，汽车上的产品形态往往比较复杂，To C呈现出来的形态虽然统一都为一个汽车产品或者是一个车机系统，但背后可能是有无数个类似百度地图这样的第三方应用、众多小程序、娱乐资源的聚合应用以及车机系统共同组成而成的，那应由谁来承担？

除了前面说到的独立第三方应用外的个人信息合规责任，在有的项目中，车企将整个车机系统定位为自己的车机系统，有自己的系统品牌，车企对整个系统承担合规责任，再根据合作协议来划分各方的合同责任。

在另一些项目中，车企没有车机系统产品的定位，可能就是由车机系统供应商来承担，但是有的车机系统供应商也没有这种品牌意识，他只把自己定位为这种系统的技术开发供应商，或者车机系统的供应商，它只作为集成的角色。

还有一些情况，车机系统供应商需要在自己的产品上，按照车企的意志接入其他供应商提供的功能，那车机系统供应商似乎也不适合单独承担整个车机的个人信息合规责任。

此外还有的项目上，车企对这种品牌的露出控制得是比较严格的，不允许供应商露出自己的品牌。一方面，用户就不会知道是谁在提供服务并收集信息，另一方面也直接影响了实际提供服务方履行合规责任的积极性。多数情况下，车企客户也不会认为自己应当承担这种个人信息合规责任。没有这方面的产品设计安排，最终可能导致没有主体承担个人信息合规责任。受损的可能不只是用户的权益，还包括两家企业的这种品牌形象。

我们认为应当按照具体的功能去识别，露出品牌的To C服务提供方，也是数据的实际的控制方，应当是履行合规责任的主体，但是按照这个标准操作存在打扰用户的问题。一台汽车中存在多个合规主体，履行具体的合规义务，单从获得用户同意这个角度看，每个服务提供方都会在自己的应用或功能内单独获得用户同意，那么用户就需要点击多个同意按钮，或者关闭多个弹窗，用户总是被打扰，一方面是用户体验差，另一方面还可能影响行车安全。此外，作为单个功能或服务的供应商，即便想做一些最合规的操作设计，也存在客户不同意的情况，落地比较困难，我们在一些项目上也曾遇到这种情况。所以，回归到第一个关于个人信息合规的困境，我们还是期待汽车行业的法规和标准尽快出台，指引企业进行合规的工作，厘清各方责任，保护用户个人信息，也推动产业的发展。

03两份文件的出台

今年五月，网信办公布了《汽车数据安全管理若干规定（征求意见稿）》（下称：《征求意见稿》），信标委也公布了《网联汽车 数据采集的安全要求（草案）》（下称：《草案》）。我们认真阅读了前述文件，在这里谈一下我们的看法。

这两份文件的发布是非常及时的，能够给企业后续合规工作带来指引，但其中的一些规定确实在可操作性方面存疑，可能对商业活动的灵活性和智能网联汽车的快速发展带来挑战。

首先谈一下《征求意见稿》倡导的车内处理、禁止向车外传输的原则。如前所述，智能网联汽车采集的数据，包括车辆本身的数据、车外数据、用户数据，如果倡导车内处理原则，与目前的产业发展情况、技术发展趋势不太一致。针对车辆本身数据和车外环境数据，国标《电动汽车远程服务与管理系统技术规范》里面明确要求，车载终端要具备将采集到的实时数据发送到企业平台的功能，公共平台从企业平台获取车辆行驶、充电等运行数据，进行监管和相关数据的分析。

此外，新基建产业的车路协同技术的发展，也要求最大化地利用云端，路测的设备算力，解放车端、降低车端的成本。数据在车端和云端会有大量的传输，从存储角度，产业趋势是云端存储优先。针对用户数据，同样是基于目前的技术发展趋势，许多数据的处理都是在云端进行计算和完成的，势必存在数据向车外传输。前面提及的IOT场景，功能的实现更是依赖车辆与外部IOT硬件之间的数据互传。如果一刀切地禁止向外传输，对万物互联的产业愿景也会有不小的影响。

如果从技术角度可以解决数据传输、计算和存储时的安全问题，并且，当数据权属确定，我们认为也不会因为向云端传输数据，或者是将数据存储在云端，就会让权利人的权益受到影响。如果数据主体的权益都能得到必要的保护，我们认为就没有理由要求数据必须在车内处理，并禁止向外传输了。

第二点也想讨论一下《征求意见稿》里倡导的每次同意、每次同意授权，且仅对每次驾驶行为有效的原则。这种方式和我们常见的一次授权长期有效的操作是存在比较大的差异的。实践中经常出现驾驶人可能只是短暂离开驾驶席的情况。这种情况类似于我们暂时地退出了软件，如果只对本次有效的话，是否意味着之后再进入就要彻底重启，再次同意一遍相关的文本，这样一来，可能存在每天开车的时候，需要点好几次弹。这种频繁取得授权，对驾驶体验以及驾驶过程中带来的影响，还需要进一步讨论。我们认为这个规定可能是考虑了公共出行、租赁场景以及将私人车辆借给他人的情况。

每次同意确实可以保证前一驾驶人的个人信息安全，这是值得肯定的。但除了这些情况之外，确实不太符合目前的用户操作习惯。我们建议，立法者在设计合规原则的时候还是应当从立法目的出发来考虑。具体获取同意的方式以及效力期限，应当结合具体的场景来设计。如果是公共出行或者车辆租赁的场景，应当考虑众多驾驶人的情况，采取一定的保护措施。例如，强制登录账号后使用；驾驶结束后强制登出账号。通过账号识别驾驶人，比如公用电脑上有多个账号，用户是用自己的账号登录使用电脑，个人信息也是可以得到很好的保护的，但如果是私人领域使用，则可以考虑参考手机端目前的策略，保持一次授权，长期有效的方式。

第三点想讨论数据处理目的限制。目前《征求意见稿》是将目的限定为与汽车的设计、服务、制造直接相关，如果生效的话，则可能对AI产业的发展造成限制。AI产业的发展重要前提之一就是基于生态布局来获取大量的数据，收集、归纳训练模型，迭代技术，以及通过大数据的分析促进各种传统产业的发展。通过车辆获取的数据类型多样，不仅仅是与车相关，还包括许多用户数据，对于这些数据的处理应用，不应当仅仅局限于汽车的设计、制造与服务，这些数据的价值远超于此。我们了解到，许多车企客户都需要对自己的用户或者潜在的用户数据进行一定的分析，精准判断出他们的需求、偏好，匹配更好的产品和服务，提高销售业绩。在车路协同领域，许多数据的处理目的都是提高或者优化政务管理，例如进行拥堵的分析、停车分析、交通巡检执法、高速路养护等。上述这些举例，数据的处理目的，可能不是和汽车的设计、制造和服务直接相关的，按照目前的《征求意见稿》，上述这些处理活动可能都是要被禁止的，这样的话对上述产业的发展都会造成限制。

三 建议

最后想简短提几点建议，作为本次发言的总结。

首先，要对私人使用和公共出行及租赁场景进行一定的区分，进而设计不同的合规原则，采用不同的合规标准。

第二，建议明确识别并定义智能网联汽车场景下与数据相关的主体及其角色，针对性地设计相应的合规责任。

第三，在设计规则的时候，要兼顾数据安全管理、个人权益保护和产业发展。

第四，考虑汽车行业的特殊性，创新地设计合规原则和标准。

最后，一定要考虑用户体验。

以上就是我的主题发言，谢谢！