虚拟语音助手VAA中的常见隐私风险，以及合规设计

根据欧盟数据保护委员会的定义，VAA（Virtual Voice Assistant)虚拟语音助手是一种服务，可以理解语音命令并执行这些命令或在需要时作为与其他 IT 系统交互的媒介。Reviews.com关于Voice Assistant是这样定义的“它们是您与所有连接设备之间的通信点”。与VA相关的概念包括以下几种：
智能个人助理：能协助人们完成基本任务的软件，通常使用自然语言。智能个人助理可以上网并搜索用户问题的答案。文字或语音都可以触发行动。
自动个人助理：这个术语是智能个人助理的同义词。
智能助理：这个术语通常指的是可以通过使用智能扬声器来提供各种服务的具有物理形态的一类产品，这些智能扬声器听到唤醒词就会变得活跃并执行某些任务。亚马逊的Echo、谷歌的Home和苹果的HomePod均属于智能助理。智能助理的特定在于通过独立的物理外在形式存在，比如智能音响。但是这个特定的边界在技术和法律上似乎意义不大。手机上的VAA服务通常被视为独立于设备的VAA软件，以为手机上承载了更多的功能。现在，儿童使用的智能手表大多配有SIM卡，其功能相当于手机。但因为智能手表显示屏功能较弱，很难说清楚它承载的VAA服务是基于物理实体还是作为软件。
虚拟数字助理：这些是自动化的软件应用程序或平台，通过理解书面或口头形式的自然语言来协助用户。
聊天机器人：文字依然是获得聊天机器人协助的主要方式。聊天机器人可以模拟与人类用户的对话。许多公司在客户服务部门使用它们来回答基本问题，并在必要时与真人联系。
语音助手：语音助手的关键是语音。语音助理是一个数字助理，它使用语音识别、语音合成和自然语言处理（NLP），通过一个特定的应用程序提供服务。
本文中，作者采用欧盟数据保护委员会对虚拟语音助手的定义，凡具有以下三种特征的语音服务均视为虚拟语音助手（以下简称“VAA”或“VAA服务”）。
（一）一种服务；
（二）理解语音命令，在需要时执行命令；或
（三）作为与其他IT系统交互的媒介；
根据Reviews.com的数据统计，用户选择语音助手主要考虑以下几个方面：声音匹配技术、记录删除选项、即时翻译技术、IoT兼容品牌、可支持语种。截至2020年，Amazon Alexa、Google Assistant、Siri均支持声音匹配技术、即时翻译技术。相比于Google Assistant、Siri仅支持通过设置删除记录，Amazon Alexa还可通过语音指令删除数据选项。目前Alexa可兼容7400以上的IoT品牌，Google次之。Siri支持21中语言，远高于市场上其他VAA。

该数据截至于2020，来自Reviews.com
下面我们来讨论以下VAA服务中常见的隐私风险，并解答针对特定风险应当如何进行隐私设计：
关于意外唤醒中的隐私风险
VVA应该“清醒”。这意味着助手会切换到活动的监听模式，以接收来自其用户的命令。VAA在被唤醒之前，始终保持在聆听状态。我们容易将聆听和录音混淆，VAA会处在始终聆听的状态。但只有被唤醒，VAA才会开始接收来自用户的命令，进而分析、处理和存储数据。
市场上几乎所有的VVA都是基于监测一个唤醒表达式或单词切换到主动监听模式（也称为激活词或唤醒词/热词）[1]（Guidelines 02/2021 on Virtual Voice Assistants），比如Siri的“hey,siri”,Google的“Hey Google”。唤醒有时也可通过物理动作来实现。按下按钮或打开应用程序也是常见的唤醒方式，比如Siri也可通过侧边按钮唤醒。
意外唤醒的情况非常普遍。本文中，笔者将用户对VAA服务的唤醒状态无意识的情形都称作意外唤醒，譬如“不小心按到了唤醒键”、“谈话中无意包含包含唤醒词”、“服务提供完毕后未正常关停”都可能引发意外唤醒。在意外唤醒的情况下，用户对录制状态无意识，因此意外唤醒可能涉及未经收获同意收集个人信息和违反透明性原则的合规风险。
建议：采用多种唤醒回应形式
市场大多数VAA产品的设计是，唤醒词通过初步监测后，VAA会进行回应。回应的方式包括语音、文本、显示灯等，比如小度音响在听到“小度小度”后会回应“我在呢”。VAA服务供应商或设计者应当为用户提供多种唤醒回应选择。若载体设备包含显示屏，除语音唤醒回应之外，设备还应当提供文本唤醒回应。若载体设备不包含显示屏，设计师可通过显示灯的闪烁设计起到回应作用。如果载体设备允许，默认设置三种形式的唤醒回应方式同时开启是最优的设计。

