你手上有一批用户数据要处理——可能是客服工单、可能是学生名单、也可能只是几条聊天记录。真正卡人的不是「要不要合规」，而是「今天先做哪件事、做到什么程度算够」。这篇给一份按顺序走的清单：先把数据分好级、再把人和链路管住、最后把留痕和响应补上，并说明哪些做法在小团队里不适用。
你手上有一批用户数据要处理——可能是客服工单、可能是学生名单、也可能只是几条聊天记录。真正卡人的不是「要不要合规」，而是「今天先做哪件事、做到什么程度算够」。这篇给一份按顺序走的清单：先把数据分好级，再把人和链路管住，最后把留痕和响应补上，每一步都落到能今天动手的动作上。
顺序别打乱。先分级再上工具，是因为工具选型取决于数据到底有多敏感；先管链路再谈留痕，是因为日志里存什么、脱敏到什么程度，得先知道数据从哪来、到哪去。下面三节按这个顺序走，每节末尾都写了什么情况下可以少做，别为了流程而流程。
第一步：先分级，别急着上工具
分级是整份清单的地基。用两条线同时判断：这条数据能不能对外说，以及泄露之后谁会受损失——是公司自己，还是能被定位到的具体个人。两条线交叉，基本能落到三档上，不用搞出七八层，层级太多没人记得住。
| 档位 | 判断特征 | 默认动作 |
|---|---|---|
| 可公开 | 本身就是对外发布的内容 | 正常流转，不额外加密 |
| 内部 | 泄露主要影响公司自身 | 限制批量导出，账号到期回收 |
| 敏感 | 能定位到具体个人 | 脱敏后再进测试，访问逐一登记 |
敏感档还要再问一句：里面有没有身份证号、联系方式、健康或行踪这类字段。有的话，处理强度再上一级；没有的话，按敏感档基础动作走就行。这个判断花不了十分钟，但决定了后面所有动作的松紧。
- 分级表一页纸写完，三列：字段名、档位、谁能看，放在团队共享位置，别只存在某个人脑子里。
- 敏感档字段列一张清单，注明每个字段进测试环境前要替换成什么，替换规则写死在脚本里而不是靠人记。
- 档位不是一次定终身，业务变化时回来改，但要留个修改记录，说明为什么改。
- 公开档不用过度加密，把流程堆在低风险数据上只会拖慢业务，还容易让团队对整套流程产生抵触。
什么时候不适用：如果你处理的是完全匿名化、且无法通过任何字段组合还原到个人的数据，敏感档那套额外流程可以省掉。但省掉的前提是留一份匿名化方法的说明——用了什么处理、为什么认为不可还原——出事时能拿它自证。拿不出说明，就得按敏感档走。
第二步：把人、账号和调用链路管住
数据泄露的常见入口不是被黑客攻破，而是权限给太宽、离职账号没收、测试环境混用生产数据。这一节的动作围绕「谁能碰、从哪条路出去」展开，不涉及具体产品选型。
- 按最小权限发账号能看汇总的不看明细，能读的不给写。发权限时在申请单上写清楚用途和期限，到期自动失效，别靠人记得去关。
- 人员变动当天回收权限离职、换岗、外包合作结束，当天核对账号清单。验证方式是拿权限清单跟当前在岗名单对一遍，两边对不上就说明有漏。
- 画一条数据出境路径调用外部模型或第三方服务前，先回答：这条数据发出去之后落在谁的日志里、存多久、能不能删。答案写下来，不确定的就先不发。
- 敏感字段进提示词前先替换替换或打码在本地完成，别指望下游帮你兜底。验证方式是拿一条真实样例走一遍全流程，看看中间环节有没有还原出原值。
- 测试环境用合成数据生产和测试用不同数据集。合成数据要确认不包含任何真实个人的组合特征，不能只是把名字换成张三。
关于外部调用的判断原则，可以先到 安全与合规（/safety） 分区看相关篇目，具体场景下的取舍对照着看更快。中转站类服务的可信度怎么判断，站内另有专门页面，这里不重复。
什么时候不适用：如果你的数据只在本机、离线模型里跑，完全不出网，第三方链路那部分风险可以降级。但本地留痕和权限管理不能省——离线环境一样会有内部人员导出、误发这类问题。
第三步：留痕、自查和出事后的顺序
留痕常被误解成「把原文都存下来」，其实反了：记录谁在什么时间调用了哪类数据、结果去了哪里就够了，原文里不该出现的字段最好压根不落盘。日志里到底不该出现什么，到 日志里不该出现什么：脱敏与留存速查（/log-redaction-retention） 逐条对照清理，比凭印象删更可靠。
- 调用留痕
- 记谁、何时、调用哪类数据、结果去向，不记原文内容。
- 导出记录
- 批量导出单独记一笔，包含数量、用途、审批人。
- 脱敏样例
- 每个敏感字段准备一组替换前后样例，用来跑回归验证。
- 权限清单
- 当前谁有什么权限的快照，定期与在岗名单核对。
自查按固定节奏走：权限清单核对一遍、导出记录抽查一次、脱敏规则跑一遍样例。节奏多快取决于数据量和人员流动频率，小团队一个月一次也够，别硬套别人的周期。查出来问题就写进待办，别只在群里说一句。
出事后顺序是「先止损、再确认范围、最后对外沟通」。止损包括吊销泄露路径上的账号和密钥；确认范围包括查调用记录和导出记录，圈出可能受影响的数据和人；对外沟通再往后。具体到吊销、查账、留证的动作，站内已有泄露应急与举证方向的篇目，这篇不重复。
自查和应急的节奏不是越快越安全。频繁自查会打断业务，间隔太长又失去意义，务实做法是把自查绑在已有的节奏上——比如版本发布、季度总结这类节点顺手做，比单独设一个没人执行的周期更容易坚持。
下一步分级表定好之后，建议顺手核一下你正在用的外部服务在日志和留存上的实际做法，再决定哪些字段可以出网。到站内安全与合规分区对照着看，比拍脑袋判断靠谱。→常见问题
小团队没人专门做合规，从哪件事开始最划算？
先做分级和权限回收这两件。分级不用工具，一页表格就能完成；权限回收只要把离职和换岗的账号清一遍，成本低、效果直接。加密和审计日志可以往后放，等业务稳定再加。
数据脱敏之后是不是就安全了，可以随便用？
不是。脱敏降低的是直接识别风险，但如果多条脱敏记录还能被拼回同一个人，风险依然在。要不要额外限制使用范围，取决于你的数据里有没有准标识符字段，这点站内数据脱敏相关篇目讲得更细。
调用外部模型时，怎么判断这次能不能发？
问三个问题：字段能不能定位到具体人、服务方的日志留存和用途约定写没写清、这次调用有没有必要用到原始值。三个都过关再发；只要有一个说不清，就先脱敏或用合成数据替代。
