数据合规趋严之后，产品设计要多想哪几步

一、背景：先说明我写的是什么、不是什么

这几年公开讨论里，个人信息保护相关的要求在变严，最小必要原则被反复提到，数据出境与跨境传输的讨论也明显增多。这些是公开可见的趋势，我只观察到这一层。

这篇不解读具体法条，也不提供法律意见。我写的是产品设计层面的动作：合规要求变严，最先受影响的往往不是法务，而是字段设计。法务给的是原则，落到产品上就是几个很具体的问题——这个字段收不收、存多久、谁能看。这几个问题答不清楚，后面的流程再规范也很难补。

二、我在设计时会先问的四个问题

1. 这个字段是否必须收集

判断方法很笨：假设没有它，功能能不能完成。多数情况下答案是能，只是体验差一点，或者运营同学要多做一步。把「体验差一点」和「合规风险」放在一起比较，选择通常不难。难的是承认那个字段本来就是为了「以后可能有用」才加的。

2. 用途能不能一句话说清

说不清通常意味着两种情况：用途本身模糊，或者一个字段背了三个目的。前者应该先想清楚再收，后者应该拆开。我会要求自己在字段表里写一句话，如果写出来需要用「以及」连接三次，这个字段的设计就有问题。

3. 保存多久

没有期限的字段迟早变成负担。期限不只是「存多久」，还包括到期之后怎么处理：删除、匿名化，还是转成统计口径。我会写一个具体期限，而不是「长期保存」。写不出期限，往往说明没人想过它什么时候没用了。

4. 谁可以看到

这一条最容易糊弄过去。只写「内部可见」等于没写，因为内部可能包含很多角色和很多场景。我会按角色和场景分别写：谁能看全量、谁能看脱敏后的、谁在什么条件下能导出、导出之后有没有记录。写完这张小表，很多权限问题会自己浮出来。

三、最小化收集清单

下面六条是我做新功能时会逐条过的清单。它不保证合规，但能挡掉大部分「本来可以不收」的情况。

• 默认不收集：新功能先按零字段设计，需要时再加，而不是先收着备用
• 能派生就不重复收集：能从已有字段算出来的，不再单独让用户填一遍
• 必填项降到真正必要的：其余改成选填，并说明填了之后有什么具体变化
• 日志不记录敏感字段：请求参数、返回体、错误信息都要过一遍，错误信息最容易漏
• 提供删除与导出路径：用户能找到入口，并且这条路径在正常权限内可以完成
• 字段分级并写清可见范围：每个字段标注级别与可见角色，落在字段表里而不是口口相传

这份清单里，最容易被跳过的是第四条。大家检查字段表时会很认真，但日志往往被当成技术细节。实际上日志会复制一份数据到另一个地方，权限更松、保留更久，出问题时却最容易被忽略。

四、设计上可以立刻做的三个动作

第一个动作，字段表加三列：「用途 / 期限 / 可见范围」。加完之后，很多字段自己就显出问题——用途写不出来，或者期限只能写「长期」。这三列不需要复杂工具，一张表就够，关键是每次评审都看。

第二个动作，默认关闭非必要采集。开关默认关，愿意开的用户自己开，并且能看见开了之后有什么变化。默认开启的采集看起来省事，但它把判断责任推给了用户，而多数用户不会去关。

第三个动作，把删除做成产品功能，而不是工单。工单意味着要有人处理、有排队、有遗漏，还常常需要用户重复描述；功能意味着用户自己能完成，后台留有记录。这个改动通常不大，但它决定了删除这件事是真的能发生，还是只写在说明里。

五、和法务、安全协作时，描述数据流比交字段表更有效

只交一张字段表，通常会被追问「这个数据从哪来、经过谁、最后给谁看」。我现在会附一段数据流描述：从哪个入口收集、经过哪些系统、存在哪里、哪些角色能访问、什么时候删除。描述不需要画得很漂亮，但每一条要能对上实际环节。

这样做的好处是讨论能落到具体位置，而不是停在原则层面。法务关心的是范围和授权，安全关心的是传输与访问控制，一段数据流能把两边的问题放在同一页上。比起反复解释「我们只收必要的」，不如直接指出哪一步收了什么、为什么收。

六、我踩过的三个坑

第一个，为了「以后可能用」多收字段。收的时候觉得不多，两年后没人说得清哪些还在用，也没人敢删。后来我们做了一次字段盘点，发现大约三成的字段没有任何读取记录。

第二个，测试数据用了真实信息。测试环境权限松、日志全，真实信息进去之后扩散得比想象中快。后来统一改成构造数据，需要真实分布时用统计特征，而不是真实记录。

第三个，导出功能没有权限校验。导出往往是最容易被忽略的入口，因为它看起来只是一个按钮。导出范围、字段范围、操作记录，三样都要有，缺一样就等于把前面的控制全部绕开。

七、结尾

合规不是上线前的一次检查，是字段设计时的几次停顿。每次多问一句「这个字段真的需要吗」，后面能省下的解释和清理，通常比停顿花的时间多。我至今也没做到每次都问，但问的次数比几年前多了不少，返工也少了不少。