Legal Skill 隐私协议 AI 合规 数据合规 OPC Founder

最近法律人开源的东西越来越多。

有人开源合同生成 Skill，有人开源审查工作流，也有人把自己在某个细分业务里踩过的坑，整理成可以复用的工具。

我们也把自己在 AI 合规和数据合规领域的经验，做成了第一个可以拿出来开源的产品：

项目地址在这里：

https://github.com/xiarenzhimajuan-ailaw/privacy-policy-self-service-generator-mvp

我们的口号很直白：

开源什么，其实是个选择题。

真正需要判断的活儿，比如一个功能有没有数据合规风险，在执法口径下站不站得住，依赖实务经验，还是律师的领域。

但还有一类活，本来就不太需要律师。客户自己也在用 AI 搞，只是搞得似是而非，风险埋在看不见的地方。

比如隐私协议。

一些功能简单的 App、小程序和早期网站，第一版隐私协议未必需要一开始就做成深度法律意见。微信小程序上线时也有官方隐私保护指引和模板入口。很多团队真正卡住的，不是复杂法律判断，而是压根不知道从哪里开始。

这种事，我甚至愿意直接让当事人先去问 AI。

先有个大概认知，再决定要不要找人。

问完还觉得需要律师，那也好，至少我们有了能往下聊的基础。

问完问题就解决了，那效率更高。

所以这次干脆把工具做好，直接交到他们手里。

于是市场上出现了几种经典做法。

第一种，复制一份大厂隐私政策，把产品名和公司名换掉。

第二种，让 AI 生成一份看起来还行的。

第三种，先不上。

主打一个产品先跑，合规在后面追。

这次开源的 Skill，就是来解决这个问题的。

我做这个 Skill 的起因，是看过太多 AI 生成的隐私协议。

长，很长，非常长。可即便这么长，内容遗漏和硬伤照样一大堆。

更离谱的是，我之前看过一份黑客松的隐私协议，差不多三万字，最初版本里居然完全没有提到「未成年人」。

这就很魔幻。

一个面向大量青少年参与者的活动，隐私协议写了三万字，却没有看见未成年人。

会让 AI 写出很长的隐私协议，不代表真的理解自己的数据流转。

很多 founder 对隐私协议的理解，还停留在一个非常朴素的阶段。

上线前找个模板，换个产品名，换个公司名，再加一句「我们高度重视您的隐私」，然后放到网页底部。

一套流程下来，很像给产品贴了一张合规创可贴。

问题是，隐私协议不是网页装饰。

它要回答的是：你的产品到底怎么处理用户数据。

《个人信息保护法》第十七条说得很清楚。处理个人信息前，要用显著方式、清晰易懂的语言，真实、准确、完整地告知处理者名称和联系方式、处理目的、处理方式、个人信息种类、保存期限，以及用户行使权利的方式和程序。

简单翻译一下就是：

所以这次开源的 1.1.1 版本，只做一件事：

给 OPC 和 founder 生成最初版本的隐私协议 MVP 建议稿。

它主要面向 OPC、founder、个人开发者、独立开发者和早期创业团队，帮助他们在产品上线前，先形成一份符合中国数据合规和 AI 合规基本要求的隐私协议草案。

这也是我想展示给 AI 创业者和律师同行看的地方。

AI 合规和数据合规，首先是一种产品拆解能力。

你要知道产品在哪里收集数据，在哪里调用模型，在哪里接入 SDK，在哪里发生跨境访问，在哪里触发敏感个人信息，在哪里可能涉及未成年人，用户又在哪里退出。

整个流程就三步：

第一步，先问事实，解决「你不知道有哪些」。

先给出一张产品事实清单。

产品叫什么，运营主体是谁，联系方式是什么，产品面向谁，核心功能是什么，收集哪些个人信息，哪些信息是功能必需，有没有用户上传内容，有没有第三方 SDK、API、插件、模型服务、云服务。

如果你的产品是 AI 或 AIGC 工具，它还会继续问：用户上传的图片、文件、提示词，会不会用于模型训练或模型优化；有没有第三方模型服务；有没有公开发布、社区展示、下载、二次创作或对外使用场景。

先把数据流转情况问清楚，后面才谈得上怎么写。

