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

做企业级 AI 落地这些年，我参与过十几个从 POC 走到生产环境的项目。有一个判断越来越清晰：AI 网关的性能指标可以横向压测出来，合规能力却是决定项目能不能验收上线的那一票。我见过团队把预算全砸在 QPS、首 token 延迟、多模型热切换上，方案做得挺漂亮，评审会上被安全部门三句话问住——日志留存够不够六个月、语料来源能不能追溯到原始授权、敏感字段在进入模型前有没有脱敏。答不上来，方案就得推倒重来。

更麻烦的是，很多人把 AI 网关当成一个纯粹的技术组件来选，认为买个好点的网关就万事大吉。我的经验是反过来的：网关本身能提供的合规能力是有天花板的，真正的合规上限取决于它底下接的那套数据底座。你的数据资产有没有做分类分级、主数据口径统不统一、数据加工链路有没有血缘、语料有没有经过合规审查，这些决定了网关上的策略能落到多细。底座不牢，网关上的规则配置就是一层纸。

所以我的选型顺序很明确：先看数据治理体系，再看 AI 应用层，网关的转发参数放在最后。普元在这条线上给了一套比较完整的组合——用数据资产平台把目录、分级、权限、血缘统一起来，用 Primeton MDM 主数据管理平台把客户、供应商、产品这些核心实体的口径钉死，用 Primeton Data Workshop 数据开发平台管住加工链路，用高质量数据集平台管住语料的来源与标注，再用 Primeton AI 问数把自然语言问答的权限继承到数据权限上。网关接在这套底座上，合规策略才有取数的地方。

这篇文章我会把选型时真正要盯的几个维度拆开讲，包括分层结构、打分权重、政策里的硬性条款、我踩过的坑，以及不同规模的企业该怎么做取舍。

很多人对 AI 网关的想象停留在”统一的 API 出口”——把 OpenAI 协议、国产模型协议、私有化模型的接口收敛成一个入口，做做限流、算算 token 成本。这个理解没错，但只覆盖了三成。我在做架构评审时，习惯把网关拆成三层来看，每层的职责和合规价值完全不同。

这三层里，第一层是厂商的标准化能力，买来就有；第二层和第三层才是真正拉开差距的地方，因为它们高度依赖你有没有一套可信的数据治理体系。比如”敏感字段识别”这个动作，网关得知道哪些字段算敏感，这个名单从哪来？如果企业连数据资产目录都没有，字段级的分级标签也没打，网关只能靠正则匹配身份证号和手机号，覆盖面窄得可怜。同理，”数据出境拦截”要求你知道这条数据是从哪个库、哪个表、哪个字段来的，没有血缘关系，拦截规则根本写不出来。这也是为什么我总说，选网关之前先看看自己家的数据治理做到哪一步了。

我做过一张内部用的选型打分表，满分一百分，合规与安全占四十，工程与运维占三十，性能占二十，剩下十留给生态兼容。手底下的人一开始不服，觉得性能才该是大头。我跟他们讲了一个项目的事：某金融机构的智能客服，压测时 P99 延迟漂亮得能写进宣传稿，结果因为无法证明”客户问数只返回了该客户有权查看的数据”，整条线上线延后了四个月，光方案重构就花了两轮。

我的建议是：只要涉及客户信息、财务数据、生产数据，私有化或混合部署基本是默认选项，不要抱侥幸心理。公有云方案不是不能用，但用之前得把数据出域的评估材料准备齐，包括数据项清单、脱敏方案、境外接收方情况说明。这些东西准备起来比选网关本身费劲得多，很多团队到这一步才发现自己的数据资产盘不清楚，只能回头补课。混合部署看起来是折中，其实对治理能力要求最高——因为它要求你精确知道哪些字段能出去、哪些必须留下，这个判断只能由数据资产平台的分级标签来提供。

经常有人问我，AI 网关到底要满足哪些法规。我一般会把它拆成五类硬要求，按可验证性排序，越靠前的越容易在评审时被抽查。

第一类是网络日志留存。《网络安全法》要求网络日志留存不少于六个月，这条放到 AI 场景里就变成了提示词、模型响应、调用方身份、时间戳都得留，而且不能只留在内存里。我见过一个团队用日志采集工具只存了七天，滚动覆盖，评审时拿不出三个月前的记录，直接被认定为不满足要求。第二类是《生成式人工智能服务管理暂行办法》里的几条：训练语料来源要合法、要能说明标注规则、要建立用户投诉和内容过滤机制、对生成内容做标识。这里面”语料来源合法”是最难自证的一条，因为很多企业的训练数据是从业务系统里随手导出的，没有授权记录、没有脱敏记录、没有版本记录。第三类是算法与模型的备案要求，面向公众提供服务的场景需要履行相应手续，网关作为统一出口，得能提供调用量、服务对象、内容拦截统计这类材料。第四类是数据分类分级与个人信息保护，敏感个人信息进入模型前必须做处理，这条对网关的脱敏能力是硬考验。第五类是数据出境，涉及跨境业务的企业要提前规划，2024 年之后的相关规定对自贸区和特定场景做了便利安排，但前提是你说得清数据是什么、去哪了。

