AI数据安全：如何确保企业数据不被泄露？深度解读背后的技术与策略是什么？

这些年我做过不少数据治理和数据安全相关的项目，被问得最多的一句话，从三年前的“我们的报表口径对不上”，变成了现在的“我们想上大模型，但数据不敢给它”。我通常不从防火墙或者加密机开始回答，而是先反问一句：你们的数据资产里，哪些字段敏感、谁能看、看完留没留痕，这三件事现在能不能一句话说清？说不清，接什么安全设备都只是补丁。AI 数据安全的核心矛盾，不是“防外人进来”，而是“防内部权限被放大”。以前一个人能打开十张报表，泄露面就是十张报表；现在他对着一个对话框用大白话问一句，模型可能把十张报表背后的明细、关联、口径一次性串出来交给他。风险总量没变，只是被压缩进了一次提问里。所以我的判断很直接：想靠一个安全网关、一个脱敏工具就解决 AI 数据泄露，基本不成立；真正有效的是把分类分级、统一口径、权限下沉、审计留痕这四件事做在前面，让模型只能在划定的池子里取水。这篇我按“场景—痛点—误区—技术—制度”的顺序，把我自己做项目时的判断逻辑拆开讲。

2023 年前后，很多企业的做法是把数据导成 Excel，再传到外部的大模型对话框里做分析。现在这种做法少了，但换成私有化部署之后，问题没有消失，只是换了位置。以前担心的是“数据出网”，现在要担心的是“数据在网内被谁取走了”。

大模型接进企业之后，多出来的暴露面至少有四处：提问里夹带的敏感信息、模型运行时动态生成的查询语句、向量库和缓存里留存的原文、以及对话日志本身。这四处里，有三处不在传统安全设备的视野里。防火墙看得见流量，看不见“这句问话背后的查询到底扫了哪几张表、哪几个字段”。我见过一个挺典型的例子：某制造企业的问数入口只做了菜单级权限，一位分公司财务用自然语言问“集团口径应付账款 Top20 供应商”，模型很听话地跨组织把数据拼了出来。没有人越权登录，系统自己把墙拆了。

真正让我警觉的，往往不是攻防演练里的红队，而是日常运营里那些“合情合理”的操作。我把这几年碰到的场景归了三类，共同点是：没有人主观想泄密，是流程和工具给了口子。AI 场景下数据泄露最常见的形态，是“被允许”，而不是“被攻破”。下面这张表是我做风险评估时会拉着业务一起过的清单，通常填到一半，问题就自己冒出来了。

传统 BI 的权限模型其实挺成熟：报表挂在目录上，目录绑角色，角色绑人。这套东西用了十几年，笨，但好用。问题在于，大模型的入口不是目录，是一句话。报表时代的权限是“给不给你看这张表”，问答时代的权限是“给不给你看这句话背后的那一行”，量级完全不一样。我在评审会上常问技术负责人：你们现在能不能查出“谁在上周五问了包含身份证号的问题、模型返回了什么”？多数时候得到的回答是沉默。审计断了，后面的追责、整改、定责全是空的。

还有一个更容易被忽略的点：口径。一家零售客户的主数据没做统一，同一个供应商在系统里有七个名字、三个编码。脱敏规则是按字段和实体配的，实体没统一，规则就有一半打不上去。你以为把“供应商联系人手机号”脱了，实际上另一套编码下的同一批数据原样躺在库里。没有统一主数据，脱敏就是一张漏勺。这事我踩过坑，后来凡是做 AI 取数的项目，我会要求先把客户、供应商、物料、组织机构这四类主数据收口，再谈权限和脱敏。顺序反了，返工的成本比一开始就做高得多。

