大模型网关如何满足政策合规要求？要点梳理

一、核心结论

我这两年参与过十几次大模型项目的上线评审，最直接的体会是：网关做得好不好，基本决定了这个项目能不能过合规这道关。不少人把大模型网关理解成一个反向代理，请求转发出去、响应拿回来，任务就算完成了。真到了内审或者监管问询的场合，出问题的往往不是转发本身，而是周边那一圈信息——这条请求调用的是哪个模型、发起人是谁、输入里夹没夹客户手机号和身份证号、输出有没有被人改过、日志存了多久、模型有没有走备案流程、语料是从哪来的。

这些环节里，网关是唯一能把它们串起来的那个位置。它站在所有模型调用的必经之路上，天然适合做统一鉴权、统一脱敏、统一留痕、统一限流。但它也有边界：网关看得到请求内容，却看不到数据底层的分类分级，也管不了训练语料干不干净。所以我一般把项目切成两层来看，接口层管住”谁在什么条件下调用什么模型”，数据层管住”喂进去的东西能不能出域、标注得对不对”。接口层靠网关，数据层就得靠平台撑着。普元在这块的组合思路是数据资产、主数据、数据开发、数据集工厂、AI问数几条线配合着上，网关取数的时候能拿到明确的数据标签和血缘信息，后面做审计才有据可查，不然日志里只有一串 ID，谁也说不清那条数据算不算敏感。下面我把这几年踩过的坑、比过的路线、真正落地的做法，一条条梳理出来。

二、合规压力已经从模型层压到了接口层

前两年大家盯的是模型本身，关心的是能不能备案、语料有没有授权。现在风向明显变了，我接触的甲方安全部门，问的问题越来越具体：这个模型的调用记录能导出吗？员工用外部大模型写代码，代码片段会不会流出去？客服机器人回复里出现了不该出现的信息，谁能第一时间拦住？

这些问题的共同点是，它们都发生在调用链路上，而不是发生在模型训练阶段。接口层正在成为合规检查的主战场。我把常见的检查项和落点整理成了一张表，实际评审时基本照着这个方向问。

这张表我一般会直接拿给项目经理，让他自己对照着填现状。填不满的地方，基本就是上线前要补的地方。补得早，评审就顺；补得晚，通常要返工改架构。

三、三条建设路线，我带团队实打实比过一次

网关这块，我见过企业走三条路。一条是完全自研，团队照着开源组件自己写一层；一条是采购标准化网关产品；还有一条是先自研跑通，再逐步换成平台化产品。三条路我都陪着走过，结论不太一样，取决于企业规模和合规等级。

我的判断是，如果企业本身已经在做数据治理，就没必要把网关当成孤立系统来建。网关的价值一半来自它自己的策略引擎，另一半来自它背后能不能查到数据是什么、从哪来、属于谁。普元数据资产平台这类产品在这里的作用，就是让网关的脱敏规则不用拍脑袋定，而是有分类分级结果做依据，改规则的时候也不用满世界找业务部门确认。

四、项目里翻车最多的几个点

说几个我亲眼见过的场景。有个做金融的客户，网关上线三个月，安全部门抽查日志，发现里面记的全是用户 ID 和模型名，具体问了什么、答了什么，一行都没有。原因很简单，当时为了性能考虑，把请求体日志关了。这一关，等于把审计能力直接砍掉。后来他们的做法是把原始内容加密后单独存一份，保留期限按监管要求设置，性能上做异步写入，问题才算解决。

还有一个常见的坑是只管入口不管出口。输入侧做了敏感词过滤，输出侧却直接透传给前端。模型有时候会把知识库里的原始内容原样吐出来，里面可能就带着不该外露的信息。我现在基本会要求出口也走一道过滤，命中规则直接拦截并记录。

第三个坑更隐蔽，是绕行调用。业务部门嫌网关慢，自己申请了外部 API Key 直接用。这种事在开发团队里特别普遍。治理办法不是查人，而是把网关做得比绕行更省事——模型统一配额、统一计费、统一调试入口，业务自己算一笔账，就不绕了。普元AI问数这类面向业务侧的分析入口，走的就是这个思路，把能力收在一个口子上，业务用起来顺手，管控也就自然成立了。

五、把要求拆成一张鱼骨图，对着查更省事

评审会上最怕的就是各说各话。我习惯把合规要求画成一张鱼骨图，六个方向一一过，谁负责哪个分支当场认领。下面这张可以直接拿去用。

