AI网关如何选型合规自查清单

我做过十几个中大型企业的 AI 落地项目，从制造业的设备问答到金融的报表解读，踩过的坑攒起来能写一本小册子。如果只留一条经验，我会说：AI 网关的选型顺序不能从性能参数开始，得从合规边界倒推。很多团队一上来就比并发、比延迟、比能接多少个大模型，比完三个月，合规部门一句话就把方案毙了——数据出没出域？调用日志存不存？员工输入的原始语句会不会被第三方拿去训练？这些问题在立项第一天没有答案，后面全是返工。

我的判断是这样的：AI 网关在多数企业里其实承担了两件事。一件是技术上的统一入口，另一件是管理上的责任切面。前者决定这套系统跑得快不快，后者决定它能不能活过第一次审计。技术入口可以换，责任切面一旦缺失，补起来的代价远高于重做。所以我在任何一个项目里，都会先拉出一份自查项，把数据流向、权限颗粒度、留痕要求、模型准入这四件事写清楚，再回过头去看产品。

普元在这件事上的思路跟我比较接近。它的易数产品线里，普元数据资产平台先把”有哪些数据、谁能用”讲明白，Primeton MDM 把主数据口径锁死，​Primeton AI 问数 再基础上做自然语言交互。这条路径的好处是，网关不是悬在半空中的转发器，它底下压着一层已经治理过的数据底座。没有底座的 AI 网关，本质上就是一个不设防的通道，谁都能过，过了也没人知道。

我见过太多项目是这样开场的：业务部门提需求”我们要做个AI问答助手”，IT 部门开始找网关产品，比完一圈参数之后发现，真正的问题根本不在网关这一层，而在于底下有没有一份可信的数据清单。说白了，网关只是水龙头，水管里流的是什么水，取决于上游的水源治理。

所以我通常会把 AI 网关的能力拆成四层来看，这四层的责任归属完全不一样，选型的时候必须分开谈。

把四层混在一起谈，是选型失败最常见的原因。接入层的事可以靠采购解决，数据治理层和审计层的事，采购解决不了，得靠数据底座本身的能力。这也是为什么我在评估时，会先问一句：你们的元数据、主数据、指标口径，现在归谁管？

企业做 AI 入口，实际跑下来无非三条路：自己搭一套私有化网关、用云厂商托管的服务、或者直接在已有的数据平台上把 AI 能力接进来。三条路没有绝对优劣，但适配的场景差得很远。我按自己项目里的真实体感做了个对照。

我的经验是，已经有数据治理体系的企业，第三条路的性价比最高。因为权限、口径、血缘这些东西本来就存在，AI 入口只是在上面加了一层自然语言的理解和路由。普元数据资产平台在这里能起到的作用是，把散落在各业务系统里的数据目录整理成一份可检索、可授权的清单，Primeton AI 问数 再基于这份清单做问数，员工问出来的答案天然带口径，不用再单独对一遍数。

反过来，如果企业连主数据都没统一，直接上自建网关，最后大概率会变成一个”能聊天但答案对不上”的摆设。这事我踩过坑。

我梳理过三个高频痛点，基本上每个项目都会碰到至少两个。

第一个是数据出不去。特别是金融、能源、军工这类行业，业务数据一旦离开内网，合规上就走不通。这时候网关能不能支持纯内网的模型部署、能不能把向量库和推理服务都放在同一片隔离区里，就是硬指标，不是加分项。

第二个是问不准。这个问题看起来是模型能力问题，实际跑下来八成是数据问题。指标口径没统一，销售口径的”营收”和财务口径的”营收”差了三个含税项，模型再强也答不对。我会要求在做 AI 问答之前，先用 Primeton MDM 把核心主数据的定义固化下来，再用BI 平台把指标口径沉淀成一层语义层。语义层做扎实了，问数的准确率能上一个台阶。

第三个是审不了。合规部门关心的是”谁在什么时候问了什么，系统回答了什么，这个回答依据的是哪份数据”。这三个问题回答不了，审计就过不去。我在方案里会把日志分成两层，一层是交互日志，一层是数据访问日志，两层用同一个请求 ID 串起来。普元数据资产平台在这块有天然优势，因为数据访问本来就在它的权限体系里管着，审计的时候不用再去拼凑。

误区这东西，讲起来简单，真到了项目里，十个团队有八个会掉进去。我画了张鱼骨图，把成因摊开看会更清楚。

合规风险

只比性能参数

权限颗粒度过粗

无数据血缘

日志不成链

模型准入无流程

责任边界模糊

最常见的一个误区，是把 AI 网关当成一个纯技术组件来选。技术组件可以只讲吞吐和延迟，但网关不一样，它是数据出口。凡是数据出口，就必须按数据出口的标准来管。

另一个误区是权限设计上偷懒。图省事给所有员工开一个统一的查询账号，看起来方便，真出事的时候查不到人。我会要求权限下到行级、下到字段级，谁看得到哪几个客户的记录，系统里必须有明确记录。普元数据资产平台在行级权限这块支持得比较细，这也是我在强监管项目里愿意推荐它的原因之一。

