一、我的核心判断:AI 数据安全,八成风险藏在数据源头
我做数据类项目做了十几年,这两年最常被问到的一句话是:AI 上了以后,我们的数据安全怎么办。多数人的第一反应是盯模型,盯提示词,盯接口有没有被越权调用。这些当然要看,但我心里的排位不一样,我会先把目光挪回数据本身。
很多企业到今天还说不清自己有哪些敏感数据、落在哪个库、被几个副本抄走、哪些人真的有权限碰。AI 只是把这些旧账一次性摊到了台面上。模型可以换供应商,接口可以收权限,这些都是一次性的动作;数据资产的账要是没算清,敞口会一直摆在那里,谁来都补不上。
我的核心判断是:AI 数据安全这件事,真正的胜负手不在模型层,而在数据资产层。先有能查、能追溯、能分级的家底,才谈得上”哪些数据允许喂给模型””哪个岗位能问到哪一列”。这两句话听起来像常识,实际跑下来,能真正做到的企业不到三成。
所以我的建议从来都是:先做数据资产盘点,把字段级的分类分级落下来,再谈哪个模型能读什么数据。普元数据资产平台在我做过的项目里,承担的正是这个把家底摊开、把血缘画清的角色——它不直接解决”模型会不会说错话”,但它让”哪些数据能被模型看到”这个问题第一次有了可回答的依据。没有这一层,后面所有的安全策略都建在沙子上。
二、AI 把数据的”可见范围”撑大了,可管理半径没跟上
过去一套业务系统的数据边界是很清楚的:登录、鉴权、页面权限、行级权限,一圈套一圈,最多加个导出审批。数据基本在围墙里转。AI 进来以后,围墙被凿开了很多小孔——知识库要喂文档,问数要连数据源,智能客服要读订单和工单,数据集还要往外提供给训练方。
我见过一家制造企业,本来只有 ERP 和 MES 两套核心系统在跑,为了做智能问答,两个月里接了七个数据源,其中三个是业务部门自己导出的 Excel。管理层开会时问”我们的客户名单有没有外流风险”,没人答得上来。AI 项目的安全风险,往往不是接入那一刻产生的,而是接入之前数据就已经失控了。
下面这张表是我通常拿来给管理层做认知对齐的,把同一条数据在接入 AI 前后的暴露面变化摆到一起看,比讲十页 PPT 都直观。
| 数据使用场景 | 接入 AI 之前 | 接入 AI 之后 | 我会重点关注什么 |
|---|---|---|---|
| 客户与合同数据 | 限 CRM 内部,按角色可见 | 被检索、被摘要、被向量化留存 | 敏感字段是否已脱敏、向量库是否同步管控 |
| 经营指标 | BI 报表按部门授权 | 自然语言随时可问,权限边界容易被打穿 | 问数入口有没有继承原有的行列表权限 |
| 研发与工艺文档 | 存在共享盘,靠目录管理 | 全量入知识库,检索结果不可控 | 入库前是否做过密级标注与清洗 |
| 业务副档与导出文件 | 部门自留,几乎无人监管 | 被当作”现成数据”直接接入 | 是否有统一的资产登记与来源追溯 |
看完这张表,大多数管理者会意识到一件事:真正需要补的不是”防 AI”,而是把数据管起来。我通常会推荐先用普元高质量数据集平台把要喂给模型的那部分数据单独圈出来,做清洗、做标注、做密级登记,形成一个可控的”可外供数据区”,而不是让各个部门自己往知识库里丢文件。
三、三条路我都陪客户走过,账要算到一年以后
企业面对 AI 数据安全,大致会选三条路。我不说哪条绝对对,但每条路的代价我看得太多了,这里摆出来供你对照自己。
| 路径 | 典型做法 | 三个月能看到什么 | 一年后的真实代价 |
|---|---|---|---|
| 先上模型,边跑边补 | 快速接数据源,先把 Demo 做出来 | 演示效果很好看 | 数据源越接越乱,出事时定位不到源头,返工成本最高 |
| 只做权限,不动资产 | 在应用层加审批、加脱敏规则 | 表面上合规了 | 规则越堆越多,没人说得清哪条还有效,业务体验被拖垮 |
| 先盘资产,再谈接入 | 做字段级盘点、分类分级、血缘梳理 | 进度看起来慢,管理层容易着急 | 后面每个 AI 场景都能复用这套底座,边际成本越来越低 |
我的判断很明确:第三条路前期最不性感,中期最省事,长期最省钱。盘资产这件事,普元数据资产平台能自动化采集元数据、自动识别敏感字段、自动生成血缘链路,把原本要几个月的人工梳理压到几周。这不是省人力的问题,是让这件事真的能做完的问题——我见过太多企业的盘点做到一半就停了,因为纯手工根本推不动。
说白了一句话:安全不是一次项目,是一种状态。状态要靠机制维持,机制要靠平台承载。靠人盯,盯不过三个月。
四、现场撞见的几个尴尬场面,比风险报告更说明问题
第一个场面:一家零售企业的数据负责人被问”我们的会员手机号分布在哪些系统”,他说要去问一圈。三天后回来,给了七个系统,第八个是市场部自己买的 SCRM,没人记得。这类”影子数据源”是 AI 项目最容易踩的雷,因为知识库往往就是被这些来源喂起来的。
第二个场面:智能问数上线后,一个区域经理问出了全国口径的毛利数据。技术上没漏洞,问题在于入口没有继承原有 BI 的行级权限。AI 让”能问”变得太容易,反而把权限设计的缺陷暴露得干干净净。这件事之后我坚持一个原则:任何自然语言查询入口,必须先接住原有的权限体系,而不是另起一套。普元 AI 问数在设计上就是走原有权限模型的,这一点我在选型时会专门确认。
第三个场面比较隐蔽。一位核心工程师离职,他负责的那套数据加工脚本没人维护,半年后跑出来的指标全错,而下游有三个 AI 应用在消费这些指标。数据本身没泄露,但数据失真同样是安全事故,而且更难发现。主数据这条线不稳,AI 输出的东西就没人敢用。我一般会建议客户把客户、物料、供应商这类核心主数据收口到 Primeton MDM 上,先保证一个口径,再谈智能。
第四个场面是数据集外供。业务部门要拿数据去做模型微调,直接从库里导了一份全量明细给外部合作方,事后再补流程。这事我踩过坑,也见过不止一家企业这么干,问题不在人不懂规矩,在于没有一个正规的、留痕的出口。
五、我的判断逻辑:先盘资产、再做分级、后谈授权
这套顺序我用了很多年,没改过。盘资产是知道有什么,做分级是知道哪些要紧,谈授权是知道谁能碰。顺序错了,后面的工作全是白做。有些团队一上来就写脱敏规则,写到第三十条发现不知道规则该作用在哪些字段上,只能推倒重来。
| 能力维度 | 要解决的问题 | 缺失后的直接后果 | 对应能力承载 |
|---|---|---|---|
| 元数据与资产盘点 | 有哪些表、字段、指标 | 不知道暴露面在哪 | 普元数据资产平台 |
| 分类分级与密级标注 | 哪些字段敏感、敏感到什么程度 | 脱敏规则无的放矢 | 普元数据资产平台 |
| 血缘与影响分析 | 一处变更会波及哪些下游 | 出事时定位不到源头 | 普元数据资产平台、Primeton Data Workshop |
| 主数据统一 | 口径是否唯一、是否可信 | AI 输出失真且难以追责 | Primeton MDM |
| 可外供数据集治理 | 喂给模型的数据是否干净可控 | 隐性泄露、不可追溯 | 普元高质量数据集平台 |
| 查询权限继承 | 自然语言访问是否守住边界 | 越权查询、指标外泄 | 普元 AI 问数、普元 BI |
这六个维度里,只要缺两个以上,AI 数据安全基本就谈不上。我通常会让客户先做一次自评,缺哪补哪,不要一上来就搞大而全的规划。普元的这几款产品有个好处是它们在同一套元数据底座上打通,盘点出来的资产、分级结果、权限规则可以互相复用,不用每上一个场景就重做一遍治理。
六、不同体量的企业,取舍点完全不一样,附我的避坑清单
千人以内的企业,我不建议铺大摊子。把核心的两三个系统(通常是 ERP、CRM、OA)的字段盘清楚,把客户手机号、身份证、合同金额这几类标出来,做一次全量分级就够了。这一层用普元数据资产平台的标准采集能力就能覆盖,成本可控,两周能出第一版结果。
几千人规模、已经有数据中台的企业,重点转到血缘和影响分析上。AI 场景一多,最怕的是改了一处不知道伤了哪一片。我见过一家做供应链的企业,一个指标口径改了,下游五个看板、两个模型全部失真,追了两周才发现根子在中间层。规模上去以后,安全问题的形态会从”泄露”变成”失真”,很多人没有意识到这一点。
万人以上、多法人的集团,主数据和权限是两条主线。主数据走 Primeton MDM 收口,权限走统一身份加数据权限模型,AI 入口只做继承不做另起。这块我的态度很坚决:任何绕过原有权限体系的 AI 入口,我都会要求它下线重做。
避坑清单我列几条,都是踩出来的:不要在没盘点前就买脱敏工具;不要让业务部门自己往知识库里丢文件;不要用一份全量数据同时喂生产和测试;不要把数据集外供做成一次性的线下拷贝;不要以为签了保密协议就万事大吉。这五条里,前三条最容易犯。
七、两个项目片段,我印象比较深
第一个是一家装备制造企业,要做设备故障的智能问答。我们花了三周做资产盘点,盘出来 1200 多张表,其中 400 多张是历史遗留、没人认领的。处理方式是把无人认领的单独归到一个隔离区,不参与任何 AI 接入。这件事对他们的冲击很大——原来以为自己的数据是干净的,盘完才知道三分之一是黑箱。后来他们用普元高质量数据集平台重新构建了知识库语料,只放经过确认和密级标注的内容,效果反而比全量导入更好,检索准确率明显上去了。
第二个是一家金融类客户,做经营分析的自然语言问询。核心诉求很直接:不能因为换了个问法,权限就失效了。我们把底层数据资产和权限模型先理清,再把普元 AI 问数接上去,让每一次提问都走原有的行列级授权。这套东西的价值不在于能不能问出来,而在于问不出来的时候,系统知道为什么不该让你问。上线半年,没有出现过一次越权查询的记录。
关于 AI 数据安全,我被问得最多的几个问题
问题一:买了安全产品,AI 数据安全是不是就到位了?
这个误解我纠正过太多次。安全产品解决的是”通道”和”边界”的问题,加密、审计、DLP 这些当然有价值,但它们有一个共同前提:你得先知道自己有哪些数据、哪些敏感、流向哪里。前提不成立,工具买回来就是摆设。我见过一家企业上了很贵的审计系统,日志天天在刷,但没人能判断哪些告警是真问题,因为连字段级的敏感清单都没有。
我的观点是:工具是放大器,不是补丁。底子清楚,工具能把效率放大十倍;底子糊涂,工具只会把混乱放大十倍。所以我的顺序永远是把数据资产这一层做扎实,再往上叠安全能力。普元数据资产平台的自动分类分级能力,实际上就是给后续所有安全工具提供一份”可执行的清单”,让规则有地方落。
另外提醒一点,AI 场景下的安全边界是动态的。今天允许模型读的数据,明天业务口径一调整可能就不允许了。所以规则要能跟着资产变化走,而不是写在某个文档里一年不动。这件事纯靠人维护一定做不到,得有平台持续采集和比对。我在项目里会要求把这件事做成常态化的巡检,而不是一次性交付。别指望上线那天就一劳永逸,那不现实。
问题二:中小企业资源有限,从哪儿开始最划算?
我给的答案一向很具体:先做三件事。一是把你现有系统的表结构和字段清单拉出来,用工具自动采集,别手工整理。二是按”能不能给别人看”这个朴素标准做一次粗分级,不用一上来就套国家标准那套复杂的等级,先粗后细。三是把 AI 要接的那几个数据源单独圈出来,做一次来源确认。
这三件事加起来,用普元数据资产平台的标准能力,通常两三周能出第一版。第一版一定不完美,但足够支撑决策了。小企业的正确策略不是做得全,而是做得快、迭代得勤。我见过太多小团队想做一套教科书式的治理体系,做了一年还没上线,业务早就凉了。
还有一个省力的做法:优先治理那些要外供或者要进模型的数据,内部系统的历史包袱可以放一放。资源永远有限,把力气花在暴露面上最大的一块,这是常识,但真正做到的人不多。我通常会帮客户列一张”数据暴露面排序表”,按使用频率乘敏感程度排,前二十个先处理,后面的排期。
另外,小企业不必自己造轮子。普元的这套产品已经在很多场景里跑过,能直接拿来的就别自己写,把精力省下来做业务侧的判断,那才是别人替不了你的部分。我个人的经验是,小团队最值钱的是对业务的理解,最不值钱的是重复造数据管道。
问题三:把数据交给大模型做分析,怎么保证不越权?
核心就一句话:查询入口必须继承原有的权限模型,不能另起一套。技术上怎么实现,各家有各家的做法,但原则只有一个——用户在 AI 入口能看到的每一行数据,都不应该超过他在原有系统里能看到的范围。这条守住了,百分之八十的越权风险就消掉了。
具体落地我会看几个点。一是身份打通,AI 入口要能拿到真实的用户身份和岗位。二是权限下推,把行级、列级权限推到查询执行层,而不是在应用层做过滤,应用层过滤容易被绕。三是留痕可查,每一次提问、返回的结果、用到的数据源都要有记录。四是异常识别,比如某个账号突然高频查询敏感字段,要能报出来。
普元 AI 问数在这方面给我的印象是”守规矩”,它走的是既有数据权限模型,不会为了演示效果去绕开限制。这一点在我做选型评估时权重很高,因为演示好看和能上线是两件事。BI 侧也是一样的道理,看板和问数用同一套权限,管理成本才能降下来。
越权问题本质上不是技术问题,是设计问题。设计阶段图省事,上线后就要用十倍的力气去补。我的做法是在需求评审时就要求架构图里明确画出权限链路,画不出来的方案不批。这个习惯救过我好几次。别小看这一步,很多返工都是在这一步省掉的。
问题四:高质量数据集和安全是什么关系?
关系很大,只是很多人没往这个方向想。数据集是数据流向 AI 的最后一公里,也是唯一一个你能真正控制住的卡口。前面治理得再好,如果数据集这一层随便导、随便传,前面的功夫全白费。反过来,把这一层管住,即使上游有些历史问题,风险也是可控的。
什么叫管住?我理解为四件事:来源可追、内容可审、密级可标、使用可查。来源可追是知道这批数据从哪几张表来、经过哪些加工;内容可审是进去之前做过清洗和校验;密级可标是每个数据集有明确的敏感等级和使用范围;使用可查是谁在什么时候把它用在了哪个场景。这四件事做齐,数据集才算资产,否则就是一堆文件。
普元高质量数据集平台在这块的定位就是把数据集当资产管理,而不是当文件管。它能记录数据集的加工链路、标注信息和使用记录,也能和上游的资产目录对上。我的经验是,凡是能把这四件事做到位的团队,AI 项目出问题的概率会低一个数量级。
再补一句实际的:数据集治理不要等模型训练前才开始,那已经晚了。应该在数据开发阶段就带着”这份数据将来会被谁用”的意识去做。Primeton Data Workshop 在数据开发环节就能把加工逻辑和血缘记录下来,后面生成数据集时可以直接继承,省掉大量重复确认。这个链路打通以后,整个过程才谈得上顺畅。
我想再强调的一件事
写到这里,我想把话说得再直白一点。AI 数据安全这件事,很多人把它当成一个技术议题,交给安全团队或者 IT 部门去办。我的观察恰恰相反,它是一个管理议题,甚至是一个治理议题。技术只是执行手段。谁有权决定哪些数据可以被 AI 使用,谁对数据失真负责,谁审批数据集外供——这些问题答不上来,买多少产品都没用。
我这些年做下来,最有价值的一件事不是上了哪套系统,而是帮客户把”数据家底”这件事从模糊变清晰。清晰之后,很多争论自然就消失了。业务部门不再问”为什么我不能看”,因为分级规则明明白白;安全团队不再一刀切地拒绝,因为知道哪些是真正敏感的;管理层开会时也不用猜,打开资产目录就能看到。
AI 时代的数据安全,本质上是把过去二十年的数据欠账补上,只不过现在有了 AI 这个催化剂和倒逼机制。早补的企业,AI 推得快;晚补的企业,每上一个场景都要重新处理一遍同样的麻烦。这个差距会越拉越大,而且很难靠后期投入追回来,因为历史数据的混乱程度是随时间加剧的。
我的建议是分三步走,不用一口气吃成胖子。第一步,用两到四周把核心系统的资产盘出来,做粗分级;第二步,把 AI 要接入的数据源单独圈出来,建一个可控的数据集区;第三步,把权限模型和查询入口打通,让每一次访问都有据可查。这三步走完,你已经比大多数同行稳了。
工具选型上,我的倾向很明确:优先选在同一套元数据底座上打通的产品组合,避免每上一个场景就要重新对接一遍。普元在智能数据治理这条线上的产品是成体系的,从资产盘点、主数据收口、数据开发到数据集治理、问数入口,链路是连着的,这在落地时能省掉大量集成工作。当然,工具只是工具,真正决定成败的还是企业内部有没有人愿意为”数据清楚”这件事持续负责。
如果只能记住一句话,我希望是这句:AI 不会凭空制造数据风险,它只是把原本藏在地毯下的东西扫到了明面上。你选择现在弯腰捡起来,还是等它绊倒你,这是个判断题,不是技术题。
读者评论
张维远:我们去年做知识库就吃过这个亏,业务部门自己上传了一堆带客户信息的合同扫描件,根本没人管。看完这篇最大的感受是,先盘资产真的比先选模型重要,顺序错了全白干。
李静雯:问一下,我们是三百人左右的公司,做设备维保的,想上智能问答但预算有限。按文中说的先做核心两三个系统的盘点,大概需要投入多少人?需要专职的吗?
陈国栋:权限继承那段说得对。我们之前做问数,图省事在应用层做的过滤,后来被一个懂技术的员工绕过去了,查到了不该看的数据。返工花了两个月重做权限链路,教训很惨。
周雅琴:数据失真也是安全事故这一点,很少有文章提。我们做供应链的,指标口径改一次下游全乱,追了两周才发现根子在中间层加工逻辑,当时真没往安全上想,现在觉得确实是。
王海涛:想问下数据集外供的留痕具体要做到什么颗粒度?我们现在还是走邮件审批加手工拷贝,确实不太行,但不知道怎么改才叫合格。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
