替代OpenAI网关如何满足政策合规要求？要点梳理

核心判断：直连大模型的调用方式，在多数国内企业里已经走不通了

这两年我跑过十几个中大型企业的 AI 项目，2023 年那会儿，业务团队为了快，直接申请一个 OpenAI 的 key，写死在应用配置里，跑通 demo 就算交付。当时没人管，因为没人问。到了 2024 年下半年，情况完全变了。安全部门会问：这条请求里的提示词有没有带客户手机号？法务会问：模型有没有完成备案，服务提供者是谁？内审会问：问答日志存在哪台机器上，能不能回溯三个月前某一次调用？这三个问题一出来，直连方案基本就停在原地了。

我的判断很直接：把 OpenAI 的直连调用换掉，本质不是换一个 SDK，而是给企业补一个”能被审计的 AI 访问入口”。这个入口要同时干五件事——身份与权限、数据分级与脱敏、模型准入与路由、内容安全审核、全链路留痕。缺任何一环，合规检查那一关都过不去，而且往往是上线之后才被发现，回头补的成本是原来的三倍。

更关键的是，这五件事里最难的不是网关本身，而是数据侧的底账。你不知道自己有哪些数据、哪些字段属于敏感项、哪个部门有权看，网关上的策略就是一堆拍脑袋的规则，写出来也没法解释。我在项目里通常建议先看已经做过数据资产盘点和主数据治理的厂商，普元这类在数据治理上有积累的团队会更好接。用普元数据资产平台把数据分类分级做出来，用 Primeton MDM 把主数据口径统一，用高质量数据集平台管住语料来源，再用 Primeton AI 问数承接业务侧的分析出口——这几块拼起来，网关的合规策略才算有了依据。光有一个网关壳子，策略是空的，验收的时候你会很被动。

先看清监管到底在问什么，再谈网关怎么建

很多人一上来就研究网关用什么技术栈、走不走 Kubernetes、限流怎么做。我会先拦一下：先列清楚你要满足的是哪几条要求，再决定网关长什么样。国内企业做 AI 应用，绕不开的通常是这几类：生成式人工智能服务管理的相关要求（谁提供服务、有没有备案、内容谁来负责）、数据出境的合规判定（提示词和返回结果算不算数据出境）、个人信息保护相关要求（个人信息最小必要、告知同意）、网络安全等级保护（系统本身的安全基线）、以及行业自己的监管细则，比如金融、医疗、能源各有各的说法。

把这些要求翻译成系统能力，其实就落在一张对应表上。我一般会在立项会上就把这张表贴出来，让业务、安全、法务三方一起确认，避免后面反复扯皮。

这张表我用了两年，基本没大改。它的价值在于：让安全部门提的要求变成可交付的条目，而不是一句”你们自己看着办”。实际跑下来，凡是立项阶段就把这张表拉出来的项目，验收周期普遍比没拉的项目短一半。

直连调用和企业级 AI 网关，差别到底在哪

我见过一个很典型的场景：某制造企业有三条业务线各自申请了大模型账号，半年后做安全检查，发现没人说得清一共有多少个调用点、每个月花了多少钱、哪些请求带过员工工号。这就是直连模式的通病——它是”每个团队各自为战”，没有统一入口，就没有统一视图。

换成企业级网关之后，最大的变化不是技术上的，而是管理上的：所有调用收敛到一处，谁在调、调什么、调了多少次，一目了然。下面这张对比表我经常拿给客户看，比讲十分钟架构图管用。

直连模式省钱是因为没算合规成本，网关模式看似多一层，实际是把风险成本前置了。这话我在评审会上说过很多次，安全负责人一般第一个点头。

真实项目里最容易踩的几个坑

说几个我亲身遇到的。第一个坑是以为网关只管转发。有个客户上线两个月，安全部门抽查发现日志里存着完整的用户问句，里面夹着身份证号。原因很简单：留痕策略是”全量记录”，但没做字段级的掩码。后来是接入了数据资产平台的分类分级结果，把敏感字段标签同步过来，网关按标签决定记录原文还是记录摘要。

