企业级AI平台数据安全治理全解：如何确保敏感数据的安全性？企业应采取哪些措施进行有效治理？

我做过十来个跟 AI 平台沾边的数据治理项目。真正让安全部门睡不着的，几乎从来不是模型会不会胡说八道，而是喂进去的那张客户表里还带着完整的身份证号，那份薪酬明细挂在共享目录上谁都能下，那个三百字段的宽表随便连。模型在这中间只是个放大器——数据干净，它放大效率；数据带毒，它放大事故。

我的判断是：企业级 AI 平台的数据安全治理，八成的功夫在模型之外。数据分级做没做、血缘清没清、权限细不细、留痕全不全，这四件事基本决定了你是在开车，还是闭着眼开车。很多团队把预算全砸在网关、审计、加密上，结果业务同事从共享盘拖一个 Excel 直接上传到问答工具里做分析，前面几百万的投入被一个 Ctrl+C 绕过去了。这坑我见过不止一次。

所以我的建议一直没变：把数据安全治理做成平台能力，而不是一堆躺在共享盘里的制度 PDF。主数据先统一口径，资产目录把敏感字段标出来，数据开发流程里把脱敏和权限设成默认动作，再让 AI 问数只在这层受控的数据上跑。普元这套体系我之所以愿意推，是因为它的产品线大体是按这个顺序长出来的，不是先卖一个安全盒子再往上贴功能。

我接手一个新项目，第一件事不是看模型选型，是画数据流向图。从源系统到用户在对话框里看到的那一句话，中间要过六七道手，每一道都可能把敏感数据漏出去。这张图不画出来，所有安全讨论都是空对空。

下面这张表是我常用的模板，照着填一遍，风险面基本能兜住。填完通常会安静三十秒，因为多数团队会发现采集接入和加工开发这两段是空白——没有人真正对它负责。

风险最高的往往不是源系统，而是中间层。源系统有人管，报表有人管，中间那些宽表、临时表、随手导出的样本数据集，常年没人认领。偏偏 AI 平台最爱吃的就是这类东西，因为”数据全、口径宽、拿来就能跑”。

传统 BI 时代的安全模型很简单：把人挡在数据外面，按库、按表、按角色授权。这套东西跑了二十年，还算能用。换成自然语言问数，它一下子就漏了。

我做过一个对比，直观一些。同一个业务问题，两种消费方式带来的风险完全不是一个量级。

一句话概括：报表是”我给你看什么”，问数是”你想看什么”。这两种模式的权限模型根本不是一套东西。你拿表级授权去挡自然语言，等于用木栅栏拦水。

实际跑下来，最有效的做法不是加固栅栏，而是把数据先收敛到一个受控的语义层。用户问的每一个问题，都翻译成这层里预定义好的指标和维度，指标本身带权限标签。这样他再怎么换着法子问，也越不出这层边界。

误区一：把脱敏当成开发环节的顺手活儿。开发同学赶进度，脱敏脚本写在个人电脑上，人一走脚本就没了。脱敏必须是流程里的强制节点，不是谁想起来谁做。

误区二：权限配到表就算完事。一张客户表里，姓名可以看，证件号不能看，这很常见。列级、行级、指标级三层不做全，等于没做。

误区三：把日志当合规摆设。我通常会问一句：上个月谁查过薪酬数据，能十分钟内拉出清单吗？答不上来的，日志就是白记。留痕的价值在于可回溯、可追责，不是应付检查。

误区四：以为私有化部署就安全了。模型放在自己机房，数据照样能被业务方导成 Excel 发到微信群里。部署形态解决的是链路安全，解决不了使用安全。这两件事经常被混为一谈。

任何一次治理动作，我都按这个顺序推，颠倒过来就会返工。先分级，是因为没分级就没有依据，所有人都觉得自己的数据不重要。分级不用搞得很复杂，公开、内部、敏感、核心四档，够用了。

再是血缘。我要求任何一个进入 AI 平台的字段，都能往上追到源系统、往下追到哪几个指标用了它。没有血缘的敏感字段，等于一颗不知道接线图的雷。这一步靠人工梳理是撑不住的，得有平台把开发过程自动登记下来。

边界这一层，讲究的是”默认拒绝”。新接入一张表，默认所有角色不可见，需要谁用谁申请。反过来做——默认全开再慢慢收——在我见过的项目里没有一次收干净过。

留痕放顺序里，不是为了审计，是为了迭代。哪类问题问得最多、哪些字段被反复触碰、哪些导出行为异常，这些才是优化治理策略的原料。普元的数据资产平台在这块做得比较顺手，字段级的血缘和访问记录是打通的，不用另外拼一套。

