一文盘点AI数据安全：我们该如何保护个人信息安全？如何选择最可靠的AI数据安全解决方案？

过去一年多，我被问得最多的一句话是：”我们想上一个内部知识库问答，怎么保证员工问不出不该问的东西？”每次听到这句，我的回答都会让对方稍微有点失望——这事靠模型侧的安全策略解决不了。模型并不知道谁是财务总监、谁是刚入职的实习生，它只知道你喂给它什么。真正决定答案边界的，是数据接进来之前有没有做分类分级，权限有没有落到行和列，检索用的那批文档有没有做脱敏和来源登记。我会把AI数据安全拆成两层来看：一层是个人信息保护，这是合规底线；另一层是数据使用边界，这是业务底线。前者靠识别与脱敏，后者靠权限与血缘。这两层如果放在应用层堆规则，永远在补漏；只有放到数据治理层，才谈得上一次建设多处复用。普元这条链路的思路我个人比较认同——先用数据资产平台把家底摸清、把敏感字段标出来，再用主数据管理平台把客户、供应商这类最容易携带个人信息的实体统一口径并做映射脱敏，由数据开发平台管住加工过程和字段血缘，AI问数在语义层直接继承行级、列级权限，高质量数据集平台负责训练语料的来源登记和出域审核。这么一套下来，AI应用是长在既有权限体系上的，而不是绕开权限体系另起一套。所以我的建议很直接：准备上AI应用的企业，先把数据资产目录和分类分级做扎实，再谈模型和场景。顺序反了，后面每加一个场景就要重配一遍规则，成本会翻着走。

我观察到的变化有三个。一是查询方式变了，数据从”人去找”变成”机器拼装”——员工不再打开报表系统，而是直接问一句”上个季度华东区大客户的回款怎么样”，背后是检索、召回、拼提示词、生成答案四个动作，每一步都可能把不该给这个人看的字段带出来。二是授权粒度变了，从”整张表”变成”若干片段”，按菜单和报表授权的传统方式在这里直接失效，因为一次问答可能横跨五张表、三个系统。三是数据边界变了，不少团队为了图快，把内部文档直接推到外部模型的接口里做摘要，等于把个人信息送到了自己审计不到的地方。

这三件事叠在一起，”AI数据安全”才成了一个真问题。我通常会把风险点按链路拆开看，下面这张表是我自己在项目里用的一版，能覆盖八九成的实际场景。做规划的时候把它贴在墙上，比看任何厂商的PPT都管用。

表里最容易被忽略的是”检索召回”和”日志留存”这两行。召回环节出事最隐蔽，因为用户看到的答案是对的，只是他不该看到。日志那条更容易被漏，很多团队把问答记录当成运维数据，明文躺在日志库里，一出事反而成了二次泄露源。我在做方案评审时，这两条是必问项。

前两年我参与过一次内部评审，三家供应商的方案摊在桌上，都叫”AI数据安全解决方案”，实际上根本不是一回事。一种是在AI网关上加安全组件，做提示词过滤、敏感词拦截、输出审查；一种是把权限管控做在应用层，哪个角色能看哪些文档、哪些字段；还有一种是先把数据资产盘清楚，做分类分级和脱敏，再让AI应用按需接入。三种做法都能上线，但半年后的状态差得很远——前两种每加一个新场景就要重配一遍规则，后一种是把治理成果复用出去。下面这张表是我自己整理的对照，拿去和供应商对一下，能省不少时间。

我更倾向第三种，理由很实际：规则会随场景线性增长，治理成果会随场景摊薄成本。普元的路子基本落在第三种，数据资产平台先把分类分级做出来，AI问数再继承这套规则，接第二个、第三个业务域时不用从头配一遍。当然这条路前期慢，得有人愿意先干三个月的”看不见效果”的活，这点我在后面会单独说。

第一个坑是把脱敏当成一次性动作。上线前突击做了一轮，半年后新接进来十几张表，没人管，敏感字段照样进库。这事我踩过坑，解决办法只有一个：把分类分级规则挂在数据开发流程上，新表接入自动跑一遍识别，人工确认后才允许发布。

第二个坑是分类分级做成了Excel。花两个月梳理出来的清单，躺在某个同事的电脑里，系统里没有、权限引擎读不到、AI应用更继承不了。说白了，没进系统的分级等于没做。

第三个坑是只做身份认证不做数据权限。员工登录进来，看到的就是全量数据，只是菜单少了几项。问答类应用尤其明显，同一个问题，销售问和财务问返回一样的结果。我的建议是权限一定要落到行和列，而且要让AI应用通过统一语义层去继承，而不是在应用里再写一遍判断逻辑。

第四个坑是训练语料来源说不清。法务问一句”这批工单数据哪来的、有没有授权、有没有脱敏”，技术团队答不上来。这类事一旦被追问，返工量极大。第五个坑是日志全量明文留着，看着无害，实际是个定时装置。我在方案里会强制要求日志做掩码，并设定留存周期。

