隐私政策和权限政策有什么区别

做 App 或小程序上线前，产品一般会把隐私政策和权限政策一起甩给运营或法务，然后没人说得清哪句该写在哪一份里。结果就是权限弹窗上的说明跟隐私政策对不上，被渠道或审核打回来。这篇不讲法条，只给职责边界、对照表和自查顺序，让两个人分工时不互相踩脚。

上线前最常见的场景：产品经理把两份文案一起丢给运营或法务，然后没人说得清哪句该写在哪一份里。结果就是权限弹窗上的说明跟隐私政策对不上，被渠道或审核打回来，来回改两三轮。

这篇不讲法条，只讲职责边界和自查顺序。目标很简单：让负责功能的人和负责合规的人分工时不互相踩脚，改完还能自己验一遍。判断拿不准的地方，到 /safety 看站内对术语的分类口径，比各自猜要靠谱。

先弄清两份文件各自在回答什么问题

一句话区分：隐私政策回答的是「你收集了哪些个人信息、拿去干什么、给谁、留多久、我怎么撤回」，对象是数据本身；权限政策回答的是「App 为什么要调用系统能力（相机、定位、通讯录、剪贴板等）、什么时候调、不给我还能不能用」，对象是设备能力。

边界口诀

权限是入口，隐私是去向。用户点「允许」只是授权了入口，不代表你就能随便把数据传出去，去向上仍受隐私政策约束。

同一件事的两种写法

隐私政策写「我们会读取相册图片用于生成内容」，权限政策写「首次使用生成功能时申请相册读取权限」。前者讲目的，后者讲时机。

判断口径

拿不准某个表述该放哪一份时，到 /safety 核对当前分区对术语的分类口径，不要靠个人理解硬扛。

• 纯网页端没有系统权限一说，通常只有隐私政策这一份。
• 纯本地工具不联网、不收集数据时，权限政策可能比隐私政策还长。
• 只申请了极少数权限且不涉及个人信息收集时，两份的篇幅可能严重不对称，这很正常。
• 涉及第三方 SDK 时，两份都要提到，但侧重不同：隐私政策讲数据流向，权限政策讲 SDK 触发的能力调用。

改需求时，哪一份要动、谁来动

新增权限是最容易出事的一类改动，因为很多团队只改权限政策就以为完事了。实际上一旦申请了新的系统能力，对应的数据收集项和用途说明必须在隐私政策里也出现，否则就是典型的不一致，渠道审核会直接要求整改。

分工建议按「谁知道细节谁主导」来分：权限政策由负责那个功能的产品或开发主导，因为只有他们知道什么操作触发调用；隐私政策由法务或合规主导，产品只负责提交数据流清单，不要替法务写结论性的用途表述。

1. 改前先对齐功能评审时就把「这次会不会新增权限、会不会新增数据收集」写在需求单里，别等上线前才发现。
2. 各自改各自那段权限政策改申请时机和场景说明，隐私政策加收集项与用途，不要一个人包办两份。
3. 改完交叉读一遍重点看同一功能在两份里的措辞是否能对上，一处写「优化体验」一处写「个性化推荐」就是没对齐。
4. 上线前对代码把两份文案和实际代码里的调用点对一遍。文案说不再申请剪贴板，代码里还在读，这就白改了。

两份文案对齐自查清单

对齐的核心动作是双向检查：正向从权限看隐私，反向从隐私看权限。单向查容易漏，因为两份文件通常由两个人分头改。

• 正向：把所有权限申请点列出来，逐条问「这条在隐私政策里有没有对应的收集项」。
• 反向：隐私政策里写的每个收集项，能不能找到实际触发它的功能。找不到就是写了没做的空头承诺。
• 三处措辞对齐：权限弹窗用途说明、应用商店权限说明、隐私政策用途描述，对同一功能要能对上。
• 撤回路径对齐：隐私政策说了用户怎么撤回同意，权限政策也要说清关掉权限后 App 怎样降级，不能一方说还能用、另一方能说直接不可用。
• 术语统一：同一个词在两份文件里不能有两种意思，术语标注口径可参考 /ai-dict/category/safety 里的条目。
• 留痕：每次改动留版本和改动原因，被问起变更时能拿出对照。

什么情况下这套自查不适用：如果产品压根没有系统权限申请（比如纯 H5），那就不存在两份对齐问题，重点变成隐私政策本身是否讲清数据用途和撤回路径。反过来，如果产品是纯本地工具且不联网，隐私政策可能非常短，自查重心应放在权限政策上。

产品运营最容易踩的四个坑

这四个坑的共同点是把两份文件当成一份写、或者当成一次性任务写。实际它们是两套不同职责的文档，由不同角色维护，改动节奏也不一样。把它们放进同一套发布流程里管，问题会少很多。

权限政策让用户知道「你在问我要什么」，隐私政策让用户知道「你拿到之后打算怎么办」。两句话都对上，才算真的讲清楚了。