亚马逊出品的Alexa隐私设计
建议：采用具有标识性的语音类唤醒回应
目前，大多语音类唤醒回应的类型有二，音频类回应和语言类回应。Siri的“叮”声唤醒回应属于前者。下图是Iphone的Siri的唤醒过程。



如图示，Siri在刚被唤醒后，并没有立即做出语音回应，此时屏幕出现了“请问需要什么帮助”的文本回应。两秒之后，当屏幕出现文本“你可以这样问我”时，Siri才发出“叮”的回应，未发出任何语言类语音回应。这是典型的音频类回应。音频类回应在含显示屏的载体设备中居多。原因在于，显示屏可提供文本回应。而语言类回应在智能音响和无屏智能穿戴设备中比较常见，比如Bose QuiteControl 30的唤醒回应就包含了电量信息和连接设备名称。如果你身边有VAA服务设备，可现场进行一次唤醒体验。
目前VAA服务的音频类语言回应存在持续时间过短且不具有标志性的问题。这导致用户很难将之与其他服务或设备的提示音区分。音频类回最易与短信提示音或按键提示音发生混淆。
那语言类语音回应呢？相较于音频类语音回应，语言类语音回应与其他提示音发生混淆的可能性较小。最简单语言回应，例如“在呢”，也能起到一定的标识作用。但在多VAA服务的情况下，仅仅表明服务状态的“在呢”，或包含电量信息和连接设备信息的“battery30%，connect to XX”等语言类回应也会混淆的情况，用户无法定位是哪个VAA服务处在就绪状态。
美剧《摩登家庭》中主角Phil因为无法通过报警音定位报警器，而砸掉了家里多个报警器。因此语音唤醒回应应具有标识性。此外，标识性有助于厘清VAA供应商与第三方的责任边界。因此唤醒回应中应当包含（第三方）服务名称。此外，出于目的限制原则的考虑，建议回应包含复述请求内容。综上，建议采用“标识性音频”+“服务名称”＋“服务状态”＋“服务请求内容”，以提高语音类回应形的标识性。
关于回应迟延中的隐私风险
迟延是指，VAA服务被唤醒时与VAA做出唤醒回应时之间的时差。前文中，我们在意外唤醒中清晰地描述了Siri地唤醒过程，在这个过程中，语音回应出现了两秒左右地迟延。在数据合规风险上，迟延地意义在于，迟延时间段内，用户（可能）没有意识到录音开启。和意外唤醒一样，数据收集者面临着未经用户授权收集个人信息的风险。此外，迟延还可能出现在请求的解析阶段，如果第三方服务未确定好意图参数，那VAA会因无法完成操作所需的参数或无可选参数，而无法完成任务或正确表达任务阻碍因素。
建议：开发语音接口，确认第三方服务的意图和意图参数
欧盟数据保护委员会在《2021年2月虚拟语音助理指南》中在对无屏幕终端设备提供VAA服务履行告知义务时认为，通过无屏幕终端设备提供VVA服务的数据控制者仍然必须根据GDPR通知用户。根据GDPR的规定，在设置VVA或安装或首次使用VVA应用程序时，仍然必须告知用户。并建议VVA供应商/设计者和开发者开发基于语音的接口，以方便提供强制性信息。显然，开发语音接口是提供VAA服务和履行用户告知义务的应有之义，VAA技术的出发点，是使用户在肢体和视觉被占据的情况下，实现声控。从这一点来讲，语音唤醒回应是用户粘性最高的回应方式。即使供应商会通过网页或APP提供文本隐私政策，这一点也不例外。
在连接第三方服务调用接口时，第三方的应用程序和 VAA服务的SDK必须在解析阶段就请求的含义达成一致。 此阶段视为向用户询问第三方应用程序所需的一切，并在必要时询问其他信息或说明的时间。例如，如果用户要求向Leon发送消息，并且他们有多个名为Leon的联系人，则消息应用程序可以让 VAA询问他们指的是哪个 Leon。与意图相关的详细信息，例如消息收件人的姓名，称为参数。在解决阶段，您可以指明完成操作所需的参数和可选的参数。第二阶段——称为确认阶段——发生在你拥有处理意图所需的所有信息时。这个阶段可以让用户有机会确保他们想要完成任务。例如，具有财务影响的任务需要确认。 除了征求用户的同意外，如果有什么会阻止您的应用完成操作，您可以在此阶段显示错误。 例如，如果用户在取货地点关闭时使用应用订购要取的商品，则第三方应用可以通过VAA描述为什么它现在无法完成该操作。在确认阶段显示此错误可避免让用户等到他们为该项目付款时才发现他们的请求已失败。
建议：语音回应优先
前文提到，如果VAA服务载体设备能够提供显示屏、显示灯，那么“文本+音频+显示灯”三者是最优解决方案。理想情况下，所有的唤醒回应方式都不应当有迟延。但当供应商的技术水平可能并不能满足零迟延的技术要求，或者发包商无法负担零时延的成本，怎么样的涉及能够更好地平衡相关方利益和合规风险呢？那么，VAA设计者应首先保证语音类回应零时延。这样，用户可在肢体或视觉被占据的情况下，最快了解到VAA的数据收集和处理情况。语音作为用户使用VAA粘性最高的交互方式，也是履行告知义务的最佳途径。
关于监测机制的隐私风险
无论是出于验证学习数据库的考虑，还是为了纠部署算法时出现的错误，人工智能系统的学习和训练需要人工干预。这也被称为“数字劳动”。基于结果准确性和用户体验的双重考虑，VAA通过Two-pass监测机制对语音进行监测和识别。VAA本地服务在本地设置较低的阈值放行语音请求，通过后，将语音数据传输到服务器进行二次监测。
人工干预引申出关于目的、传输、存储限制的问题：监测关键字是否传输到远程服务器？是否为满足数据学习数据库的目的收集更多的数据？当监测阈值低，关键字被识别到传输范围内，是否有更多的音频数据会离开本地，甚至存储在第三方？如何保障数字劳动中用户的隐私，如何分配本地和服务器责任的归属？
建议：隐私政策中考虑监测机制因素
人工干预需要的数据往往与用户服务请求或实现合同目的没有直接关系。因此根据最小化原则及关于用户授权的规定，VAA供应商需要获得用户关于这部分数据收集使用的额外授权。VAA设计者应当将用于NLP算法训练的数据的使用目加入隐私政策。其次，服务应当允许用户关停APP使用该类数据。
作为部分服务的最终提供者，第三方也应当将人工干预考虑在隐私设置中。双方应当在合同、服务水平协议等相关协议中明确数据保护义务。VAA服务供应商应当提供第三方服务提供者的隐私政策访问接口和隐私偏好设置的接口，以保证隐私政策的可访问性。VAA供应商与第三方服务供应商应当充分履行背景调查和资质审核，根据行业、服务的类型、关键词的敏感级别对接口设置不同和访问控制，VAA服务也应设置差异化的监测阈值，为具有较低安全水平的第三方将提供更高的首次监测阈值，以限制数据的传输。
关于隐私政策捆绑和账号捆绑的风险
VAA服务涉及账号和隐私政策绑定。大型VAA服务供应商也存在这样的问题，实行统一的账号管理和统一的隐私政策，例如sansung的Bixby、IBM的Watson、微软的Cortana。然而统一的隐私政策捆绑和账号捆绑涉及使用冗长和复杂的隐私政策，不符合GDPR的透明度原则。账号绑定虽然有利于账号的统一管理，但存在诸多安全性问题，比如不同的服务适合不同的身份认证方式，账号密码数据的共享和存储问题。
建议：采用独立的隐私设计和访问控制机制
此语境下，独立的隐私设计，包含独立的隐私政策和隐私设置。独立的隐私政策，要求VAA供应商解除与设备或服务隐私政策的捆绑。有关VAA的隐私政策应当更加侧重于它的服务特性。但注意，同一品牌下的隐私政策仍然适用于VAA服务，所以用户和供应商都应关注隐私协议之间的衔接。并且，供应商应当保证独立隐私政策的可访问性，比较推荐的做法是，为隐私政策提供语音访问选项。比如，用户可直接通过说出“请阅读隐私政策”收听详细的隐私政策。此外，第三方服务也应当为VAA服务端口开放该服务的隐私政策访问接口。除了应考虑便于访问外，VAA还应当为用户提供语音的其他隐私偏好设置，比如请求回读和记录删除功能。也应当为与个人信息密切相关的功能提供关停选项，比如定位服务、兴趣话题（如烘焙或篮球）。
账号捆绑是为了实现账号的统一管理，但账号的统一管理涉及到用户账号密码及身份认证信息的共享，而且同一套身份管理系统无法满足特定服务对安全级别的要求。因此VAA服务应当多层次的纵深访问控制机制，必要的时候，可使用独立的账号管理系统。