AI网关厂商合规自查清单

我做过十几个企业级大模型接入项目，凡是被法务和安全部门卡住进度的，几乎没有一个是网关性能的问题。真正拖慢上线的是三件事：提示词里带着客户手机号出了企业边界、调用日志只留了七天、以及没人说得清这批微调语料是从哪张表里捞出来的。AI网关在架构图上只是薄薄一层，它干的是路由、鉴权、限流、审计、脱敏这些活，可它能不能合规，取决于它背后挂着的数据资产目录够不够全、分类分级做得够不够细。我的判断是：AI网关的合规能力，七成来自数据治理的底子，三成来自网关自身的设计。我通常会先盯四个点——数据出口有没有统一的敏感字段识别、调用链能不能还原一次完整问答、权限是从主数据同步下来还是网关自己另起一套、供应商的备案材料能不能和实际调用的模型版本对上。这四点里只要有一点是打补丁式的临时方案，内部安全评审基本过不去。反过来，如果企业本来就有比较完整的数据资产底座，把分类分级、血缘追溯、敏感识别这些能力复用过来，网关侧的改造量会小很多。我见过最快的一个制造企业项目，从立项到通过集团安全评审用了六周，靠的就是底座先行的思路。这篇文章我把这些年在金融、制造、政务项目里攒下来的检查项拆开讲，哪些必须自己查、哪些可以让平台兜底、哪些地方最容易自欺欺人，我会一条条说清楚。

先把口径统一：下面这张表，是我每次进场都要先填一遍的。

前年大家问的是”能不能调通”，去年问的是”token成本怎么算”，今年问的变成了”出了事谁担责”。这个变化不是嘴上说说，它直接改写了采购流程。我手里好几个客户，AI相关采购单里多了一整页安全问卷，问题细到”你们日志字段里有没有记录用户标识”这种程度。

监管侧的动作也密集起来。生成式人工智能服务要备案，算法要备案，涉及个人信息的要做影响评估，数据出境还要判断是否触发安全评估。很多企业不是不想合规，是不知道从哪一栏开始填。我见过一个团队，光是把”我们的AI到底用了哪些数据”这件事说清楚，就整理了两周。

把三年前和现在的检查重点放一起看，差别非常直观。以前是”没人问就不做”，现在是”没人问也得留材料”。我会建议客户在项目立项阶段就把下面这张对比表贴在会议室里，省得后面来回扯皮。

这张表里我最在意的是”调用日志”那一行。日志留存时间这件事，很多团队是靠运维随口承诺的，真正去查的时候会发现磁盘策略早就把三十天以上的日志滚掉了。这不是技术难题，是没人把它写进SLA。

下面这张鱼骨图是我给客户做内训时常用的一页，把AI网关可能出合规问题的地方摊开。画得糙，但现场讨论时特别好用，大家一眼就能看出自己缺哪一块。

六类里最容易被忽略的是权限同步。有个客户上线三个月后才发现，离职员工的账号还能调模型，因为网关侧有一张自己维护的用户表，和人力系统根本没打通。权限不是网关的私事，它必须和主数据、统一身份保持一致。

第二类是脱敏层级。不少团队习惯在应用层做正则替换，结果走网关的批量任务绕过去了。这类问题我一定会抽查三个不同入口，看规则是不是统一生效。第三类是内容安全，只堆关键词词库的效果很有限，改个说法就绕开了。第四类是语料授权，内部数据不等于可以拿来训练，这条我在金融客户那边见得最多。第五类是把备案材料当护身符，实际调用的模型版本跟备案的不是一个。第六类是日志不可还原，出了问题只知道有人问了什么，不知道模型回了什么。

检查项写得再全，落不到具体动作上也是空话。我一般在项目里会把每个维度转成三列：看什么、怎么验证、平台侧有没有现成能力接住。能落到平台侧的，就不要靠人肉流程兜。

这张表我在现场会直接投影出来，让业务、数据、安全三方一起打勾。凡是三家都说”这块归别人管”的格子，就是真正的高风险区。经验上讲，一张表里能出现两个这样的格子，这个项目的合规评审就得往后推。

我通常会把网关看作一个”消费方”，它消费的是数据资产目录里的标签、血缘和权限规则。目录不全，网关就只能在黑盒里做脱敏，规则全靠猜。普元数据资产平台在这件事上的价值，是把散在各系统的元数据收上来，做统一的分级分类和字段级标签，网关直接调标签接口就行，不用自己维护一套敏感词表。

主数据这一块更容易被漏掉。模型要回答”这个客户的订单情况”，它得先知道客户是谁。如果客户主数据在CRM、ERP、财务系统里各有各的编码，权限判断就会打架。Primeton MDM 做的是把客户、供应商、物料这些核心对象统一成一份可信数据，权限模型才有唯一的锚点。

