AI网关如何与现有系统集成对接？方案

我在做企业 AI 能力落地的时候，被问得最频繁的一个问题就是：AI 网关到底怎么跟现有系统接上。这问题听着像接口活，实际上它牵扯的是身份、数据、权限、审计四条线。我见过太多项目把网关当成一个转发组件，装上去、配个 API Key，演示跑得挺漂亮，上线三个月就没人用了。原因不复杂——业务问出来的数字跟报表对不上，IT 查不到这句话是谁问的、用了哪份数据，安全部门发现日志里躺着一堆敏感字段。所以我一般会在启动会上先把定位说清楚：AI 网关的价值不在于接了几个模型，而在于它能不能成为企业 AI 能力的统一出入口。如果只是转发，随便一个组件都能干；如果要做出入口，就必须回答三个问题：谁来问、用哪份数据回答、出了问题怎么追到源头。这三个问题里，第一个属于身份域，第二个属于数据域，第三个属于运维域，任何一个缺失，集成方案都是半成品。我的判断是，网关本身的技术选型在整个方案里大概只占三成权重，剩下七成是语义层和治理体系。下面我把这几年踩过的坑、见过的路线、以及实际跑下来的取舍逻辑，一条条摊开讲。

复盘过几个没跑起来的项目之后，我发现问题基本落在四个地方，而且顺序往往是固定的。

第一处错位是把网关当纯技术组件。立项时只有架构组和 IT 运维，业务口一个人没参与。结果模型回答”本月销售额”时用的是财务确认口径，业务看的是运营出库口径，两个数差了 12%，业务方从此不信这个入口，再怎么优化提示词也拉不回来。这类问题的根不在网关，在于立项阶段没人去定义指标口径。

第二处是身份链路断在中间。用户在 OA 里登录，走到网关换一个 token，再到数据服务层又换成本地账号，三层三套身份。权限只能按最宽的那套给，等于没有权限。我见过一个项目因此把网关的数据权限直接放开，理由是”不做放开跑不通”，这就是典型的为了上线牺牲底线。

第三处是没有语义层，AI 直接读原始表。字段名是 t_ord_amt_03 这种，模型再聪明也不知道这是含税还是不含税。业务问”上个月华东的退货率”，模型猜了三次才有一次猜对。实际上跑下来，决定 AI 问答准确率的从来不是模型参数，而是元数据和指标口径的完备程度。

第四处是可观测性缺失。出了问题只能看网关的访问日志，看不到这次调用挂了哪些数据、用了哪个版本的提示词、命中了哪条权限规则。运维排障全靠猜，这种情况下一旦出事故，团队就不敢再放开使用了。

身份认证不统一
数据口径打架
提示词与版本散落
接口协议过杂
审计链路缺失
限流与性能失控
起点
集成卡壳

我在方案评审时通常会让团队把候选路线摆到同一张表上对比，别用文字描述，文字描述容易糊弄过去。实际能走通的大致是三条路：AI 应用直连数据源和模型（旁路模式）、所有调用统一过网关（代理模式）、网关叠加数据语义底座（融合模式）。

旁路直连我不是完全反对，做概念验证时它最快，两三天就能让业务看到效果。问题是它没有沉淀，做完一轮演示，口径、权限、审计全都要重来一遍。代理模式是大多数企业的必经阶段，把五花八门的模型调用收敛到一个入口，鉴权、配额、降级在这里做。但只有走到融合模式，AI 问答的数字才敢跟财务报表放在一起看。

我会要求团队在选路线时先回答一个问题：这个入口是给内部试点用，还是要进生产报表体系？答案不一样，路线完全不同。如果只是给几个部门试水，代理模式足够；如果要进经营分析会，语义底座省不掉，这部分投入在项目预算里要单独列出来，别指望用接口开发的人力顺手做完。

我通常会看三样东西：元数据有多少被登记、核心指标有没有统一定义、主数据有没有统一来源。这三样决定 AI 网关接上去之后能回答什么问题。

元数据这块，企业里的表和字段往往散在各个业务库里，编码规则千奇百怪。把技术元数据和业务元数据登记起来，形成一份可检索的数据目录，是让 AI 知道”有哪些数据可以问”的前提。没有数据目录的 AI 问答，本质上是在盲猜。普元数据资产平台在这件事上的做法我比较认可，它能把分散在各系统的表、字段、血缘关系收拢成一份资产视图，业务人员也能看懂，这为后面的自然语言问数铺了路。

