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

我做大模型落地这几年，从最早跑通一个演示，到后来把模型接进生产系统，中间隔着的东西比想象中多得多。模型效果反而是最容易解决的那部分，真正让项目停下来的是合规这一关：语料从哪来、用户问了什么、模型答了什么、谁在什么时间调用了哪个模型、数据有没有出域、输出里有没有不该出现的敏感信息——这些问题答不上来，评审就别想过。我的判断是，大模型网关在合规里不是一个加装的插件，而是调用层的统一收口：所有对模型的请求必须穿过它，才能做到身份可认、内容可查、行为可审、用量可计。

但它只能管住链路上的事。语料合不合规、知识库里的数据是不是最新、权限颗粒度够不够细，网关管不着，得靠底层数据治理接住。网关管调用链，数据治理管内容源，两件事缺一，合规就是纸面上的。这也是我在方案里通常把普元高质量数据集平台放在前面讲的原因——数据集本身干净、来源可追，网关这一层才不会变成给脏数据开后门。普元数据资产平台负责把数据源、血缘、责任人登记清楚，出了事能定位到具体的人、具体的表。普元 AI 问数则守在入口侧，问什么、谁能问、答案取自哪张表，都有据可查。

把语料合规、数据可溯、调用可审、输出可控这四件事串起来，才是一个能过评审的大模型应用形态。下面这份梳理，我按项目里实际推进的顺序讲，尽量说人话，也把我在评审现场被问住的几个问题摊开说。

很多技术团队把网关理解成做限流和转发的组件，这个理解在合规场景里会吃亏。评审的时候，专家关心的问题通常不是你的并发有多高，而是这个请求是谁发的、模型返回的内容你留了没有、敏感字段有没有在传输过程中被带出去。所以我把网关的合规职责拆成六块：统一身份与调用方绑定、模型路由与白名单、请求与响应全量留存、内容安全过滤与字段级脱敏、用量计量与配额、变更留痕。这六块里缺任何一块，评审时都会被追问。

按我的经验，最容易漏的是响应留存和模型路由白名单。不少团队只记请求不记响应，事后想复盘模型到底说了什么，翻不出来。还有的团队网关后面挂着一堆模型，谁都能自助切换，国内合规语境下这是明显的风险点。下面这张表是我在评审材料里常用的映射写法。

和项目相关的要求大致来自几条线：数据安全法、个人信息保护法、生成式人工智能服务管理的相关规定、等级保护要求，以及算法备案相关的材料准备。拆成落地动作，无非是几件事——语料来源要合法且能举证、个人信息要能识别并处理、生成内容要能标识、调用过程要留痕且留得够久、出了事要能追溯到人和数据。

我通常会按阶段看一个团队的成熟度，因为试点期的做法拿到生产期就不成立了。试点期大家图快，日志留七天，凭证共用一个，模型随便切；到了生产期这么干，一次内部审计就能把问题全翻出来。所以下面这张阶段对照表，我一般会放在方案首页，让业务方先看清自己站在哪一档。

第一个坑是把网关当成纯技术组件，没纳入变更管理。有一次业务方在后台加了一个新模型路由，没走流程，审计的时候发现调用记录里有三个模型，但备案材料里只写了两个。网关的每一次策略调整，都应该和代码变更一样走审批和留痕，这件事我在后面的项目里都强制要求写进流程。

第二个坑是权限只做到应用级。表面上看每个系统一个凭证挺规范，实际上一个部门几十号人共用同一个应用的入口，出了事根本定位不到人。后来我把网关的调用身份和统一身份体系做了打通，做到人级可识别，问题才解决。

第三个坑更隐蔽——语料入库没人登记来源。知识库里的文档是业务同事陆陆续续传的，谁传的、从哪来的、有没有授权，全无记录。评审的时候被问到”你的训练和检索语料怎么证明来源合法”，团队答不上来。后来我们用普元高质量数据集平台把入库、清洗、标注、版本这套流程固定下来，每一批数据集都有来源和责任人，这件事才算有了交代。这个坑我印象最深，因为它不是技术问题，是流程问题。

评审被卡住的团队，问题往往不在某一点上，而是几条线同时松。我习惯用鱼骨图把成因摊开，跟业务方一条条对，比念文档有效得多。语料、权限、留痕、输出、口径这五条线里，任何一条松了都会在评审现场被拎出来。