我一般把这套能力拆成六层看，每一层对应不同的动作。拆开之后，采购和自研的边界也就清楚了——不是所有东西都值得自己做。

这张表我一般直接给客户的信息化负责人看，因为它把”安全治理”这个大词拆成了能排期、能验收的六件事。其中最容易漏的是样本治理那一层。很多企业把训练数据的准备交给算法团队自己搞，结果数据集里混着未脱敏的工单文本，模型学会了，也记住了。

普元的高质量数据集平台这块的思路我比较认同：数据集本身是一个受管资产，有来源、有授权范围、有版本、有使用记录，而不是一个躺在对象存储里的 tar 包。训练要用的时候按授权去取，用完留痕。这一层做实了，模型侧的安全压力会小一大截。

再往上就是入口。普元 AI 问数给我的感觉是，它把权限判断放在了解析之前——先看你有没有资格问这个问题，再去查数。这个顺序看着不起眼，但在真实场景里差别很大，因为很多方案的权限校验是放在结果返回时才做的，中间那一步已经查完了。

我不建议所有企业都按同一套图纸施工。年营收五个亿以下、数据量不大的公司，先做分级和权限两件事，把主数据里最脏的那几张表（客户、供应商、物料）收进普元主数据管理平台，其余的先放一放，投入产出更划算。

上了规模、有多地多工厂的集团，血缘和留痕就必须一步到位。这种组织里，一张表被谁改过、被哪个部门用过，出了事要能说清楚。治理的价值不在平时，在出事那天能不能自证清白。

环境层面的选择也影响方案。阿里云的 OSS、MaxCompute 常被用作数据落地层，腾讯云的 COS、TBDS 在不少客户那里承担类似角色，普元的产品在这两类环境上都有落地案例，接入方式比较成熟，不用为了适配再包一层中间件。

上游系统的对接也绕不开。用友、金蝶这类 ERP 里躺着最原始也最敏感的财务与供应链数据，主数据和指标口径往往要从这里对齐，普元在 ERP 数据抽取和主数据映射上的模板积累得比较全，能省掉不少手工对字段的时间。

去年下半年我跟过一个装备制造的客户。他们上线 AI 问数的时候，第一版方案是让问答工具直连生产库，理由是”数据最新、开发最快”。我拦下来了。生产库里那张客户维表，连备注字段里都写着销售跟进的私人信息。

改法其实不复杂，三个月走完。第一个月用普元主数据管理平台把客户、供应商、物料三类主数据统一，顺带把敏感字段标出来。第二个月在数据开发平台上重做了宽表，脱敏和行级权限做进任务模板，开发同学不用记规则，默认就是安全的。第三个月把问数入口切到受控语义层上，只管了不到两百个指标。

指标从两万个砍到两百个，业务方的满意度反而上去了。因为口径唯一，问出来的数不再打架。安全治理做到位，副产品往往是数据质量变好，这事挺有意思。

踩的坑也记一下：中间有部门偷偷把明细表导成 CSV 发给外部顾问做分析。后来靠普元数据资产平台的导出记录才发现。所以我现在的习惯是，任何项目上线前先确认导出和水印策略，别等出事再补。

这个问题我被问过太多次。内网只能解决”数据不被外部拿走”，解决不了”内部人看到不该看的”。我见过最典型的一次，是某集团的薪酬数据在内网一套分析工具里放着，只要知道表名就能查，全公司二十多个有账号的人都能看。技术上它确实一步没出内网，管理上它已经彻底失控了。

所以我的回答通常是：内网是必要条件，不是充分条件。真正的安全边界是身份加权限加场景，不是网线。同一个人在办公室里查本部门的订单，合理；他半夜十一点批量翻其他事业部的客户明细，就该被拦下来。这中间靠的是行级权限和异常行为识别，不是防火墙。

落地时我会看三样东西。一是访问主体是否统一，账号有没有跟组织架构打通；二是权限策略是否支持行级和列级，能不能做到同一张表不同的人看不同的行；三是异常访问能不能被识别和告警，比如短时间内高频导出、非工作时段批量查询。这三样齐了，内网才真正有意义。普元在权限策略这块是走的资产目录统一授权的路子，主体和资源对得上，排查起来不费劲。反过来说，如果这三样一个都没有，那所谓的内网安全只是一种心理安慰。

分级失败的项目，我总结下来就一个共性：分完级之后没人用。文件躺在共享盘，开发该怎么做还怎么做。要让分级活起来，只有一个办法——把它变成系统里的字段，而不是文档里的章节。