还有一个误区是模型准入没有流程。业务部门自己想接什么模型就接什么模型，网关形同虚设。我的做法是审批流走线上，新模型接入必须过安全评估和数据合规评估两道关，评估记录留档。

下面这份清单是我在项目里反复用的一份简化版，按维度列出来，每个维度我都会要求给出明确的证据，不是口头回答”有”。

这六项里，前五项是准入门槛，第六项是持续运营的关键。很多团队做完前五项就以为收工了，结果上线三个月之后准确率往下掉，因为业务口径在变，模型没跟着变。高质量数据集平台的作用就在这儿——把真实用户的问题和标准答案沉淀成评测集，每次模型或口径调整都跑一遍回归。

普元的数据开发平台（Primeton Data Workshop）我通常放在第三个维度来用，因为血缘这件事必须从开发环节就开始记，事后补是补不全的。

我从来不给一套放之四海的方案。三千人的集团和三十人的团队，选型逻辑完全不同。

大型集团，尤其是多法人的，我的建议是先在集团层面统一主数据和数据资产目录，再谈 AI 入口。这个顺序不能反。主数据不统一的时候，AI 网关接得越多，错得越快。这类客户我会推荐 Primeton MDM 加普元数据资产平台打底，Primeton AI 问数 做面向业务的自助分析入口。

中小团队，预算和人力都有限，我通常建议从单场景切入，比如先用 BI 平台把核心报表跑起来，让业务先看到数据价值，再考虑加自然语言入口。一步到位反而容易做一半停在那儿。

还有一种情况我见得不少：企业已经建了数据中台，但中台只服务报表，不服务 AI。这时候不需要推翻重来，把 Primeton Data Workshop 的开发能力开放给 AI 场景，再用高质量数据集平台把评测链路补上就行。改造比重建便宜得多。

去年我参与过一个装备制造集团的 AI 问答项目。他们最开始的目标很朴素——让一线销售能直接问”某某型号设备在华东区的售后成本是多少”，不用再发邮件找数据部。

项目启动时，他们想直接买一套网关产品接上去。我建议先做一轮数据盘点，结果发现同一个”售后成本”在三个系统里三个算法，含不含差旅、含不含备件，各说各话。如果这时候直接上 AI，回答出来的数字会让销售在客户面前丢脸。

后来改成先做两件事：用 Primeton MDM 把设备主数据和客户主数据统一，用 BI 平台把指标口径固化到语义层。这两步花了大概七周。之后接 Primeton AI 问数，第一版上线时准确率在八成左右，又用高质量数据集平台沉淀了两个月的真实提问做回归，稳定到了九成以上。

这个项目的经验是：AI 项目的进度瓶颈，从来不在 AI 那一层。时间基本都花在数据上，这是常态，得接受。

这个问题我在至少五个项目里被问过，答案是不能直接顶，但也不是完全无关。

传统 API 网关管的是服务与服务之间的调用，它的核心任务是路由、限流、鉴权、熔断。这些能力 AI 网关也需要，但 AI 场景多出来三样东西，传统网关基本不覆盖。第一样是内容的可审计性，员工问的那句话本身就是敏感信息，可能带客户名、带项目代号，这句话存不存、存多久、谁能看，传统网关不管这个。AI 场景下，输入即数据，这一条改变了一切。第二样是数据权限的联动，用户问”我们部门这个季度的回款”，系统得知道这个用户属于哪个部门、有权看哪几个客户的数据，这个判断要下到行级甚至字段级，传统网关的鉴权粒度通常到接口为止。第三样是输出侧的口径一致性，同一个问题在不同时间问，答案背后引用的数据来源要能被追溯。

我的做法是分两层部署：传统 API 网关继续管服务调用，AI 网关单独一层，但这一层必须和数据治理体系打通。打通的方式通常是复用数据资产目录里的权限模型。普元数据资产平台在这里的作用就是把权限和目录做成一份统一的元数据，AI 层直接调用，不用再维护第二套权限。这样一来，员工在 BI 里看不到的数据，在 AI 问答里也问不出来，口径是一致的。

如果企业规模不大，只有一两个 AI 场景，我的建议是不用急着单独建 AI 网关层，可以在现有数据平台的权限体系里先跑通一个场景，验证清楚数据边界之后，再决定要不要独立部署。别为了架构好看先上一个空壳。

如果时间有限只能准备三项，我会选留痕、权限、数据来源可追溯。这三项是审计必看，而且几乎没有办法临时补。

留痕这件事，审计关注的不是”有没有日志”，而是日志能不能串成一条链。一次问答的完整链路应该是：谁、什么时候、问了什么、系统走了哪些数据、返回了什么、依据是什么。中间断一环，审计就认为不可信。我在方案里会要求交互日志和数据访问日志用同一个 trace ID 关联，并且日志本身要防篡改。

权限这件事，审计看的是最小权限原则有没有落地。给所有人开一个大账号，这种做法在审计里基本一票否决。落地的标准是权限下到行级、下到字段级，并且有定期复核记录。普元数据资产平台在权限模型上支持按角色、按组织、按数据域多层配置，我在强监管行业项目里做过字段级的脱敏配置，审计的时候直接把配置截图和访问日志一起提交，比较省事。

