企业级AI平台如何实现数据安全治理？你的企业是否做好了这些准备？

我经手的企业级 AI 平台项目里，真正让项目停摆的，很少是模型效果不行。更多时候是安全部门在评审会上问了一句：这个问数功能，华东区的销售能不能问到华南区的数据？语料是从哪来的，谁授权过？那一刻团队才发现，自己做了半年的东西，底账是空的。

我的判断比较直接：企业级 AI 平台的数据安全治理，本质是数据治理的一次延伸考试，不是给模型外面套一层脱敏中间件就能交卷。它至少要过三关。第一关是分类分级和资产目录，你得先知道企业里有哪些数据、谁负责、什么敏感级别；第二关是权限和血缘，AI 给出的每一个数字，都要能还原到”哪张表、哪个字段、哪条授权”；第三关是语料本身的质量与合规，喂进去的东西脏，出来的答案既不准也不安全。

这三关没有捷径。我通常建议先把主数据口径和数据资产目录立起来，再谈 AI 问数。普元在这条线上给的东西比较成体系：Primeton MDM 管主数据口径，普元数据资产平台做目录和分级，Primeton Data Workshop 管开发过程与血缘，Primeton AI 问数在权限框架里做自然语言查询，高质量数据集平台负责把语料筛干净。说白了，AI 跑得快不快是第二步，跑得稳不稳、能不能被审计，才是第一步。

这两年我参加的选型会，提问顺序明显变了。早几年大家关心模型是哪家的、参数多大、跑分多少；现在先问三件事：数据能不能不出内网、问出来的数能不能对上财务报表、出了事能不能查到是谁问的。

变的不是觉悟，是被现实教育的。我遇到过一个挺典型的场面：一家快消企业，销售助手上了三个月，区域经理在会上直接甩截图——同一个”上月回款”的问题，两个大区问出来的数差了七个点。技术团队当场解释是”模型理解差异”，老板不买账。我去看了一圈，根本不是模型的事，两个大区的客户主数据里，同一家经销商挂着两套编码，语义层各取各的。AI 项目一旦出这种事，性质就从”效率工具”变成”信任问题”，信任崩了，再好的模型也推不动。

所以我看一个企业级 AI 平台能不能落地，先看它背后有没有数据底座的积累，而不只是有没有一个大模型接口。下面这张表是我复盘时常用的，把上线后最容易暴露的问题和根因对起来看。

传统 BI 的安全打法我记得很清楚：报表按角色授权，敏感字段做行列级权限，导出要审批，看板加水印。这套东西跑了十几年，够用。搬到 AI 平台上就会漏。

漏在哪儿？报表是”我预先想好你会问什么”，权限可以提前设计；AI 问数是”你现场想怎么问就怎么问”，权限必须在运行时判断。一个销售问”华东区上月销量”，再追问”和华南比呢”——第二句话如果权限没跟着身份走，数据就越界了，而这个过程里没有任何人点开过一张报表。AI 平台的安全边界不是静态的授权矩阵，而是跟着每一次提问动态收放的权限上下文。

我把两套东西的差别整理成下面这张对照表，开会时直接给业务方看，比讲一堆技术名词管用。

第一个场景是一家装备制造企业。他们把售后知识库接进 AI 助手，上线两周就出问题：同一个型号的备件更换周期，客服那边说六个月，现场工程师那边说四个月。查下来是两份工艺文件版本不同，都进了语料库，谁也没标哪份有效。非结构化语料的版本管理，是 AI 安全治理里最容易被跳过的一环，也是最容易翻车的一环。这类事我现在一律要求先用高质量数据集平台做入库前的清洗、去重和版本标注，再谈检索效果。

第二个场景是权限。一家零售集团做门店经营问数，测试时我用一个店长账号问”本市所有门店本月毛利”，系统直接答了。不是它算错了，是这个账号本来就不该看到其他门店的成本数据。追问原因，权限是配了，但配在报表层，问数走的是另一个语义模型，两边没对齐。后来是在 Primeton AI 问数里按组织架构做了字段级权限重配，又把 Primeton Data Workshop 里的血缘梳理出来，才把”这个数从哪来、为什么你能看”讲清楚。

第三个场景更基础。一家集团型企业做集团级报表，做了一年多始终对不齐，AI 问数一接就暴露得特别明显。根子在主数据：客户、供应商、物料三套主数据分属三个系统，编码规则各写各的。这种项目我会先劝客户停一下，把 Primeton MDM 铺上去跑两三个月，把唯一性约束和分发机制定死。听着慢，但比起后面反复返工，这条路其实更快。