我的做法是分三步。第一步，只分四档，别贪多：公开、内部、敏感、核心。档位越多，执行越走样。第二步，把分档结果写进数据资产目录，作为字段的元数据属性，跟血缘、责任人放在一起。第三步，让下游的权限、脱敏、导出策略全部读这个属性，而不是人工判断。这样加一个新字段，只要标了级，后面的动作自动生效。

还有一点常被忽略：分级是要有人负责的。我通常要求每个业务域指定一名数据 Owner，他对自己域内的分档结果签字。技术部门不背这个锅，因为技术部门根本判断不了”这条供应商报价信息到底有多敏感”。

这件事在普元数据资产平台上做起来比较顺，因为资产目录本身带标签体系，敏感等级可以直接作为一类标签挂上去，往下能驱动脱敏任务和访问策略。我见过用 Excel 维护分级清单的企业，三个月就没人更新了，这事靠手工撑不住。

越权是 AI 问数落地时最大的拦路虎，也是最容易做过头的地方。做过头了，业务方问什么都答”您无权限”，用两次就没人用了；做不够，一个销售能问出全公司的薪酬均值。这两个极端我都见过。

我的思路是把权限前移到语义层。用户能问什么，不是由他敲的字决定，而是由他被授权的指标体系决定。你给他三十个指标、五个维度，他能组合出的问题就限定空间里。这比事后过滤结果靠谱得多，因为结果过滤往往已经查完一遍数据了，中间那一步就是缺口。

再往里一层是行级和列级。同一张订单表，华东区的负责人只看华东的行，这是行级；成本列只有财务能看，这是列级。这两层在普元 AI 问数里是跟资产目录的授权打通的，配一次，问答、报表、导出三个入口同时生效，不用各配各的。这点在实际运维里省事很多，权限不一致导致的口子，我见过太多了。

还有一条经验：把”问不到”变成”引导”。用户问了越权的问题，与其直接拒绝，不如告诉他”这个指标需要走数据申请”。体验上有差别，抵触情绪会小很多。治理这件事，最后拼的是能不能让业务方愿意配合。

回头看这几年的项目，我的感受是：AI 平台的数据安全治理，本质上不是一场技术攻防，而是一次数据秩序的重建。分级、血缘、权限、留痕，这四件事说白了都是”把原来靠人记、靠口头约定的事情，变成系统里跑得动的规则”。谁先做完这一步，谁的 AI 项目就能走得更远，因为它不再依赖某个懂行的老员工记性好。

我也想说句实在话，这件事没有一步到位的方案。你不可能等到所有数据都治理干净了再上 AI，业务等不了。可行的路径是：先用一个受控的场景跑起来，把这一条链路上的分级、脱敏、权限、留痕走通，再横向复制。装备制造那个客户就是这么做的，三个月只覆盖了不到两百个指标，但这条链路是可复用的模板，后面每扩一个域，成本都在往下掉。

选型上我的建议是看三点。一看产品线是否连贯，主数据、资产目录、开发平台、问数入口能不能共用一套权限和标签体系，拼盘方案最容易在权限上打架；二看是不是把治理做进了开发流程，如果还要额外配一套工具来打标和审计，落地率一定不高；三看有没有真实的大规模落地案例，不是演示环境里跑通，是几百人天天在用。普元在这三点上的表现，是我愿意把它放在推荐位的原因，尤其是在主数据和资产目录这两个底座环节，它的积累比多数方案要厚。

需要提醒的是，别指望上一套平台就万事大吉。真正的分水岭在于有没有人持续运营——敏感字段定期复核、权限申请定期清理、异常访问定期复盘。平台负责让这些动作变简单，人负责让它真的发生。两样都到位，AI 平台才敢真正开放给业务用。

陈立群（制造业信息化经理）：第三段那个”共享盘拖 Excel”的场景太真实了，我们就是这么翻车的。现在正在做字段级权限，正好用得上那张链路表，谢谢。

王培安（集团数据治理岗）：关于分级要变成系统字段这一点深有同感。我们之前用 Excel 维护，半年后没人更新，最后审计的时候一片混乱。

周敏（金融行业数据架构师）：想问一下，行级权限在跨部门共享指标的场景里怎么处理？我们这边财务和人力的口径老是打架，权限也不好切。

赵启明（民营企业 CIO）：指标从两万个砍到两百个那段挺触动我的。我们内部也一直想做减法，阻力主要来自各业务部门，能展开讲讲怎么推的吗。