APP隐私政策需要改版了,要素式的合规要求

2026-05-25 17:55
来源:数据合规e站通

2026 年 1 月网信办发布《互联网应用程序个人信息收集使用规定(征求意见稿)》,监管覆盖 App、SDK、分发平台和终端,对告知 - 同意机制进行了强化,对于权限申请、敏感信息采集存储传输、账号注销等进行了明确的限制,并对SDK、分发平台、智能终端日出了专项要求。

征求意见稿对于APP合规提出了更加严格的要求,本文仅个人信息收集使用规则(隐私政策)部分的合规要求进行说明。

一、主体的显示

征求意见稿要求隐私政策展示数据处理者的主体信息。这不是什么特别要求,《个人信息保护法》第 17 条已经明确要求展示名称和联系方式。

处理个人信息应当以显著方式、清晰易懂的语言,向个人告知个人信息处理者的名称或者姓名、联系方式等事项。

但是,上述要求并未明确在哪里显示,GB/T44588—2024《互联网平台及产品服务个人信息处理规则》中也未要求需要具备上述内容。

征求意见稿是首次明确在隐私政策中显示处理者的信息,并且以显著方式(加粗、放大、异色)显示。这与GDPR 第 13 (1)(a) 条的要求一致。

示例如下:

控制者:ABC Ltd.(英国公司,注册号 12345678)

地址:123 Main St, London EC1A 1BB, UK

联系:privacy@abcltd.com | +44 123 456 7890

DPO:dpo@abcltd.com

二、个人信息采集的结构化显示要求

1、内容要求

征求意见稿明确要求个人信息采集部分的内容包括:


    采集目的
    采集方式
    个人信息种类
    调用权限名称
    采集频度收集使用敏感个人信息的必要性

    对用户权益的影响

    后面几项是对于APP隐私政策表述的新要求。

    2、结构化表述要求

    以往的隐私政策大都是大篇幅的文字表述,这与律师撰写文书的习惯有关,需要以流畅的文字进行表述、阐释和宣讲。

    以下是一个平台网站关于个人信息收集的表述:

    (一)账号注册登录 

     当您注册使用XX服务时,您需要向我们提供手机号码,我们将通过发送短信验证码来验证您的身份是否有效,通过SIM卡信息识别并显示对应的运营商。您的账号名为您的默认昵称,您可以自主选择修改和补充您的昵称、头像、账号名以及您的实名认证相关信息,这些信息均属于您的“账号信息”。  注册完成后,您可以选择使用XX账号信息或者授权我们获取您的第三方账号信息进行登录,若您不提供这类信息,您将无法登录和使用我们的产品与/或服务,此时您可使用浏览和搜索功能,我们将不会收集您的上述个人信息。  

    (二)下单及订单管理 

     当您选择对商品/服务进行结算时,XX会生成您购买商品的订单。您需要在订单中至少填写您的收货人姓名、收货地址(您可以通过手动填写或者允许系统获取您的位置信息)以及手机号码,同时该订单中会载明订单号、您所购买的商品或服务信息、下单时间、您应支付的货款金额及支付方式。您可以另外填写收货人的联系电话、邮箱、邮编以增加更多的联系方式确保商品可以准确送达,不填写这些信息不影响您订单的生成。若您需要开具发票,还需要提供发票抬头、纳税人识别号以及接收发票的邮箱。  上述所有信息构成您的“订单信息”,我们将使用......

    上述文字看起来高大上,但是要从中提取出个人信息的采集是否合规并不容易。合规的框架被花团锦簇的藤曼文字遮藏了。

    鉴于大段文字的繁杂,征求意见要求以“结构化”的方式表述个人信息的采集。

    从文本的角度,结构化就是两种方式:表格或者列表。

    上述两段文字用“结构化”的表格表述如下:

    上述表格看起来古板,但是毫无疑问清晰得多,这有利于用户(监管)的快速阅读理解,但也意味着原来可以文采飞扬的发挥,变成了干巴巴的表格。

    用列表方式表述如下:


    这种“结构化”的格式很类似2025年在全国推广的要素式起诉状,就差将整个隐私政策制作为一个表格了。

    与程序员不同,律师对于结构化的表述有一种天然的反感,因为没有行文的节奏和美感,但是数字化和AI时代,结构化代替非结构化是一个显而易见的趋势和要求,从业人员只能去适应。

    三、SDK的内容和结构化显示

    1、SDK显示内容

    征求意见稿对SDK的内容做出了明确的规定:

    1)软件开发工具包名称(包名)

    2)版本

    3)主要功能

    4)运营者名称或者姓名

    5)收集使用个人信息的种类

    6)完整的软件开发工具包个人信息收集使用规则链接


    2、SDK的格式化显示

    在过往的隐私政策中,大部分SDK就以表格方式呈现,因为SDK是一个纯技术工具,没有什么可以发挥文采和充分表达的余地。


    以下是一个示例:

    四、存储期限的表述要求

    个人信息的保存期限是《个人信息保护法》第19条和第47条的明确要求,但是实务中真正能做到合规的是少数,因为这涉及到公司管理制度的变更,数据删除将带来一系列复杂的后续问题。

    因为是法律的明确要求,之前的隐私政策通常都做出了相应的回应,普遍的表述如下:

    “我们仅在必要期限内保存个人信息,到期后删除或匿名化。”
    “保存至服务终止或不再必要为止。”

    “法律法规另有规定的,从其规定。”

    征求意见稿要求对于个人信息存储给出明确的期限以及到期后的处理方式,保存期限难以确定的,应明确保存期限的确定方法。

    这就对于个人信息存储期限提出了实际合规的要求,而不再是形式上的表述。因为一旦表述清楚就是可以测试的,一旦检测与表述不一致就意味着不合规。

    示例如下:

    四、存储期限的表述要求

    之前的隐私政策通常笼统写明用户享有各项法定权利,但无具体操作入口,很多无 APP 内自助路径,对于用户权利保障的表述如同上述存储期限一样含混模糊。

    征求意见稿要求对用户的九项权利实现给出明确的路径,并优先在APP内实现。

    示例如下:

    上述征求意见稿的出台,意味着隐私政策含混其词可以蒙混过关的好日子将要过去了,只是形式上的表述已经不能满足合规和监管的要求,需要实质上的合规。同时也将意味着APP可能面临新一轮的监管查处。