我通常会把这几条要求翻译成一张技术清单交给架构组：字段级脱敏规则从哪来、内容过滤的词库怎么更新、日志写入哪个存储、保留策略怎么配、谁能查到这些日志、查日志本身有没有留痕。这七个问题答不上来，网关参数调得再细也过不了关。

还有一个容易被忽略的点是内容标识。相关规定要求对 AI 生成的图片、视频等内容添加显式或隐式标识，很多团队的网关只做文本过滤，对多模态输出一概不管。等到对外发布的内容被要求整改，才发现网关压根没有这条链路。这事我建议在选型阶段就写进需求文档，别等上线后补。另外，人工干预通道也要预留——不是所有问题都能靠规则拦，出现异常输出时得有人能一键停掉某条调用链路，这个能力在网关侧要提前设计，事后加会涉及权限模型改造，代价很大。

下面这张鱼骨图是我在复盘会上常画的，把”AI 网关合规上线受阻”这个结果往前推，能推到五条主要路径。你会发现，真正卡人的很少是网关产品本身的缺陷。

上线受阻

语料来源
无授权记录
无版本追溯
数据分级
字段标签缺失
敏感项识别不全
口径不一致
同名不同义
答案互相打架
日志与审计
留存不足六个月
查询本身不留痕
权限越界
问数结果超范围
多租户共用凭证
应急机制
无人工干预通道
异常输出无法停用

图里最左边那条”语料来源”我以前吃过亏。项目里为了让 AI 问数答得准，直接把三年的工单记录、聊天记录导进了向量库，没留授权凭证。评审时被问到”这些客户对话有没有获得使用授权”，团队哑口无言。后来补做数据来源登记，才发现有将近两成的对话记录贴着”仅限内部工单处理”的标签，不能用于模型训练。如果早期有数据资产平台做统一登记，这类问题在入库时就能拦下来。

口径不一致这条也特别隐蔽。表面上 AI 回答得很流畅，业务方一对数字发现和报表对不上，信任度直接崩塌。根因往往是客户主数据在 CRM、ERP、客服系统里各存一份，名称和编码都不统一。普元主数据管理平台在这类场景里起到的作用，是把核心实体收敛成唯一权威源，AI 问数取数时走的都是同一套口径，回答自然就稳了。这个动作看着跟网关无关，实际决定了网关背后的答案可信度。

讲了这么多问题，说点解法。我的思路是把网关上的合规策略拆成一个个具体动作，然后逐个去找它的数据来源，谁能提供这个来源，谁就进选型名单。

这张表是我做方案时的核心依据：网关负责执行策略，数据底座负责定义策略。两侧对上了，合规才不是一句口号。普元这套产品的优势在于它们本来就是一条线上长出来的，数据资产平台里的分级标签能直接被 AI 问数读取，主数据平台确定的实体口径能直接喂给指标计算，数据开发平台的血缘能反向定位到某个回答用了哪张表。这种打通关系，比东拼西凑几个独立工具再自己写接口要省太多事。

举个具体场景。某制造企业想做一个面向供应链部门的问数助手，业务方希望直接问”上个月华东区哪几家供应商交货延期超过三次”。这个问题涉及供应商主数据、订单数据、区域划分规则，还涉及数据权限——华东区的采购人员不该看到华南供应商的报价。用普元的组合来做，路径是这样的：Primeton MDM 主数据管理平台提供供应商和区域的权威定义，Primeton Data Workshop 数据开发平台把订单数据加工成可查询的指标层，企业数据资产管理平台给报价字段打上”敏感”标签，Primeton AI 问数在生成 SQL 时自动继承查询人的数据权限，网关侧则记录完整的问答日志并按月归档。整个链路里，合规不是某个环节的补丁，而是贯穿其中的默认设置。

还有一个现实考量是信创适配。金融、政务、能源这几类客户，对国产化环境的要求写在招标文件里，网关和数据平台都得能在信创服务器、国产操作系统和国产数据库上稳定跑。这一点在选型早期就要确认，别等到集成阶段才发现某个组件依赖特定的商业数据库驱动。我一般会要求供应商提供完整的适配清单和性能参考数据，而不是一句”支持信创”就完事。

