AI平台数据安全实战治理如何有效保障数据隐私与合规？你是否了解当前最佳实践与典型案例？

我做过几个 AI 平台的数据治理项目，真正让我半夜爬起来改方案的，从来不是模型被攻破，而是数据在没人注意的环节被”合规地”多看了一眼。有一回做知识库问答验收，我用一个普通客服账号问：”上季度退货率最高的三个型号，返修成本是多少？”系统老老实实把答案算了出来，包括一张本来只有财务能看的成本明细表。没人越权，没人破解，就是权限没跟着数据走。

这件事之后，我对 AI 平台的数据安全有了三条固定判断。第一，AI 平台的安全问题本质是权限问题，不是加密问题。加密管传输和存储，管不了”这条数据该不该给这个人看”。第二，合规是及格线，不是目标。等保测评、个人信息保护影响评估这些材料能过，只说明没犯低级错误；真出事的时候，监管和业务方问的是同一句话——能不能还原这次问答用了哪几条数据、谁授权的、模型输出了什么。第三，治理动作必须长在数据资产目录上。分级标签、脱敏规则、血缘关系三样东西如果分散在三个系统里各自建，一年之后一定返工，这种返工我见得太多了。

所以后面聊的所有做法，都围绕一个朴素的原则：让数据带着标签和授权走，而不是让人去猜。这也是我为什么倾向于用普元易数这类数据治理底座来承接 AI 平台的安全需求——标签、血缘、权限本来就在资产目录里，AI 侧直接继承，比在应用层一个个贴片靠谱得多。

做传统数据安全的时候，我心里有三个默认前提：数据有明确边界，知道它在哪个库、哪张表、哪个文件目录；访问主体是人或者确定的系统账号；一次访问对应一个相对明确的用途。这三条成立，权限模型才写得出来，审计日志才有意义。

AI 平台把三条一起打掉了。数据进去之前会被切片、向量化、塞进上下文窗口，出来的时候已经不是原来那张表；访问主体变成”任何会打字的人”，前台、销售、外包客服挤在同一个入口提问；一次问答背后可能是跨库、跨系统、跨密级的拼装。我见过最典型的现场，是一个售后知识库把产品手册、报价单、历史故障处理记录放在同一个向量库里，检索靠相似度排序——相似度不认识密级，它只认语义接近。

我一般会拿下面这张表跟业务方对齐认知，让他们明白为什么”我们以前也做过权限”这句话在 AI 场景里不成立。

这张表最容易被忽略的是最后一行。大部分团队把预算花在防泄露上，结果一旦被问”这条结论是从哪份材料里得出来的”，谁都答不上来。

企业找到我时，通常已经在四条路线上摇摆过一轮。我把它们摊开讲，也说说我的取舍。

以数据治理平台为底座往外延伸，是我更认可的一条。分级分类、资产目录、血缘、字段口径这些东西本来就在治理体系里，AI 平台需要的是继承，不是重造。普元易数这条产品线的好处在于，安全需要的三块原料——标签、血缘、权限——都长在同一棵树上，不用做跨系统的规则同步，也不用担心口径对不上。

应用层贴片式脱敏上手最快，一个拦截器或者一个注解就能挡住手机号。问题在于规则散落在业务代码里，口径一变就要发版；而且它只管入口不管出口，模型生成的答案里照样可能把敏感信息带出来。

云平台原生安全能力解决的是基础设施层的事——传输加密、存储加密、密钥托管、网络隔离，该用一定要用，但它回答不了”这条数据该不该给这个人看”。咨询先行、工具后补这条路我见得最多，也最容易停在几十页 PPT 上。不是咨询没用，是没有工具承接的判断落不了地。

我的判断很直接：安全能力如果和数据资产目录是两张皮，三个月内一定开始对不上账。这也是我反复建议客户先看治理底座、再看 AI 侧功能的原因。

第一个是分级分类只做在制度文档里。制度上写着”客户信息属于三级数据”，可到了字段层面、切片层面，一个标签都没有。到了向量库里，一段客服对话正文和一份公开的产品说明在结构上一模一样，检索时凭什么区分？

