乐于分享
好东西不私藏

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

APP隐私政策需要改版了,要素式的合规要求
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可能面临新一轮的监管查处。
卓建数据合规团队

卓建律师事务所数据合规团队是国内最早从事数据合规业务的律师事务所之一,卓建数据合规研究院是律所为数据合规成立的专门机构,数据合规团队有近20名DPO律师,在个人信息保护、数据出境和数据资产交易方面积累了大量的客户和案例。

李兰兰律师
13418782876
李兰兰律师,广东卓建律师事务所高级合伙人,卓建数据合规中心主任,广东省律师协会合规与风控法律专业委员会主任,深圳市律师协会数据合规法律专业委员会主任,拥有20多年法律服务经验,现专注于企业合规和数字治理设计,是国内最早从事数据合规业务的律师之一。
推荐阅读:
GDPR合规自查评估(附程序)
如何落实敏感信息“加密”和“分开存储”的合规要求?
敏感数据加密和单独存储的补充说明
一文了解GDPR的LIA 评估(附模板下载)
个人信息保护合规审计自查(附程序)
欧盟EDPB发布新的DPIA模板
《数据法案》的数据“自行获取”的合规要求
《数据法案》中必须共享的数据类型示例

欧盟《数据法案》(DA)核心内容及企业合规要求

《数据法案》全文条款十分钟快速预览
一图看懂欧盟《数据法案》
《数据法案》小微企业的豁免情形
产品出口欧盟的合规新要求:《数据法案》

GDPR 软件产品开发合规指南

十个GDPR处罚案例:访问权、处理目的、敏感数据、存储期限和系统安全

欧盟《人工智能法案》(AI Act)核心内容及企业合规要求

车企出海欧盟的数据合规要求

智能设备出口欧盟的合规要求

SaaS软件出海数据合规(2):数据处理者的合规要求

数据合规中的“同意”实务操作
出海企业的人工智能合规
出海企业如何实现GDPR的快速合规?
欧盟《数字服务法》发威,TikTok被调查
《数据法案》数据共享的形式、方式和格式
我们企业的数据到底是不是“重要数据”?
容易忽视的必备合规项:数据处理活动记录(RoPA),要求和示例