炫酷的AI手机背后,难以绕开数据处理的方式与规则,更无法将数据安全责任置于真空地带。迄今为止,作为人类最为亲密的信息终端产品——手机,其上承载了大量的个人隐私数据信息,如何面向消费者建立值得信任的手机端侧AI处理服务,是摆在产业界面前的重大课题。
2024年,部署生成式AI技术的新款手机陆续发布,标志着AI手机市场拉开序幕[1]。10月,苹果第一款真正意义上的AI手机iPhone 16正式亮相,其搭载的apple Intelligence采用“端侧大模型 云端大模型”的方式,不但可以在设备上处理日常的文字任务,还可以结合云端完成更复杂的图像视频分析[2]。紧随其后,vivo 推出的蓝心端侧大模型 3B与手机智能体(Agent)——PhoneGPT可以自主拆解、反馈、完成任务,如自动打开APP应用,搜索餐厅,并拨打电话完成订座[3]。
除了在端侧部署AI大模型外,手机终端还引入云端AI能力,其中包括自有的云端AI与第三方AI两种方式。第一种如苹果的“隐私云”(PCC,Private Cloud Compute),其通过自研的云系统进行云端AI计算,将用户设备上的处理安全性和隐私性尽力延伸到云端。为此,苹果专门配置了apple silicon服务器以专为隐私保护设计而加固的苹果操作系统,并采取了包括权限访问控制、端到端加密等软硬件一体的安全措施。第二种是与外部合作的方式。对于第三方大模型,目前终端厂商多采取开放态度。如荣耀、三星与百度云千帆等合作,接入行业垂直大模型与通用大模型;OPPO手机国际版将接入谷歌AI大模型Gemini;小米接入豆包大模型等等。苹果则将外接大模型部署到PCC节点之外,如GPT-4o等只能响应经过处理后的非个人化的数据和相关需求。
未来,随着融合的深入,“生成式AI技术将在智能手机上孕育出一个甚至多个智能体(AI Agent)……但预计在很长一段时间里,智能体仍将会和 APP 共存。”[4]由此,在隐私保护与数据安全层面,重点问题浮出水面。在AI手机商业场景中,AI手机终端、第三方大模型、APP以及云服务之间将构建起怎样的生态关系?在端侧部署AI大模型应用AI智能体的过程中,将带来哪些新的隐私风险与数据安全挑战,不同商业主体之间又将如何构建数据规则,最终打造让消费者信任的端侧AI生态?
技术不是解决一切问题的“灵丹妙药”,更不是责任承担的“免死金牌”。在技术思维之外,法律的规则秩序与责任边界,在隐私保护的最终方案中也将扮演重要作用。尽管传统的数据保护法律规则在颠覆式的AI技术浪潮下,越发显现出滞后性,但在没有形成新的治理规则的背景下,仍需基于现有的法律与治理框架予以分析。正如欧盟《AI ACT》所提出:AI服务活动仍将适用欧盟数据保护法律——GDPR的相关要求。本文即从法律视角出发,分析当前AI手机带来的四大隐私与数据安全挑战。
明确不同企业的角色定位是确认责任边界的前提。在责任主体方面,对于上述不同的企业类型,需根据特定的业务场景、技术逻辑和法律规范明确其属于数据控制者(data controller)、数据处理者(data processor)抑或是其他主体角色;此外,还需要在“合作协同”的业务场景下,明确不同主体的责任关系,如共同处理,对外提供、委托处理关系,以期形成明确有序的安全生态。然而总体来看,基于当前端侧AI手机的商业进展,终端厂商与APP开发者,第三方AI服务提供者在数据安全上的责任关系并不十分明确。
以AI手机宣传的经典场景为例,手机智能体(Agent)基于AI大模型能力,实现“点餐”任务目前主要通过三个重要环节:一是智能体通过截屏录屏或相机拍摄,适时“看见”屏幕内容,并进行总结和播报;二是智能体对用户的语音指令进行理解,并将其拆解转化为任务流程;三是模拟人类手势触摸屏幕,对APP执行部分操作。如在vivo的官方演示中,蓝心小V可以自主点击屏幕,找到用户所需,关掉弹出广告,最终完成订餐。需要格外注意的是,在此过程中,除非终端系统主动开放相关技术接口,终端AI的识别、操作动作无法被APP所知晓或阻止。我们可以通过以上场景分析相关主体在数据安全上的法律角色。
先看终端厂商。对于在手机终端上开发部署大模型的厂商,其面向用户提供AI服务时,明确知晓收集的信息种类与处理目的。就信息种类而言,按照现有的技术实现方式(手机录屏),其收集的个人信息类型将会十分丰富,包含各类敏感信息。例如:用户使用服务时提交的个人信息、个人语音命令、以及通过录屏,甚至操作APP获得的个人信息等。就处理目的而言,厂商亦明确知晓其正在处理的是以语义方式“与已识别或可识别的自然人有关的信息”,而不仅仅是计算机代码。因此,终端厂商作为数据控制者的角色是确定的。
再看APP服务提供者。在移动互联网生态中,直接面向消费者提供服务的APP一般均会被视为数据控制者,在如电商、社交、出行等服务场景中承担着相应的隐私保护与数据安全责任。然而,当端侧AI智能体基于APP的服务能力完成特定任务时,终端厂商与APP服务提供者在数据安全上的责任边界变得模糊。
如上所述,AI手机目前实现此类特定任务的过程并不同于移动互联网时代的“自动化操作”“辅助操作”,即并非通过与APP服务提供者的合作直接调用其API;在端侧AI的场景下,实际上是智能体模拟用户在APP中进行读屏理解、操作,在未达成与终端厂商的合作时, APP对于手机的AI功能实际控制能力有限。即使APP履行了其自身系统的数据安全管理义务,也无法对可能的不当操作做出及时的响应或干预,避免可能带来的风险。在此类情形下,APP服务提供者无法与终端厂商构成“共同处理”关系。
而在外接AI服务方面,同样存在着数据安全责任边界不清的问题。以三星手机与谷歌Gemini的合作为例,可能会出现迥然不同的责任关系:
用户使用识图功能,识别具体网页和商品时,如果是将圈选或滚动截屏的内容发送给谷歌云在云端进行处理,在此类用户直接调用的情况下,谷歌云直接收集数据、决定处理的方式,谷歌云有可能构成单独的数据控制者;
而如果三星手机端侧大模型已经进行了初步的处理,再借助谷歌云端AI进行深入分析,两者围绕数据处理的决策是不可分离且对数据处理的目的和方式均产生了实际性影响,则二者有可能被认定为“共同处理”[5];
除以上两种外,如果厂商将所收集的个人数据加密后以自己的名义上传到第三方云端AI处理,并以自己的名义输出了结果,则也有可能被认定为“委托处理”。
前两种方式在三星的公开文件当中或可窥见一二:“您需要登陆谷歌账户才能充分利用 Galaxy AI 功能,该账户允许谷歌根据您的互动提供定制服务。”[6],并且在用户使用相关服务时会显示谷歌搜索界面和图标。第三种方式如部分终端厂商与百度云千帆、豆包等云端大模型合作,在操作界面并未明确注明具体的AI服务功能提供者,于用户而言,输入与输出都是通过终端智能体。在此情况下,或可认定为委托处理关系,即终端厂商将面对用户独立承担所提供的AI功能服务涉及的全部数据安全责任。
如上分析,端侧AI带来了全新的数据处理模式,打破了传统移动互联网时代的隐私保护与数据安全秩序。对此,明确数据安全的责任边界是与AI技术研发同等重要的优先事项。企业主体之间,终端厂商、APP开发者、第三方云端AI厂商需要事先进行明确的权责划分与约定,探索建立可事后追溯的数据安全保护机制。在调用模型、插件,进行应用编排时,对过程进行可验证的记录管理。除此之外,终端厂商还应当为载有敏感信息等特定的APP(如金融、社交、医疗等敏感场景)开放相应技术机制,对于屏幕识别、操作等数据获取处理,允许APP明确拒绝。如三星明确声明:“不会进入 WhatsApp 等流行的第三方信息平台,因为这些平台的信息都是受保护的。”[7]
以往手机获取的信息主要包括用户设备及应用信息、日志信息、底层权限信息等;在端侧AI场景以及当前主要基于读屏录屏的技术方式,除上述全面的信息权限外,终端智能体还可以获取录屏的文件本身,并进一步通过模型分析,获取其所展现的身份、位置、支付等各类敏感信息。由于录屏场景十分丰富,其所识别的信息类型也将无法提前预测,并且极有可能包含了大量其他自然人的个人信息。
智能体甚至还可以将用户数据和插件、应用的三方数据进行混合利用。即使在最理想的情况下,这些文件不会被发送到云端进行理解和分析,但其本身的收集过程,是否与个人信息保护的基本原则——目的限制、最小必要相自洽,仍存在疑问。此外,“端侧处理”并不意味着脱离了数据保护规则的约束。即使这些录屏、截屏储存在本地,如果缺乏足够的信息披露,本地数据存储也并不意味着安全。例如,微软最新的AI“Recall”功能每隔几秒钟就会对用户的活动屏幕进行截图而遭到安全专家的强烈反对。尽管微软坚称,由于所有 Recall 数据都存储在本地,并通过设备加密或 BitLocker 加密,并不会侵犯隐私。但Absolute公司的一项调查发现,有42%的终端设备在任何时候都没有得到保护。”专家Weinberg表示其于用户教育方面也存在漏洞,并未明确收集的数据类型。[8]
当前,苹果在欧洲市场对AI功能的延迟和削减,也反映了此类冲突并非空穴来风。据报道,这主要是由于隐私、公平竞争和透明度方面的担忧。[9][10]科技编辑Mark Wilson指出, “苹果与用户的关系如此密切,以至于它在引入人工智能时,甚至不需要担心我们是否会同意。公平地说,似乎没有人在问,这些未知的人工智能系统怎么能分析我的私人文本?我们盲目地相信苹果会为了我们的利益使用我们的信息。”[11]
“生成式AI技术需要数据进行训练,也需要从用户那里获取更多数据进行训练。GDPR对此有很多疑问。”[12]——埃隆·马斯克
在大模型研发的早期阶段,训练数据并不以个人信息为目标[13]。然而,随着各垂直领域的应用深入,涉及个人信息进行训练的投诉纠纷也时有发生。2024年3月,欧洲隐私倡导组织NOYB对社交媒体平台X提起GDPR投诉,因其擅自使用超过6000万欧洲用户个人数据训练其大型语言模型“Grok”,这一行为严重违反了GDPR关于准确度、访问权、更正权与被遗忘权的要求。[14]Meta和LinkedIn也面临类似投诉。[15]同样,在对苹果PCC进行考察时,专家也提出,一旦PCC被用于训练,那么数据将会被保留。无状态计算(stateless computation)——即不留下任何痕迹的计算——几乎是不可能实现的。[16]
目前来看,终端实现持续的个性化服务,未来有大概率需要云端数据训练模型,如三星已明确声明“在云端处理数据的功能可能会用于模型训练”,那么,如何解决模型训练过程中有关个人信息的安全以及如何保证用户的个人权利就尤为重要。正如Noyb所提出的那样,智能体可能会错误地判断如用户的婚姻、健康状况、种族与宗教信仰等,并据此给予回答或建议。而用户想要进行更正却很难,因为其并非根据某一个确切的信息输出判断,而是多方数据汇聚判断得到的,并且很难从输入端进行更改。Open AI 在其隐私政策中也曾提出“鉴于我们的模型工作原理的技术复杂性,我们可能无法在每个实例中纠正不准确性。如果需要更正,用户可以填写表单。”[17]
此外,由于AI关键能力为自主化理解需求、自动推理策略以及自动完成任务,因此也会触发对于“自动化决策”的担忧。报告显示,欧洲民众尤其担心个人助理AI会侵犯他们的隐私并操纵他们的决定(“低信任度”从40% 到 71% 不等)[18],终端智能体能够跨越应用,进行多方汇聚分析,甚至直接做出行动(action),其自动化决策的范围和深度都将大大提升,无疑对用户带来更加深入的影响。
短期内端侧模型能力有限,端云结合将是长期趋势。包括苹果、vivo、荣耀、三星等手机终端均与第三方云端大模型展开合作。此前,尽管终端厂商收集相关的个人信息,但对外传输的场景有限。而在终端AI时代,为了进行更精确的理解分析,终端智能体需要将数据发送到第三方云端进行处理,从而不可避免面临以下问题:[19]
一是如何建立明确且可执行的权责分配机制。由于终端可能合作的不止一个云端模型(如荣耀),在未来的生态布局当中可能涉及更多的云端通用、专业大模型,这需要终端建立更加完善的第三方安全管理机制。
二是能否实现可信任的安全保障水平。考虑到端侧模型能力有限,且模型训练和精调只能在线上,将有大量数据从端传输到云。尽管厂商多强调其在上传云端时进行了数据脱敏与加密处理,如荣耀声明其智能体在调用云端模型处理时会通过端侧防护网过滤用户隐私,vivo也声称“将对用户输入内容进行过滤,仅将训练后的模型更新匿名化后上报到服务器”。然而,就目前来看,各大厂商基本仍停留在宣誓性的声明、产品发布会上的介绍与白皮书中的只言片语中,未有更加进一步的的详细披露。
即使强如苹果,提供了自有的云端服务,并通过提供底层芯片安全加固、三层安全架构的PCC计算节点,在隐私、技术解释与告知方面仍旧受到质疑。如安全专家Adelin Travers提出,苹果目前只公开了有限的代码,外部对于PCC安全性的理解和信任将主要依赖于苹果自己的声明,而不是基于独立验证的结果。同样,由于同态加密(HE)的计算效率和可扩展性的限制,目前苹果仍需要在云端解密数据,而苹果并未明确说明这样的解密可能对用户造成的风险,也没有回答其未来是否会使用 PCC 来训练模型。[20] 苹果自有云端的安全性尚且面临如此之多的质疑,那么如何保证第三方的云端处理提供足够的安全水平更是充满挑战。
而从用户感知看,在数据已经被发送给第三方大模型处理时,很多用户无法区分两者,会误以为数据仍受到终端的保护,但其实第三方的隐私政策更加宽松,增加了敏感信息泄露的风险。此前三星公司员工就在使用ChatGPT时不慎泄露了公司的芯片机密信息。[21]马斯克也曾表示:“若苹果在操作系统中整合OpenAI,公司将禁止使用苹果设备。这被视为不可接受的安全违规行为。”
不盲目信任技术,但也无需“灾难性地担忧”[22]。在技术创新、制度规范、生态建设、用户教育的协同发展下,相信仍可以探索出面向AI时代的隐私保护与数据安全方案。如微软AI CEO苏莱曼所说:“这里的关键在于如何打造一种值得信任的技术,因为这将是一种非常亲密和个人化的体验。我们必须做好安全和隐私的部分。我认为真正的挑战在于如何设计对话,使AI伙伴能够明确地表达边界,能够说出‘这是我不准备参与的事情’”[23]。
本期文章主要由腾讯研究院-大模型研究小分队:王融 钟雨霏 王强 袁媛等完成
免责声明:本文为转载,非本网原创内容,不代表本网观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
如有疑问请发送邮件至:bangqikeconnect@gmail.com