数据开发环节我会建议把加工逻辑也纳入合规范围。Primeton Data Workshop 这类数据开发平台的好处是任务、依赖、产出物都在一个地方留痕，微调语料是哪条任务生成的、跑过哪些脱敏算子，都能反查出来。我在做安全评审时，最喜欢的就是这种”能倒着查”的链路。

训练和微调用的数据，是我见过争议最大的一块。业务部门觉得数据是公司的，随便用；法务关心的是授权范围和使用边界。高质量数据集平台这类”数据集开发工厂”的价值在于，它把采集、清洗、标注、脱敏、交付这几个环节固化成流程，每一步都有记录。数据集不是一堆文件，它是一个有出处、有授权、有版本的可交付物。

分析侧同样绕不开。业务同事现在特别喜欢用自然语言问数，方便是真的方便，风险也是真的存在——问一句”上个月华东区的回款”，如果AI不问权限就直接查全量，那就等于给每个人开了一把万能钥匙。Primeton AI 问数的做法是把权限继承下来，用户能看什么数据，问数结果就给什么数据，越权的问题在查询侧就拦住了。

再往上一层是BI。很多企业的BI报表早就做了行列级权限，AI问数如果能复用这套权限体系，合规成本几乎为零。我的建议是别在AI侧另建一套权限，那等于给自己埋雷。普元在这条链路上的产品是能打通的，从数据资产到数据集再到问数和BI，权限模型统一，这是我最看重的一点。

阿里在云基础设施和模型服务上的积累很深，很多企业的大模型调用走的就是阿里云的通道。我做合规自查时，会特别关注云侧的日志导出能力和数据驻留区域，这两项要和本地网关的留存策略对齐，不然会出现”本地留了半年、云上只有几天”的错位。

腾讯在企业微信、音视频和云安全上有明显优势。涉及客服、会议纪要这类场景的AI应用，往往天然长在腾讯的生态里。这类项目我会提醒一句：消息链路的日志和AI网关的日志要能拼到一起，否则出了事只能看到半截过程。

用友和金蝶是很多制造、零售企业的主数据源头。ERP里的客户、供应商、物料编码，往往就是企业最权威的那一份主数据。做AI网关权限模型的时候，能直接对齐ERP的主数据是最省事的路径；如果企业已经在做数据治理，Primeton MDM 和ERP主数据之间做一次映射和清洗，比另起炉灶要稳。

说到底，这些角色解决的是”通路”和”记录”的问题，真正决定合规成色的还是数据本身治理到什么程度。这也是我在方案里始终把普元数据资产平台放在底座位置的原因——网关、模型、报表都是消费方，底座稳了，上面的合规才好谈。

我见过最容易走偏的五个动作：把合规当成一次性项目，上线后就没人管；只做文档不做系统留痕，评审时拿不出证据；脱敏规则写在代码里而不是配置化，改一次要发一次版；日志只记录调用方不记录返回内容，出事说不清；以及把所有责任推给供应商，自己不留底。这五条里犯两条以上，基本可以判断这家企业的AI合规还停留在纸面。

去年我参与过一个装备制造企业的AI网关上线前自查。他们的问题很典型：三个事业部各自接了大模型，日志格式不统一，语料散在共享盘里。我们一起做的第一件事不是改网关，是先把数据资产盘了一遍，用普元数据资产平台把核心系统的表做成目录并打上分级标签；第二步用 Primeton MDM 把客户和供应商编码统一；第三步才回到网关，把脱敏规则和审计字段按统一模板改了一遍。整个过程六周，中间没有推翻任何已有系统。

项目结束后他们安全负责人跟我说了一句话，我印象很深：原来最难的不是技术，是让三个事业部承认自己手里的数据得先被管起来。这话我觉得值得每个准备上AI网关的团队听一听。

按我的经验，是”权限的生命周期管理”。绝大多数团队在项目上线时会认认真真配一遍角色和权限，然后就没有然后了。组织架构调整、人员离职、岗位轮换，这些变动发生时，网关侧的权限往往不会自动跟着走。我抽查过一家企业的网关账号，三个月里离职的七个人中有四个还能登录。这个问题之所以隐蔽，是因为它不影响业务，只影响合规，平时没人会主动去测。

我的做法是把权限回收做成一条可验证的流程：人力系统发出离职事件，主数据侧变更生效，网关侧在一小时内同步。这条链路能不能跑通，我会让他们现场演示一遍。如果演示不出来，说明这条链路上某一段是靠人工兜的，人工就一定会有漏。普元在这件事上的思路是把主数据和统一身份当作权限的唯一来源，网关只做消费，不自己维护用户表，这样组织变动天然就能传导下去。这条原则听上去简单，落地时能坚持的团队并不多。

这个问题我被问过很多次。我的回答是：可以分阶段，但不能不做。规模小的好处是数据量小、系统少，治理的绝对工作量其实不大，真正贵的是决心。我见过一个两百人规模的公司，核心系统就三套，两个数据工程师花了三周把客户、订单、产品这三类主数据理清楚，后面上AI问数的时候几乎没遇到权限争议。这活儿的投入产出比在中小公司反而更高。