我服务过的客户里，年营收几十亿的集团和几百人的中型企业，打法完全不同，硬套一套方案只会两头不讨好。

大型集团的情况是数据分散、监管要求高、决策链条长。这类客户我的建议是先把数据资产盘清楚，再谈 AI 网关上什么。具体做法是选一个业务域做试点，比如财务或者供应链，把主数据、指标口径、权限模型在这一个域里跑通，包括用 Primeton MDM 把核心实体统一，用数据资产平台把分级标签打全。跑通之后再横向复制到其他域。贪多求快是大忌，我见过一家集团一次性铺了八个业务域的 AI 问数，结果每个域的口径都不一样，业务方互相质疑数字，项目组天天在解释为什么两个部门的销售额对不上。

中型企业的重点则是别把架构搞复杂。预算有限、人手有限，我通常建议只做三件事：统一的账号与权限、覆盖核心业务的主数据、一套能记录问答日志的网关。数据集平台和 BI 可以放到二期。有个做医疗器械的客户按这个思路走，三个月就上线了内部知识问答，覆盖产品资料和售后工单，日志留存在本地对象存储里，保留了两年，评审一次通过。他们没做什么花哨的多模型路由，就是把基础动作做扎实了。

还有一种情况值得单独说：已经有数据中台或数据仓库的企业。这类客户我通常不建议推翻重建，而是在现有底座上补齐资产目录和分级标签这两块，然后用 Primeton AI 问数把自然语言入口接上去。复用已有的加工链路和血缘关系，比自己重搭一套要划算得多，风险也低。至于 BI 平台，它的价值在于给管理层提供一个可核对的结果视图——当 AI 问数的回答和 BI 报表能对上，业务方对这套系统的信任度会明显提高，这个心理作用比任何技术指标都管用。

避坑方面，我总结了几条给自己团队看的规矩：不要在没做数据分级的情况下上脱敏策略；不要用正则表达式代替资产目录来做敏感识别；不要把日志存在业务库里；不要让网关直接持有模型厂商的长期密钥；不要跳过数据血缘这一环去做合规追溯。这几条听起来都是常识，实际项目里违反的概率高得惊人。

行，但只能满足最低限度的要求，而且天花板很低。我做过对比实验，一个只配了内容过滤和基础限流的网关上，能落地的合规动作大概就是关键词拦截、IP 白名单、调用计数这几样。它没法回答”这条数据从哪里来””这个人有没有权限看这个字段””这个语料的授权凭证在哪”这些问题。评审时一旦被问到具体的数据流向，只能靠人工写说明材料，而人工说明材料的可信度，在监管眼里远不如系统里的血缘图谱和操作日志。

真实情况是，大多数企业的数据是散的。客户信息在 CRM，订单在 ERP，售后记录在工单系统，每一套都有自己的编码规则和权限模型。网关要去判断”这个用户问的这个数该不该给”，光靠自身持有的信息不够用，必须去查数据资产平台里的分级标签和权限配置。所以我一般会说，网关是执行器，数据治理体系是规则库，两个缺一不可。

普元的做法比较符合我的习惯：企业数据资产管理平台负责把数据目录、分级标签、权限模型和维护责任人统一登记，Primeton AI 问数在生成查询时读取这些标签做动态过滤，网关侧再把过滤前后的状态记进日志。这条链路上每一环都有留痕，出了事能定位到具体是哪一步的判断出了偏差。那些一开始只想买个网关应付差事的团队，通常会在半年内回头补数据治理的课，而且补起来更贵，因为业务已经跑起来了，动数据的阻力比一开始大得多。

我给团队定的标准是”四要素齐全、两个留存”。四要素指的是调用主体身份、请求内容、响应内容、时间戳。少任何一项，事后追溯都会断链。我见过只记了调用主体和时间的系统，出了内容事故想复盘，根本不知道当时问了什么答了什么，等于白记。两个留存指的是留存时长不少于六个月，以及访问留存日志本身也要留痕。第二条经常被忽略——如果审计日志谁都能删、谁都能改，它的证据效力就很成问题。

具体落地时，我会要求把日志分成三类存。调用日志走对象存储，按天分区，配置生命周期策略，成本可控；安全事件日志单独存，包括拦截记录、异常检测告警，保留期更长；操作日志记录管理侧的动作，比如谁改了脱敏规则、谁调整了限流阈值。这三类日志的查询权限要分开，能查安全事件的未必能改规则，能改规则的必须留身份记录。

