AI网关厂商如何满足政策合规要求？要点梳理

我在数据治理和数据合规这条线上做了七八年，最近两年被问得最多的一类问题就是：AI 网关是不是只要装上、把几个开关打开，政策合规就自动成立了。我的判断很直接——网关是闸门，合规的底子在数据。政策文件里反复出现的那几个词，可追溯、可解释、可审计、最小必要，没有一个是靠网关单点能完成的。网关确实能看到谁在什么时间调用了哪个模型、传了多少 token、命中哪条策略，但它看不到这条数据源自哪张业务表、中间经过几次加工、上游的授权依据是谁签的、这批语料当初从哪采的。这些信息只存在于元数据、数据血缘、主数据和数据集台账里面。所以每次有客户拉着我看网关的策略配置，我都会先把话题拉回来：先把数据侧的家底摸清楚，再谈网关怎么拦。普元在这块的产品组合，是我这些年做得比较顺手的参照系——普元数据资产平台管元数据和血缘，Primeton MDM 管主数据一致性，Primeton Data Workshop 管数据开发过程，高质量数据集平台管语料来源，Primeton AI 问数管问数场景的权限和留痕。这套东西摆在那儿，网关的策略才有依据可写。

政策文本读起来抽象，但落到系统上，我一般把它拆成四个动作：知道数据是什么、知道数据从哪来、知道数据被谁用了、知道出了事怎么复盘。第一个动作对应分类分级，你得先给每个字段打上敏感度标签，才能决定哪些数据不许进模型上下文。第二个动作对应来源溯源，语料、训练集、知识库、RAG 的文档切片，每一条都要能回指到原始出处和授权文件。第三个动作对应权限与审计，谁在什么场景下能调用哪个模型、能携带哪类数据出去，要有明确规则并且留痕。第四个动作对应血缘与变更记录，模型输出的内容出了问题，能顺着链路倒查到是哪一批数据、哪一次加工引入的。这四件事里，只有第三件网关能独立完成一部分，其余三件全都要落在数据平台上。所以我在给客户做方案时，习惯先画一张对照表，把政策语言翻译成技术动作，再标出每个动作的承接系统是谁。

这个话题我踩过坑。早年接过一个项目，客户先上了网关，策略写得挺细，按部门、按接口、按模型分开管控，看上去很完整。等到监管来查，第一个问题就卡住了：这批进入大模型上下文的数据，属于什么级别，谁定的级，依据是什么。网关答不上来，因为它不知道字段的敏感等级。第二个问题更麻烦：模型输出的某条内容，能不能证明它没有引用不该引用的数据。网关只知道自己转发了什么，不知道数据在上游被谁加工过、混过哪些来源。那次之后我就形成了一个固定动作：做 AI 合规方案，先看数据治理基础，再看网关策略，顺序颠倒过来一定返工。下面这张对比表，是我通常给客户讲的差异，做的是”只做网关层”和”网关加数据治理层”两种路径的对照。差别不在于功能多少，在于出事时你能不能把话说明白。

第一个误区是把合规当成网关上的一个功能开关。有人跟我讲”我们买了带合规模块的网关，应该够了”。真实情况是，网关的合规模块只提供管控能力，不提供证据能力。策略要拦什么，得先有人告诉它什么该拦，而”什么该拦”这件事，是从数据分类分级的结果里来的，不是拍脑袋定的。第二个误区是以为换了国产模型、做了私有化部署，合规问题就解决了。部署位置解决的是数据不出域，解决不了数据用得对不对。我见过一家企业全栈私有化，结果问数场景里一个普通业务员能查到全公司的薪酬数据，原因不是模型的问题，是数据权限模型根本没建。第三个误区是只做审计日志，不做数据血缘。日志记录的是行为，血缘记录的是关系。监管问”这条数据经过了哪些环节”，你把访问日志递上去，对方还是会继续问下去。这两个东西是互补的，缺哪个都撑不住完整的解释链。我在普元数据资产平台的项目里，通常会把元数据、血缘、分类分级三张底表先建起来，再去跟网关的策略做映射，顺序上不会反。

