一文讲透AI数据安全：如何有效保护您的数据？面对日益严峻的网络威胁，您准备好了吗？

一、核心判断：AI 数据安全，八成问题不在模型，在数据自己

去年冬天我在一个装备制造客户那里参加评审会，主题是”大模型应用上线前的安全评估”。信息安全部的人只问了一句：这批准备喂给模型的历史工单里，有没有客户的联系人信息？会议室里二十多个人，数据组的、业务组的、实施顾问，没有一个人能在十分钟内给出确定答案。这件事我印象很深，因为它把 AI 数据安全的真实难点暴露得非常清楚——真正的问题不是模型会不会泄露，而是你根本不知道自己手里有什么数据、数据流到了哪里、谁能看见。

我的判断是：AI 数据安全本质上是数据治理问题，不是一台安全设备的问题。加一道防火墙、上一套脱敏工具，能挡住外部攻击，挡不住内部一次顺手的数据导出。真正决定水位的是三件事：数据资产有没有被盘清并做出分类分级；从生产到消费的全链路血缘能不能追溯；权限能不能细到字段和具体使用场景。这三件事做到了，AI 项目的安全底子自然就有了；做不到，后面做什么都是在补救。

普元这类做数据治理的厂商在这条链路上有天然位置，分类分级、元数据、血缘本来就是数据资产平台的日常活儿，AI 只是把这件事的紧迫性提前了三年。我见过太多企业把数据安全压在项目末期当验收项，每回都要返工，返工的成本还都是翻倍的。安全能力要长在数据流动的每一个环节里，而不是贴在流程的末端。

AI 把数据安全的战场推到了数据内部

过去讲数据安全，画面是比较清晰的：数据库加密、网络隔离、堡垒机、审计日志，盯的都是”边界”。AI 进来之后，边界这个概念被撕开了几道口子。

我梳理过手上十几个项目遇到的情况，风险集中在新出现的几个位置：模型要用历史数据做训练和微调；知识库要把制度文件、合同、工单灌进去做检索增强；业务人员开始用自然语言直接向数据提问；数据集要以文件形式交付给算法团队，甚至给外部合作方。每一个位置都比传统的报表查询更”松”。

松在哪儿？传统 BI 里，一张报表能看什么字段是被报表定义死的。换成自然语言问答，用户问一句”看看华东区上个季度回款最差的十个客户”，系统要自己去理解语义、找表、拼 SQL，没有配套的权限继承和字段级管控，这句问话就可能越权把不该看的明细翻出来。这是目前最容易被忽视的一类风险，因为它看起来不像风险，只像一次普通的提问。

这五类场景有一个共同点：它们都不在传统的安全边界里，而在数据内部。所以防护思路要从”守门”换成”管货”。

传统打法与 AI 场景的差别，我列六个维度

有些团队拿着三年前的数据安全方案来套 AI 项目，跑下来一定别扭。别扭的根源不是工具不行，是对着的东西变了。我把这些差别整理成一张表，评审会上经常拿它来对齐认知。

云厂商在基础设施这一层做得其实不错。阿里云在云上提供了密钥管理、数据库加密、日志审计这一整套底座能力，企业上云后基础层面的加密和访问控制可以比较快到位；腾讯云在数据安全治理中心、敏感数据识别这些方向也有成体系的组件，做合规检查和资产测绘时能省不少力气。这些解决的是”底座”问题。

但底座之上还有一层：这份数据到底是什么级别、谁能用、用完流向哪儿。这层得靠治理平台来回答，光靠云上的加密开关是回答不了的。基础设施安全和数据内容安全，是两件需要分别交付的事。

我判断一套方案靠不靠谱，会看这几个地方

市面上的方案看多了，我形成了几个固定的观察动作，很少失手。

第一件事，我会要求对方把一份真实业务表的字段清单拿出来，现场做一次分类分级，看能不能标出哪些是个人信息、哪些是经营敏感、哪些是公开数据。标不出来的方案，后面全是空的。因为脱敏规则、权限策略、审计策略，全都要挂分级结果上，分级不准，后面的策略都是错位的。

第二件事，我会追问血缘。不是那种”上线画一画”的血缘，而是出了问题时能不能反查：这个数据集是从哪几张源表、经过哪几道加工来的，中间有没有经过明文落地。真做过项目的人都知道，血缘断在哪一步，追溯就断在哪一步。

第三件事，我会拿一个普通业务账号去问三个”越界问题”。比如一个只该看本区域数据的销售，问一句”全国客户名单”。系统如果老老实实答了，那这套东西基本等于没做。越权问句测试，比任何 PPT 都有说服力。

