合规评审会上最常吵的一句话是「这份数据到底该脱敏还是加密」。吵不出结果，通常是因为两边说的不是同一个问题：一个在讲能不能给人看，一个在讲丢了好不好恢复。这篇给一套可落地的判断顺序——先分清数据在谁手里、要防的是谁，再决定单独用哪种、还是两层一起上，最后附一份选型时的核对清单。
合规评审会上最常吵的一句话是「这份数据到底该脱敏还是加密」。吵不出结果，通常是因为两边说的不是同一个问题：一个在讲能不能给人看，一个在讲丢了好不好恢复。先把问题翻译成同一句话，讨论才推得下去。
这篇给一套可落地的判断顺序——先分清数据在谁手里、要防的是谁，再决定单独用哪种、还是两层一起上，最后附一份选型时的核对清单。全程只给判断标准和动作，具体的技术参数和当时的行情数字，一律回到站内对应页面核对。
先分清数据在谁手里、要防的是谁
选型的第一步不是问技术，而是问场景。同样是「一份用户信息」，留在自己系统里给客服看、打包给外部供应商、丢到离线环境跑分析，这三件事该做的事完全不一样。先把它落到哪一类，后面才有讨论的基础。
- 数据留在自己系统里，主要给内部人用：重点是权限、审计和最小可见，防的是内部越权看
- 数据要交给外部供应商或第三方：重点是外发那一刻的形态，防的是离开你控制范围之后的二次扩散
- 数据只在离线测试、演示、分析里用：重点是能不能还原，不需要真值的场合尽量不要留真值
- 先用一句话写清这份数据在最坏情况下会被谁看到，写不出来说明需求还没定义清楚，选什么都会返工
需要提醒的是，数据出境、跨主体流转这类场景会额外触发评估类要求，路径本身怎么选涉及另一套判断，可以到站内 /safety 分区的相关文章去核对，不要把这一步和脱敏加密的技术选择混在一次会里定。
按用途对比：什么时候脱敏、什么时候加密
一句话概括区别：脱敏改的是内容本身，改完通常不可逆或者很难还原；加密保的是形态，钥匙还在，程序照常读写。记住这个区别，绝大多数选型问题都能自己回答。
| 判断维度 | 适合脱敏 | 适合加密 |
|---|---|---|
| 要不要还原成原值 | 不需要，看到的是替代值就够 | 需要，程序还要正确读写 |
| 主要防谁 | 防拿到数据的人直接识别出个人 | 防介质丢失、库被拖走、传输被截 |
| 典型场合 | 测试环境、外部分析、演示截图 | 落库、备份、传输通道、日志留存 |
| 代价 | 改完就回不去，后续分析口径可能变 | 权限和钥匙管理复杂，漏管等于没做 |
| 常见叠法 | 展示层脱敏 | 存储层加密 |
| 失效方式 | 替代规则没覆盖到间接标识，仍可反推 | 解密权限没审批留痕，等于摆样子 |
两者不互斥。常见做法是存储层加密、展示层脱敏，同时在日志和导出环节再脱一次。各环节能覆盖到什么程度，可以参考站内术语页 /ai-dict/category/safety 的对照，那里对每类字段的常见处理方式有归纳。
选型清单：立项前把这 5 件事问完
下面这五问不是走流程，而是每一项都对应一个上线后容易翻车的点。建议在方案评审前逐条填答案，填不出来的先补需求，别急着选产品。
- 一问字段按字段而不是按整张表定策略。同一张表里手机号要脱敏、金额可能要加密、备注可能得整列禁止导出。逐列过一遍，标出各自的处理方式，落到字段级清单上。
- 二问链路数据从产生到销毁经过哪几个系统，每个系统里它处于什么形态。链路上任何一环没覆盖就等于没做，用一张简单的流向图把形态标出来。
- 三问权限谁有解密权限、谁有还原权限、这些权限怎么审批和留痕。没有审批留痕的加密基本等于摆样子，权限清单要能对上具体岗位。
- 四问验证怎么证明策略生效——抽样比对、导出测试、越权访问测试，至少留一份可复现的记录，测试用例要能被别人重跑。
- 五问例外哪些人、哪些临时任务可以绕开策略，例外怎么登记和回收。没有例外机制的方案上线后一定会被业务私开旁路，不如提前把出口设计好。
这五问的答案建议写成一页纸的表，每季度回看一次。涉及供应商能否满足这些要求时，去站内 /providers 看该中转站或供应商的资料页，再用 /tools/speed-test 做一轮实际验证，别只看销售给的说法。
哪些情况下这套选法不适用
上面这套是给「数据有外部接触面、有人有权限看」的场景准备的。如果条件不成立，硬套反而是负担，下面几种情况要主动收手。
- 数据量极小、只在单机内部流转、没有外部接触面的场景，硬上两套机制往往是负担，优先管好权限和备份更实际
- 完全不可逆的强脱敏会让很多分析场景失效，遇到这种需求要提前跟业务说清，不要上线后才发现数据没法用
- 如果关键字段本身就是间接标识，脱敏之后仍能组合反推出个人，这种要按重新识别风险单独评估，不能只做字段替换
- 涉及具体条文和阈值时，以站内 /safety 页面当时的版本为准，监管口径经常更新，写死的做法容易过期
- 涉及费用和供应商报价时，去 /official-api 和 /providers 看当时的数字，不要按任何固定值估算
最后一条经验：合规方案不是一次选完就结束的事。业务形态一变、数据流向一变，之前的分层可能就漏了。把这份清单挂进变更流程，比一次性做一套很重的方案更稳。
下一步把本文的五问清单对着你手上这份数据逐条填一遍，填不出的项目就是下一轮要补的需求；需要对照术语和监管口径时，去站内安全分区核对当时的版本。→常见问题
脱敏和加密能不能只做一个？
可以，取决于最坏情况。如果数据永远不需要还原、只给不该看真值的人看，脱敏就够；如果数据还要被程序正确读写、丢了要能恢复，就必须加密。两者都省不掉时，通常是先加密保证可还原，再在展示和导出环节补脱敏。
已经加密了，还需要脱敏吗？
需要，因为加密防的是拿到密文的人，防不住系统里本来就该看见明文的人。客服看订单、运营导报表、日志打点，这些环节里数据是明文的，靠脱敏把真值换掉才有意义。反过来只脱敏不加密，存储介质丢了或库被拖走仍然有风险。
选型时最容易踩的坑是什么？
按整张表一刀切。结果是该保护的字段漏了，不该动的字段被改得没法用，业务回头就绕过流程。比较稳的做法是按字段定策略、按链路查覆盖、把例外登记成明文流程，再留一份可复现的验证记录。