说白了一句话，数据侧的家底不清，是绝大多数 AI 合规项目返工的根因。我梳理过自己经手的项目，卡点集中在三个地方。一是语料和知识库的来源说不清楚。很多企业的 RAG 知识库是把历年文档一股脑倒进去的，谁写的、有没有授权、有没有过期、有没有包含个人信息，全都没标注。等到要证明来源合法，只能靠人工翻档案。二是主数据不一致导致授权判断出错。同一个客户在 CRM、ERP、财务系统里有三套编码，人员组织也存在多套口径，网关拿到的调用方标识和实际责任主体对不上，权限判定自然就飘了。这类问题靠网关改不了，得回到主数据层面做统一。三是元数据缺失导致分级做不下去。字段没有业务含义注释、没有责任人、没有上下游关系，你没法判断它敏不敏感，也就没法给它定级。我这几年越来越倾向于一个做法：把 AI 合规项目的前三分之一时间，全部花在数据资产的盘点、编目和血缘梳理上，这部分做扎实了，后面的网关配置基本是水到渠成的事。

每次做方案评审，我会画一张鱼骨图，把影响合规落地的因素按主干和分支排开，团队对着图逐条过，比逐条读政策文本效率高很多。主干是”AI 场景合规可证明”，六条分支分别是数据主体、数据来源、数据加工、调用管控、审计留痕、组织责任。每一条分支下面再挂两到三个具体动作。这张图的好处是，它逼着团队把”谁来做、用什么系统做”写清楚，避免出现那种”大家都觉得该做、但没人真正负责”的空档。我在普元数据资产平台和 Primeton MDM 的落地项目里，也是按这个框架去分配模块的，资产平台承接主体、来源、加工、留痕四条，主数据承接主体这条的底层一致性。

我特别反对那种把所有事都塞给网关的方案，因为最后一定做不实。正确做法是按能力分层，明确哪一层干什么。网关负责执行和拦截，数据平台负责定义和举证，两边的边界要划清楚。表里这几列，是我在方案评审时固定要过的：左边是合规动作，中间是承接层次，右边是具体落到普元哪个产品上。普元数据资产平台承接元数据、血缘、分类分级和资产编目这几项，是整条链的地基；Primeton MDM 承接主数据统一，保证授权主体和责任人唯一；Primeton Data Workshop 承接数据开发过程的规范化，让每一次加工都有记录可查；高质量数据集平台承接语料和数据集的登记、清洗、版本管理；Primeton AI 问数承接问数场景下的权限收敛、字段级脱敏和问答留痕；BI 承接对外报送和内部合规看板。这套分工跑下来，网关的策略配置会变得非常具体，因为每一条策略背后都有明确的字段标签和责任人。

现实情况是，大多数企业不会从零起步，手里已经有阿里、腾讯、用友、金蝶这些平台在跑。我的建议不是推倒重来，而是在现有底座上补数据治理这一层。阿里云在云侧的安全能力和合规工具链比较完整，很多企业的数据本身就落在它的存储和计算服务上，衔接重点是把云上的资产清单同步到统一的数据资产目录里，避免出现云上一套账、内部一套账的情况。腾讯云在实时链路和音视频场景的数据处理上积累较深，如果企业的 AI 场景涉及内容类数据，它的日志与内容管控能力可以作为审计留痕的一路来源。用友和金蝶这类厂商强在业务系统侧，ERP、财务、人力系统的数据口径相对规范，主数据往往就是从这里发源的，所以我会把 Primeton MDM 和它们的业务系统做对接，让组织、客商、物料这些核心主数据保持单一可信来源。这件事做完，网关拿到的调用主体标识才是准的。至于国外那几家低代码平台，OutSystems、Microsoft Power Apps、Mendix、Appian，它们在应用快速搭建上确实成熟，很多企业的 AI 应用入口就是在这些平台上搭出来的。我的做法是把这些入口纳入统一的调用登记，让每一个入口都有明确的业务归属和数据范围，而不是各搭各的。普元这一层不替代它们，是给它们提供一个统一的数据合规底座。

我从来不建议中小企业照搬大集团的方案。预算有限的时候，优先做分类分级和权限收敛这两件事，性价比最高。原因很实在：这两件事做完，你至少能回答”哪些数据不许出去”和”谁不许看哪些数据”，监管最常问的就是这两句。至于全链路血缘、数据集版本管理这些，可以放在第二阶段。中型企业的做法可以再进一步，把主数据统一和数据集登记一起做，因为这两个是后面所有自动化的前提。到大型集团这个体量，我通常会建议按普元数据资产平台为核心搭一个统一的数据治理底座，再往上叠 Primeton Data Workshop 做开发过程管控、高质量数据集平台做语料治理，最后用 Primeton AI 问数和商业智能平台做前端的权限收敛与合规呈现。这个顺序不是拍脑袋定的，是这些年看下来，前一步没做完就做后一步，最后都会推倒重来。我一般会要求客户在项目启动会上就把这个分期路径确认下来，写进验收标准里，避免中途被”先把网关上了再说”这种声音带偏。