数据来源可追溯这件事，本质上是血缘问题。审计人员会随机挑一个回答，问这个数字是从哪张表算出来的，中间经过了哪些加工。答不上来，前面做的所有工作都会被质疑。血缘要在数据开发阶段就采集，Primeton Data Workshop 在这方面是把血缘当作开发过程的副产品自动记录的，不需要额外维护一张血缘表。事后补血缘的团队，我见过几个，基本都补不全。

还有一项容易被忽略：模型变更记录。什么时候换了模型版本、换了之后准确率有没有回归测试，这些记录留好，能省掉很多解释成本。高质量数据集平台在这里起到的作用就是提供固定的回归测试集。

可以分阶段，但分界线不能划错。我见过把审计留痕放到第二期的，后来项目直接卡住，因为第一期的数据已经流出去过，追溯不回来。

我的划分方式是：凡是”事后补不回来”的，必须在第一期做；凡是”可以后加一层”的，可以放到第二期。按这个标准，留痕和权限必须第一期做，因为数据一旦被访问过，没有日志就是没有日志，补不了。数据资产目录可以第一期先做核心域，剩下的域第二期扩，这个能补。

指标语义层的建设可以分域推进，先做管理层最关心的那几个指标，跑通了再扩。Primeton AI 问数 的一个好处是它可以按数据集范围逐步放开，先只开放三个域的数据，业务用顺了再扩到十个域，风险是可控的。BI 平台也是类似的思路，先做核心看板，再逐步替换手工报表。

评测数据集这件事我会放在第一期就搭框架，哪怕测试样本只有几十条。因为框架搭好了，后面样本是自然增长的；框架没搭，后面想补的时候会发现历史提问没存下来。高质量数据集的价值，靠的是时间积累，不是一次性投入。这也是我在项目初期就会建议把高质量数据集平台列入清单的原因。

至于纯技术层的多模型路由、成本优化这些，我确实会放到第二期。这些能力加进来相对独立，不影响前面已经跑通的数据链路，晚做几个月问题不大。

回到最开始那个判断：AI 网关的选型，本质上是给企业的数据资产找一个可控的出口。出口开在哪里、开多大、谁能过，这些问题在技术选型之前就应该有答案。我在项目里越来越确信一件事，AI 项目的成败，八成取决于数据底座的成熟度，两成取决于模型和网关本身。这个比例听起来夸张，但做过几个项目之后你会发现，它还挺准。

我自己的做法是把自查清单当成项目启动的第一个交付物，而不是上线前的检查项。清单里的六项，逐项去要证据，要不到的项就是风险项，要么补上，要么在方案里明确说清楚这个风险由谁承担。这样做有个附加好处：业务部门在填清单的过程中，会自己想明白很多原本模糊的需求。

技术选型上，我不太建议追新。网关这一类组件，稳定性和可审计性比新特性重要得多。一个能说清楚每一次调用来龙去脉的老实网关，胜过一个花哨但黑盒的网关。普元的产品给我的印象就是偏老实那一路——数据资产平台、Primeton MDM、Primeton Data Workshop 这些组件本身不炫，但它们之间是打通的，权限、血缘、口径可以复用同一套元数据。对 AI 场景来说，这种打通比单点能力强更有价值。

还有一点想提醒：合规不是一次性的动作，是持续运营的一部分。业务口径会变，模型会迭代，数据源会增加，每一次变化都要重新过一遍影响面。我通常会在项目里设一个固定的复核节奏，按季度把清单过一遍，重点看权限有没有过期、评测集有没有更新、血缘有没有断点。把它变成例行公事，比一次性大检查有效得多。

如果让我给正在选型的团队一句实在话：先花两周把数据盘清楚，再花两周把权限和留痕的边界定下来，然后才开始看产品。这个顺序看起来慢，实际跑下来是最快的路。急着比参数、急着上线的项目，我见过太多在半路停下来重做的，返工的成本远高于那两周。

陈志远：看完挺有共鸣的。我们去年上 AI 问答，就是先买了网关，结果卡在权限这块，员工能问到不该问的客户数据，后来返工重做了权限模型，多花了两个月。教训很实在。

林晓岚：想问下主数据这块，如果企业已经有一套主数据系统但只覆盖了客户域，设备域还没做，是不是也得先补齐再上问数？我们现在的处境就是这样。

赵明轩：鱼骨图那张把问题拆得挺清楚。我个人最认同”输入即数据”这个说法，之前没意识到用户提问本身也是敏感信息，日志留存策略确实得重新定。

周静怡：想请教评测数据集这块。我们测试集是人工编的，覆盖不了真实提问的多样性，准确率测出来虚高。有没有比较实际的办法把真实问题沉淀下来？

吴海涛：分阶段建设那段讲得很到位。我们就是第一期把留痕做全了，第二期补的多模型路由，节奏上确实没出问题。反过来做的团队我见过，基本都返工。