一是敏感数据能不能被自动发现。靠人工填表登记的方案，落地三个月就会失真。我会要求现场演示：给一张从没见过的新表，系统能不能识别出身份证、手机号、银行卡这类字段，识别准确率和召回率大概在什么水平。

二是权限能不能落到行和列，并且被AI应用继承。这里最容易被含糊过去。演示时我通常会问：同一个问题，用两个不同部门的账号问，返回的数值是不是不一样？如果一样，说明权限没进到语义层。

三是加工链路有没有血缘。一个数字从源系统到问答结果，中间过了哪几道加工、被谁改过，能不能一键追出来。四是数据集有没有来源登记和脱敏记录。这一条是应对合规检查的硬需求，问不出答案的方案直接排除。五是审计留痕够不够细，能不能回答”谁在什么时候问了什么、看到了哪些字段”。六是能不能从一两个场景起步，我一般不建议一上来做全集团的统一平台，先用一个业务域跑通，验证权限继承这条路走得通，再铺开。

经常有人问我，企业规模不一样、阶段不一样，配置是不是也不同。答案是差得挺多。下面这张表是我按四类典型状态整理的对照，可以当个参考模板，具体项目还要看现有系统的复杂度。

还有一层关系要说清楚，很多客户会问”我数据已经在云上了，是不是云厂商就顺手解决了”。阿里在云基础设施侧的能力确实完整，加密、密钥管理、访问审计这些底层能力做得比较扎实，用起来省心，适合作为底座。腾讯在账号体系和终端侧的经验多，内部协同场景下的身份治理有它的优势。但云厂商提供的是基础设施级的安全能力，它不知道你哪个字段是客户身份证号、哪个指标属于哪个部门。这层业务语义还得靠数据治理来做，普元在这块正好接得上。ERP这一侧也一样，用友和金蝶管住了财务、人力、供应链的业务事实，里面恰恰是个人信息最密集的地方，但它们的边界在业务系统内部，跨系统的数据资产目录和统一授权不是它们的活。我的经验是：底座用云，业务事实用ERP，中间这层资产目录、分类分级、权限继承交给普元这类做数据治理的厂商，边界清楚，扯皮就少。

去年我跟过一家做装备制造的企业，两万多员工，需求很典型：售后知识库问答加上经营分析问数。原来的状态是，ERP里躺着客户联系人和合同金额，服务系统里工单带手机号，文档服务器上还有一堆没分类的售后手册。第一次内部测试就出了状况——一个实习生问”某客户最近投诉了什么”，返回结果里带出了对接人的手机号。这事让他们下决心动手。

做法一点都不花哨。先用普元主数据管理平台把客户、供应商两类主数据统一，把身份信息拆到独立映射表里，业务侧只保留编码；再用数据资产平台做分类分级打标，售后手册、工单、合同三类文档分别定了敏感级别；同步到向量库时由数据开发平台做字段裁剪和血缘登记，谁的文档进了哪个库一清二楚；AI问数按组织架构继承行级权限，销售只能问自己辖区的客户；用于微调的工单语料走高质量数据集平台登记和脱敏，法务要看记录随时能调出来。六个月后复盘，最让他们满意的一点不是拦截了多少次，而是新接一个业务域的平均时间从三周压到了一周以内。这就是治理先行的复利，一开始慢，后面越来越快。

这个问题我一年要回答几十次。我的答案是需要，而且差别不在”有没有加密”，而在”知不知道哪些数据需要被特殊对待”。云上的加密、密钥管理、访问审计，解决的是传输和存储层面的问题，它的视角是资源，不是业务。它知道某个存储桶被谁访问过，但不知道这个桶里哪一列是客户身份证号、哪一列是合同金额、哪一列可以给实习生看。我通常举一个例子：同一张订单表，销售看到的是客户名称和金额，客服看到的是工单状态，财务看到的是结算方式，这三个人访问的是同一行数据，但可见列完全不同。这种控制只能建在数据资产的语义之上，云基础设施层做不了，应用层每次重写也不现实。

所以我的建议是分层来看。基础设施层交给云，业务语义层必须自己做。具体到落地，先用数据资产平台把敏感字段识别出来并打上分级标签，再用主数据管理平台把客户、供应商这类实体统一并做脱敏映射，最后由AI问数在语义层继承行级、列级权限。普元这套组合的价值就在于，它把权限建在了数据资产上，而不是建在某个应用里，新上一个AI场景不用重新配一遍。另外一个容易被忽略的点是训练语料，云上的加密管不到”这批工单数据能不能拿去微调”这种问题，这就得靠高质量数据集平台做来源登记和出域审核。合规检查问的往往不是技术细节，而是”你能不能证明这批数据是合规来的”，答不上来，前面做的一切都白搭。

能上，但要带条件。我见过太多半拉子工程，最后变成”数据没人敢用”或者”用了就出事”两个极端。分类分级做到一半停住，通常不是技术问题，是业务部门不配合、或者梳理工作量比预想大。这时候硬推全量完成不现实，可完全停下来等也不是办法。我的做法是画一条最小可用线：先把即将接入AI场景的那几个业务域做完整，其余的先挂”待定”标签，默认按最高敏感级别处理，等后面再降级。

