AI Agent用上客户数据又不泄露隐私？Aura的本地化脱敏实测

每一家尝试引入 AI Agent 的企业，几乎都会撞上同一堵墙：真正有价值的问题，答案都藏在自己的数据里。

哪些客户欠款超过一个月？谁还在等我们回复？大家抱怨最多的是什么？ 要回答这些问题，Agent 就得读取你的客户名单、发票和邮件。而这恰恰是你最不敢上传到云端大模型的东西——姓名、邮箱、电话、账户号，这些是从未同意被外发的个人信息。

结果就是两条路：要么放弃提问，要么硬着头皮粘贴进去，然后祈祷不出事。Aura 的开发者想找到第三条路，并把整个方案拿去做了实测。

核心思路：Agent 看到的是令牌，你看到的是真名

在 Agent 接触任何一张表之前，Aura 会在本地生成一份副本，把其中的每一个姓名、邮箱、电话和账户号都替换成一个稳定的令牌（token）。

你拥有的原始数据	Agent 实际看到的
Olena Petrenko, olena@firm.ua, 欠款 12,000	name_1, email_1, 欠款 12,000
"打电话给 Kowalski 先生，他想把发票发到 jan@firma.pl"	"打电话给 name_2，他想把发票发到 email_2"

关键在于同一个人永远对应同一个令牌。这样 Agent 依然能够计数、分组、关联多张表，并跨行追踪同一个客户。当你要求它"把欠款名单发给我"时，结果会写入你本机的一个文件，并把真实姓名还原回去——Agent 全程只知道这个文件的名字。

随之而来的疑问也很直接：看不到真实姓名，AI 会不会变笨？

这种技术思路在数据隐私领域有一个正式名称：假名化（Pseudonymization），是GDPR（欧盟通用数据保护条例）第4条明确定义的一种数据处理手段。其本质是用可逆的标识符替换直接标识符，使数据在没有额外映射表的情况下无法归因到具体个人。与"匿名化"的关键区别在于可逆性：令牌和真实姓名之间存在一张本地保存的映射表，这张表决定了"同一个人永远对应同一个令牌"——正是这种稳定性让AI能够跨表跨行追踪同一客户，但也意味着一旦映射表泄露，保护即告失效。GDPR允许假名化数据在一定条件下享受较低合规负担，但并不等同于完全脱离数据保护义务，这也是原文强调"这是假名化而非匿名化"的法律背景所在。

AI 会变差吗？几乎不会

开发者使用了公开基准 BIRD 来验证。这是一个让 AI 写 SQL 来回答真实数据库问题的测试集，覆盖 4 个数据库共 179 道题，由 Google 的 gemini-3.8-flash 负责生成查询。

Agent 看到的内容	正确率	外泄到云端的姓名/邮箱/号码数量
真实数据	68.2%	849
令牌替代姓名（Aura）	67.6%	0
仅表结构，无数据行	65.9%	0
纯本地小模型，不外发	35.2%	0

结果很说明问题：令牌化方案与完全开放访问的差距仅有 0.6 个百分点，落在噪声范围内，但外泄的个人信息从 849 条直接归零。换用第二个模型 Qwen 结论一致（令牌 67.0% vs 真实数据 64.8%）。

而很多人直觉上会选的"干脆全部本地跑"方案反而糟糕得多——本机小模型答对的题目只有一半左右（35.2%）。这组对比恰好点出了脱敏网关的价值：既保留了云端大模型的能力，又守住了数据边界。

BIRD（BIg Bench for Text-to-SQL） 是由香港大学联合 Google 等机构发布的文本转SQL基准测试集，专门用于衡量AI在真实业务数据库场景下的自然语言理解与查询生成能力。与早期的Spider等基准不同，BIRD包含脏数据、数值推理和外部知识依赖等现实挑战，被广泛认为比合成数据集更能反映企业级数据库应用的实际难度。测试的核心指标是"执行准确率"——AI生成的SQL能否在数据库上运行并返回与标准答案一致的结果，而非仅仅语法上正确。这一基准的选择对于验证脱敏方案的合理性至关重要：如果令牌化损害了AI的分析能力，企业就不会采用；而0.6%的精度差距意味着用令牌替换真实姓名对SQL推理逻辑几乎没有干扰，因为SQL的核心操作（计数、分组、关联）依赖的是字段值的一致性，而非其语义含义。