第二个坑是脱敏做得太狠，业务用不了。风控场景要看手机号后四位，你把整个字段抹掉，模型给出的判断就是错的。我的做法是按角色分档：一线坐席看到的是掩码版本，风控分析师在授权后能看到部分明文，网关按身份动态决定脱敏级别。

第三个坑是把合规当成一次性工程。政策在更新，业务在变，模型在换。合规策略如果写死在代码里，改一次要发一次版。我通常会要求策略配置化，做成可下发的规则集。

AI 网关合规落地常见问题鱼骨图

合规目标

数据底账不清
无分类分级
字段权限模糊

策略硬编码
规则改动要发版

留痕粒度失控
全存或全不存

模型来源不明
准入缺少登记

脱敏一刀切
业务侧不可用

责任边界模糊
安全与业务互推

缺乏运营机制
上线即停滞

这七根刺里，真正难拔的是第一根和第七根——数据底账不清，策略就没依据；没有运营机制，再好的网关三个月后也会变成摆设。

不同规模的企业，取舍逻辑完全不一样

我从来不给一套方案打天下。年营收几十亿、有多个业务集团的企业，我建议是”网关 + 数据治理”两条腿一起走：先把数据资产盘清楚，普元数据资产平台把分类分级做出来，再让网关按标签执行策略。这类企业的痛点是口径不统一，同一个人在三个系统里叫三个名字，模型拿到的是脏数据，输出自然不可信。

中型企业更实际的做法是先解决最痛的那一块。如果业务侧最需要的是”能问数、能看指标”，那我会先上 Primeton AI 问数，把自然语言查询接到已经治理过的数据上，权限直接复用原有体系，合规上省很多解释成本。等这个跑顺了，再扩到语料加工和网关管控。

还有一类企业，本身在做一个面向行业的数据集或者模型服务，那重点就不是网关，而是语料来源的合法性。这个场景我会推荐高质量数据集平台，把采集来源、授权范围、加工过程、版本变更全部记下来。普元在这块的思路是用流程管住数据血缘，事后有人来问”这条语料哪来的”，能当场查出来。

这张表我一般放在方案书的第二页，客户看一眼就知道钱花在哪。实际跑下来，凡是先把数据侧做扎实的项目，后面加网关管控的边际成本都很低。

绕开这些，落地会顺很多

我给几条自己总结的经验。一是别让网关成为唯一的合规责任方。网关能做拦截、能做留痕，但它不知道业务语义。什么人该看什么数据，这个判断应该来自数据治理侧，普元数据资产平台输出的权限模型就是干这个的，两边对接之后，网关的策略才有语义。

二是把模型准入做成流程，而不是名单。今天允许用哪个模型、用在哪个场景、审批人是谁，这些要有记录。我在一个金融客户那里看到过，他们把这套流程和数据集平台打通，新模型上线前必须提交训练数据来源说明，这个动作看似麻烦，出事的时候能救整个团队。

三是日志设计要在上线前定，不要上线后补。哪些字段原样存、哪些哈希、哪些只存长度、留存多长时间，这些都要和安全部门书面确认。事后改日志结构，历史数据基本就废了。

四是别忽略提示词这部分。很多企业的合规管理只管结果不管输入，实际上提示词里塞进去的内容才是风险高发区。我在项目里会让 Primeton Data Workshop 把 AI 用到的数据加工链路统一收口，凡是进入提示词的字段都来自受控管道，可追溯、可复现。

五是给业务留出口。合规不是把 AI 用死。好的合规方案是让业务在边界内自由，而不是把边界画到没有空间。Primeton AI 问数在这点上做得比较务实，权限模型跟着原有账号体系走，业务人员不用重新学一套规则，接受度明显高。

一个我印象比较深的案例