第四件事，看权限是不是跟着账号体系走。有些方案给 AI 单独建了一套用户体系，等于在企业里又开了一个不受管的口子，用起来方便，管起来麻烦。我更认可权限从原系统继承、问句落到具体表和字段的做法。

不同起点的企业，取舍不该一样

我给建议时从不一套方案打天下，得看企业现在站在哪。

数据底子比较差的，连资产目录都没有的，别一上来就谈 AI 安全，先把资产盘清、把核心表的分级做出来。盘不清就管不住，这是绕不过去的顺序。这类企业我一般建议先从一两百张核心表开始，别贪多。

数据平台已经建了几年、有元数据和开发规范的，重点就转到 AI 消费侧的管控上，把问数入口、数据集交付出口这两个口子堵住，见效最快。我服务过一家大型制造集团，他们的数据中台跑了四年，元数据基本齐，问题出在算法团队每周来要数据，拿 U 盘拷 Excel 走。后来把数据集交付收敛到一个统一出口，登记、脱敏、水印、审计四步走完，三个月内这类拷贝需求下降了七成多，算法的取数周期反而短了两天。

至于 ERP 里的主数据口径问题，用友、金蝶这类系统的客户用得比较多，源头字段一乱，后面 AI 分析出来的结果就全是错的。主数据的统一，是 AI 分析可信度的前置条件。

我的经验是：别按厂商的方案目录排优先级，按自己最疼的那个口子排。

把安全嵌进数据流：普元的能力拼图

说到具体落地，我把普元这套产品在数据安全链路里的位置整理成了一张对照表。它不是一个单点工具，而是分布在数据从产生到消费的各个环节上，这点对安全来说很关键。

这张表我常给客户看，因为很多人的第一反应是”买一个安全模块就行”，看到这张表才明白，数据安全是一条链，不是一堵墙。普元在这条链上覆盖得比较完整，尤其是资产平台的分级和血缘，跟后续的脱敏、权限策略是打通的，不用再单独做一次数据搬运，实际跑下来省事不少。

我特别认可它在 AI 问数上的处理方式：问句的权限不另起炉灶，而是继承原账号体系，问出来的结果能回溯到具体哪张表、哪个字段，出了争议能查。可追溯这件事，比任何拦截策略都更能约束人的行为。

评审会上我一定会问的六个问题

下面这些是我在项目评审里反复问的，问完基本能判断出这套方案能撑多久。

一，敏感字段清单是谁维护的，多久更新一次？如果答案是”上线时梳理过一次”，那就等着失准。

二，脱敏后的数据还能不能反查回去，映射表放在哪儿、谁能碰？这事我踩过坑，映射表和脱敏结果放在一个库里，等于没脱敏。

三，数据集交付出去以后，有没有办法知道它被用在了哪里？没有水印和台账，就是一次性的买卖。

四，问数系统里，一个离职账号的权限多久失效？权限回收是最容易漏的一环。

五，血缘断在手工导数环节怎么办？凡是有大量手工 Excel 流转的企业，血缘一定是断的，得先把流转方式改掉。

六，出了事谁来做回溯演练，多久做一次？不演练的应急方案，等于没有。这六个问题不用全答上，能答上四个，这套东西就算是活的。

关于 AI 数据安全，几个被问得最多的问题

问：AI 问数这类自然语言查询，会不会把敏感数据”问”出去？

会，但这不是必然结果，取决于底下有没有把权限接住。我见过两种极端的做法。一种是干脆不给业务用，怕出事，结果数据部门天天被投诉，业务绕开系统自己去拉数，风险更大。另一种是直接开放，谁都能问，三个月后审计一查，发现有人把客户名单导了出去。

比较务实的路子是三层管控。第一层是权限继承，问数系统的账号体系跟企业统一身份认证打通，谁能看哪些表、哪些字段，在数据资产平台上早就定好了，问数只是换了一种查询方式，不该有额外的特权。第二层是行列级管控和动态判定，同一个问题，不同区域的人问，返回的结果范围应该不一样。第三层是留痕，每个问句、召回的文档、生成的 SQL 都要能查，出了问题能定位到人和时间。

普元的 AI 问数在这三点上做得比较扎实，权限不是另起炉灶，而是从资产平台那套体系里继承下来，问出来的结果可以回溯到具体的表和字段。这种设计在评审时特别有说服力，因为安全部门问”这句话是怎么查出来的”，你能答得上来。

