合规不是上线前的补丁：它是产品的第一版架构

早期团队对合规的标准态度是：「先跑起来，等监管找上门、等平台审核卡住、等客户问了再说。」这个策略听起来省时间，实际是把一笔小钱换成一笔大钱。我们陪跑过的项目里，凡是上线后再补合规的，没有一个不返工——区别只是返工发生在上架审核、融资尽调，还是大客户采购这三关的哪一关。

先看几组公开数字。GDPR 的罚款上限是全球年营收的 4% 或 2000 万欧元，取高者；苹果 App Store 早就强制填报隐私标签，数据收集类型答错会直接拒审；企业客户采购 SaaS 之前先发一份几百道题的安全问卷，已经是行业标配。我们自己的账更直观：一个工具类产品因为用户数据存错了区域，上架被卡了 6 周；另一个项目在融资尽调时被要求补数据处理协议和完整的审计日志，两个工程师返工了两个月。行业里那句老话依然成立——上线之后再补合规模块，成本大约是开发初期就内置的 3 倍。

合规其实是三个架构决策

很多创始人以为合规是法务的事，找个模板写份隐私政策就完了。落到工程上完全不是这么回事——合规是三个必须由架构来回答的问题：

• 数据放哪。用户数据存在哪个区域、跨境怎么流动，这是数据库选型和部署架构的决定。等产品有了十万用户再迁移存储区域，动的是地基。
• 数据留多久。用户注销后数据删不删、多久删、备份里的副本怎么办。「删除权」不是一句文案，是一套要真能跑通的级联删除逻辑。
• 谁能看。内部员工能不能看到用户数据、看了留不留痕。权限模型和审计日志是第一版就要建的表，后期补等于把后台重写一遍。

你会发现，这三条没有一条是法务文档能解决的——它们全是数据表结构和系统架构层面的决定。这就是为什么「先上线再补」必然返工：你补的不是纸，是结构。

第一行代码就能做的四件事

• 建一张数据分类清单。列清楚产品收集的每一类数据：必需的、可选的、压根不该碰的。最小收集是性价比最高的合规动作——没有的数据永远不会泄露。
• 把删除和导出做成真功能。用户能注销、能导出自己的数据，这两条写进第一版开发清单。它们既是合规要求，也是最直接的信任建设。
• 审计日志从第一天开。谁在什么时候读了什么、改了什么，全部留痕。建表成本大约一天，后期补是两个月，而在尽调和出事故的时候，它的价值无法估量。
• 依赖项过一遍许可证和数据流向。接第三方 SDK 之前想清楚它把数据发去了哪。很多产品的合规窟窿不在自己的代码里，在集成的别人的代码里。

有人会说：我们是小团队，没预算做这些。上面四个动作加起来不到一周工时，比一次上架被拒、一次尽调卡壳便宜几个数量级。合规真正的成本从来不是「做」，是「晚做」。

51Kaifa 做「2 周 MVP」时，交付清单里固定有一页「数据与合规基线」：数据分类、删除导出、审计日志、隐私政策挂接。它不性感，演示日也没人给它鼓掌，但它是产品能走进上架审核、尽调会议室和大客户采购流程的门票。好产品的完成度，本来就包括「经得起检查」这一层。