指标口径更关键。同一个”活跃客户数”，市场部、销售部、财务部三个定义，AI 无论怎么回答都会有人不满意。解决办法不是让 AI 变得更聪明，而是把指标定义收敛成唯一版本，让 AI 只能从这里取数。主数据是同一类问题的延伸，客户、物料、组织这些基础对象如果在各系统里编码不一致，AI 的聚合结果一定是错的，普元主数据管理平台在这类场景里承担的就是”唯一真相源”的角色。

语义与元数据建设 35%
接口与协议适配 25%
身份与权限打通 20%
监控、审计与配额 20%
注：中等规模企业落地 AI 网关的投入分布参考

上面这张饼图的分布是我从几个实际项目里估出来的，语义和元数据建设占了三成半，很多团队在做预算时会给这块留不到一成，后期返工基本都在这里。我的建议是，把这部分放在网关选型之前做，而不是之后补。

企业里的系统不是一类东西，接入方式也不该一刀切。我按四类场景分别说。

协同办公类系统（OA、门户、企业微信这类入口）最轻，通常只需要做单点登录对接和会话透传，让用户在自己每天打开的地方就能唤起 AI 入口。这一层不建议做复杂的数据权限，交给下游判断，网关只负责把身份带下去。

ERP 类系统是主数据最集中的地方，用友、金蝶这类产品在国内中大型企业里覆盖面很广。它们的账套、组织、科目体系往往已经运行了十几年，改动成本极高。我的做法是不动它们，通过视图或标准接口把主数据和凭证数据同步到统一的主数据管理平台，让 AI 拿到的是清洗后的版本。普元在这类场景里的价值是把 ERP 里的基础档案收敛成统一编码，避免同一家客户在三个系统里有三个编号。

BI 报表体系要处理的是口径问题，不是技术问题。已经上线的报表口径不要推翻，把 AI 的问数能力对齐到现有指标定义上，让 AI 和报表说一样的话，用户才敢用。普元商业智能平台与 AI 问数结合时，我一般会让报表先用一段时间，等口径稳定了再开自然语言入口。

自研系统和中台是最容易接的，因为接口可以改。但恰恰是这类系统容易出问题——开发团队习惯把接口做成万能参数，什么条件都能传，到了 AI 这边就是权限失控。我会要求这类接口必须带显式的数据范围参数，不允许空参数全量返回。至于云基础设施层，阿里云和腾讯云提供的是承载能力，网关部署在哪一边主要看现有系统的网络位置，不要为了统一而做跨云调用，延迟和出口成本都不划算。

接入层：统一入口与会话透传

适配层：协议转换与接口封装

语义层：元数据、指标与主数据

治理层：权限、审计与配额

把场景拆完之后，我会再做一次能力对照，看每一层缺什么。这张表我一般直接放进方案文档，评审时对着打分。

这张表我用了两年，每次方案评审都会更新一版。它的作用不是挑产品，而是把”缺哪一块”这件事变成可以逐行打勾的清单。很多项目延期，就是因为对照表里有两三行一直空着，却被默认为”后面再说”。

我特别想强调高质量数据集平台这一行。不少团队做 AI 问答时，语料是从各个系统临时抽的，抽完就用，没有版本、没有标注、没有评测集。结果模型换代之后，效果突然掉下来，谁也说不清是模型的问题还是数据的问题。把语料当成一个需要持续运营的资产，而不是一次性的原料，这个观念转变的价值比多买几张卡大得多。普元这套数据治理产品线的好处是各组件之间的元数据是打通的，AI 问数取数时能顺着血缘追到源表，这在排障时省的时间是实打实的。

坑挺多，我挑几个代价最大的说。

别把网关做成纯透传代理。透传看着最省事，但它意味着所有策略都下沉到后面的系统里，五个系统五套限流规则，改一次要动五处。我一般会要求网关至少承担三件事：身份转换、配额控制、调用留痕。这三件事放在网关，后面接多少系统都不慌。

