隐私政策协议模板范文

做小程序、App 或者接了大模型功能，备案和上架时经常被要求挂一份隐私政策。网上下载的模板大多缺项、跟你的实际业务对不上，直接抄过去反而留坑。这篇不讲法律定性，只给你一份起草顺序：先列字段、再套范文骨架、最后按自查表逐条核，附常见问题。

做小程序、App，或者接了大模型功能之后，备案和上架时经常被要求挂一份隐私政策。网上下载的模板大多缺项，跟你的实际业务对不上，直接抄过去反而留坑。这篇不讲法律定性，只给你一份起草顺序：先列字段、再套范文骨架、最后按自查表逐条核，附常见坑。

判断标准很简单：政策里写的每一条，你都得能在代码或后台里指出对应位置。指不出来的，要么删掉，要么补上实现。下面四节按执行顺序展开，建议边读边把自己产品套进去填。

先别抄模板：起草前要定下来的四件事

模板之所以坑人，是因为它默认了一个不存在的统一业务。动手之前先把这四件事写在一张纸上，标成「已确定 / 待确认」，待确认的超过两条就先别动笔，因为你后面每填一个空都依赖它。

处理者与受众

谁对信息负责、用户主要在哪。面向境内用户和面向海外用户的条款结构差别很大，涉及未成年人要单独加一节，这几项直接决定要不要增加单独同意和单独条款。

信息三分类

把要收的信息按「用户主动填的 / 系统自动采的 / 从第三方拿的」列清楚。注册、下单、客服属于第一类，设备号、日志、埋点属于第二类，第三方登录回传的头像昵称属于第三类。

用途、期限、共享对象

每类信息对应一个用途、一个留存期限、一个共享对象。写不出共享对象类型就别写「可能共享给合作伙伴」这种模糊话，这是最容易被追问、也最容易翻车的一句。

生效信息与联系方式

版本号、生效方式、联系邮箱或在线表单必须能真的联系上。填一个没人看的企业邮箱，等于把唯一的沟通入口堵死，用户投诉时你连解释机会都没有。

模板范文骨架：八个必填块，按这个顺序写

骨架按这个顺序排，是因为用户的阅读顺序和监管的检查顺序大体一致：先知道你是谁、收什么，再谈怎么用、怎么共享，然后是用户能做什么、怎么找你。顺序别乱跳，写的时候也更不容易漏。

填表时有个通用技巧：凡是写「等」「相关」「可能」的地方，都拿笔圈出来，回头逐条改成具体项。这几个词看着圆滑，实际是给自己留了个无法兑现的承诺。

带 AI 功能的站，额外要补的几段

普通工具类的政策不覆盖 AI 场景。只要你的产品把用户输入发给了第三方模型接口，或者拿用户数据做了二次利用，就在通用骨架之外补下面的内容，别指望模板会替你写。

• 明确用户输入会不会被用于模型训练、留存多久、谁能看到。这一条最容易被追问，写含糊等于没写。
• 说明第三方模型服务商在这里的身份是受托处理方，以及数据会发到哪个区域。涉及跨境就单列。
• 如果做内容生成，补一句生成内容的标识与审核机制，和内容标识类要求对齐。
• 给出「别往提示词里放敏感信息」的提示，并链接到站内已有的 Key 安全与数据边界文章，让用户知道边界在哪。
• 如果开了对话历史、缓存或者调试日志，逐个说明存什么、存多久、怎么删。

什么情况下不适用：如果你的产品只是本地跑模型、输入不出设备，那么训练和数据出境这两段可以简化，但仍要说明本地处理的事实，别因为「没上传」就整段不写。判断依据是数据有没有离开用户设备，而不是你有没有调用模型。

发布前自查清单：六项对不上就先别上线

这份清单的顺序是「先查事实、再查链路、最后查证据」。事实对不上，后面全白搭；事实对了，再去看用户能不能真的走到那些入口。

1. 比对实际采集逐条核对 SDK 和埋点清单。政策里写了但代码没收，是空承诺；代码收了你没写，是漏披露。两种都要改，改完再复核一遍清单。
2. 检查跳转链路注册页勾选框、设置页入口、官网底部链接，三个位置都要能点开同一版本的政策。分开维护多份文本是常见翻车点。
3. 验证撤销同意实际点一遍，看撤销后能不能真的关掉对应采集。写得出路径才算数，写不出就说明这个入口还没做。
4. 检查留存表述留存期限别写「长期」，写具体时长或者判定标准。写不出来的，回到第一部分补上。
5. 归档版本把每次修订的旧版本留一份，记录修订时间和修订点。真出争议时，这是你唯一能拿出来的证据。
6. 拿手机走全流程按用户视角从头走一遍：注册、使用、找政策、提请求、注销。卡在哪一步，说明那一步的条款只是纸面存在。

隐私政策不是写给监管看的文案，是写给用户的说明书；用户按它操作，能不能走通，才是检验标准。