哪些数据需要脱敏

不少团队的脱敏是「看到手机号就打码」，结果提示词、日志、附件、导出文件里还留着能拼出身份的组合字段。这篇给一套可执行的梳理顺序：先按数据类型和业务场景划分范围，再对照数据生命周期的采集、传输、入模、落库、导出、销毁各阶段决定在哪里介入，最后附自查清单和不适用情形。

很多团队的脱敏动作只有一条：看到手机号就打码。结果提示词里留着姓名加部门，日志里留着完整身份证，附件和导出表格原封不动，几个字段一拼还是能定位到具体的人。问题不在做得不够狠，而在于没先把「哪些数据算敏感、要脱到什么程度、在哪一步动手」框清楚。

这篇给一套可执行的梳理顺序：先按数据类型和业务场景划范围，再对照数据生命周期的各个阶段决定在哪儿介入最划算，最后附自查清单和几种其实不必脱敏的情形。范围不清就动手，往往是该脱的没脱，不该改的改了一堆。

先按数据类型划范围：这几类优先，剩下的排后面

划分范围时不要按「字段名里有没有 phone、id」来筛，而是按「这个字段能不能指向一个具体的人或一份具体的事」来判断。下面四类按优先级从高到低排，前两类是所有团队都得先过一遍的。

判断准标识类是否要处理，有个简单办法：把候选字段列出来，问一句「这几列合在一起，能否在百人以上的名单里唯一定位一个人」。能定位的，就按直接标识同等对待。这一条对中小团队尤其重要，因为样本越小越容易重识别。

再按场景定优先级：不是所有数据都要同等对待

同样的数据，发给外部和留在内网，处理强度应该不一样。用「数据出不出你的可控边界」当作第一道分界线，比按数据类别一刀切更省人力。

• 要发给外部模型或第三方服务的，按最严的一档处理，边界怎么划可以参考站内 API Key 安全和数据边界审计相关的判断口径
• 只在内网流转、访问权限已经收敛到具体人的，可以放宽到审计可见、明文可查，但要有访问记录
• 用于测试、演示、培训的样本，一律用构造数据替换，不要拿生产数据改几个字就上
• 对外发布的报告、榜单、案例，脱敏对象还包括统计颗粒度，太细的交叉维度本身就是泄露
• 涉及多人协作的表格和文档，注意历史版本和评论里是否还留着改之前的原文

数据生命周期里，脱敏该在哪几步介入

脱敏不是某个环节的一次性动作，而是沿着数据流动路径布几个卡点。下面按采集、传输、入模、落库、共享销毁的顺序给排查动作，每一步都能单独验证。

1. 采集与录入对着表单和导入模板过一遍，能在源头不收的字段直接删掉，能分字段存的别塞进一个备注框。验证方式：随机抽三条新录入的数据，看有没有把证件号、电话写进自由文本。
2. 传输与调用出网前做一次过滤，重点是提示词、附件和请求体，别只盯结构化字段。验证方式：抓一次真实的外部调用，把请求内容整体看一遍，而不是只看那几个你记得的字段。
3. 入模与推理上下文里出现的标识符要么替换为占位符，要么在会话结束后按策略清理。验证方式：会话结束一段时间后，回查历史记录里还能不能搜到姓名或手机号。
4. 落库与日志日志侧的取舍可以对照站内日志脱敏与保留策略的思路；导出台账、备份文件和临时缓存常被忽略，要一并纳入。验证方式：从备份里恢复一份到独立环境，搜一遍敏感字段。
5. 共享与销毁对外提供数据前再查一遍，销毁要确认备份、缓存、导出副本都覆盖到。验证方式：列出一份「这批数据存在哪几个地方」的清单，逐个确认处理状态。

脱到什么程度算够：分级、留痕与不适用情形

脱敏不是越狠越好。把需要保留的格式也打乱，下游分析就跑不动，业务方会绕开流程自己另存一份，反而更危险。按用途分级比一刀切更实际。

替换或泛化

能定位到个人的字段，换成占位符或更粗的粒度，例如把具体生日改成年龄段

聚合或加噪

只用于分析的场景，输出统计结果而不是明细，必要时叠加扰动降低反推可能

映射表分离

替换规则和对应关系要和脱敏数据分开存放、分开授权，否则等于没脱

处理留痕

记录谁在什么时候对哪批数据做了什么处理，出问题时能追溯责任和影响范围

最后说说不适用的情况。数据量极小、维度极少的样本，脱敏后仍可能被反推出来，这种情况下要么干脆不共享，要么先做聚合再谈脱敏。还有一种情况是数据本身已经公开且可交叉验证，例如官网公示信息，重复脱敏只是浪费人力，但要注意别把公开信息和其他字段组合出新的可识别结果。

如果你所在团队同时用多家官方 API 或中转服务，判断边界时最好把「数据流向哪几家」也列出来，各家的数据处理口径不一样，具体条款到站内的中转站评测和价格追踪页面核对当时的信息，别凭印象。