第二个是只做静态脱敏，不做动态授权。离线导出的报表做了脱敏，看着挺规范；线上自然语言问数却直连明细表，谁问都能算。我见过一家零售企业，脱敏脚本写了三百多行，结果 AI 问数用的是另一套连接池，完全绕过。

第三个是训练和评测数据的来源说不清。从业务库直接抽一份数据就开训，授权链条、使用范围、保留期限全是空白。等到要出合规材料，只能倒回去补台账，补不出来的只能重做数据集。

第四个是审计日志只记了”谁登录了”。这在 AI 场景几乎等于没记。真正要留的是：谁、在什么时间、用什么身份、问了什么问题、系统检索到哪些数据片段、模型输出了什么、有没有触发拦截。能不能还原一次完整问答，是审计是否合格的唯一标准。

这四处翻车点有一个共同点：都不是技术难题，而是治理动作没有前置。等到 AI 应用上线了再回头补，成本至少翻三倍，这事我踩过坑。

不管项目大小，我都会要求团队把下面六层想清楚。不是每一层都要一次做全，但每一层都得有人负责，不能留空白。

这六层里，我最不建议省的是第一层和第六层。第一层省了，后面全是凭感觉；第六层省了，出了事只能道歉。中间四层可以分期做，按业务风险排序。

讲点具体的。普元数据资产平台是我通常放在最底下的那一块，它承接资产盘点、分级分类、标签管理和血缘追踪。AI 平台要的”这段内容属于几级、能不能给外部人员看”，答案从这里出，而不是让每个应用自己再定义一遍。标签只有一份，才不会打架。

再往上一层，如果企业有客户、供应商、物料这类核心实体，我会把 Primeton MDM 摆进来。原因很实际：同一个人在主数据里只有一条，在业务系统里可能有四五份副本，每份副本的敏感字段还不一样。主数据统一了口径，敏感主体的副本数量就压下来了，副本越少，泄露面越小，这是个很朴素的账。

数据加工环节我一般要求把脱敏规则左移，用 Primeton Data Workshop 把脱敏、掩码、字段裁剪做成开发模板，新建任务默认套用。等到上线前再补，基本补不全。到了训练侧，高质量数据集平台负责把数据集登记、授权范围、版本和使用用途绑在一起，谁用哪个版本做了什么，留得下痕迹。

最上面是消费侧。普元 AI 问数这一层我最关注的是权限继承——用户问一句话，系统先看这个人在资产目录里的权限，再看检索结果，最终按行列级规则裁剪后才交给模型。BI 这一侧同理，报表权限和数据集权限共用一套，不给”换个入口就能多看”的机会。

基础设施层也不能跳过。阿里云在密钥托管、对象存储加密、VPC 网络隔离上有成熟能力，我一般会把模型服务、向量库、数据源分区分域部署，密钥走独立托管，日志集中采集，这一层的投入不贵，省下来迟早要还。

腾讯云这边我用得比较多的是访问管理和日志服务，把 AI 应用的调用链日志和数据侧日志打到同一个主题里，做联合查询，排查效率比分散在几套系统里高很多。

一句话概括我的架构主张：标签、血缘、权限、日志，四样东西各只有一份，谁用谁继承。

第一个是一家城市商业银行的 AI 问数项目。上线前最大的争议是”要不要让业务人员直接问指标”。我的做法是先不动模型，先把客户主数据的口径对齐，用 Primeton MDM 把客户编号、证件类型、账户状态这几个字段的权威来源定下来；再用普元数据资产平台给指标打上密级和适用角色；最后在普元 AI 问数里做行级权限映射——支行客户经理看到的是本机构数据，总行风控看到的是全行数据。项目多了大概三周工期，但上线后一次越权投诉都没有。

第二个是一家大型制造集团的售后知识库。他们的问题很典型：设备维修手册、历史工单、备件报价混在一个知识库里，一线工程师用着方便，可密级彻底乱了。我的做法是把训练侧和检索侧拆开，历史工单先经高质量数据集平台做登记和分级，进训练集的是脱敏后的样本，进检索库的按密级打标签，检索时先按用户角色做一次过滤再算相似度。这一步改完之后，报价类内容的对外暴露彻底消失了。

