先说结论：防住泄露只是及格，合规使用才是底线

我们讲数据安全时，重点在"用户数据怎么保护才不踩雷"——加密、脱敏、权限这些是技术防护。但光防住还不够：你怎么收集、怎么告知、怎么取得授权，是法律层面的事。这一篇接着那篇，讲合规的另外一半——隐私政策与个人信息保护。

隐私政策是不是必须有？

必须有，而且不能藏。

  • 独立可查：要有专门的隐私政策页面，用户能随时点开看，不能藏在几层菜单之后；
  • 内容完整：收集了什么、为什么收、怎么用、存多久、怎么删除，都要写清楚；
  • 版本留痕：政策改动要记录，重大变更要重新告知。

很多小程序上线被拒、被投诉，问题不出在"偷数据"，而出在"没把话说清楚"。微信审核和 App Store 上架都查隐私政策，这块含糊必卡——和我们讲审核被拒、APP 过审的逻辑是一体的。

收集用户信息，怎么做到"告知—同意"？

这是个保法的核心要求：

  • 显著告知：在收集前就讲明白，而不是塞进长篇协议里让用户"默认同意"；
  • 具体授权："同意接收营销"和"同意读取通讯录"是两件事，不能一个勾选全打包；
  • 最小必要：只收业务真正需要的，多收一项就多一分风险。

把授权当成"和用户的一次明确约定"，而不是"赶紧勾上赶紧过"。我们在做交易类、医疗类项目时，会特别把授权节点设计清楚，避免上线后被动。

哪些信息算"敏感个人信息"，要更谨慎？

敏感信息一旦泄露，危害更大，处理门槛也更高：

  • 典型敏感项：身份证号、人脸、生物识别、行踪、健康、金融账户等；
  • 更高门槛：需要"单独同意"、更严格的加密与访问控制；
  • 能不收就不收：能用匿名化解决的业务，就别碰实名敏感字段。

这和我们在数据安全里讲的"分级保护"是同一思路——越敏感，防护和授权都要越重。

用户要删除、要导出，你接得住吗？

合规不是单向的，用户有权利：

  • 查阅与复制：用户有权知道你存了它什么；
  • 更正与删除：信息错了能改、不想留了能删；
  • 撤回授权：之前同意的，后面也能收回。

这些能力要在产品里留出口，而不是"理论上支持、实际操作找不到"。我们做定制开发时，会把"用户数据权利"当成功能需求写进方案，而不是上线后补。

最后

数据安全的那篇保的是"不泄露"，这篇保的是"用得正"。两者合起来，才是完整的个人信息保护。如果你要做涉及用户数据的业务、又担心合规踩线，把场景说给我们——我们的产品与合规支持里就包含这类规划，方案评估免费，别等上线被约谈才补课。