如何为应用或网站生成隐私政策

以新用户的身份体验产品，再将界面与后端逐一对照。注册、找回密码、上传、结账、客服和分析都可能形成不同的数据流。既要检查公开落地页，也要检查登录后的应用；前者的营销像素和后者的错误报告服务都需要纳入。

建立一份简明工作清单，分为功能、信息、接收方和用途四列。遇到不确定之处就明确记录，不要用看似合理的猜测填补。如果某项集成只存在于演示分支，检查它是否会进入生产环境。我们的网站隐私政策指南介绍了更全面的梳理流程。

检查依赖清单、环境变量名称、部署设置、网络请求和 webhook 处理程序，从中识别身份验证、数据库存储、邮件发送、支付、诊断和模型 API 等服务。仅有软件包名称并不能证明服务正在使用；应追踪其调用方并核实已部署的配置。

不要在笔记或任何与助手的对话中放入凭据、连接字符串、个人记录或客户消息。所需的是服务商身份及处理目的，而非 API 密钥。逐一确认启用的服务接收什么信息，以及是否使用请求日志等可选功能。保留期限信息不明确时，应标记为待调查事项，在批准措辞前查清。

打开隐私政策生成器，填写个人信息处理披露内容。选择与服务相符的产品类型：网站、应用、商店或托管软件产品。服务条款是另一份有关服务使用与购买的文档；选择隐私政策不会同时生成两者。

根据清单作答，不要勾选所有可用功能。条款越多，并不意味着文档越准确。如果是包含工作区和订阅的托管产品，可继续阅读如何生成 SaaS 隐私政策。如果某个问题暴露出团队尚无删除流程，应先决定要实现的流程，再向用户作出说明。

生成器无法仅凭产品名称判断目标受众、实际保留期限，或由谁处理隐私请求。这些决定应由运营方作出。询问负责人、检查系统，或调整功能，直到能够明确回答。不要只因问卷要求作答，就选择一个方便的答案。

例如，删除账户所在的数据库行后，上传文件和客服记录可能仍然存在。此时声称所有信息都会立即消失就会造成误导。使用可丢弃的测试账户，追踪创建至删除的完整过程，并检查每个关联系统。不要使用真实客户记录进行测试。最终说明应描述能够反复执行的操作，并包含有正当理由的例外情况。

从头到尾阅读生成的预览。核对运营方身份、产品名称、公开联系方式、数据类别、用途、服务商说明、地区章节和保留期限说明。将每项实质性陈述与清单中的依据对应。如果某条款出乎意料，应检查所选答案，不要仅因措辞专业就接受。

隐私政策内容核对清单可以帮助组织审阅。生成的措辞不构成法律意见，也不保证合规。高风险产品可能需要专业审查。应由了解已发布应用的人负责事实准确性，不宜完全交给编程助手。

无需账户即可填写问卷和查看预览。简单文档可免费下载为 HTML 或 PDF；高级选项可能影响价格。购买前，查看基于实际答案显示的金额。可选的托管发布和订阅有各自的访问规则。当前定价部分介绍了可用方案。

如果需要自行托管完整页面，可选择独立 HTML。若页面已有导航和视觉样式，可使用受支持的 HTML 片段。托管文档提供公开链接，无需另建法律文档路由。PDF 适合作为配套下载，但可读的 HTML 页面通常更便于在应用各处链接。

使用稳定地址，并在隐私浏览窗口中验证。该地址应直接显示实际文档，无需账户、会过期的预览令牌或开发服务器。将链接放在页脚、注册、结账及其他相关信息收集位置。原生应用也需要提供容易找到的应用内入口。

我们的隐私政策链接放置指南介绍了这些位置。用手机和键盘测试链接，并确认生产构建包含最新审阅版本。本地开发环境预览成功，并不能证明部署后陌生访客也能打开同一页面。

保存事实答案和批准的文档版本，并记录它们对应的产品版本。新增广告 SDK、AI 服务商、销售地区或调整保留惯例时，重新梳理清单并检查受影响的答案。不要悄悄重写旧版本，导致无法看清用户过去获知的内容。

使用更新指南，围绕实际变化安排审阅。指定负责人检查链接并处理请求。定期提醒可以促使团队审阅，但无法证明产品没有变化。实际目标是让准确文档与产品的真实运行方式相衔接，而不仅是完成一次生成器操作。