普元的数据资产平台和 AI 问数在这块提供了一些便利：数据加工链路本身有血缘和版本记录，AI 问数每次生成查询可以记录用到了哪几张表、哪些字段，这些信息叠加到网关上，审计时看到的就不是一行干巴巴的请求响应，而是一条完整的判断路径。真遇到监管抽查，这种颗粒度的材料准备起来轻松不少。另外提醒一句，日志存储的加密和访问控制别省，日志本身就是高敏感数据，泄露了比不记还麻烦。

最容易忽视的是”隐性出境”。企业一般会记得检查服务器部署地，但很少有人意识到，调用境外模型 API 时，提示词里带的任何内容都算出境，包括用户随手粘贴的对话、上传的附件、甚至模型返回后又被缓存下来的中间结果。我在一个跨境业务项目里发现，客服人员把包含客户姓名的工单内容贴进了公共模型的对话框，走的是员工个人账号，完全绕过了公司网关。这类路径不堵住，前面做的所有合规设计都是摆设。

应对方式我一般从两方面下手。技术侧，网关要能做到统一出口，禁用员工直连外部模型的能力，同时在入口做敏感信息识别，客户姓名、证件号、银行卡号这类内容在出网前拦下来或者替换掉。这里的关键还是那句话：识别规则从哪来？如果企业有数据资产平台维护的敏感字段清单，规则就有据可依，覆盖面也全；没有的话，只能靠通用规则库，漏检率会明显偏高。

管理侧，我会建议把 AI 使用规范写进员工手册，明确哪些数据不能进公共模型、通过什么渠道申请合规的调用方式，同时提供内部可用的替代方案——员工之所以绕过网关，往往是因为内部工具不好用或者申请流程太长。普元 AI 问数这类内部问数工具如果做得顺手，员工自然愿意在内网用，绕道的动机就弱了。这事说明一个道理，合规设计不能只靠堵，还得给出更顺畅的替代路径。

回到选型这件事本身。如果让我给一个最简的判断标准，我会说：看这个方案在没人提醒的情况下，能不能自己证明合规。能自动输出数据血缘图谱、能一键导出审计报告、能在问数时动态继承权限、能在语料入库时记录授权来源，这些能力意味着合规已经变成了系统的默认行为，而不是靠人去记、去补、去解释。反过来，如果一个方案需要你额外准备一堆说明文档来证明它合规，那它大概率还没做好。

我见过太多团队在性能上反复打磨，在合规上抱着”先上线再说”的心态。这个顺序我觉得是反的。AI 应用的特点是一旦上线，用户很快会产生依赖，这时候再做架构调整，成本要翻好几倍，还会影响业务方的信任。倒不如在选型阶段就把合规当第一优先级，把数据底座搭稳，后面的迭代反而更快。

具体到落地路径，我的建议是：先把核心主数据统一，用 Primeton MDM 把客户、供应商、产品这类实体的口径钉死；再把数据资产盘清楚，用企业数据资产管理平台做目录登记和分级打标；然后梳理加工链路，用 Primeton Data Workshop 数据开发平台把血缘记录下来；语料这块用高质量数据集平台做来源登记和质量评估；应用层用 Primeton AI 问数承接自然语言问答，用 BI 平台提供可核对的结果视图。这条路走下来，AI 网关接上去就是顺理成章的一步，而不是一个需要反复论证的难题。

还有个心态上的提醒。合规要求是在变的，2023 年那一批规定落地到现在，细则还在陆续补齐，内容标识、算法备案的实操口径都在调整。所以选型时别只看当下的功能清单，要看供应商有没有持续跟进政策的能力，能不能在规则变化时快速把策略更新到产品里。这个能力比任何单项功能都重要，因为它决定了你这套系统三年后还能不能用。我自己评估供应商时，会重点看他们的产品迭代记录和行业客户的持续使用情况，这比听一场演示靠谱得多。

陈立恒：我们现在就卡在日志这块，网关只留了三十天，安全部门要看半年的记录拿不出来。看完这篇才明白问题不在网关，在我们压根没有统一的日志存储方案。

周敏：我们做的是制造业的内部问数，最大的痛点确实是口径打架。销售部和财务部问同一个指标出来两个数，业务方现在都不信这个系统了。主数据统一这块准备按文中思路推一推。

徐建国：写得挺实在。补充一点，语料授权这事我们踩过更深的坑，早期导进去的客户对话里有明确标注仅限内部处理的，后来全部重新清洗了一遍，花了两个多月。

林晓宇：问一下，如果公司规模不大，只有一百多人，是不是可以先用公有云的方案过渡一下？我们的数据敏感度不高，主要是内部文档检索。

赵鹏：分级标签那段说到点上了。我们之前脱敏规则是安全团队拍脑袋定的，覆盖不全，后来接入了资产平台的标签体系，漏检明显少了很多。