隐私政策和权限政策区别

做产品文档时最容易混的一件事：用户数据怎么收集写进了隐私政策，App 要哪些系统权限却只丢在设置页里一句话。结果法务评审问「权限这块依据在哪」答不上来，产品改版又被追问「多要一个权限要不要更新隐私政策」。这篇把两份文件的概念边界、触发场景和各自的落地清单讲清楚，让你改版时知道先动哪一份。

做产品文档最容易混的一件事：用户数据怎么收集写进了隐私政策，App 要哪些系统权限却只丢在设置页里一句话。结果法务评审问「权限这块依据在哪」答不上来，产品改版又被追问「多要一个权限要不要更新隐私政策」。这篇把两份文件的概念边界、触发场景和各自的落地清单讲清楚，让你改版时知道先动哪一份。

先给一个判断标准：看这次改动影响的是「拿到了什么数据」还是「能调用设备什么能力」。前者归隐私政策，后者归权限政策。很多项目两份文件混着写，根源就是没做这个区分。如果你是产品，先拿需求单对照下面两张表；如果你是法务，先问一句「这次改的是数据侧还是能力侧」，比通读全文快得多。

先分清两份文件各管什么

一句话区分：隐私政策面向「数据」，权限政策面向「能力」。数据指的是这条信息从用户身上被收集之后怎么用、存多久、给不给第三方；能力指的是这台设备上的相机、麦克风、相册、通讯录、定位、通知等，App 什么时候申请、申请来干什么。两者对象不同，读者阅读时机也不同。

隐私政策

收集哪些个人信息、用来干什么、存多久、给不给第三方、用户怎么查和删

权限政策

设备上有哪些系统能力会被调用、什么时候申请、用来做什么、拒绝后有什么后果

常见误解

把权限说明塞进隐私政策就算完事，其实用户看隐私政策时并不知道你到底会弹几次授权框

适用范围

纯网页产品、无原生客户端、不调用设备系统能力时，通常只需要隐私政策

什么情况下不适用上面这套二分：产品没有原生客户端、或者所有能力都通过浏览器标准接口调用且不涉及设备级授权时，通常不存在独立权限政策的问题，隐私政策里把数据流向写清楚就够了。反过来，如果一个功能既新增了设备能力又扩大了数据采集面，那两份都要动，别只挑一份改。

什么改动动哪一份：一张对照表

这张表用起来有个顺序：先判断有没有新弹窗，再看有没有新的数据字段，两者取并集就是这次要动的文件清单。最容易漏的是第三种——删功能时只写了产品更新说明，权限政策里的条目还留着，时间一长没人说得清这个授权项为什么还在。

• 先看需求单里有没有「申请 / 调用」这类字眼，有就大概率动权限政策；
• 再看有没有新增字段、新增用途、新增第三方，有就大概率动隐私政策；
• 第三方 SDK 换供应商时逐项对照：它带进来哪些权限、回传哪些数据，两份文件都过一遍；
• 只改文案的版本别借机扩大授权范围，扩了就要重新走评审；
• 判断不了时，把两份文件都拉出来对着实际行为核一遍，比争论定义快。

写权限政策时按这个清单过一遍

1. 逐项列权限把每类权限写成一条：申请时机（启动即要还是用到才要）、用途一句话、拒绝后的降级表现。
2. 写清降级后果说明「不给这个权限，哪些功能不能用」，而不是笼统写「为了更好体验」。
3. 给退出路径列出从系统设置里怎么关，关掉后 App 内哪里会提示，用户能不能只关一部分。
4. 控制条目数量别把权限当营销位一次列十几项，用户和评审都不会读完，只列真正会调用的。
5. 敏感项单独标对定位、通讯录这类敏感能力单独标注，交给法务确认是否需要额外告知或单独同意。
6. 真机验证发布前在真机上跑一遍授权流程，看弹窗文案、时机是否和文档写的一致。

这份清单的顺序建议不要打乱：先列全再写后果，最后才做敏感项标注。很多团队反过来，先纠结措辞，结果列到一半发现漏了两项权限，前面对齐过的文案又得重写。如果你手上没有现成的权限清单，从工程侧的调用点反查比凭印象列更靠谱。

评审、留档与版本节奏

两份文件各自要有版本号和生效说明，改动能追溯到具体需求单，改版时先确认这次动的是数据侧还是能力侧。评审会上把「这次动哪份、为什么」写在结论里，比事后补文档省事。涉及对外披露口径、地区差异这类判断，到站内安全与合规相关页面核对当时的说明，别拿旧印象套。

• 每次改动留一条记录：需求单号、动了哪份文件、哪个条目；
• 发布前做一次实际行为对照，真机跑授权流程；
• 只在内部环境测试、未对真实用户发布的版本可以简化流程，但上线前必须补齐；
• 地区差异、对外披露口径这类问题，到站内相关页面看当前口径再定；
• 评审结论里明确「本次不动的那份」也要写，避免下次又从头讨论。

隐私政策管数据怎么用，权限政策管设备能力怎么要；一次改动先归边，再动文件。