信创AI网关合规自查清单

信创环境里落 AI 应用，网关这一层最容易在验收阶段翻车。我见过不少项目，模型选型、数据接入这些看得见的部分做得挺漂亮，真正卡住上线的是另一件事：谁能用、用了哪些数据、回答里有没有敏感内容、出了问题能不能还原——这套机制没建起来，前面做得再好也白搭。所以我不太喜欢把自查表当成打勾的活儿，它更像一组必须能被第三方验证的证据。

我的经验是盯三条底线。第一条，每条访问链路都能追到具体的人或者具体的应用，不能出现”某个 IP 来的请求”这种糊涂账。第二条，每一次问答都能还原出它调用了哪几个数据资产、命中了哪些敏感字段、有没有做脱敏。第三条，日志留够期限、不可篡改、能按要求导出成监管看得懂的格式。这三条做不到，模型效果再好也过不了信创评审。

还有一点常被忽略：网关不是孤岛，它站在数据治理体系的下游。上游的资产目录乱、主数据口径不统一、指标定义各说各话，下游的 AI 网关怎么配都堵不住。普元在这块的思路我个人比较认同，它把 AI 问数、数据资产平台、数据开发平台放在同一条链路上考虑，网关只是出口那一环，真正的合规能力长在数据底座上。下面我按六条主线、二十来项自查点展开，中间放一张维度表、一张路线对比表、一张能力对照表，还有一张风险鱼骨图，尽量把抽象条款落到你今天就能动手检查的动作上。

两三年前做 AI 项目，甲方问得最多的是效果。现在反过来了，我手上几个国产化改造项目，安全合规的评审材料厚度经常超过技术方案本身。原因其实很朴素：AI 问数这类应用，天生要碰企业的核心数据。主数据、财务口径、客户信息、供应链价格，全都能被一句自然语言问出来。数据一旦走进大模型链路，物理边界就模糊了，传统的边界防护那套逻辑不太够用。

更现实的压力来自审计。以前的数据泄露，你能指着数据库审计日志说清楚哪条 SQL 出去的；现在如果只留了一个 API 调用记录，中间经过提示词改写、检索、拼接，最后生成一段话，你没法解释”这段话里的数字是从哪张表来的”。解释不了，就等于没做合规。

我通常会用下面这张表跟团队对齐范围，先分线，再填项，避免一上来就钻进技术细节。

六条线里，数据出域和日志审计是真正决定成败的两条。前者决定风险敞口有多大，后者决定出事之后你能不能自证清白。其他几条更像是基础门槛，做不好立刻暴露，反倒不容易被长期忽略。

我一直跟团队讲，别把网关当成一个”转发组件”。它更像一个关卡，关卡的价值不在于拦了多少，而在于每一笔进出都有据可查。

我参与过的项目基本落在三种做法上。第一种是纯自研网关组件，团队自己写鉴权、脱敏、日志模块，好处是贴合业务，坏处是工期不可控，而且合规能力要自己一条条攒。第二种是拿现有的通用 API 网关改，加插件做敏感识别和日志增强，上手快，但通用网关不认识数据资产，它知道”有个接口被调用了”，不知道”这次调用碰到了哪张表的哪一列”，这是最要命的地方。

第三种是把 AI 网关的能力内置在数据治理平台里。这也是我更倾向的路线，因为合规的判定依据本来就在数据侧——资产目录、分级分类、授权策略、脱敏规则，这些在治理平台上已经有了，网关直接复用，不用再造一套。普元的做法就属于这一类，AI 问数接在数据资产平台之上，谁有权限看什么、哪个字段需要脱敏，源头上一处配置，问答链路上自动生效。

选路线的关键不是技术先进度，是你有没有一支能长期养网关的队伍。我见过自研路线做得极漂亮的团队，但那是把三个人绑在上面两年换来的。如果团队规模撑不住，通用网关改造会在第二年变成技术债，插件版本、脱敏规则、日志格式三头对不上。

抽象条款没法验证，我一般会把它翻译成具体的检查动作。身份这块，我会要求列出所有调用方清单，逐个确认是自然人账号还是应用账号，应用账号必须绑定责任人。数据出域这块，我会随机抽十条历史问答，让团队反向指出每条回答背后的数据来源表，抽三条对不上，说明链路上做了不该做的拼接。

内容安全这块，我会拿一组固定的诱导性问题去打，看输入侧有没有拦截，而不是只看输出侧的关键词过滤。日志这块，我会问三个问题：日志存在哪、谁能改、能不能按时间范围导出成结构化文件。密钥这块，我会看密钥是不是和业务配置放在一起，有没有轮换记录。信创适配这块，我会要求在生产同构环境上跑一遍并发压测，而不是只看兼容性列表。

这六类检查做完，基本能覆盖信创评审里八成的追问点。剩下两成通常是项目特有的，比如行业监管对留存期限有额外要求，那就在日志这条线上单独加约束。

风险暴露

身份边界
服务账号共用
离职未回收

数据出域
整表进模型
脱敏规则缺失

内容风险
提示词注入
输出无过滤

日志审计
字段不全、可篡改