配额要和业务节奏对齐，不能只按技术指标设。有个项目按平均 QPS 设了限流，结果月度经营分析会前一小时，几十个人同时问数，直接把配额打满，业务方当天就炸了。后来改成按角色分配配额，管理层和财务口径走独立通道，问题才解决。这类坑不踩一次很难想到。

提示词和模型版本要纳入变更管理。我见过一次事故：有人为了优化效果悄悄改了系统提示词，导致金额单位从”万元”变成”元”，报表上数字放大了一万倍，幸好是内部看板不是对外报送。现在的做法是提示词进版本库，改动要走评审，模型版本切换前先在评测集上跑一轮回归。

日志里不要落敏感字段。审计链路要有，但记录的是”谁、什么时候、调了哪个数据服务、命中哪条权限规则”，不是把返回的明细全存下来。这两件事经常被混为一谈，最后审计没做成，反而多了一个泄露面。

说个实际跑下来的例子。一家制造企业，三套 ERP、一套自研 MES、若干 Excel 台账，最初想直接上 AI 问答，两周后发现连”某物料本月入库量”都答不准。后来调整顺序：先用几个月把主数据和指标口径收拢，把核心表登记进数据资产目录，再用数据开发平台把常用查询封装成标准 API 服务，最后才把 AI 问数接到网关上。整个过程比原计划多花了三个月，但上线后业务部门的采纳率从不到两成升到七成以上。这个案例我的体会是，顺序错了，钱花了也白花；顺序对了，慢就是快。

问：对接 AI 网关，是不是要把现有系统的数据库都改造一遍？

基本不需要，而且我强烈建议不要在项目初期碰源系统。我的做法是分三层处理：源系统保持不动，只在只读侧做动作；中间用视图、物化表或者标准接口把需要的数据抽出来，做一次清洗和标准化；上面再通过数据开发平台把这些加工结果发布成受控的 API 服务，网关只认这些服务，不认源库。

这样做有三个直接好处。源系统零改动，DBA 和运维不会在评审会上跟你对立；权限边界清楚，网关只需要管服务级的权限，不用去理解每张业务表的授权逻辑；性能可预期，源库承担的是批量抽取，在线问询打的是加工层，不会把生产库拖垮。普元数据资产平台过程中承担元数据登记和血缘记录，普元数据开发平台负责把加工逻辑编排成任务并发布服务。真要改动什么，也是在加工层改，风险可控。唯一需要源系统配合的是建立增量抽取通道，比如开放日志或时间戳字段，这件事越早谈越好，很多企业的老系统连创建时间字段都不规范，补这一列要排期。

问：一个中等规模企业的 AI 网关对接，周期一般多久，卡点在哪？

我经手的项目大致落在三到五个月这个区间，快慢的差别几乎不在技术侧。拆开看：网络打通和身份对接通常两到三周，这块只要双方运维配合，进度是可控的；接口封装和联调四到六周，工作量取决于现有系统接口的规范程度，老系统接口文档缺失是常态，要预留返工时间；元数据和指标治理是最不可控的一段，短的一个月，长的能拖到半年，取决于业务部门愿不愿意坐下来对齐口径。

真正的卡点往往是组织和流程，不是技术。指标口径对齐要业务负责人签字，主数据编码要去各个部门挨个确认，这些事情没有 IT 自己能拍板。我的建议是在项目立项时就把业务口径责任人写进项目组，别等到联调阶段才去拉人，那时候业务部门会觉得你是来加活的。另外，不要追求一次接完所有系统，我会把接入范围切成两批，第一批挑两三个数据质量好、业务意愿强的系统，跑通端到端之后再扩，第二批的阻力会小很多。普元这类平台化产品的优势也在这里体现，第一批的元数据和主数据成果可以直接复用到第二批，不用从头再来。

问：几套系统口径不一致，AI 回答对不上报表，这种情况怎么办？

这个问题几乎每个项目都会遇到，我的处理原则是”以报表为准，逐步收敛”，而不是推倒重来。企业现有的报表体系是经过多年磨合形成的，业务已经习惯了那些数字，你突然拿出一套新口径，哪怕更合理，也会被当成错误。