第二步，合规校验，解决「你不知道哪些对」。

这个 Skill 会根据《个人信息保护法》等法律法规、国家标准和合规实践，逐项检查一份 MVP 隐私协议该有的内容：

如果涉及 AI 训练、自动化决策、敏感个人信息、未成年人、跨境传输这些高风险事项，MVP 版本也不能靠一句「相关信息」糊过去。

合规校验这一步，它守着两条原则。

事实不清，不硬写。不知道有没有 SDK，就不会假装没有 SDK；不知道是否跨境，就不会直接写「不存在跨境传输」；不知道用户上传内容是否用于训练，就不会替你写「我们不会用于训练」。

不确定的，不替你拍板。该留空、该标成待确认的，就让你来完成。

注意，是 MVP。

不是低标准。

MVP 的意思是正文可以短一点，结构可以轻一点，但核心告知不能空着。

第三步，MVP 协议生成与复查。

它会在最小范围内，生成一份可以继续迭代的隐私协议建议稿，同时输出个人信息收集简表、第三方 SDK / API / 插件 / 合作方简表、用户权利路径简表，以及本版忽略或简化的内容、后续完善事项和复查报告。

很多自动化工具填完空就收工了。

这个 Skill 生成完才算开始。它会回头扫一遍：哪些字段其实没问实，这一版简化了什么、跳过了什么，后面还要补什么，全都标出来，写进复查报告。

AI 在不知道产品真实数据流转的情况下写错隐私协议，可能会把 SDK、模型训练、跨境访问、未成年人、用户删除路径这些关键问题一起写没了。

所以它要先把产品事实问出来，再用法律法规和相关标准核对，最后在最小范围内生成一份能继续迭代的 MVP 隐私协议建议稿。

这个 Skill 在动笔之前，会把产品的数据事实一条条问清楚：收集了哪些个人信息，哪些是功能必需，有没有第三方 SDK，用户上传内容会不会用于训练，有没有跨境访问，有没有未成年人，有没有敏感个人信息。

这串问题，本身就是一份自查清单。

你完全可以不生成任何协议，只拿这串问题，对着自己的产品过一遍。

能一条条答上来，说明你对自己的数据流转是清楚的，协议怎么写都不会太离谱。

答不上来，那协议先别急着写，先把产品搞明白。

这个项目目前只是 1.0。

后面我会继续做两个方向。

v2.0 会面向完整深度版隐私协议，适合产品事实已经比较完整的团队。

到了这个阶段，隐私协议就不能只写基础信息了。SDK 清单、权限清单、第三方服务商清单、AI 训练规则、保存期限、跨境判断、委托处理、自动化决策，这些都要进一步展开。

v3.0 会面向基于 MVP 协议的持续扩充。

很多产品不是一次长成的。

今天只是网页工具，明天加登录，后天加支付，再过一阵子接入模型服务、内容审核、云存储、推荐算法、会员系统。

协议也应该跟着产品一起更新。

这也是我们想长期做的事：在 AI 合规、数据合规这些复杂、琐碎但高频场景里，一个个把能开源的工具做出来。隐私协议 MVP 生成器是第一个，后面还会有更多 Skill。

很多 AI 产品的服务条款里，都会写类似这样的免责声明：AI 输出可能不准确、不完整、过时或者具有误导性，不应被视为事实或专业建议；用户应当自行评估输出的准确性、合法性和适用性；不得把 AI 输出直接用于法律、金融、医疗等会对个人产生重大影响的决策。

这个 1.1.1 版本生成的是隐私协议 MVP 版本建议稿，仅供参考。

它适合帮 OPC、founder 和早期团队把最初版本先立起来，把个人信息处理者、产品范围、个人信息类型、第三方 SDK、AI 功能、模型训练、跨境访问、用户权利路径这些基础问题先说清楚。

但如果你的产品数据流转很复杂，比如涉及未成年人、敏感个人信息、跨境传输、AI 训练、自动化决策、金融、医疗、教育、大规模用户数据，或者已经进入平台审核、B 端客户采购、融资尽调、监管沟通这些场景，就不要只停留在工具生成。

这时候就需要找专业法律人士了。

也可以找我。

真正复杂的数据合规问题，最后还是要回到具体产品、具体数据、具体链路里解决。