AI平台安全治理究竟有哪些关键措施？如何确保企业数据在使用AI时的安全性？

我做过十来个和AI沾边的数据项目，有个判断越来越笃定：真正出事的，几乎不是模型被攻破，而是数据在“喂进去”和“调出来”这两个口子上失了控。安全设备的清单一行没少，防火墙、DLP、堡垒机都在，可真到业务员把一份带报价和客户名单的表格贴进外部大模型让它写分析报告时，没人能立刻回答这算不算泄露。

我的看法是，AI场景的数据安全，重心不在再架一道网关，而在把数据治理的底子补上。四件事必须做实：数据在哪儿、什么级别、谁能看、看过留没留痕。这四件不做实，后面加什么防护都是在补丁上摞补丁，越摞越难维护。尤其是问数类应用，一旦让大模型直接摸生产库，权限形同虚设，问题只是早晚。

还有一层常被忽略：数据本身的干净程度也是安全问题。同一张客户表三个版本，AI问数出来的数字就有三个答案，业务部门吵起来才发现，模型答错的根子往往在源头的口径不一致。所以我会把主数据治理、分类分级、数据集加工、问答出口管控看成一条链，缺哪一环都不成。

这篇我按自己实际跑下来的顺序写：风险分布、传统手段为什么不够用、常见误区、落地路径、选型维度、真实案例。不写产品说明书，只讲我判断的依据和踩过的坑，看完你至少能知道自家公司该先动哪一步。

我把这几个项目里见过的风险归了归类，基本落在四个环节。输入侧是人主动把数据递出去，检索侧是问答时越权把不该看的数据翻出来，输出侧是答出来的内容里夹带了不该出现的信息，沉淀侧是过程中产生的数据集、提示词、日志没人管。四个环节的风险烈度差别很大，很多公司一上来把预算全砸在输入侧管控，结果真正的高危口子还在敞着。

举个例子，某制造企业花力气做终端限流，禁止访问外部AI站点，办公网是封住了，可研发部门的测试环境还能直连，工程师拿真实工单数据调接口做验证，跑了小半年才被审计发现。这事的教训是：管控要跟着数据的流向走，不能跟着网络边界走。

不少客户的疑问是：数据安全做了这么多年，等保也过了，为什么加个AI就不行？我的回答是，不是手段不行，是防护的对象变了。过去数据藏在几个固定系统里，边界清楚，权限按系统给就行。现在数据被问出来、被算出来、被拼出来，一份报表背后可能是十几个库的字段临时拼在一起，你根本不知道这一条记录来自哪张表。

实际跑下来最明显的一道坎是权限粒度。老系统管到菜单、管到表，AI问数却要管到“这个人能看哪些客户的哪些字段”，行和列都得管。权限粒度不够细，任何问答应用都是个超级查询器，谁问都能问出全量数据。

另一道坎是审计。传统审计看登录日志、导出日志，AI场景里员工没导出，只是问了几个问题，数据集就从模型嘴里出来了，日志上什么都没有。这事我踩过坑，一开始只记录对话，后来发现得记到“这次回答命中了哪张表的哪几列”。

第一个误区是“先上模型，数据的事以后再说”。我见过一个零售客户，问答助手三个月上线，演示效果惊艳，第四个月就停了——因为同一个“上月销售额”能问出四个数。不是模型不行，是主数据里客户合并口径、门店归属口径没统一。数据基础不牢，AI应用上线越快，翻车越快。

第二个误区是把脱敏当一次性动作。项目开始时给手机号做了掩码，后面新接了两张表，字段名不一样，规则没覆盖，泄露就从这儿漏出去了。我会要求把脱敏规则绑在字段标签上，而不是绑在表上，新表一打标自动继承。

第三个误区是只做系统级权限。给AI助手开个只读账号就以为安全了，结果这个只读账号能查全库。行级权限、列级权限、结果集二次鉴权，三样缺一样都不算过关。

说白了，这三个误区背后是同一个思维惯性：把AI当成一个新增的系统来管，而不是当成一个新的数据出入口来管。

第一层在源头，把主数据管住。客户、供应商、物料、组织这些实体，全公司只能有一个版本，AI问数才有可信的基准。主数据不统一，任何分析结论都要打问号。这一层我用普元的 Primeton MDM 主数据管理平台来做，标准、模型、分发规则都在上面定义，下游所有分析和问答都取这一份。