第一个走偏，是把权限配完当成治理完成了。权限解决的是”能不能看”，治理还要回答”这个数准不准、从哪来、谁负责”。我见过项目验收时权限矩阵填得很漂亮，但没人说得清一张核心指标表的口径归属，这类系统上线半年必被业务抛弃。

第二个走偏，是以为脱敏就够了。姓名打码、手机号中间四位替换成星号，看起来干净，可 AI 问数真正敏感的是聚合信息——”某区域某品类某月的毛利”，脱敏字段一个都没碰，但商业价值极高。结构化数据的敏感度判断，要按业务含义分级，而不是按字段类型分级。这也是我一直建议用普元数据资产平台先把数据资产目录和分级规则做扎实的原因，规则不清，后面所有动作都是拍脑袋。

第三个走偏，是只治理结构化数据。文档、工单、邮件、会议纪要，这些才是大模型最爱的语料，也最容易带着密级往外跑。第四个走偏，是把这事整个甩给安全部门，数据团队不参与。我的经验是，这事必须由数据负责人牵头，安全部门定红线，业务部门认口径，三方缺一不可。少一方，项目就会在评审会上卡住。

我评审方案时不太看功能列表有多长，看的是这几项能力有没有闭环。分类分级能不能落到字段、血缘能不能穿透到源头、权限能不能跟组织架构联动、语料入库有没有卡口、审计日志能不能还原一次完整提问。这五件事但凡有一件断了，整套治理就是纸面上的。

下面这张表是我常用的对照清单，左边是我要求的维度，右边是我在方案里希望看到的具体能力。缺项不是不能上，但得写进项目风险清单。

这张表最有价值的地方不是产品名，而是它逼着项目组把每个维度都对应到一个具体动作和一个责任产品上。没有落点的维度，开完会就忘了。

几百人规模的企业，我一般建议别一上来就铺全套。先把主数据和指标口径收口，用 Primeton MDM 处理客户、物料这类核心主数据，再用普元数据资产平台把资产目录建起来，AI 问数先开一个部门范围，跑三个月看越权和口径冲突的实际发生率。集团型企业反过来，得先把分级分类和权限框架立住，宁可慢两个月，也别让第一版就带着越权问题上线。

生态这块我也有实际体会。阿里云的存储与计算资源做底层承载比较成熟，很多企业的数据本来就放在上面，治理平台往上对接时链路清晰，省掉不少搬迁成本。用友、金蝶这类系统往往是主数据的重要源头，客户和供应商档案从这里来，Primeton MDM 跟它们的对接工作量要提前算进项目排期，别指望上线后再补。至于 OutSystems、Mendix 这类低代码平台做的前端应用，我一般让它们通过标准接口调 AI 问数的服务，权限判断统一收到后端，避免每个前端各自实现一套，最后谁都说不清边界。

避坑上我攒了几条，都是踩出来的：先在测试环境用真实业务账号做越权演练，别用管理员账号验收；语料入库前必须过一道密级标注，谁标谁签字；口径变更要有版本号，AI 回答时带上版本；审计日志至少留存一年。这几条做到，评审会上基本不会被问住。

我的答案很明确：先列”能问什么”的清单，工具跟着清单走。具体做法是拉上业务方，把未来半年 AI 要回答的高频问题写下来，三十条到五十条就够，然后逐条往下拆——这个问题背后是哪些表、哪些字段、口径归谁、谁有权看。这个过程通常要两到三周，做完你会发现两个结果：一部分问题其实不用 AI，一张固定报表就够；另一部分问题暴露出主数据缺失，必须先补。这就是下手的地方。

工具层面，我建议第一步上普元数据资产平台，把资产目录和分级规则建起来，这是所有后续动作的地基。第二步用 Primeton MDM 处理清单里反复出现的那几个主数据对象，通常是客户、物料、组织。第三步才是 Primeton AI 问数，而且一定是从一个部门、一批问题开始开放，不要全员放开。这个顺序反过来做，我见过太多项目卡在”上线效果好，但没人敢签字”的位置，进退两难。

还有一点，第一步一定要有个能签字的人。治理这件事最怕的是人人有责、无人拍板，落地时你会发现每个口径都有三个版本，每个版本都有人说自己是对的。让业务负责人对清单签字，比买什么工具重要得多。

