第六章 数据安全质询
6.2 数据脱敏与私有化取舍
承前：上一节我们用数据流向图和字段级分级清单化解了叫停危机，其中反复出现一个词——"脱敏后可用"。这一节就把它展开：脱敏到底有哪几种做法、各自牺牲了什么；以及一个更上游的决策——要不要干脆不上云，直接私有化部署。脱敏和私有化，是同一条安全光谱上的两个点：前者是"把数据洗了再出门"，后者是"根本不出门"。选哪个点，取决于成本、性能、安全、合规的四维权衡。
6.2.1 脱敏是"降价"，不是"免责"
先建立一个正确预期：脱敏的本质是用数据的信息量换安全性。任何脱敏手段都会让数据失去一部分信息，模型看到的是"打了码"的世界，效果必然受影响。所以脱敏方案设计的核心问题从来不是"怎么脱最安全"（全部替换成星号最安全，但模型也就废了），而是在安全底线之上，保留完成任务所需的最小信息量。
打个比方：你要请一个外地顾问看病历，但不能让他知道病人是谁。把名字涂掉、生日只留年份、地址只留城市——顾问照样能判断病情（业务目标），但反推不出病人身份（安全目标）。涂掉的信息越多，越安全，但涂到连症状都看不见，顾问就白请了。医生要的是"病例的形状"，不是"病人的名字"。
这个视角能帮你避开最常见的沟通陷阱：安全部门天然想多涂，业务部门天然想少涂。FDE 的价值是把争论从立场拉回到任务需求：先定义模型要用这份数据完成什么判断，再倒推哪些字段是判断必需的，哪些只是"顺手都给"。
6.2.2 三种基本手段：掩码、替换、泛化
脱敏手段有很多名字，但归纳起来是三类。用青禾优选的会员数据做例子：
掩码（Masking）：遮住一部分，保留形状。手机号 138****5678——人眼和程序都知道这是个手机号，但定位不到具体的人。适合需要保留数据格式的场景：模型要判断"这是不是有效手机号"，掩码后格式还在。代价：如果中间四位也能定位到个人（小城市号段），掩码不够安全。
替换（Substitution / Pseudonymization）：换成假值。张三换成"会员A_0012"，所有出现张三的地方一致地换成同一个代号。这是对模型最友好的方式——个体关系全部保留（同一会员的多次消费仍然关联），只是身份标签变了。GDPR 把这种手段叫"假名化"：它降低了风险但不算匿名——只要代号映射表还在，就能还原。所以映射表本身要单独加密保管。模型侧的典型用法：拿会员 ID 的加盐哈希当主键，Agent 全程只碰哈希值。
泛化（Generalization）：降低精度。年龄 34 岁泛化成"30-40 段"，地址泛化到"城市+城区"，消费金额取整到百位。适合统计分析型任务：模型要判断"这个客群的消费趋势"，精度损失换来了不可定位。
三种手段经常组合使用，按字段定级：
字段脱敏策略示例（青禾会员场景）
字段 等级 手段 模型还能用它做什么
─────────────────────────────────────────────────────────
member_id 高敏 加盐哈希替换 唯一标识个体、关联行为序列
phone 高敏 掩码+不出链路 格式校验（仅此而已）
name 中敏 一致性替换 "某会员"上下文指代
birth_year 中敏 泛化(年龄带) 生命周期分层判断
address 高敏 泛化(城市级) 区域维度分析
consume_amt 低敏 取整泛化 复购/客单趋势分析
member_level 低敏 不脱敏 核心业务判断（本来就要用它）
─────────────────────────────────────────────────────────注意最后一行：不是所有数据都要脱。会员等级、品类偏好这类低敏数据是模型做业务判断的原料，全脱了项目就没有意义。字段级策略表的价值就在于精确到"哪些脱、怎么脱、脱完还剩什么用途"。
顺带纠正一个概念混淆：传输加密和存储加密不属于脱敏。TLS、磁盘加密是"运输和仓储安全"，解决的是"数据在路上/在库里被偷看"；脱敏解决的是"数据被合法拿到手之后还认不认得出人"。两者是互补的两类控制：加密防中间人，脱敏防终点滥用。给安全部门的材料里要分开写，混在一起会显得不专业——也确实有厂商拿"我们全程加密"来模糊"数据到了我们手里会怎样"的问题。
6.2.3 工程实现：脱敏放在链路的哪个位置
策略定了，工程上要选脱敏的执行位置。三个选项，安全性和工程成本递增：
- 出口脱敏（Agent 底座网关处）：在数据离开客户环境前的最后一关做统一脱敏。优点是集中、改一处管全局；缺点是"最后一关"之前的内部链路（日志、缓存）里数据还是原文。
- 源脱敏（数据从 CRM/数仓取出时）：在数据源头就转成脱敏视图，Agent 从头到尾只碰脱敏数据。最安全，但要改动客户数据架构，协调成本高。
- 字段级动态脱敏（查询时按角色实时脱）：数据不动，按调用者角色在查询层实时处理——这其实已经是 6.3 节字段级权限的范畴，下一节展开。
沙盘里青禾选的是方案 1 起步、逐步向方案 2 演进：先用网关层规则引擎（正则 + 实体识别）拦住高敏字段，等业务验证通过后再推动 IT 建设脱敏数仓视图。工具上，微软开源的 Presidio 是常见起点——它提供 PII 识别（Analyzer）和脱敏执行（Anonymizer）两个模块，支持掩码、哈希、替换、加密等操作符，可以内嵌在自己的管道里；但要清醒：它官方文档明确提醒自动检测不能保证找出所有敏感信息，规则必须叠加客户自己的字段清单，而不能只靠自动识别兜底。
一个容易被忽略的坑：脱敏要做在 prompt 组装之前，而不是之后。如果组装好的 prompt 里已经带了原文，再在发送前做一次正则清洗，漏检率高（原文嵌在长文本里，格式千变万化）。正确顺序是：结构化数据先按字段策略脱敏，再进入 prompt 模板。
6.2.4 私有化 vs 云端：四维权衡
现在回到那个更上游的问题：既然数据出门这么麻烦，要不要干脆私有化？先给结论：这是一个成本/性能/安全/合规的四维权衡，不是"安全必须私有化"的单选题。错误的安全直觉会把项目引向更贵的方案。
| 维度 | 云端 API | 私有化部署 |
|---|---|---|
| 前期成本 | 近零，按 token 计费 | GPU 服务器（8 卡 A100 级机器月成本数万元起）+ 运维人力 |
| 边际成本 | 随用量线性增长 | 固定成本摊薄，量大后反而便宜 |
| 模型能力 | 最前沿模型随时可用 | 开源模型，前沿能力通常略逊一档 |
| 迭代速度 | 厂商升级即受益 | 升级要自己重新部署、重新评估 |
| 安全边界 | 数据物理离开客户环境 | 数据全程不出内网 |
| 合规证明 | 依赖厂商条款与 DPA | 边界清晰，审计容易 |
| 团队要求 | 应用开发能力即可 | 需要模型部署运维能力 |
看行业差异就明白了：
- 金融：个人金融信息按行业规范分为 C3/C2/C1 三级（C3 最敏感，如密码、生物识别信息），高敏数据合规要求极严。头部机构普遍走私有化或金融云专区，云端 API 只承接非敏感环节。对于强敏场景，私有化不是选择题。
- 医疗：病历数据敏感度同级别，且医疗数据集大、训练/微调需求多，私有化比例高。
- 零售：恰恰是最灵活的行业——商品、营销文案、品类趋势这类数据敏感度低，上云阻力小；只有会员 PII 需要重点防护。所以青禾的答案不是二选一，而是分层混部：会员级分析走私有化小模型或脱敏后的云端调用，商品知识问答、营销文案生成直接用云端旗舰模型。
决策上有一个实用法则：数据敏感度 × 数据体量。高敏 × 大体量 → 私有化；高敏 × 小体量 → 脱敏后云端或小规模私有化都可行，算 TCO；低敏 × 任何体量 → 云端优先，把预算花在更好的模型上。别忘了那个经典误区：开源模型免费 ≠ 便宜——一台 8 卡服务器的月成本抵得上很多中型项目全年的 API 账单，调用量撑不起来就是纯亏损。
6.2.5 沙盘应用：青禾的分层方案
回到沙盘。数据分级评审后，方案收敛成三块：
- 会员级个体分析（谁会流失）：模型只需要行为模式的形状，不需要身份。用加盐哈希替换 member_id，手机号干脆不出链路（用哈希 ID 做关联），年龄/地址泛化——这部分在脱敏充分的前提下允许调用境内云端模型。
- 商品与营销知识问答：不涉及个人信息，直接用云端旗舰模型，享受最强能力。
- 后续如果要做的门店级敏感场景（如摄像头客流分析）：预留私有化路线，当前阶段不启动。
这个方案在评审会上一次通过的关键，是每一条都能回溯到 6.1 节的字段分级清单：方案不是"谈出来的"，是从数据分级推导出来的。这就是把安全做成工程的连锁价值——上一节的功课，直接降低了这一节的谈判成本。
6.2.6 要点总结
- 脱敏的本质是拿信息量换安全性，设计目标是"安全底线之上保留任务所需的最小信息量"，先定义模型要做什么判断，再倒推脱敏策略。
- 三种基本手段：掩码（保格式）、替换（保关系，注意假名化≠匿名）、泛化（保分布）；按字段定级组合使用，低敏字段不必为脱而脱。
- 传输/存储加密与脱敏是两类互补控制：加密防"在路上被偷看"，脱敏防"到手后被滥用"，材料里要分开写清楚。
- 脱敏要发生在 prompt 组装之前；自动 PII 识别（如 Presidio）不能替代字段清单兜底。
- 私有化 vs 云端是成本/性能/安全/合规四维权衡：按"敏感度×体量"矩阵决策，零售场景常用分层混部，金融医疗强敏场景私有化是刚需。
参考资料
- Microsoft Presidio（GitHub） — 微软开源 PII 识别与匿名化框架，支持掩码/哈希/替换/加密等操作符，文档明确提示自动检测的局限
- GDPR 官方文本（EUR-Lex） — 第 4 条定义了匿名化与假名化的法律区分，脱敏方案的国际法参照
- 个人金融信息保护技术规范 JR/T 0171—2020 解读 — 海问律所对央行 C1/C2/C3 分级及金融数据防护要求的解读
- OWASP Top 10 for LLM Applications 2025 — LLM02 敏感信息披露风险及缓解措施，脱敏是其中的核心控制之一