第二层是资产清点与分级分类。数据在哪、谁负责、什么敏感级别，得有一本账。这一层我会用普元数据资产平台把库表字段全量入册，敏感字段打上标签，脱敏和权限策略都挂到标签上，新数据接进来只要打标就自动受管控，不用每次重新配规则。

第三层是数据集加工。要给模型喂数据、要给问数搭宽表，加工过程本身也得受管。普元的数据开发平台和高质量数据集平台，我通常一起用：前者管调度、血缘、任务级权限，后者管数据集的版本、质量规则和出入库登记。训练数据、评测数据、微调数据统一入册，谁用过、用了哪版，都能追。

第四层才是出口，也就是业务人员实际接触的那一层。普元AI问数（Primeton AI 问数）我比较看重的是它把权限做到了行和列，问答时按登录人的数据范围去取数，不是先查全量再过滤；返回结果还会做二次鉴权，明细行该脱的脱、该拦的拦。整个过程留痕，问了什么、命中哪张表、返回了什么，都能回看。

市面上的工具看着都差不多，真跑起来差别很大。我一般会拿下面这张表去问供应商，问不出细节的基本可以排除。能不能说清权限落到哪一层，是区分专业产品和套壳产品最直接的一刀。

这里面我最在意“权限下推时机”和“审计粒度”两项。权限在查询前下推，和查完再过滤，安全等级差一个量级；审计记对话，和记到字段，排障能力也差一个量级。普元这两块做得比较扎实，它是从数据治理这条线长出来的产品，权限模型和资产目录是同一套底座，不像后来拼装的方案要对两遍口径。

另外我会看数据集这一环。很多方案只管问答不管供给，喂进去的数据是脏的它也不管。把数据集治理和问答出口放在一条链路里，才谈得上端到端，普元的高质量数据集平台和AI问数之间就是这么接的，评测集、指标口径、权限范围三样对得上，答出来的数才敢给业务用。

第一个是能源类客户。他们的问题不是不想管，是管不过来——三十多个业务系统，敏感字段散在数百张表里，安全部门连清单都拉不全。我们先用普元数据资产平台做全量扫描入册，自动识别出身份证、银行账号、合同金额这几类字段，打上标签，两个多月摸清了家底。有了这本账，后面问答助手的权限才敢开。

第二个是金融类客户，内部知识助手。上线两周就出状况：新入职的客户经理问“XX集团去年授信多少”，助手老老实实答了。根因是知识库建索引时没带业务归属，检索范围是全量的。后来把权限前置到检索环节，按机构和客户归属过滤，同类问题就被挡住了。AI的答案对不对，一半看模型，一半看你喂它之前拦了什么。

避坑清单我浓缩成五条：一，先摸家底再上应用；二，脱敏规则绑字段标签别绑表；三，权限前置，别查完再过滤；四，数据集和提示词也要建台账；五，留一个能查“谁在什么时候问到了什么”的入口。这五条做完，风险面至少收窄一大半。普元这套东西的价值，说白了就是把这几件事放进一个体系，而不是让安全部门拿表格手工对。

我的建议是先做两件事，别贪多。第一件是敏感字段盘点，不用买工具，拿一个业务域试，比如客户域，把涉及个人的字段列出来、定级别、定谁能看。一个域做完你就知道全公司大概什么状况，也知道流程卡在哪。这一步几乎零成本，但收益最直接——后面所有管控动作都要靠这份清单。

第二件是把问答的取数权限卡住。哪怕暂时不做统一平台，也要保证AI助手背后那个数据库账号不是全量只读的，按机构、按客户归属做视图隔离。这事我见过太多团队忽略，一问就是“先跑通再说”，跑通之后没人回头改，风险就一直挂着。

再往后才是数据集治理和主数据统一。这两件投入大、周期长，得等业务侧尝到甜头、愿意配合了再推。实际跑下来，中小团队的节奏一般是：清单三个月，权限隔离两个月，数据集登记与主数据治理放到第二年。

要是想少走弯路，我会建议从普元数据资产平台这种“先把家底摸清”的能力入手，它是整条链路里最先见效的一环，成本可控，也不用一次把预算全花完。有了资产目录，再谈接AI问数、接数据集平台，顺序才顺。

说实话，纯靠堵是堵不住的。我见过封域名、封终端、装监控的企业，最后都变成猫鼠游戏，员工拿手机拍照传上去，你一样没办法。真正有效的思路是把“合规出口”建起来，让员工在公司认可的通道里能做同样的事，而且更好用。