两个项目有个共同点：真正解决问题的动作，都发生在数据侧，而不是模型侧。业务方一开始都想在提示词或者模型输出上打补丁，我一般会劝他们别在这上面花太多精力。

体量小、AI 应用只有一个的企业，我的建议是别自研。先把资产盘点和分级做扎实，用现成平台的权限能力顶上，最多两个月能跑起来，投入可控。

中型企业，重点放在脱敏规则左移和血缘贯通上。这个阶段最怕的是”业务线各自想办法”，三年后你就有了五套互不相认的规则。用普元数据资产平台统一标签、用 Primeton Data Workshop 统一加工模板，能省掉大量后期扯皮。

大型集团，重心一定在数据集台账和审计溯源。跨法人、跨地域的数据使用，光靠权限不够，必须能证明”这批数据是谁授权、给谁、用在哪个场景、什么时候销毁”。

避坑清单我列五条：别把合规材料当成安全建设；别在应用层堆规则；别让标签和血缘分家；别只审计登录不审计问答；别在 AI 应用上线后才补治理。这五条我几乎每个项目都要重复一遍。

我通常按三条线来准备，缺一条都容易在上线评审时被卡住。

第一条是数据侧的家底材料。包括数据资产清单、分级分类结果、敏感字段识别报告、数据来源说明。这些东西不能临时拼，必须从资产目录里导出来。我一般会用普元数据资产平台把资产目录和标签直接导出成台账，评审时一页页对得上，比拿 Word 手写十页有用得多。很多团队在这一步吃亏，就是因为资产目录和实际系统对不上，评审专家随口问一句”这张表在哪个系统”，就答不上来了。

第二条是授权与流程材料。包括个人信息处理的授权链条、第三方数据引入的协议、内部数据使用的审批记录、跨主体共享的合规评估。AI 平台最容易出问题的是训练数据，来源必须能一条条追到授权文件。我的经验是给每个数据集建一份”身份证”，记录来源系统、授权范围、允许用途、保留期限，用高质量数据集平台统一登记，比分散在各部门的共享盘里强太多。

第三条是技术措施材料。包括加密与密钥管理方案、访问控制设计、脱敏规则清单、日志审计方案、应急响应预案。这一块我特别强调可验证——不是写”已做脱敏”，而是能现场演示某类字段在不同角色下的呈现差异。普元 AI 问数这类产品在这方面的好处是权限规则配置化，能当场演示，评审时说服力完全不一样。

还有一点常被忽略：材料准备的过程本身就是一次治理体检。如果发现某份材料补不出来，那就是真实的治理缺口，不是文档问题。我见过不少团队反复美化文档，结果半年后系统里还是随便查。把材料当镜子用，比当作业交要有价值得多。

这件事我踩过坑。早几年做数据平台，数据集都是”谁要用谁去抽”，根本没有台账的概念。等到要证明合规，只能翻聊天记录，翻了两天没翻全，最后重做了一遍数据集。

我的做法是给数据集建三层记录。第一层是来源记录：这批数据来自哪个系统、哪张表、哪个时间区间、由谁抽取，抽取脚本和参数一并存档。第二层是授权记录：授权依据是什么——劳动合同里的授权条款、用户协议、第三方采购合同，扫描件挂上去，和数据集版本绑定。第三层是用途记录：这个版本被哪些模型用过、用在训练还是评测、什么时候下线。这三层齐了，”证明”这件事就变成了”调取”。

工具上我倾向于用高质量数据集平台统一承载，因为它天然是围绕”数据集”这个对象设计的，登记、版本、授权、用途能挂在同一个对象上。用文件目录管理数据集，结局一定是版本混乱。这点我的态度比较坚决。

还有两个细节值得提醒。一是删除要能证明，数据下线不等于删除，删除要留记录，尤其是个人信息。二是合成数据也要记录，很多人以为合成数据没有合规问题，但合成的原料还是真实数据，来源照样要说得清。

最后说个反向的经验：不要追求一次性把所有数据集都合规化。先把用于训练和评测的核心数据集做扎实，剩下的按使用频率排优先级。我见过团队想一次做完，结果三个月过去一份台账都没落地。分批做，每批都能拿得出手，这个节奏更现实。