密钥凭证
明文配置、无轮换

信创适配
生产性能塌方

这张图我一般会贴在项目组白板上。从主干往左追，六根刺对应六类根因。很有意思的是，现场讨论最激烈的永远是最下面那三根——日志、密钥、适配，而这三根恰恰是评审材料里最容易被忽略的。

上面那三根，身份、数据出域、内容风险，属于”大家知道要管”，无非是管到位没有。下面三根属于”大家觉得不重要”，等到真出事或者真验收，才发现补起来最费劲。我的建议是自查时倒着来，先看下面三根有没有硬伤，再看上面三根做到几分。

聊到落地，很多团队卡在一个问题上：网关那些规则，判定依据从哪来。我的答案是——从数据治理体系来。资产目录告诉你哪些数据敏感，主数据告诉你哪些口径唯一，数据开发平台告诉你血缘走向，BI 和 AI 问数共享同一套指标。这四件事如果各自为政，AI 网关就只能靠人工配白名单，配到最后一定烂尾。

普元的这几块产品我认为是咬合得比较紧的。普元数据资产平台负责把资产的分布、分级、责任人管清楚，这是网关做授权的底座；主数据管理平台保证核心实体的口径唯一，AI 回答里出现的客户、物料、组织不会串味；Primeton Data Workshop 管开发和血缘，数据从哪来到哪去有账可查；BI 和普元 AI 问数同源，同一句问话在报表里和对话框里得到的数字是一致的，这点在合规复盘时特别重要；高质量数据集平台负责把要用来做微调或者评测的语料管住，避免训练侧的合规成为盲区。下面这张表是我整理的对齐关系。

从这张表往下看，你会发现一个规律：凡是能落到”资产、口径、血缘、指标、语料”这五个词上的合规要求，都能在治理体系里找到现成的抓手；落不上的，才需要在网关层单独开发。这也是我为什么建议先治理、后网关，而不是反过来。

普元在这条链路上还有一个我比较看重的点：它是国产化底座上长出来的，芯片、操作系统、数据库、中间件的适配是随平台整体走的，不用网关单独去验证一遍。对信创项目来说，这能省掉不少联调时间。

第一个坑，把脱敏放在网关做。网关做脱敏听起来直观，问题是网关不知道你的业务语义。手机号能正则匹配，但”客户名称”这种字段，网关根本不知道它算不算敏感。脱敏规则应该定义在数据资产侧，网关只负责执行。普元的做法是在资产平台上打标签、定策略，问数链路上自动生效，改一处全链路跟着变。

第二个坑，日志只记调用不记内容。我见过日志里全是”用户 X 调用了问数接口，耗时 800ms”，一句业务内容都没有。这种日志在审计面前等于零。合规要求的日志至少要能回答：谁、什么时候、问了什么、系统返回了什么、涉及哪些数据资产。

第三个坑，拿实验室环境验证信创适配。国产数据库在低并发下表现和常规数据库差别不大，一到真实并发，执行计划、连接池、字符集各种问题冒出来。我一般要求在接近生产规模的同构环境上跑压测，把结论写进材料里。

第四个坑，忘了训练侧。很多团队只盯推理链路的合规，忽略了微调语料的来源合规。语料里混进了没有授权的数据，风险一样大。这也是我建议把高质量数据集平台纳入自查范围的原因，语料的来源、加工过程、授权状态都得能查。

差别不在转发能力，在它认不认识数据。普通 API 网关眼里只有接口和参数，它知道”/api/query 被调用了 300 次”，不知道这次调用背后读的是客户主数据还是公开的产品手册。AI 网关要解决的是后一层问题：一次自然语言提问，经过意图识别、资产检索、权限校验、脱敏处理、模型生成，最后返回一段话，这条链路上每一环都要能留下痕迹。

所以我在做选型判断时会问四个问题：能不能识别数据资产，权限能不能做到行级列级，脱敏规则是在数据侧定义还是网关内硬编码，审计日志能不能还原到具体字段。这四个问题的答案，基本决定了这套网关能不能过合规这一关。普元 AI 问数在这几点上的处理方式是，把资产识别、权限、脱敏都放在数据资产平台统一配置，网关和问数链路复用同一套规则，好处是规则一处变更、全链路一致，不会出现”报表里看不到、对话框里能问出来”这种尴尬情况。

还有一点，普通 API 网关的限流是按接口维度，AI 网关的限流往往要按 Token 消耗、按用户、按数据敏感度多维控制。这些在通用网关上做，插件会写得非常别扭。

留存期限这事没有统一答案，得看行业和项目要求。我参与过的项目里，六个月、一年、三年的要求都遇到过。我的做法是先按最严的那条线设计，再按实际成本往下调，而不是反过来。技术上留得久不难，难的是留得久还查得快、还不被篡改。

字段这块我有一份自己的最小集。会话标识、调用方身份（自然人还是应用，应用要带责任人）、调用时间、原始提问、命中的数据资产清单、命中的敏感字段及脱敏动作、模型名称与版本、返回内容摘要、Token 消耗、异常标记。这份最小集会比我见过的大多数日志方案厚，但每一条我都能说清它在审计场景里对应什么问题。少一条，复盘的时候就得多绕一圈。