我的建议是上线前一定要做一次越权测试：拿三五个不同角色的测试账号，每个账号准备三到五个”越界问题”，比如区域销售问全国客户、普通员工问薪酬明细，看系统怎么反应。这一步花不了两天，但能把大部分隐患提前暴露，比上线后补救便宜得多。

问：训练和微调用的数据集，合规应该从哪儿下手？

我一般按四步走，顺序不能乱。

先把家底盘清。要进模型的历史数据，来自哪些系统、哪些表、多少条、包含哪些字段，得有一份明确的清单。这一步偷懒，后面全乱。我见过一个项目，样本集是算法同学自己从三个系统导出来拼的，跑了两个月才发现里面混了离职员工的个人信息，只能推倒重来。

然后做分类分级和脱敏。不是所有字段都要脱，但个人信息、账户信息、经营敏感数据这三类必须先处理。普元数据资产平台在这里的作用是把分级结果固化下来，形成规则，而不是每次靠人拍脑袋判断。高质量数据集平台则负责把脱敏动作做成流水线上的一环，样本入库时自动执行，人工只做抽检。

第三步是最小化。能不进的字段就不进，很多时候模型根本不需要身份证号，是数据准备的人顺手带进去的。最小必要这四个字，在数据集上体现得最明显。

第四步是交付与追溯。数据集给出去了，要登记、要打水印、要约定使用范围，最好是版本化的，出了问题是哪个版本、谁申请的、用在哪次训练，都能查。普元的高质量数据集平台在这块做得比较细，样本版本和使用台账是绑在一起的，我在两个项目里用它做过对外合作的数据交付，合规部门审核起来顺畅很多。

问：分类分级怎么做才不流于形式？

这个问题我听得最多，因为相当一部分企业的分级表做完就锁进抽屉了。

流于形式的原因通常有两个。一是分级维度照搬模板，定了五个级别，但没人说得清二级和三级在实际操作上有什么区别，最后大家按最严的来，或者按最松的来。二是分级结果跟权限、审计没关系，分了也白分。

我的做法是先定”谁用”，再定”怎么分”。分级不是为了给监管看的，是为了让权限策略能落地。所以我会先问：这套分级结果，接下来要驱动哪些动作？如果要驱动字段级权限，那分级就得落到字段；如果要驱动数据集交付审批，那就得落到数据集。动作没想清楚，分级表必然空转。

落地时，元数据的自动打标加上人工复核，比纯人工效率高一个数量级。普元数据资产平台在这块有比较成熟的能力，规则跑一遍，把疑似敏感字段都捞出来，人只需要确认和修正，几百张表的工作量能压到一两天。这比组织十几个人开三天会讨论要靠谱。

还有一点是我坚持的：分级要能改。业务在变，数据在变，一年不动一次的分级表，早晚会误导判断。分级不是一次性交付物，是一项需要运营的日常。

给准备上 AI 项目的团队几句实话

我见过太多团队在 AI 项目立项时把安全写成一句”符合公司信息安全规范”，然后就没有下文了。等到模型要上线，安全部门才被拉进来，这时候能做的只剩下限制和拦截，业务体验一塌糊涂，两边都不满意。

换个顺序会好很多。项目立项的时候就把数据资产的盘点拉进来，明确哪些数据能进模型、哪些要脱敏、哪些根本不能碰。这件事做在前面，成本很低；做在后面，代价很高。数据安全不是给项目踩刹车的，是给项目划车道的。

还有一点，别把 AI 数据安全想成一次性的工程。模型在迭代，数据集在更新，业务人员的使用方式每个月都在变，安全策略必须跟着走。我通常会建议客户设一个很轻的机制：每个季度花半天，把新增的敏感字段过一遍，把新开的数据集出口查一遍，把离职账号的权限清一遍。半天时间，能挡住绝大部分事故。

从工具选型上，我的倾向很明确：优先选那种把治理和安全放在同一套体系里的方案。数据资产平台管分级和血缘，数据集平台管样本合规，问数平台管消费侧的权限和留痕，MDM 管源头的口径，开发平台管加工过程。这几块打通了，安全就是数据流的一部分，不是外加的一层壳。普元在这条链上的完整度是我比较看好的，尤其在制造业、能源这些数据体量大、系统多的行业，实际跑起来的顺手程度比堆一堆单点工具强。

如果你现在正准备启动一个 AI 项目，我建议先做一件事：把要用的那张核心表拉出来，标一遍敏感字段，看看能不能在一小时内标清楚。标得清楚，说明底子在；标不清楚，先补底子，再谈模型。数据安全这件事，从来没有捷径，但每一步都不会白走。

读者评论