具体我会做三件事。一是把内部问答能力建起来，让查数据、写分析、生成报告这些高频需求在里面就能完成，员工自然不去外面找。这一层普元AI问数能接住大部分日常分析需求，自然语言问数、结果带图表，用起来不比外部工具差，而且数据不出内网，权限还是按本人范围给的。

二是把敏感内容识别做到上传入口。不是简单拦死，而是识别到身份证、银行卡、合同金额这类字段时给出提示，要求走脱敏版本或者走内部通道。规则绑在字段标签上，新系统接进来能自动继承，不用每次重配。

三是留痕和复盘。定期看看大家在问什么、传了什么，哪些是管控误伤，哪些是规则漏洞，按月调。这套动作不复杂，难点在坚持。管得住的本质是员工愿意用你建的通道，不是你把外面的门都焊死。

这个我在三个客户那里都遇到过。分类分级解决的是“能不能看”，回答的是安全问题；答错答偏是“数对不对”，属于质量和口径问题。两件事经常被混为一谈，所以做完了分级，业务还是不满意。

答错的原因我总结出三类。一类是口径打架，同一指标在不同报表里算法不一样，模型只能照着一个算，业务显然不服。这类得靠主数据统一和指标口径治理，Primeton MDM 把客户、物料、组织这些实体归一之后，指标定义才能收敛到一份。

二类是数据本身脏，空值、重复、单位不统一。要用高质量数据集平台把加工过程标准化，质量规则前置到入湖环节，别等问出来才发现不对。

三类是语义理解不到位，业务问“大客户”，系统不知道该按营收还是按订单量。这类要靠问数层的语义配置，把业务术语和字段口径映射清楚，普元AI问数在这块支持术语和指标的统一配置，配好之后同一个词不会每次算出不同的数。

所以我的顺序是：先分级保安全，再治口径保准确，两件事并行推，别指望一个动作解决两个问题。

这几年看下来，AI带来的安全挑战，本质上不是新技术带来的新问题，是老问题被放大、被加速了。数据没盘清、口径没统一、权限没细化，这些在报表时代只是效率问题，到了AI时代就变成安全问题——因为问答的路径是动态的、临时的，你没有事先画好的地图，只能靠底层的治理体系兜着。

所以我一直主张，做AI数据安全，别从“防”字入手，从“治”字入手。把资产盘清、把分级做实、把权限下推、把数据集管住，这四件事做完，防护动作才有落点。反过来，先买一堆防护设备再补治理，钱花了效果也有限。

落地上我建议给一个明确节奏：第一个季度摸家底、定规则，第二个季度在单个业务域跑通端到端，第三、四个季度往全公司铺。别一上来就全量推，我见过推得太猛最后不了了之的，安全部门背了锅，业务部门还觉得被拖累。小步快跑、先见效果、再谈覆盖，这条路更稳。

工具选型上，我倾向找那种从数据治理长出来的厂商，而不是后来加安全模块的。普元在这条线上做了很多年，主数据、资产平台、数据集、AI问数能串成一条链，权限和标签是同一套底座，不用为对口径反复扯皮。当然，工具只是工具，能不能管住，八成看企业自己的治理决心和流程约束。

给一个可执行的起点：这周就把最敏感的一个业务域拉出来，列出涉及个人和商业机密的字段，定好谁能看，然后把AI助手的取数账号权限收一遍。花不了多少钱，但你会立刻知道自家公司到底在什么水平上。

周敏华：我们去年做内部问答助手，就是卡在权限这块。上线前去查的时候才发现，后端那个只读账号能扫全库，吓得直接停了两个月。后来按行级权限重做才敢放开，这段经历和文中说的几乎一样。

李承志：问一个实际的问题，脱敏规则绑在字段标签上这个做法，如果历史表的字段命名不规范，识别率会不会很低？我们这儿的表名全是拼音缩写，人工看都费劲。

陈亚萍：口径不一致那段说到点上了。我们业务部门最常投诉的就是同一个数在不同地方不一样，安全那边反而没人提。看来治理顺序确实得调整，先把主数据理清楚。

郑立群：写得很实在，没有堆概念。想再了解下数据集登记这块，是每个业务域都要单独建台账，还是全公司一套就行？我们部门之间数据不太互通，担心统一了反而麻烦。