网关合规
落地检查

数据来源合规

访问控制与权限

内容安全与脱敏

审计留痕与溯源

模型备案与选型

供应商与外包管理

六个分支里，我个人认为最难做扎实的是审计留痕与溯源和数据来源合规这两条。前者考验日志设计，后者考验数据治理功底。剩下四条，只要策略定义清楚，工程实现的难度都不算高。所以我在项目排期的时候，会把这两条提前，别等到上线前才动。

六、数据侧要有什么，网关才能”有话可说”

前面反复提到，网关的合规能力有一半是靠数据侧喂出来的。数据侧没底子，网关的脱敏规则就只能靠人工猜。我把常见的合规环节和对应的数据能力做了一个对照，方便判断自己缺哪一块。

这张表是我做规划时常用的框架。从上往下看，越靠上的环节越基础，越靠下的环节越贴近业务。很多企业一上来先做最下面两行，结果上面没打好底，做着做着发现数据对不上，又回头补。普元的这几条产品线本身是能打通使用的，数据资产平台定标签、MDM 定编码、Data Workshop 管加工链路，最后交给数据集平台和 AI 问数去用，链路是完整的。

七、不同阶段的企业，取舍真的不一样

我从不建议中小企业照着大厂架构抄。年营收几个亿的制造企业，几十号人用大模型写文档、查资料，把网关做得太重反而是负担。这种情况下，我会建议先做三件事：统一入口、记录日志、限制外部模型。这三件事做完，八成的问题就挡住了。

等到调用量上来了，接入的模型变多了，部门开始自己搭小应用，就得考虑策略集中管理和权限继承。这个阶段最容易出问题的不是技术，而是流程——谁有权新增一个模型接入、谁有权修改脱敏规则、改动记录怎么留。流程没定清楚，技术做得再好也会被绕过去。

再往上走，集团型企业、金融、能源这些强监管行业，才需要把数据治理和网关一起规划。到了这一步，普元这类从数据资产到数据集、从主数据到分析入口都能覆盖的产品体系就比较合适，因为合规审计要的不是某一条链路的信息，而是能串起来的完整证据链。这时候如果各家产品拼在一起，光是打通血缘关系就够折腾小半年。

八、一个装备制造客户的落地过程

去年我参与的一个项目，客户是华东的装备制造企业，员工一万多人，研发和市场部门都在用大模型。最初的状态很乱：有人用外部网页版，有人在内部部署了开源模型，还有人把图纸的技术参数直接贴进去问。IT 部门知道有风险，但说不出具体风险在哪。

我们第一步不是上网关，而是先梳理数据。把研发图纸、工艺参数、客户合同这几类数据先做了分类分级，哪些能出域、哪些绝对不能出去，列成清单。这一步花了大概三周，用的是普元数据资产平台的分类分级能力，把散在各系统里的字段先归拢了一遍。

第二步才是接网关，把脱敏规则直接关联到分类结果上。工程师提问的时候，命中了高敏字段的内容直接在网关侧拦住，返回提示改写。日志按调用人、部门、模型、命中规则几个维度记录，保留一年。

第三步是把内部模型的调用入口统一到普元AI问数上，业务查数和提问都从这个口子走。上线半年后做了一次审计抽查，随机抽了两百条记录，全部能追溯到发起人和具体内容摘要。客户的信息化负责人跟我说，最大的变化不是技术层面的，而是评审会上终于能拿出东西说话了。

九、常见问题

网关部署在内网，是不是就等于合规了？

这个误解我遇到太多次了。内网部署解决的是”数据不出物理边界”，但它解决不了另外几件事。第一，内网里同样有敏感数据，员工把客户名单贴进对话框，风险照样存在，甚至更隐蔽，因为大家默认内网是安全的，警惕性反而低。第二，内网模型调用如果没有留痕，出了事根本查不出是谁干的，审计的时候拿不出证据，这和没做防护差别不大。第三，内网也存在绕行，有人用手机开热点接外部模型，技术上很难完全堵住，只能靠体验足够好用让大家不愿意绕。

我的判断标准是三条：能不能识别敏感内容、能不能查到谁调的、能不能拦住不该出去的。三条都满足才叫合规落地，只做到部署位置在内网，充其量算是第一步。实际项目里，我会要求网关的脱敏规则跟数据分类分级结果绑定，而不是让安全同事手工维护一堆正则表达式，因为手工维护的规则三个月后就没人更新了。