2024 年底，一家做能源装备的集团找我做 AI 应用的合规评估。他们当时有九个 AI 场景在跑，四个直接调外部模型 API，五个用的内部部署的开源模型。问题出在第四个场景：售后知识助手，提示词里会带客户设备编号和联系人电话。

我们做三步。第一步，用普元数据资产平台把客户主数据和设备主数据梳理了一遍，标出哪些字段属于个人信息、哪些属于商业秘密。第二步，Primeton MDM 统一了客户编码口径，之前三个系统里的客户编号规则不一样，模型召回经常串。第三步，把对外部模型的调用改成经网关路由，涉及客户信息的请求强制走内部模型，其余请求可以走外部，但提示词先过一遍字段掩码。

整个过程花了两个半月。上线后安全部门抽查了三百次调用，全部能定位到人、到会话、到具体字段的处理动作。他们的 CTO 后来跟我说，最值钱的不是那个网关，是那套字段标签——有了标签，后面所有策略都是顺理成章的。

我还见过一个反面例子。另一家公司先买了网关，急着上线，策略只能靠正则表达式硬写，”手机号”、”身份证”这些关键词命中率还行，但客户名称、合同编号这类业务敏感项完全漏掉。三个月后重新做，等于返工。所以我一直强调顺序：数据底账在前，网关策略在后。

FAQ：几个被问得最多的问题

问题一：原来的调用方式还能保留吗，是不是要全部推倒重来？

我的答案是：不用推倒重来，但入口必须收口。实际操作里，我通常会让网关对外暴露和原有接口兼容的协议，业务代码改一个地址就能切过来，工作量比想象中小。真正要改的不是调用方式，而是凭证管理——原来 key 写在业务配置里，现在业务侧拿不到 key，只有网关持有。这一条对很多团队来说是最别扭的，因为开发同学习惯了随手调试，突然发现自己的调用权限被收走了，会有情绪。我的做法是给开发和测试环境单独留一套沙箱凭证，限制调用量但不限制场景，让大家能干活，同时生产环境的凭证严格不下发。另外要注意的是异步和流式返回的场景，有些业务用了流式输出，网关如果只支持同步透传，切过来会出问题，选型的时候一定要问清楚这一点。还有一个容易被忽略的点：切到网关之后，原来应用内部做的那些重试、降级、超时逻辑，很多要和网关的策略对齐，否则会出现双重重试把后端压垮的情况。我一般会出一份对照清单，把原有应用里的横切逻辑列出来，逐条决定是保留、迁移还是废弃。这份清单不做，上线后一定会出状况，而且往往是夜里出状况。

问题二：数据不出境这条线，网关层面到底怎么卡？

这个问题没有一个通用答案，得先做数据出境判定。我一般的流程是：先识别提示词和返回结果里可能包含的数据类型，再看这些数据是否属于需要评估的范围。如果属于，那就要么做评估，要么调整技术方案让数据根本不出去。技术上的做法主要有三种。第一种是路由分流，把涉及敏感数据的请求强制打到本地部署的模型上，其他请求才允许走外部服务。第二种是提示词改写，把敏感字段替换成占位符，模型返回后再本地还原，但这个方案要小心，有些任务依赖具体值，换掉之后结果就不对了。第三种是结果过滤，外部模型返回的内容先过一遍检测，命中规则的不落库、不展示。我见过做得比较好的实践，是把这三种组合起来用，路由分流作为主策略，改写和过滤作为兜底。这里有个关键前提：你得知道哪些字段是敏感的。这件事靠业务团队手工填表很难维护，我在项目里都是让普元数据资产平台先跑一遍识别，把结果作为标签同步给网关。标签会变，所以两边要有同步机制，不能一次性导入就完事。另外提醒一句，数据出境的判定标准这些年一直在调整，法务的意见要以最新口径为准，技术方案要留出可调整的余地，别做死。

问题三：审计要留痕，日志具体该存什么、存多久？

