前沿洞见 · 行业观察 · · 国科智飞 Gavin
企业数据脱敏，不该指望大模型顺手做掉
OpenAI 开源了一个 1.5B 的 PII 过滤器。它给出的行业信号比工具本身更重要：专用小模型正在回到企业 AI 的工程现场。
企业用 AI，第一道坎往往不是效果，而是隐私。
合同、病历、聊天记录、客户档案，全都带着个人信息。很多公司卡在这里：想让 AI 帮忙处理，又不敢把数据发出去。于是有人提出一个听起来很聪明的方案——让大模型顺手把敏感信息脱敏掉。
这个方案从逻辑上就不成立。
一个值得注意的开源模型
OpenAI 开源了一个叫 Privacy Filter 的模型，专门做 PII（个人身份信息）检测与遮盖。它的几个参数很说明问题：总参数 1.5B，实际激活只有 50M（gpt-oss 的稀疏 MoE 架构），支持 128K 上下文，Apache 2.0 许可，可以在笔记本甚至浏览器里直接运行。
更重要的是它的工作方式：它不是生成模型，而是双向 token 分类器——一次前向把整段文本标注完，配合 Viterbi 约束解码输出完整的敏感片段，标注风格是 BIOES。它识别姓名、电话、邮箱、地址、账号、密钥等八类信息，在 PII-Masking-300k 基准上开箱约 96% F1。定位也很清楚：不是合规认证工具，而是数据管线最前端的一个过滤组件。（项目地址：https://github.com/openai/privacy-filter ，权重在 Hugging Face 的 openai/privacy-filter）
一句话概括它的设计哲学：脱敏要的是"不漏"，而生成模型的天性是"补全"。
脱敏是分类问题，不是生成问题
为什么不让大模型做？因为这两件事的性质完全不同。
生成模型的本职是"编排"和"创作"：它会补全、会联想、会自信地犯错。而脱敏需要的是确定性——这段文本里有没有敏感信息、边界从哪里到哪里、有没有漏掉。把一件需要确定性的事情，交给一个以不确定性为特征的工具，本身就是风险。
这个风险有两个具体来源。第一是漏检：生成模型没有"我必须找出所有电话号码"的机制，它只对"接下来该生成什么"负责，于是敏感信息可能被它流畅地"带过去"；第二是幻觉：它可能在"脱敏"的过程中把原文改写、合并，甚至编出一个并不存在的姓名。前者是安全问题，后者是数据质量问题——对下游业务来说，两个都不能接受。
分类器的逻辑正好相反：它的输出空间被限定在"每个 token 是不是敏感片段的一部分"，再用约束解码保证输出的是连续、完整的片段。没有创作空间，也就没有创作带来的风险。
还有两个现实问题：成本和链路。每一次请求都过一遍前沿模型，费用高、延迟大；而脱敏应该发生在数据离开企业之前，是管线的第一环，不是最后一道滤镜——等数据到了模型厂商那边再脱敏，本身就已经晚了。
为什么这件事比看起来难
如果只是找手机号和身份证号，正则表达式就够了。难的是 PII 里的大部分类别——姓名、地址、账号——它们是"开放集合"：没有人能穷举全世界的人名和地址格式。
看一句客服对话里的话："张先生说他下周三来取货，到时候打尾号 8823 那个电话。"这里面至少有三个需要判断的地方：哪些字是姓名（"张先生"是称呼，不是完整姓名）、"下周三"算不算需要遮盖的日期信息、一串数字是订单号还是手机号尾号。正则抓不住"张先生"，规则引擎分不清订单号和账号，只有结合上下文才能判断。
这也解释了"双向"和"约束解码"的意义：判断一个词是不是人名，往往要看它前后的词；判断一个数字是不是敏感标识，要看它出现在什么句式里。分类器逐 token 判断，配合序列标注和约束解码，输出的不是一堆零散标签，而是边界完整的片段——这对下游的替换很重要：切歪一个字符，脱敏就会漏。
小而专的模型正在回到现场
过去两年，行业的注意力都在参数竞赛上。但企业真正买单的指标很朴素：能不能在我自己的环境里跑、许可能不能商用、能不能用自己的数据微调、单次成本是多少。
一个 1.5B 的专用模型，在这些维度上的工程价值，可能大于又一个榜单第一的通用大模型。它给出的信号比工具本身更重要：千亿参数的军备竞赛降温之后，模型开始分工——大模型负责理解和生成，小模型负责确定性的把关；真正决定 AI 能不能进业务流程的，往往是这些不起眼的"零件"。
对企业的三条实际建议
如果你正在把 AI 接进业务流程，有三件事值得先做：
第一，把数据流画出来。 搞清楚哪些字段真的会被送出企业，哪些其实不需要出域。很多隐私问题不是技术问题，而是"根本不知道数据去哪了"。
第二，把脱敏放在最前端。 不要等出了问题再补，更不要指望下游厂商"会处理"。过滤发生在数据离开你的系统之前，才算数。
第三，选型时看部署形态。 能不能私有化、许可能不能商用、成本会不会随调用量线性上涨——这三问决定了方案能不能长期活在业务流程里，而不是只在演示环境里好看。
自建脱敏能力的三条路线
企业在实操里通常有三条路，适用的场景完全不同：
规则与词典。 适合格式固定的标识——手机号、银行卡号、身份证号。成本最低、确定性最高，但对姓名、地址这类开放实体几乎无能为力，需要持续维护。
开源专用小模型。 适合通用 PII 的第一道过滤。部署灵活、可私有化，代价是需要自己评测、自己调优，并接受一定的漏检和误杀。
商用 API。 上手最快，适合验证阶段，但数据要出域，成本和合规风险随之上升，长期跑在大流量管线上未必划算。
多数企业的正确答案是组合：规则守住高确定性的格式类信息，模型处理开放类实体，API 只用在数据本身不敏感的场景。选型时真正要问的不是"哪个最准"，而是"这套组合能不能在漏检率和成本之间长期平衡"。
一个零件，不等于一套防线
需要提醒的是，privacy-by-design 是一个体系：数据采集的最小化、前端过滤、权限控制、审计留痕、责任边界，缺一不可。一个过滤器解决不了合规问题，也不能拿它当免责声明。
另一个容易被忽略的边界是：通用 PII 模型对中文语境、行业专有标识（工号、病历号、内部编码这类）的覆盖，必须在自己的真实数据上重新评测。评测的指标不是"聪明不聪明"，而是漏检率和误杀率——这两项不过关，再漂亮的架构也进不了生产。
还有一个方向值得警惕：误杀。把公司名当成人名、把订单号当成账号，过度遮盖会破坏数据的可用性——脱敏之后的数据还要能被分析、被使用。好的过滤不是盖得越多越好，而是在"不漏"和"可用"之间找到平衡。
把工具当体系，是企业在 AI 时代最容易交的学费。
评价一个 AI 供应商的标准，正在从"谁最聪明"，变成"谁能在我自己的机房里，解决我这个具体问题"。