真正的难点在自由文本

结构化表格是最简单的情况：一个叫"Name"的列里装的就是姓名。但真实业务数据的大头是文本——备注、评论、邮件正文。一个人名可能出现在任何位置、任何语言、任何语法变形中。

行业的标准做法是用一个小型 AI 模型去文本里找个人信息。为了能跑在普通办公电脑上，模型不能是动辄几 GB 的庞然大物。开发者测试了能找到的四个最轻量的多语言模型，在覆盖 21 种语言的公开测试集（法院判决、欧盟法律文本、合成金融文档）上评估。

结论是：单靠模型都不够好。表现最好的也只能识别出 69%–78% 的人名，意味着大约每四个名字里就有一个会漏到云端。

真正奏效的做法，是利用网关本就掌握的信息——这段文本属于谁。一封邮件有发件人和收件人，一条备注归属于某个客户的记录行。这些人的姓名、地址、号码是已知的，因此可以在文本中以任何形态被可靠地找出来（比如波兰语变格后的 "Kowalskiego" 对应 Kowalski，"Mr Benham" 对应 Stephen Andrew Benham），完全不需要为任何语言准备词表。模型只需负责捕捉那些偶然提及的"陌生人"。

文本类型	隐藏人物比例
金融文档（7 种语言）	95%
法院判决	文中有姓名者约 95%（占全部提及的 82%，其余为法院已匿名化的孤立缩写如 "A."）
欧盟法律文本（21 种语言，多数人不在任何记录中）	55%

开发者还拿自己收件箱里的 85 封真实邮件做了实测：Aura 替换掉了所有发件人、收件人，以及正文中超过 750 个姓名、地址、号码和链接。随后它会自检——在 Agent 副本中逐一搜索它隐藏的 254 个值。结果是没有留下任何完整姓名、地址或号码，只剩三个孤立单词（一个城市名、一个单独的名字）。

这项自检现已内置于应用，每次上传后自动运行，不必只听开发者的一面之词。

在自然语言处理中，从非结构化文本中识别人名、地址、电话等个人信息的任务被称为命名实体识别（NER，Named Entity Recognition）。传统NER模型依赖语言模型对上下文的理解，但对于隐私保护场景存在两个固有瓶颈：一是召回率天花板——模型无法识别它从未见过的名字写法或罕见语言变形；二是尺寸与性能的权衡——能够处理21种语言的高精度模型通常体积庞大，无法在普通办公电脑上实时运行。文章提出的"利用文本归属关系"本质上是将NER问题转化为一个更简单的字符串匹配与模糊查找问题：已知人名的各种变形（如波兰语变格）可以通过形态学规则或编辑距离算法预先枚举，这种方法不依赖语言模型的泛化能力，因此在已知人物上的召回率远高于纯模型方案，同时计算开销极低。

它做不到什么

隐私承诺很容易被夸大，这一点原文说得相当坦诚。

• 这是假名化（pseudonymization），不是匿名化。 Agent 仍然能看到内容本身：主题、金额、日期、公司名。如果内容本身就能定位到某人（比如"我们最大客户的 CEO"），令牌无能为力。
• 自由文本的覆盖率取决于你的数据。 当被提及的人就在你的数据里时覆盖最高，对陌生人则较低。孤立的单词——比如一个单独的名字或城市——可能残留。
• 跨字母体系的名字无法关联。 一条西里尔字母的记录不会匹配拉丁字母的签名，只有开启那个可选模型才能捕捉。

怎么试

Aura 的 Windows 版免费提供（aurasdk.dev/desktop）。在 Data 标签页里有两个区域：

• Upload：Agent 原样看到文件，适合你不担心隐私的文档。
• Safe upload：姓名、联系方式和号码（包括邮件和备注内部的）被替换为令牌，副本还会经过自检。

它支持 Excel、CSV、SQLite 以及邮件格式（.eml、来自 Gmail/Thunderbird/Apple Mail 的 .mbox），一键即可连接 Claude Code、Claude Desktop、Cursor 等 Agent。那个可选模型约 380 MB，仅在你开启时才下载，用于额外隐藏不在你数据中的人物。所有处理都在本机完成。

这还是一个早期版本。对于那些既想用 AI 处理客户数据、又受制于隐私合规的团队来说，这种"本地脱敏网关"的思路值得关注——它没有在能力和隐私之间二选一，而是试图把两者同时留下。