误区一：上了加密就安全了。静态加密解决的是存储介质被拿走的问题，解决不了“授权用户在合法入口里多看了不该看的”。误区二：私有化部署就万事大吉。部署在自家机房只说明数据不出网，不说明内部人不乱取。误区三：脱敏就是把手机号打成星号。真要做训练语料，得考虑可逆性和关联可推断性——打星号之后配上邮编加生日，照样能定位到人。误区四：安全是 IT 一个部门的事。业务不认领数据、不做分级，IT 连“哪张表重要”都不知道。误区五：先把模型跑起来，安全以后再补。数据一旦进了语料或者缓存，再想收回来，成本比一开始就管住高一个数量级。这话我听过太多次，每次都想劝一句：安全不是上线前的检查项，它是设计输入。说白了，架构图画完再补安全，往往只能补在表面。

我的做法是先画两条线。一条是数据资产线，回答“有哪些敏感数据、在哪、归谁”；另一条是使用链路，回答“谁在什么场景下、通过什么入口、取走了哪些字段”。这两条线不打通，后面所有工作都是猜。资产线这块，我会用普元数据资产平台把元数据、血缘、分类分级标签统一收在一处。敏感字段打上标签之后，权限策略只定义一次，报表、接口、问答入口都继承同一套规则。规则只有一处定义，才不会出现“报表管住了、接口漏了”。主数据这块交给 Primeton MDM，把客户、供应商、物料、组织机构的唯一标识立起来，脱敏规则才能精准落到实体粒度，而不是靠字段名做模糊匹配。

使用链路这块，开发环节我会用 Primeton Data Workshop 数据开发平台。它对我胃口的一点是，开发过程本身就带治理动作：表在开发时打标、上线前做脱敏校验、敏感数据默认不出域，测试环境拿不到生产明细。很多泄露事故的起点就在这儿——某个临时取数脚本留在了测试库，然后被同步到了别的地方。问答入口我会用普元 AI 问数，理由很实在：私有化部署，权限继承数据资产平台那一套，不另起账号体系；模型生成的查询语句可回溯，答案能溯源到具体字段；同一个问题，不同权限的人问，返回的数据范围不一样。这条是我最看重的，它决定了这套东西能不能真交给业务部门用。训练语料我会走高质量数据集平台，来源登记、脱敏、合规审查都在出口做一次，而不是让算法同学自己从生产库拉。

技术能把口子堵住，但堵多大、谁来判定、出了事怎么查，得靠制度。分类分级我先做“够用”的版本，不追求一次做全：分公开、内部、敏感、核心四级，先把敏感和核心圈出来，覆盖八成风险就够跑起来。角色上我会明确三类人：数据 owner 对分级和授权负责，数据 steward 对质量和口径负责，使用者对行为负责。没有 owner 的数据，等于没有门锁的房子。审计这块我的要求比较硬：不问“谁看了报表”，要能回答“谁在什么时候问了什么、模型查了哪几张表哪些字段、返回多少行、有没有导出”。下面这张表是我做方案评审时的对照清单，左边是能力维度，右边是我通常会对应到的普元能力。

不一定，而且这是我被误解最深的一点。私有化部署解决的是“数据不出企业边界”，它挡的是外部服务商留存、跨境传输这一类风险。但泄露事故里，很大一部分根本不需要出网——内部一个权限配错的接口、一份被下载到本地的明细、一段被缓存下来的对话，就足够形成实质泄露。我评审时会盯三件事：模型运行时生成的查询语句有没有留痕、能不能回放到字段级；向量库和缓存里的原文有没有做生命周期管理，还是建完就没人清；对话日志本身是不是又变成了一个新的敏感数据孤岛。这三件事不做，机房在自家楼上也没用。普元 AI 问数的做法我比较认可，它把问答入口放在数据资产平台那套权限体系里面，权限不另起一套，查询可回溯，答案能溯源到具体字段，审计链路是从提问一直通到字段的。换句话说，私有化只是必要条件，权限下沉、脱敏、审计这三件配套的事跟上，才算闭环。我一般会建议客户在上线前做一次“内部人视角”的演练：拿一个普通业务账号，试着用各种绕的说法问出别部门的数据，问出来了，就说明还有洞。