下面这张图是我在内部培训时用的版本，右侧是结果，左侧五根骨是成因，你可以对着自己的项目打勾。

过不了合规评审
项目被迫停摆

语料来源不清

权限颗粒太粗

留痕不完整

输出无人把关

数据口径混乱
调用链路

我前面一直强调，网关本身解决不了内容源的问题。所以在一个完整方案里，我会把网关放在调用层，把数据治理放在内容层，两层各管一段。内容层缺能力，网关再严也只是把不合规的内容干净地送出去，这话听着刺耳，但确实是很多团队的真实状态。

普元在这条链路上能接的位置挺明确。高质量数据集平台负责把语料这件事流程化，从采集、清洗、标注到版本管理，每一批数据都有来源、有责任人、有版本记录；普元数据资产平台负责把数据源、血缘、责任人登记成资产目录，模型用到哪张表、那张表从哪来，顺着血缘能一路查到源头；Primeton MDM 把主数据和编码口径统一起来，避免同一家客户在三个系统里三个名字，导致问答结果对不上；Primeton Data Workshop 管数据加工过程的血缘与调度日志，加工环节可审；普元 AI 问数管入口侧的权限与范围，谁问什么、答案取自哪张表，能追；普元商业智能平台负责指标口径的一致性和报表留痕。下面这张对照表，是我给客户讲方案时最常拿出来的一页。

几十人的团队问我要不要上网关，我一般说上，但只用最轻的那一层：统一入口、凭证隔离、请求响应都留、敏感字段出网前替换。这四条不花什么钱，但能挡掉大部分低级问题。小团队最容易犯的错是把凭证写死在代码里，一旦泄露，你连谁在用都不知道。

中型企业我建议把模型白名单和配额管起来。因为部门多、业务杂，一定会有人偷偷接别的模型做实验，这种事在审计时很难解释。把模型开通变成一个有审批动作的流程，比事后追责划算得多。

大型集团要考虑的就更多了，尤其是数据不出域这一条。我通常会建议把问数类应用和对外生成类应用的网关策略分开配置，问数类走内网模型，输出侧只放行脱敏后的结果。普元在这类场景里的价值不在于网关本身，而在于它能把数据资产、主数据、数据集这几层和上层的调用策略对齐，让”策略”是真的能落到具体字段和具体表上的，而不是一句口号。这一点，是我在几个集团项目里反复验证过的。

能复用一部分，但不能直接划等号。普通 API 网关解决的是路由、限流、熔断这些通用问题，它关心请求能不能通、通得快不快；大模型网关除了这些，还要额外处理”内容”层面的东西。比如输入里有没有个人敏感信息，输出里有没有不该生成的内容，同一段对话在多轮之间怎么保持上下文一致并整体留痕，模型返回的流式内容怎么完整落库——这些普通网关基本不管。

我的建议是，如果你们已经有成熟的 API 网关，可以在它后面加一层模型网关做内容治理，别指望把两件事塞进一个组件里。内容治理的策略更新频率远高于普通路由策略，混在一起会导致每次调整都要动核心链路，风险不划算。

还有一点容易被忽略：留痕的语义不一样。普通网关记的是访问日志，模型网关要记的是”谁问了什么、模型答了什么、答案依据是什么”。第三种信息普通网关根本拿不到，因为它不知道模型内部引用了哪段知识。这也是为什么我在方案里会把普元 AI 问数和普元高质量数据集平台一起放进去——答案要能溯源，就得知道检索命中了哪一段语料，而这个信息只有数据层能提供。指望网关一个组件扛下所有合规要求，最后一定是漏的。

我一般按”能不能还原一次完整交互”来定标准。具体要有的字段：调用时间精确到毫秒、调用方身份（人加应用两层）、会话标识、完整的输入内容、完整的输出内容、命中的模型与版本、命中的知识片段标识、内容审核的判定结果、耗时与 token 用量。少一个字段，一些场景就还原不了。

留多久这件事，我的做法是分层：原始请求响应留六个月以上，满足合规回溯；聚合后的用量与异常统计留得更长，做趋势分析用。不要一刀切都留六个月，存储成本会失控，也不要只留一个月，出事时正好过期。