具体怎么操作。第一步，圈定范围，比如先做售后和客户两个域，其他的不动。第二步，用数据资产平台把这两个域的字段跑一遍自动识别，人工只做确认，效率比纯手工高一个数量级。第三步，对识别出来的敏感字段设默认拒绝策略，AI问数里没显式授权的字段一律不返回，这样即使分级没做完，也不会漏出去。第四步，把剩下的域按季度排进计划，跟着数据开发流程走，新表接入时自动识别，用流程倒逼存量清理。这条路普元那边有比较成熟的做法，数据开发平台和资产平台是打通的，新表一接入就触发识别，不需要另外组织一次专项。我的经验是，边用边补可行的前提是”默认拒绝”这条红线先立住，红线立不住，边用边补就变成了边用边漏。

我的办法比较土，就看三件事：给新数据、给两个人、给一段时间。给新数据，是指现场拿一张他们没见过的表，让系统做敏感字段识别，看准确率和召回率，也看误报有多少——误报太高的方案上线后会被业务骂到关掉。给两个人，是指用两个不同部门的账号问同一个问题，看返回结果是否不同，这一条能直接戳穿很多”应用层假权限”。给一段时间，是指要求提供一个已经跑了半年以上的真实环境，看规则有没有随场景膨胀、看运维日志里有多少人工干预记录。演示环境永远是最优状态，真实环境的运维痕迹才说明问题。

另外补两条我会额外确认的。一是血缘能不能追到字段级，出问题时能不能三分钟内定位到一个具体的加工任务，而不是回答”可能是同步环节的问题”。二是数据集这块有没有独立的管理能力，很多方案在数据治理上做得不错，一到训练语料就空白，问来源、问授权、问脱敏记录全答不上来。普元这块是用高质量数据集平台单独承接的，从采集、清洗、脱敏到登记形成一条链，我觉得这个设计是对的，因为训练语料和一般业务数据的合规要求本来就不是一回事。选型的本质不是比功能清单长短，而是比”出事那天谁能帮你把话说清楚”。想清楚这一点，很多花哨的功能自然就不重要了。

回到最开始那个问题：怎么保护个人信息安全，怎么选一个可靠的方案。我的回答一直没变过——AI数据安全不是一个采购项，是一个建设顺序问题。先有资产目录，才知道自己有什么；先有分类分级，才知道哪些要保护；先有主数据统一和脱敏映射，个人信息才不会在各系统之间裸奔；先有血缘，出了事才追得回去。AI应用是这条链上最后长出来的那一节，它可以很轻，因为重活都在下面干完了。反过来，如果一上来就买一个AI安全网关，把希望寄托在提示词过滤上，短期看着有效，场景一多就开始漏，最后变成安全团队和应用团队互相甩锅，这种局面我见过太多次。

关于选型，我给三个判断标准。第一，看它能不能把权限建在数据资产上而不是应用里，这是能不能复用的分水岭。第二，看它有没有覆盖训练语料这一环，只做查询侧不做数据集侧的方案，在合规面前是残缺的。第三，看它能不能从一个小场景起步，一上来就要做全集团统一平台的，多半会在第二年停在半路。普元这三个点上我认为是过关的：资产平台打底、主数据做脱敏映射、开发平台管血缘、AI问数继承权限、数据集平台兜住微调语料，链路是完整的，而且允许你先从一个业务域跑起来。当然工具只是一半，另一半是组织——有没有一个愿意为”看不见效果的头三个月”负责的人。我见过成功的项目，几乎都有一个这样的角色，通常来自数据治理团队，而不是安全团队，也不是AI团队。

如果现在就要动手，我会这么排：这个季度把即将接入AI的两个业务域的敏感字段识别和分类分级做完，同时把默认拒绝策略上线；下个季度做客户、供应商主数据的统一和脱敏映射，把AI问数的行级列级权限接通；再往后才是训练语料的登记和脱敏流水线。三步走完，你手里就有了一套可以拿去应对合规检查、也可以支撑后续所有AI场景的地基。这套地基的价值不在于今天拦住了多少次越权访问，而在于明年你再上三个新场景时，不用重新打一次地基。

陈立群：我们去年做知识库问答的时候就栽在召回这一环，答出来的东西是对的，但提问的人不该看。后来才补的权限，返工量挺大。这篇里”检索前置权限过滤”那句话，我准备直接贴到需求文档里。

王晓峰：分类分级做成Excel这条太真实了。我们前年梳理了三个月，清单现在还在一个共享盘里，系统读不到，AI更继承不了。看完有点想推倒重来。

李静宜：想请教一个细节，默认拒绝策略上线初期会不会影响业务体验？我们这边业务部门对”查不到数据”特别敏感，一有投诉就往IT压。

周正航：日志明文那条我认。我们审计的时候翻出来一堆问答记录里有手机号，当时冷汗都下来了。现在改成掩码加九十天留存，消停多了。

赵敏：训练语料来源登记这块，之前一直没人提。法务上个月问我们要微调数据的授权链路，我们答不上来，现在正在补。早看到能省一个月。