为什么合规检查总是显得太晚
当产品已经完成数据表、接口、页面和运营流程后，再试图添加用户同意、删除、权限隔离或日志往往会牵动多个模块。问题不在于团队没有写一份检查表，而在于关键能力没有成为架构的一部分。
“默认考虑合规”并不意味着每个开发者都要成为法律专家。更实际的做法是把经常重复的控制目标建设成共享能力，并在需求、数据和测试中对它们进行明确验收。
五项应当进入架构的能力
1. 数据最小化与字段责任
每个个人信息字段都应当能回答收集目的、使用位置、访问角色、保存期限和删除方式。如果无法说明，就应评估是否必须收集。
2. 统一身份与最小权限
认证、授权和业务权益需要分层处理。后台不应使用一个“超级角色”覆盖日常工作，高风险操作应当设置二次确认、审批或多因素认证。
3. 统一保留与删除机制
删除不是在一张表中执行一条语句。它还涉及搜索索引、缓存、对象存储、日志、数据仓库和备份。产品需要定义活动数据的删除、备份的循环覆盖和存在保留义务时的限制处理。
4. 可配置的告知与同意
政策文本、版本、适用范围、用户确认时间和重新同意条件应当结构化保存，而不是只把一段文本写在页面里。
5. 分级日志与审计
安全日志、业务日志和分析数据应当区分目的、保存期和查看权限。不应把完整敏感内容默认写入普通运行日志。
“做了”与“能证明做了”
商业系统不仅要执行控制，还需要在设定权限下证明控制曾经执行。例如，一次权限变更需要留下申请人、审批人、变更前后、时间和原因；一次高风险数据导出需要记录范围、用途和处理结果。证据链应当避免不必要地复制业务数据，同时防止一般用户篡改。
每一次变更都可能改变合规结论
新增一个字段、更换一家供应商、调整一个接口返回或将数据用于新的分析目的，都可能引入新的处理活动。因此，需求和代码变更流程应当包含数据与合规影响的识别项，对高风险变更触发专项复核，并保存结论与依据。
如何开始
对已运行的产品，不需要等待一次“全面重构”。可以先从三件事开始：建立数据和系统清单；对高风险角色与操作实施最小权限；将导出、删除、权限变更和政策版本纳入可追溯管理。随后通过每一次功能迭代，逐步将通用控制收敛到平台能力中。