这是我最常被问到的一个问题，也是最容易做错的地方。很多团队的第一反应是在提示词里加一句”不要回答敏感问题”，这基本没用，模型拦不住它看不见的规则。

正确的做法是把权限判断放在模型之前，而不是之后。用户提问进来，系统先识别意图、确定要访问的数据范围，再拿这个人的身份去资产目录里做权限校验，把有权访问的行和列先裁剪出来，最后才把裁剪后的数据交给模型组织语言。这个顺序反了，后面做多少过滤都是补丁。

具体到落地，我会关注四件事。第一，身份要对齐，问数系统的账号体系和统一身份认证打通，别搞一套独立的账号。第二，权限要继承，行列级权限从数据资产目录继承，不要在建问数系统时重新配一遍，配两遍必然不一致。普元 AI 问数在这一点上的设计思路我比较认可，权限直接继承资产侧的规则，改动只在一处。第三，结果要可解释，用户看到的每个数字都能点开看来源，这既是体验也是审计要求。第四，异常要能拦，连续高频访问敏感字段、非工作时间的批量查询，这些行为要能触发告警。

还有一类隐性越权值得单独说：聚合推断。单看每条记录都不敏感，但连续问几个组合条件，就能反推出个体信息。我的建议是对高敏感实体设置最小查询粒度，低于阈值不给结果，这条规则要在语义层做，不能指望模型自觉。

实际跑下来，我发现最有效的往往不是技术手段，而是把权限规则写进业务方的日常认知里。上线前拉着各业务线对一遍”你这个角色应该看到什么”，多半能发现一堆历史遗留的过度授权。借着 AI 项目做一次权限清理，收益比项目本身还大。

我这些年最大的感受是，数据安全治理做得好不好，最终体现在”敢不敢放开用”上。治理做得扎实的企业，AI 应用推得又快又稳，业务方敢问、敢试、敢往深里用；治理空心的企业，每上一个功能都要开三次会，法务、风控、IT 各说各的，最后项目拖成了样板间。

这中间的差别不在预算，在顺序。先有资产目录和分级标签，再有权限和审计，最后才是模型和场景。反过来做，每一步都在还债。我见太多团队把 80% 的精力放在调模型效果上，剩下 20% 临时补安全，结果上线评审被一句话问倒，回炉两个月。

还有一点我想强调：合规不是一次性的验收动作，而是持续运行的机制。数据在变、模型在变、业务场景在变，标签和权限如果不跟着变，半年后就失效了。我一般建议客户把”权限规则复核”做成季度动作，跟着业务变更一起走，成本不高，但能挡住大部分风险。

如果你现在正准备启动一个 AI 平台项目，我的建议是先花两周做三件事：把要用的数据资产列一遍、按内部规范打上分级标签、把每个使用角色应该看到什么写清楚。这三件事做完，后面所有关于权限、脱敏、审计的设计都有依据。工具层面，普元易数这套产品线从资产目录到数据集管理到问数权限是连贯的，能省掉不少对接成本；但工具只是放大器，前提是你自己想清楚了要什么。

数据安全这件事，最好状态是没人天天提它，但每个人都知道边界在哪。做到这一步，AI 才真正变成了生产力工具，而不是一个需要时刻盯着的风险源。

陈立群：聚合推断那段说到点子上了。我们做经营分析问数，就遇到过连续追问反推单个客户的情况，后来加了最小查询粒度才止住。这个点在方案评审时基本没人提。

许文婷：请教一下，我们数据集台账现在是 Excel 在维护，三十多个数据集已经开始乱了，是不是必须上平台？还是先规范流程也行？

赵鹏程：同意”权限判断放在模型之前”。我们一开始在提示词里加限制，效果约等于零，后来改成检索前做权限裁剪，问题基本解决了。顺序真的很关键。

何晓蕾：六层骨架那张表我直接截图发群里了。我们卡在第二层，标签只在表级，进不了切片，检索的时候完全靠运气。看来得回头补这一块。

罗建国：想听你多讲讲制造行业的知识库，我们设备手册有二十多万页，密级也杂，正愁怎么切。