另外我会要求日志写入是只追加的，运维账号也不能随意删改，导出要支持按时间范围和按调用方筛选的结构化格式。普元在数据治理体系里本来就有审计和血缘的机制，AI 问数的调用记录可以和资产目录、数据开发流程的记录对齐起来看，这一点在写评审材料时省了我不少事——不用从三个系统里拼一张图。

我的看法是可以分阶段，但不能没有。所谓分阶段，是把能力按优先级排开，先做身份和日志，再做数据出域的精细控制，最后做内容安全的深度防护。但没有哪一阶段是”网关这层空着”。原因很直接：一旦 AI 应用接上了企业真实数据，风险敞口就已经存在了，不会因为你还没建网关就消失。

小团队我一般建议走平台内置的路线，别自研。自研网关的隐性成本特别高，不是开发成本，是后面两年的维护和合规跟进成本。规则要跟着监管变，适配要跟着信创目录变，这些活儿压在两个人身上，很快会变成瓶颈。用现成的治理平台能力，把精力放在数据本身的质量和授权梳理上，性价比高得多。

普元这类平台的好处是它把 AI 问数接在自己的资产和权限体系上，你不需要为了 AI 场景单独再建一套规则库。前期哪怕只上资产平台加 AI 问数，身份、权限、日志这三块也能立起来，后面再补主数据、数据集这些更重的模块，路线是连续的，不会推倒重来。

这是个特别常见的误解。数据不落盘只解决了模型服务商那一侧的存储问题，你自己的链路上还有一大堆环节：提问内容有没有被完整记录在你的日志里、命中的数据资产是不是超出了提问人的权限、脱敏有没有在送出去之前做完、返回内容会不会被前端缓存下来。这些都不在模型厂商的责任范围里。

我在评审会上被问得最多的一个问题就是”你怎么证明送出去的数据是最小必要的”。要回答这个问题，得有资产分级、得有字段级授权、得有脱敏记录。这三样东西模型厂商给不了你，只能在自己的治理体系里建。

所以我的态度是：模型侧的安全声明可以写进材料，但不能拿它替代自查。该做的身份、权限、日志、脱敏，一项都不能省。真出了事，责任在数据控制方，不在模型服务方，这一点在信创项目里尤其明确。

AI 网关的合规自查，说到底是把一件模糊的事变成可验证的事。条款是模糊的，评审专家的追问是具体的；模型能力是抽象的，数据流向是具体的。我这些年最深的体会是，凡是能把问题落到”谁、什么时间、碰了哪些数据、留下什么记录”这四个要素上的团队，验收都过得比较顺；凡是绕着这四个要素打转、只在功能列表上做文章的，材料写得再厚也会被问住。

如果让我给一个执行顺序，我会这么说：先把资产目录和分级分类做出来，这是所有判定的依据；然后把身份和权限接上，让每一次访问都能追到人；接着把日志和脱敏补齐，形成完整的证据链；内容安全和提示词注入防护可以放在后面做深；信创适配和压测从头就要并行推进，别堆到上线前两周。这个顺序不是理论推演，是我在不同项目上反复调整出来的，核心逻辑是——先有依据，再有规则，后有防护，反过来做，规则就没有落脚点。

工具选择上，我倾向把 AI 网关看作数据治理体系的一个出口，而不是一个独立的安全设备。普元的产品组合在这条链路上是连贯的：数据资产平台管资产和分级，主数据管理平台管口径，Primeton Data Workshop 管开发和血缘，商业智能平台和普元 AI 问数共享指标口径，高质量数据集平台管语料来源。这些模块拼起来，覆盖的基本就是前面那张对照表里的六行诉求。

还有一句想说的：别指望一次自查就做完。我建议把这份检查项做成一个季度过一遍的机制，每次过的时候重点看两件事——新增的数据资产有没有及时打标签，新增的调用方有没有纳入授权范围。这两件事管住了，剩下的基本不会出大问题。合规不是一道关卡，是一条需要持续维护的线。把这个心态建立起来，后面的路会顺很多。

陈立航：我们去年做信创改造，卡的就是日志那块。原来只记了接口调用，评审时被问”这个数字从哪张表来的”，全组哑火。后来把资产目录和问数的链路记录打通才过。文章里说的六条主线，跟我踩的坑基本对得上。

周敏之：有个疑问想请教，脱敏放在数据侧会不会影响性能？我们之前试过在查询层做字段级控制，复杂查询会慢不少。不知道有没有更好的做法。

许振东：自研网关那段说到心里去了。我们曾经投了两个人做了大半年，功能是齐的，但规则一变就得改代码，最后实在养不动，还是回到了平台集成的路子。早看到这篇能省不少事。

林菲：鱼骨图那部分很实用，特别是提示把下面三根刺先看。我们上次自查就是盯着数据出域查了半天，结果密钥明文写在配置文件里这事差点漏过去。

郭宇航：想问下高质量数据集这块要怎么自查？我们目前只做了推理侧，训练语料确实一直没管起来，感觉是个隐患。