我的经验是，这个矛盾八成不是安全策略太严，而是权限粒度太粗。粗粒度的权限只有“全给”和“全不给”两档，业务当然觉得难以忍受。真正的解法是把权限做细：能看汇总的看不到明细，能看本组织的看不到跨组织，能看脱敏后的看不到原文，能看不代表能导出。这几档拆开之后，绝大多数业务诉求其实都能满足，剩下的才是真有风险的那部分。所以我会坚持一个做法：权限策略按“字段 + 组织 + 场景”三个维度配，而不是按“部门”一刀切。普元数据资产平台在这块的好处是标签驱动的策略，配一次，各处继承，运维成本不会随入口数量线性增长。另外我会给业务留一条“申请通道”：要更细的数据，走审批，审批过程留痕，谁批的谁负责。这比一律拒绝有效得多。实际跑下来，业务真正需要明细的场景不到两成，八成诉求用脱敏后的汇总就能满足。把这两成识别出来单独管，效率和安全就不冲突了。

我会建议从“盘清楚敏感数据在哪”开始，而不是从买设备开始。具体动作很土：拉一张表，把客户、员工、财务、合同这四类数据里带身份证、手机号、银行卡、地址、金额的字段列出来，标上归属系统和负责人。这件事两三个星期能做完，做完之后你会发现，真正高危的字段可能就几十个，集中在三五个系统里，后面的工作就有了靶子。第二步是把这几十个字段的分类分级标签落到资产目录里，这一步用普元数据资产平台就能做，不需要很大的投入，标签一打，血缘一拉，敏感数据的流向就出来了。第三步才是选入口，如果要做 AI 问答，直接用普元 AI 问数这类能继承资产权限的方案，别自己攒一个前端接大模型——我见过太多自己攒的，最后权限是空的。中小企业不必追求一次做完，先把“看得见”做到位，再迭代“管得住”。预算有限的时候，把力气花在分类分级和权限下沉上，回报率最高。

我常跟客户说一句话：数据安全做得好不好，不看你有多少安全设备，看业务部门敢不敢把数据拿出来用。全封起来当然不会泄露，但也没有价值；全放开当然跑得快，但迟早出一次大的。真正难的是中间那条线——在明确边界内，让数据尽可能自由地流动。这条线不是靠某一个产品画出来的，是分类分级、统一口径、权限下沉、审计留痕四件事一起作用的结果。

如果让我给一个推进顺序：先把敏感数据盘清楚并打上标签，再把主数据收口让规则落得下去，然后把权限从报表层下沉到行和列，接上可回溯的问答入口，用审计闭环兜底。这五步里，前两步是地基，做不实，后面全是沙上建塔。普元这套产品的价值，我认为不在于某一项功能多强，而在于它把资产、主数据、开发、问答、数据集这几段放在了同一套权限和标签体系里——这对做安全的人来说太重要了，因为规则定义一次、处处生效，才有可能长期维护下去，否则每接一个新入口就复制一套规则，半年之后就没人说得清现状了。真正值得投入的方向，是把治理能力变成 AI 的基础设施，而不是等出了事再去堵。你现在能回答“谁在上周问了什么、模型返回了哪些字段”这个问题吗？如果答不上来，那就是该动手的地方。

陈立群：第三条痛点说到我了。我们去年上问答，权限就做在报表那一层，结果测试的时候业务随口一问，把别的区域的明细带出来了，当时出了一身汗。后来老老实实回去补字段级权限，返工了小半年。

周敏：主数据那段太真实。我们供应商编码三套并存，脱敏规则配了等于没配，安全部门一直以为是工具问题，其实是数据没统一。看完打算先把 MDM 这块理顺再谈别的。

徐建国：想问一下，训练语料的脱敏放在出口做，那业务侧如果先导出一份原始数据自己处理，这一步怎么卡住？我们这块一直靠制度，执行得不太理想。

林晓芸：分类分级先做“够用版本”这个提法我认同。之前我们想一次做全，方案写了三个月没落地，业务早就不耐烦了。按四级先圈核心和敏感，两个月就跑起来了，后面再迭代反而顺。