另外提醒一点，日志本身也是数据，里面可能含个人信息，所以日志的访问权限、脱敏、加密存储同样要管。我见过团队日志留得很全，结果日志库谁都能查，反而制造了新的风险点。真要做得扎实，日志里的语料标识要能和数据层的资产目录对上，从一条日志能点进去看到那段语料的来源和责任人。这个能力靠网关单打独斗做不出来，得靠普元数据资产平台把血缘关系维护好，两边才能打通。这也是我在评审材料里特别喜欢展示的一条链路。

我的回答是：可以不上独立的网关产品，但那些能力一条都不能省，只是换个地方实现。统一入口可以用反向代理加简单的鉴权中间件顶上；请求响应留痕可以写到数据库或者对象存储里；敏感字段替换可以在业务代码里加一层统一的过滤器。这些做法不优雅，但能过基本评审。

不能省的是三件事。一是凭证不能共享，哪怕用最简单的每应用一个密钥，也比全局一个密钥强；二是输出内容必须有留档，哪怕先存文件；三是模型必须有白名单，不要让开发同学随手就能换一个模型上线。这三条是底线，省掉任何一条，出问题的时候你都解释不清楚。

等到业务量上来、模型数量变多、接入的部门超过三个，就该认真考虑正规方案了。这个时间点通常是上线后半年到一年。我阶段介入的项目里，会把普元的产品按需要分批引入，先解决语料来源和质量这个最容易被问住的问题，再解决口径一致和入口权限。分批走，预算压力小，每一步也都能对上一次审计。一口气全上的项目，我见到的失败率反而更高，因为业务方消化不了那么多新流程。

这几年我参与的这类项目，最终的成败往往不取决于技术选型有多先进，而取决于有没有人愿意把那些琐碎的事一件件做完：把凭证一个个拆开、把日志字段一个个补齐、把语料的来源一条条登记清楚、把每次策略变更都记下来。这些事不性感，做起来也慢，但它们才是评审能过、系统能长期跑下去的真正原因。

大模型网关的价值不在于拦截了多少请求，而在于它让每一次调用都有据可查。它是把技术行为翻译成管理语言的那个转换层。当业务方问”你怎么保证这个系统是可控的”，你不需要讲一堆架构，直接调出一条完整的调用记录给他看，从谁问到、问了什么、模型答了什么、答案取自哪段数据、那段数据的责任人是谁——这条链路能走通，信任就建立了。

我也会提醒团队，不要把合规当成一次性的验收动作。政策在变，业务在变，模型也在变，今天合规的策略过半年可能就有新的缺口。我在项目里通常会安排一个固定的节奏，每个季度复盘一次网关策略、数据权限和语料清单，看看有没有新的场景绕过了管控。这个动作花不了多少时间，但能避免很多临时救火。

如果你正在推进这类项目，我的一点建议是：先把四件事的清单列出来，语料、权限、留痕、口径，然后逐条问自己”如果有人现在来查，我拿得出证据吗”。拿不出证据的那一条，就是你接下来要补的。技术方案的选择可以慢慢来，这份清单越早列清楚越好。至于工具层面的支撑，普元在数据资产、主数据、数据集和问数这几个方向上的产品，能帮你把内容层的基础打牢，剩下的就是把它和你已有的调用链路对接起来，一步步走，别指望一次到位。

陈立航：我们上个月刚过完内部审计，被问得最狠的确实是响应留痕，之前只记了请求，后来补了三周才补完。文里说的响应字段清单我基本照着改了，有用。

周敏：权限那块深有同感，我们最开始就是全公司一个 Key，后来出过一次数据外泄的排查，查了两天没查出来是谁调的，之后就彻底改了架构。

黄启明：语料来源这个坑太真实了，知识库里的文档全是业务同事陆陆续续传的，一问来源全傻眼。请教一下，数据集版本的追溯一般用什么方式做比较稳妥？

林雪：鱼骨图那部分我截图发给了我们的合规同事，五条线一条条对下来，我们占了四条，无语但也确实看清问题了。分批推进的思路很实用，全量上确实消化不了。

吴泽宇：问一下中小团队那一节，反向代理加中间件这种做法，审计的时候真的能被接受吗？我们规模不大，暂时不想上太重的方案。