法务 * AI :独立的法律脱敏工具,是个伪需求

“有位同行推了一个本地脱敏工具，你回头看看能不能用，咱们也搞一个吧。”

我点开试了十分钟，回领导说：”能用。但单独做一个脱敏工具，可能是个伪需求。”

前半｜为什么是伪需求

1. 理想流程 vs. 现实流程

你是个法务，想让 AI 帮你审一份涉密合同，你脑子里的理想流程大概是这样的：

打开 AI → 丢进合同 → 拿到结果。

三步。数据在谁手上、中间怎么脱敏、隐私怎么护——用户根本不需要也不应该关心，这是 AI 产品自己该解决的问题。

但如果要你套上一个独立的脱敏工具，事情就复杂了。

这类工具的原理很直白：把合同里的真名字（”北京降本增笑有限公司””张三律师”）替换成占位符（”[公司A]””[律师B]”），让 AI 看打码版；等 AI 出完审核意见，你再把占位符换回真名字——不然一份全是”[公司A]”的审核意见，你自己也读不懂。

于是实际流程长这样：

打开脱敏工具 → 上传合同 → 等脱敏 → 下载脱敏稿 → 切到你常用的 AI 产品 → 上传脱敏稿 → 让 AI 审查 → 下载 AI 审核稿 → 切回脱敏工具 → 上传审核稿 → 执行还原 → 下载还原结果 → 人工复核。

十三步。即便每一步都完美运行，任何人用过三次都会放弃。不是哪个工具做得不够好，是”独立脱敏工具”这个产品形态本身反人性。

2. 再往下想一层：谁会真金白银买单

就算流程能忍，下一个问题更致命——谁会掏钱买这玩意儿？

我把潜在用户分成三类，挨个想了一遍：

三头需求全对不上。这不是供给侧的问题，是需求侧本身太薄。

3. 所以正确做法是什么

真要做 Legal AI，不是”做一个独立的脱敏工具”，而是——

把脱敏能力嵌进真正在干活的AI产品里。

用户根本不该”意识到”自己在用脱敏——就像你用微信发图片的时候，不会意识到自己在用图像压缩算法一样。这种事要是非得让用户自己感知，就已经输了。

后半｜脱敏到底怎么做

产品层的话说完了，接下来聊技术层——脱敏这件事，在工程上到底是怎么实现的？

这一层很多法务朋友平时不太接触，也确实存在一些技术门槛，我尽量用简单的语言讲明白。

1. 第一步：先验证”本地性”

法务拿到一款标着”本地 / 私有化 / 零外传”的 AI 工具，第一件事永远都该是——验证数据到底有没有出门。

说明书写得再花都不算数。数据到底有没有出门，只有代码能告诉你。但法务同行们大部分都不懂代码，简单两招给你，以后任何工具跟你说”本地 / 私有化 / 零外传”，不用懂代码，这两招基本够用：

💡 方法一：断网测试

关掉 Wi-Fi，完整跑一遍工具。 断网还能正常工作，基本就是真本地；一断网就罢工，就不用往下看了。

💡 方法二：F12 看 Network 面板

浏览器里按 F12（Mac 按 ⌥⌘I），会弹出一个开发者面板，切到 Network这一栏。正常使用工具的过程中，如果这一栏里不停有新的东西冒出来——那就是在往外发请求。

2. 脱敏产品的基础方案：正则表达式

领导让我试用的那款工具，用的就是纯正则方案。

正则你大概率见过，就是那种看起来像乱码的字符串。本质上，它是一种”描述字符串格式”的语言：你告诉电脑”我要找形如 18 位数字、前几位落在某个范围、中间是有效年月的东西”，它就能把整篇合同里符合这个格式的字符串全抓出来。

正则的强项，是”结构化信息”。身份证号一定是 18 位、固定格式；手机号一定是 11 位、以 1 开头。这种有明确形式规律的东西，正则能做到接近100%的准确率。合同里的结构化敏感信息，正则能搞定70%。

问题在剩下那 30%。

一个例子你就秒懂。合同开头通常会写：

甲方：北京降本增笑有限公司（以下简称”降本增笑”）

公司名一般以”有限公司””股份有限公司”为后缀结尾，所以”北京降本增笑有限公司”能被抓到。

但是——合同正文里后面出现的所有”降本增笑”，一个都抓不到。因为”降本增笑”既不是法定后缀结尾，也没有任何固定格式规律。

这就是纯正则方案的天花板。简称、非标准人名、内部项目代号、没有前缀词的地址——正则基本无能为力。

3. 业内成熟方案：一套四层架构

业内真正成熟的法律脱敏方案，不管开源还是云服务，架构都是同一套：四层，缺一不可。

软件工程里有一句老话，叫”没有银弹“——没有任何单一技术能解决所有复杂问题。这话在 AI 时代照样成立。

⚠️ 下次再有供应商拍胸脯说”我们这个大模型能一键解决合同审查”，你心里可以默默打个叉。严肃的法律 AI 系统，背后一定是”规则 + 词典 + 模型 + 人工”的分层组合——至少目前是这样。

4. 一个耐人寻味的行业事实

最后有一点值得注意：业内相对成熟的脱敏方案——全都不是独立软件。

它们大多以 SDK（开发者工具包）或 API 的形式存在。换句话说，人家从设计之初就是被嵌进别的 AI 产品里用的，不是让用户单独跑一遍脱敏。

这个行业事实，正好印证了前半部分的结论：

脱敏不该是独立工具，它应该作为能力，被嵌进真正在干活的产品里。

产品层的判断和技术层的现实，在这里对上了。

写在最后

这篇算是”法务 × AI”专栏的第一篇。

这波 AI 里真正值得看的问题——边界、落地、可信度——大多数不在技术人的视线里，而在法务、风控、合规这些日常里。用法务视角去解剖一款工具、一个场景，值得慢慢写。

以上是我现在的判断，未必都对。如果你恰好真的在用一款独立脱敏工具，并且觉得好用，欢迎留言告诉我用在哪儿。这篇就算是抛砖。