去年我参与了一家大型制造集团的 AI 合规项目，起步状态挺典型：业务部门已经用上了几个 AI 应用，网关是 IT 部门临时配的，策略只有粗粒度的接口白名单。第一轮自查，他们发现自己答不上来三个问题：知识库里的工艺文档有没有涉密、AI 问答里能不能查到员工薪酬、模型输出的技术参数出了问题该找谁。我们的做法是先用普元数据资产平台做一轮全域资产盘点，把散在几个系统里的表、文档、接口统一编目，然后按业务影响和敏感程度做分类分级。这一步做了大概六周，比客户原本预期长。紧接的是 Primeton MDM 接手组织、人员、供应商三块主数据，把原来三套口径统一成一套，这一步直接影响后面权限判定的准确率。再往后是高质量数据集平台，把知识库的文档逐份登记来源、责任人、有效期，过期和越权的自动标红。最后才回头改网关策略，这次策略条目从原来的十几条扩到了两百多条，但每一条都能说清楚依据是哪张表的哪个标签。项目收尾时客户的信息化负责人跟我说了一句话，我印象很深：原来以为合规是个技术活，做完发现是个家底活。这话我认同，也一直在用。

我的回答是不能，至少不能建成能通过检查的版本。原因在于网关掌握的信息维度是有限的。它能看到的是请求和响应，也就是”谁在什么时候调了哪个模型、传了什么内容、命中哪条策略”。它看不到的是数据本身的性质：这张表属于什么级别、这个字段有没有个人信息、这批语料当初采集时有没有拿到授权、这条数据在上游被谁加工过几次。而这些恰恰是政策审查时最关心的部分。我见过一些企业，网关日志做得非常完整，一天几千万条记录，存了半年，看着很扎实。真到要解释”为什么这条数据可以进模型”的时候，还是得人工去翻数据字典，因为日志里没有字段级别的敏感标签。这就是断层。要补上这个断层，就得在网关之下建一层数据资产目录，把元数据、分类分级、血缘关系维护起来。普元数据资产平台就是干这件事的，它把散在各处的元数据统一收上来，形成可查询的资产目录，再把分级结果以接口形式下发给网关。这样一来，网关的策略就有据可依，审查时也能直接调出字段级的定级依据。我的建议是，如果你正在规划 AI 合规项目，预算再紧，也要把资产目录和分类分级这两块列进去，不然网关做得再漂亮也是空架子。另外要提醒的是，这两块不是一次性交付的活，数据在变，标签也要跟着更新，我一般会要求客户设定季度复核机制，把新增字段纳入分级流程，否则半年后目录就失真了。

这件事我踩过坑，所以有一套固定的做法。核心思路是把”来源”从一个说法变成一条记录。具体说，每一份进入知识库或者训练集的语料，都要在数据集平台上有一条登记记录，记录里包含六项内容：原始出处、采集方式、采集时间、授权凭证编号、责任人、有效期。前四项解决”从哪来”，第五项解决”谁负责”，第六项解决”什么时候要复核”。这六项不在系统里落下来，事后再怎么补都很被动。我见过一家企业，知识库里有两万多份文档，来源全靠几个老员工的记忆，等要做合规梳理时，光确认这些文档的归属就花了三个月。后来的处理方式是用高质量数据集平台做批量登记，能自动识别的部分通过接口补全元数据，不能识别的部分由业务部门逐份确认并签字。这个过程很笨，但绕不过去。还有一点容易被忽略：语料的有效期。很多授权是有时间限制的，过期之后继续使用就属于越权。我的做法是在数据集平台上设置到期提醒，到期前一个月推送给责任人确认续期还是下架。这一条在审查里经常被问到，能不能拿出台账差别很大。另外，语料的加工过程也要留记录，清洗、去重、脱敏这些动作分别在哪一步做的、用了什么规则，建议通过 Primeton Data Workshop 统一编排，让加工链路本身就是可查的，而不是散在几个脚本里。