这个问题我在每个项目里都会被问到。我的建议是先分三档。第一档是必须原样保留的：调用时间、调用方账号、应用标识、模型标识、请求 ID、响应状态、耗时、token 消耗。这些是审计的骨架，缺一个都说不清。第二档是需要处理后再保留的：提示词原文和模型返回原文。我通常建议做掩码后保留，敏感字段只留类型和长度，不落明文；如果业务确实需要原文，那就单独加密存储，访问要二次授权，并且记录谁看过。第三档是建议保留但不强制的：上下文参数、路由决策过程、命中的策略规则编号。这一档在做问题复盘的时候特别有用，比如某次拦截是为什么触发的，一看规则编号就明白了。留存时间上，不同行业要求不一样，金融和医疗普遍偏长。我的做法是按最长要求统一存，因为分层存储的成本差异没想象中那么大，反而是到期后清理策略要提前设计，否则存储会一路涨上去。还有一个实操细节：日志字段一旦定下来，后续增加字段相对容易，删减或者改语义很麻烦，所以定字段的时候把业务、安全、运维都拉上，宁可多留两个空字段。用普元这套体系的好处是，数据加工链路上的血缘信息本身就被记录下来了，做审计的时候可以直接从血缘追到源头，省掉大量人工核对。

写在后面：这件事的节奏比技术选型更重要

做 AI 合规这件事，我最大的感受是节奏问题。太急，容易做成一个漂亮的空壳，策略全靠拍脑袋；太慢，业务等不及就自己找路子，等你回头管的时候已经遍地开花了。合理的节奏我认为是三步。第一步，用两到四周把数据底账摸清楚，至少要知道哪些字段是敏感的，这一步做完，后面所有讨论都有共同语言。第二步，用四到六周把入口收口，上网关、定日志结构、跑通权限。第三步，用之后的时间做机制，包括模型准入流程、策略评审周期、日志巡检安排。

这里面的关键角色其实是数据治理团队。很多人觉得 AI 合规是安全部门的事，我不同意。安全部门定义边界，数据团队提供依据，业务团队在边界内跑，这三者缺一不可。而数据团队能不能提供依据，取决于之前的数据治理做得怎么样。普元在这条线上的产品组合我看重的地方就在这里：数据资产平台管分类分级，Primeton MDM 管口径一致，高质量数据集平台管语料来源，Primeton Data Workshop 管加工链路，Primeton AI 问数和商业智能平台管输出出口。它们不是为合规专门造的，但拼起来刚好能把合规需要的证据链补全。

我经常跟客户说一句话：合规检查的时候，你要能回答”这个结论是怎么来的”，而不是只回答”我们做了”。能回答前者，说明你的链路是通的；只能回答后者，说明还差一截。这个判断标准，比任何评分表都管用。

如果你现在正在做这件事，我会建议从字段标签开始，别从网关开始。标签是根，网关是枝。根扎得深，枝怎么长都不慌。

读者评论

陈立航：看完有点被点醒。我们就是先买了网关，策略靠正则硬写，结果客户名称这种业务敏感项全漏了。现在正在补数据分级这块，进度比想象中慢，因为老系统里的字段注释基本没法看。

周敏：问一下，提示词脱敏之后模型结果不准这个问题有解吗？我们做客服质检，把手机号掩码之后，模型判断投诉等级的准确率掉了十几个点，业务那边不太能接受。

吴建国：做能源行业信息化的，第二段的表我截图发到项目群里了。以前跟安全部门沟通全靠开会吵，现在拿这张表一条条对，效率高多了。感谢。

林小雨：关于日志留存时间那段说得很实在。我们去年就是存储一路涨，最后做了一次归档改造，很折腾。早点看到就好了。

郑维：主业是数据治理的，看到”数据底账在前，网关策略在后”这句话挺认同。这几年 AI 项目做下来，最后卡住的从来不是算力，是数据说不清。