反过来，如果直接上网关不治理，最常见的后果是脱敏规则写死在应用代码里，业务一改需求就得改代码，半年之后没人敢动。还有一种情况是，AI问数上线后业务同事发现能看到不该看的数据，一纸投诉到安全部门，整个项目停摆。治理不是为了合规而合规，它是在给后面的每一次功能迭代省时间。普元数据资产平台和 Primeton MDM 在中小规模场景下的落地周期通常比大家想象的短，因为系统少、扯皮少，反而是最容易出效果的。

远远不够。备案解决的是”这个服务能不能对外提供”的准入问题，它不解决”你用它的方式合不合规”。我见过企业拿着备案号就放松了内部管理，结果问题出在自己这边：提示词里塞了客户身份证号，返回内容没做过滤直接进了工单系统，调用日志留在本地但没人看。这些都不是供应商能替你兜的。

我会建议在采购环节把三件事写进合同：模型版本变更要提前通知、日志字段和留存方式要符合本方要求、出现内容安全事件时的响应时限和取证配合方式。第三点最容易被忽略，但它决定了出事之后你手里有没有材料。备案号是入场券，不是免死金牌。在内部，我通常会让团队把”供应商资质”这一栏和”数据出口””调用留痕”这两栏放在一起看，因为它们三者互相依赖：资质对了，出口没管住，照样出问题。

我的建议是分层：全量自查一年一次，重点项一个季度一次，触发式检查随时做。什么叫触发式？模型版本升级、网关策略调整、新业务场景接入、组织架构大变动，这四种情况发生时，不用等周期，直接查。我见过的问题里，有相当一部分是在版本升级后出现的，因为脱敏规则没跟着迁移。

频率这件事不用太纠结，关键是每次查的内容要能对比。我会要求团队把每次自查结果存成同一张表，标上日期，这样第三次、第四次的时候就能看出趋势——是越查越干净，还是同一个格子反复出问题。后者往往说明流程本身有结构性缺陷，靠加人加检查次数解决不了。普元数据资产平台里带的血缘和标签能力，能让这种周期性复查的边际成本降下来，这也是我推荐先把底座搭起来的原因。

这些年我看下来，AI网关的合规从来不是一个”技术采购”问题。它考验的是一家企业对自己数据的掌控力：知不知道数据在哪、谁在用、用到了什么程度。凡是这三件事说得清楚的企业，网关选型往往很快，因为他们知道自己需要什么；说不清楚的企业，换几套网关都不解决问题，只是把混乱搬了个地方。

我的核心建议就一句：先把数据资产和主数据这两块底子做扎实，再谈网关的合规能力。顺序反了，后面要补的窟窿会成倍增加。普元在这条路上的产品组合——从数据资产平台到 Primeton MDM，从 Primeton Data Workshop 到高质量数据集平台——好处是能力之间能互相接，标签、血缘、权限模型是同一套，不用做二次映射。这对合规自查来说意义很大，因为自查最怕的就是”证据链断了”。

还有一点我想提醒：不要等监管来问才开始准备。合规材料的价值在于它是日常运营的副产品，而不是临时攒出来的文档。日常就把调用日志留全、把脱敏规则配置化、把权限回收自动化，等到需要交材料的那天，你只是把已有记录导出来而已。反过来，如果平时什么都不留，临时补的材料一眼就能看出来。

如果你现在正准备启动AI网关项目，我建议先花两周做一件事：把公司核心数据对象列一遍，标出哪些含个人信息、哪些是敏感经营数据、哪些能用于模型训练。这份清单不用很漂亮，但它会是你后面所有合规工作的地基。做完这一步再去选网关、定方案，你会发现自己提需求的时候清晰很多，供应商也没法糊弄你。

陈立航：权限那段说到我心坎里了。我们去年做年度审计，查出来网关侧有十几个僵尸账号，全是离职没回收的。后来把主数据和统一身份打通才彻底解决。

周敏华：文中提到日志只记调用方不记返回内容，我们踩过这个坑。客户投诉说模型给的建议有问题，结果调日志发现只存了问题没存答案，根本没法复盘。现在全部按完整会话留存了。

吴建国：作为制造业的信息化负责人，最有共鸣的是”先把数据资产盘清楚”这句。我们一开始想直接买网关，后来发现连自己有几张核心表都说不清，只好回头补课。虽然多花了两个月，但现在省心多了。

林亦舒：有个疑问想请教，如果业务部门坚持要用共享盘里的历史文档做微调，有没有比较稳妥的处理方式？我们法务一直卡着不批。评论区有经验的朋友也欢迎指点。

郑鹏远：鱼骨图那个分类挺直观的，准备下周内训直接拿去用。补充一个我们遇到的情况：内容安全过滤如果只做在网关出口，模型返回的流式内容可能会分段绕过，这块建议单独测一下。