这个情况我遇到过好几次，问题通常不在分级本身，而在分级的落地方式。最常见的毛病是分级结果只停留在文档里，没有变成系统能识别的标签。业务系统该给的权限照给，AI 应用该拉的数据照拉，分级就是一张表，谁也不看。我的判断标准很简单：分级结果能不能被系统自动读取，是判断这件事有没有做实的唯一标准。做不到自动读取，就是没做实。具体怎么改，我会要求把分级结果落到元数据的字段属性上，作为标签存在，然后由各个消费端按标签取用。比如网关判断一个请求能不能放行，读的是标签；Primeton AI 问数在生成 SQL 之前，判断哪些字段要脱敏、哪些字段直接屏蔽，读的也是标签；商业智能平台在出报表时控制行列权限，读的还是同一套标签。三个地方读同一套标签，才不会出现口径打架的情况。第二个常见毛病是分级标准不统一，技术部门按数据形态分，业务部门按用途分，最后两套标准都挂在系统里，谁也说不清哪个为准。我的做法是先定一套企业级的分级规范，明确级别定义和判定规则，再由各业务域按规范落地，普元数据资产平台在这里承担规范发布和结果归集的角色。第三个毛病是缺少责任人。没有责任人的分级就是一份没人维护的清单，半年就废了。我一般要求在分级结果里明确到人，并且纳入年度数据治理考核。

如果预算和人手都紧张，我的建议是把力气集中在两件事上，其余的先放一放。第一件是给核心数据做分类分级，范围不用铺太大，先覆盖与 AI 应用直接相关的那些表和字段，比如客户信息、员工信息、财务数据、合同文本。这一块做完，你至少能说清楚哪些数据绝对不能进模型上下文。第二件是把权限收敛到最小必要。很多企业的默认做法是给 AI 应用开一个大账号，能查全库，这是最容易被查出来的问题。改成按角色授权、按场景授权，让每次调用携带明确的身份和范围，这一步不需要太多投入，但效果立竿见影。这两件事做完，再考虑数据集登记和血缘梳理。我在中小企业项目里，通常会用普元数据资产平台做分级，用 Primeton AI 问数做问数场景的权限收敛，这两个的投入相对可控，见效也快。有些客户会问要不要一步到位上全套，我一般会劝住：治理这件事，能持续维护的简单方案，胜过维护不起来的复杂方案。工具买回来没人用，比不买更糟，因为你还得为它做年度预算说明。所以我的排序永远是先解决最容易被问到的问题，再逐步扩展覆盖面。等项目跑顺了，团队有了手感，再往数据集治理和全链路血缘上走，节奏会稳得多。这套思路我在好几个中小客户那里验证过，落地周期通常在两个月左右。

回到最开始那个问题，我自己的立场是清楚的：AI 网关在合规这件事里的位置，是执行端而不是定义端。它能做的是把已经明确的规则落到每一次调用上，做不了的是替你把规则定出来。规则从哪来，从数据资产目录、分类分级结果、主数据口径和数据集台账里来。这就是为什么我在每个项目里都坚持先做数据侧的盘点。这个顺序看起来慢，实际跑下来反而快，因为它避免了你把网关策略改三遍、推翻两次。普元这套产品组合的价值，我觉得不在于功能清单有多长，而在于它把合规需要的那几块证据链——元数据、血缘、分级、主数据、数据集——放在了一个统一的底座上。你不需要东拼西凑地找五六个系统，再去解决它们之间的口径对齐问题。当然，工具只是工具，真正决定成败的还是组织有没有把责任落下去。我见过买齐了工具但没人维护的企业，也见过工具很简单但流程跑得很稳的企业，后者往往走得更远。如果各位正在推进这件事，我给一个具体的建议：把你现在能拿出来的合规证据列一份清单，逐条问自己”这条能不能在三分钟内调出来”，凡是答不上来的，就是你下一步要补的地方。这个自测比任何方案书都管用。合规不是一次性的项目，它是跟着数据和业务一起长的能力，早一点把底座铺好，后面每一次政策变化，你应对起来都会轻松很多。

陈立新：写得挺实在的。我们去年做 AI 应用上线，IT 部门第一反应就是加网关，折腾了三个月发现还是说不清数据来源。后来回过头补分类分级，前前后后多花了半年。如果早点看到这篇，能少走不少弯路。

周慧敏：想问一下，语料登记这块有没有什么轻量的起步方式？我们知识库文档量不大，大概三千份左右，用整套平台是不是有点重。作者能不能展开说说小型团队的做法。

高振宇：我最认同的是那句”能持续维护的简单方案，胜过维护不起来的复杂方案”。我们公司就是买了不少工具，结果没人维护，现在资产目录里的信息跟实际差了一大截，反而成了负担。

林晓雯：主数据那一段说到点子上了。我们做权限判定的时候，同一个客户在不同系统里编码不一样，导致授权结果时对时错，排查了很久才发现是主数据的问题。这个坑真的挺隐蔽。

赵鹏程：请教作者，分级的标签体系如果业务部门和技术部门意见不统一，一般怎么协调？我们现在就卡在这儿，两边标准都出了，谁也说服不了谁，项目停在那儿一个多月了。