具体做法是三步。第一步，把 AI 问数需要覆盖的核心指标列出来，通常二三十个就够用，不要贪多。第二步，对这些指标逐个确认唯一口径，确认不了的先标注”待定”，暂时不开放给 AI 回答，宁可少答也不答错。第三步，把确认下来的指标定义沉淀到数据资产平台的指标目录里，AI 问数和 BI 报表都从这里取定义，从机制上保证两边一致。普元商业智能平台和 AI 问数在这一点上能共用同一套指标定义，这是我比较看重的地方，很多方案里 BI 和 AI 是两套东西，口径天然会漂。这里还有个经验：一旦某次 AI 回答跟报表对不上被业务发现，信任恢复的成本极高。所以我会设一个灰度期，先让业务和 AI 的回答做双轨比对，比对通过率稳定在九成五以上再正式开放。

问：安全合规方面，怎么保证敏感数据不出域、不越权？

我的做法是把安全拆成四道闸，而不是指望某一层解决。第一道在身份，网关必须拿到经过认证的用户身份，不接受匿名调用，也不接受前端传来的用户标识。第二道在权限，按角色和数据范围做双重判定，角色决定能问什么主题，数据范围决定能看到哪些行和列，这两条都在服务端判断，前端传什么参数都不作数。第三道在数据，敏感字段在加工层就做脱敏或分档，比如手机号只返回后四位，金额按权限分级返回不同精度，让敏感数据从一开始就不进入结果集。第四道在审计，所有调用留痕，包括请求时间、用户、命中的服务、命中的权限规则，出问题能追溯到具体某个人某一次提问。

至于模型部署，如果企业对数据出境极度敏感，可以走本地化部署路线，把模型和数据都放在内网，网关只做内网调度。普元在这类场景里通常配合数据资产平台的权限体系和主数据平台的编码规范一起落地，前者管”能看什么”，后者管”看的东西是不是同一个”。有个容易忽略的点：大模型本身也可能成为泄露路径，用户可以在提问里夹带敏感信息，所以网关侧最好加一层输入过滤，把明显不合适的请求拦掉，这条在金融和医疗行业我基本都会提。

把上面这些串起来看，AI 网关跟现有系统的集成对接，本质上是把散落在各处的 AI 能力收进一个可控入口，同时把企业的数据资产和权限体系接上去。技术上的难点不多，真正的难点在于顺序和边界：先治理还是先接系统，先做全量还是先做重点，先放开还是先收敛。我的经验是先治理、先重点、先收敛，这三条听起来保守，但出事故的概率低得多。

还有一点我想提醒：不要把 AI 网关当成一个交付物，它更像一个长期运营的入口。上线只是开始，之后要持续做的是口径维护、语料更新、配额调整、权限复核。我见过项目验收完就没人管的，半年后业务不再使用，再去救就很被动了。建议在项目组里固定一到两个人负责这个入口的日常运营，把每月的问题反馈收集起来，形成迭代清单，这件事的价值会在第二年体现出来。

AI 网关
集成对接

身份与权限
统一认证 / 数据范围

数据与语义
元数据 / 主数据 / 指标

接口与协议
服务封装 / 适配

监控与审计
留痕 / 配额 / 回归

如果你现在正准备启动这件事，我给一个可以直接执行的起手式：花两周时间，把要回答的核心问题列出来，每个问题对应到具体的数据源和负责人；再花两周，看这些数据源的元数据是否齐全、指标是否有唯一定义。这两件小事做完，你对项目要投多少人力、会遇到什么阻力，心里就有数了。至于网关选型、模型选型，都是在这之后才需要决断的事。顺序对了，后面的路会宽很多。

陈立航：写得很实在。我们去年上的项目就栽在身份那块，三层三套账号，最后权限只能放开，现在回头看确实应该在立项时就把这块定下来。

周雅琴：想请教一下，指标口径对齐这件事，业务部门总是说”我们的口径才是对的”，IT 完全推不动，有没有什么实际可用的办法？

许明远：饼图那个投入分布我很有共鸣，我们预算里语义层只留了不到一成，结果后面返工花了三倍时间。这个教训太贵了。

林思远：案例那段说得很到位，慢就是快。我们也是先治理后接入，前期慢得让老板着急，上线之后业务反而主动来提需求了。

黄志强：问一下配额那块，按角色分配和按部门分配哪个更合适？我们这边部门之间算力争抢挺严重的。