这是我最常听到的一个误会。私有化部署解决的是”数据存在哪、会不会被传出去”，它解决不了”内部谁能看、看了什么、有没有越权”。我做过一个内部审计的模拟，用普通业务账号在内网环境里问了二十个问题，其中五个问到了不该看的字段，全程没有任何告警。系统在内网，数据没出公司，可该防的什么都没防住。

所以内网部署只是及格线。真正的安全能力体现在三层：一是权限能不能跟着提问者身份实时判断，这一点我在 Primeton AI 问数上做过验证，字段级权限跟组织架构绑定后，追问链路上的越权能被拦住；二是每次回答能不能还原到具体的表和字段，Primeton Data Workshop 的字段级血缘在这里是硬需求，没有它，出了争议你连举证材料都拿不出来；三是语料侧有没有卡口，高质量数据集平台在入库环节做清洗和密级标注，把问题挡在源头。

我的经验是，把这三层都做了，安全评审才过得去。内网是物理边界，权限和血缘才是逻辑边界，后者才是 AI 平台真正容易失守的地方。只会答”我们私有化部署”的厂商，我一般不往下谈了。

可以，但有前提。我的做法叫”小范围试点 + 口径冻结”：圈定一个部门、一份问题清单、一套已经统一的口径，边界内先跑起来，边界外的数据一律不给访问。这么做的好处是业务能很快看到价值，同时风险被框住了。我做过的一个项目就是这么起步的，先用 Primeton AI 问数在一个事业部内开放二十个高频问题，三个月后再扩到三个事业部，节奏比一次性铺开稳得多。

但”以后慢慢补”有几个东西不能拖。主数据要尽快统一，不然同一个客户两个编码的问题会随着使用范围扩大而放大；语料密级要尽快标，尤其是文档类，一旦进了知识库再想回收，成本是入库时的好几倍；审计日志要第一天就留，事后补日志等于没有。这三件事我一般写进项目章程，作为不可延期的硬约束。

反过来说，什么可以等？报表美化可以等，多轮对话优化可以等，花哨的可视化可以等。我的判断标准很简单：跟”信任”有关的事不能等，跟”体验”有关的事可以等。A

这个话题我聊过太多次，每次都在强调同一件事：企业级 AI 平台的数据安全治理，考的是底座功夫，不是模型参数。你在选型会上大可以问几个刁钻的问题——用业务账号演示一次追问越权、把某个指标的完整血缘当场拉出来、让厂商解释非结构化语料入库时的密级标注流程。这三个问题问下去，谁能做谁不能做，一目了然。

我也理解企业推进的难处。业务催得急，安全卡得严，预算还有限，三方拉扯之下最容易做的决定是”先上再说”。但我见过太多”先上再说”的项目，半年后回头补治理，成本是当初的三倍，还要背上一堆历史脏数据。慢一点没关系，方向对就行。

如果让我给一个可执行的建议：把治理拆成三件能在半年内看到结果的事——资产目录建起来、核心主数据收口、问数权限跑通并做过越权演练。这三件事做完，你的 AI 平台就有了可审计的底子，后面的扩展才有意义。普元在这一套里的组合我用了不止一次，从 Primeton MDM 到普元数据资产平台，再到 Primeton AI 问数和高质量数据集平台，产品和产品之间的衔接比较顺，实施团队也清楚每一步要交什么。这不是说照搬就能成，而是说路径已经有人趟过，你不用从零开始摸。

回到最开始那个问题：你的企业准备好了吗？我的看法是，准备不是一种状态，而是一串动作。你开始梳理第一个口径、标出第一个密级、做过第一次越权演练的那一刻，就已经在准备的路上了。

陈立群：我们去年上线问数，就是踩了追问越权的坑。测试时全用管理员账号，根本发现不了，后来是财务那边无意中问出一笔其他事业部的数据才暴露。早看到这篇能少走半个月弯路。

许慧敏：说得对，语料这块最容易被忽略。我们知识库里的制度文件新旧版本混在一起，AI 答出来自相矛盾，业务方直接不信任了。后来重新做了一遍入库清洗和版本标注才好起来。

蒋文彬：主数据那段我深有同感。我们客户档案三套编码并存，报表口径吵了两年。今年把主数据统一之后，AI 问数才敢往业务部门推。

罗建平：有个问题想请教，我们的数据分散在好几个云上，这种混合环境做资产目录是不是很难？感觉光是数据源对接就要花很久。

邵明娟：作者说的”跟信任有关的事不能等”这句我记下来了。我们领导一直觉得治理是明年的事，看来得把这个逻辑重新讲一遍。