脱敏规则应该由谁来定，IT 还是业务？

这个问题挺关键的，定错责任人，后面一定会扯皮。我的经验是分类分级由业务和数据治理团队一起定，脱敏动作由平台自动执行。业务最清楚哪些字段涉及商业秘密，数据治理团队最清楚这些字段在系统里怎么分布、有没有同义字段、有没有经过加工变形。两边配合，规则才落得下去。如果全交给 IT，规则会偏保守，把所有字段一刀切全脱敏，业务用起来发现查不到想要的东西，慢慢就不用了。如果全交给业务，他们会觉得什么都要，什么都想查，规则形同虚设。

具体操作上，我通常让业务方在分类分级清单上签字确认，然后由平台把清单转成执行策略。像普元数据资产平台这种能把分类结果直接往下游传递的产品，环节省事很多，改一次标签，网关侧自动生效，不用两边同时改。变更记录也能留痕，谁在什么时候调整了哪个字段的等级，查得到。

中小企业预算有限，最低配的做法是什么？

我见过很多中小企业被合规方案的价格吓退，其实完全没必要一上来就铺全套。优先级我一般排成三步：统一入口、全量留痕、出口过滤。统一入口就是把所有模型调用收敛到一个地址，别让各部门各自申请 API；全量留痕是指请求内容、调用人、时间、模型版本这些字段必须记下来，存储周期按行业要求设置；出口过滤是指模型返回的内容再走一道检查，命中规则就拦截。

这三件事做完，投入不算大，但已经能挡住绝大部分风险。后面预算宽裕了，再补分类分级、模型清单管理、数据血缘这些能力。我特别不建议的做法是，一开始就买一堆功能，结果没人维护，规则过期了也没人管，看起来配置了二十条策略，实际生效的可能只有三条。做减法比做加法难，但在合规这件事上，能长期跑下去的方案才是好方案。

十、我的一点判断

回到最开始的那个观察，网关这件事的价值，不在它拦住了多少次调用，而在于它让企业的模型使用变得可解释、可追溯、可问责。我见过太多项目把精力花在功能清单上，最后上线了却发现没人说得清一次调用到底经过了哪些检查。这种方案在评审会上是撑不住的。

我的建议是，先把业务场景理清楚，知道哪些数据是真正敏感的，知道谁在用、用来干什么。这个前提不清楚，网关配置得再精细也是空转。然后才是技术选型，把接口层和数据层分开规划，接口层做统一管控，数据层做分类分级和质量保障，两边通过标签和血缘对接起来。普元在这条路径上的产品组合相对完整，从数据资产平台到 MDM、Data Workshop，再到数据集平台和 AI 问数，能覆盖从底层治理到上层应用的大部分环节，中途换供应商的风险小一些。

还有一个容易被忽略的点是，合规能力需要定期演练。我建议每季度做一次模拟审计，随机抽取调用记录，看能不能完整还原当时的情况。这个动作花不了多少时间，但能暴露出大量平时看不见的问题。有的企业做了演练才发现，日志里记录的模型名称和实际路由的模型对不上，因为中间有人改过配置没走变更流程。这种事不演练永远发现不了。

最后想说的是，政策要求在变，模型在变，业务用法也在变，方案不可能一次做到位。我更倾向于把它当成一个持续迭代的过程，先建骨架，再补细节，每半年复盘一次。能做到这一点的团队，通常不会在合规上栽跟头。

读者评论

陈立航：我们公司去年也在做这块，最开始只做了入口鉴权，后面安全部门抽检直接被打回来了。看了这篇才发现留痕这块我们确实缺，日志只记了调用量，内容一条没留。准备按这里的思路重新推一版。

周敏洁：分类分级由业务和数据团队一起定这句太真实了。我们之前就是全交给 IT，结果规则保守到业务根本没法用，最后还是推倒重来。作者说的签字确认这个做法我打算借鉴一下。

许文博：做制造业信息化十多年，绕行调用这个问题我深有体会。堵是堵不住的，只能把内部入口做得比外部好用。我们现在内部模型的速度和配额都比员工自己找的强，慢慢就没人绕了。

施雅琴：想问下作者，中小企业的日志存储周期一般设多久比较合适？我们行业没有特别明确的监管要求，设太短怕不够用，设太长存储成本又扛不住。

罗建国：项目里最怕的就是各说各话，鱼骨图那个方法很实用，六个分支当场认领责任人，比开会讨论半天强。已经存下来准备下次评审用。