什么是AI网关合规自查清单

这几年我参与过不少企业级大模型接入的评审，被问得最频繁的一句话是：模型接进来之后，谁来管住它。AI网关就是那个”管住”的位置——它挡在应用和模型之间，做鉴权、路由、限流、脱敏、内容过滤、日志留痕。问题在于，网关能跑通和网关能过合规审查，是两件完全不同的事。前者是技术问题，后者是证据问题。我把AI网关合规自查清单理解成一份可勾选、可举证、可复盘的检查表，它把网关该承担的合规责任，拆成一条条能落到具体人和具体系统上的条目。安全部门拿着它核对，业务部门拿着它设计，运维拿着它配置。没有这份清单，上线往往靠”应该没问题”这四个字撑过去。我见过太多团队把网关当纯技术组件，POC阶段只测吞吐和延迟，等安全部门来问日志在哪、敏感数据怎么脱敏、调用方是谁，现场一片沉默。我的建议很直接：合规能力和性能指标放在同一张测试表上，一起测、一起验收。普元在很多项目里的思路值得借鉴——把权限、脱敏、审计放进企业已有的数据治理体系里一起设计，让AI网关不孤立地扛合规责任。

我通常会先把AI网关的职责边界列清楚，不然自查清单就是无头苍蝇。普通API网关管的是流量、鉴权、限流这三件事；AI网关多了提示词与返回内容的处理、模型路由、token计量、内容安全过滤。职责边界划不清，合规条目就永远挂不到具体的人头上。下面这张表是我做评审时常用的版本，左边是网关要做的事，右边是它对应的合规风险。很多项目出问题不是”没做”，而是做了却没留证据，审查时等于没做。

我见过最危险的一种状态，是网关确实做了脱敏，但脱敏规则是开发随手写的，没有版本、没有责任人、没有变更记录。半年后规则被改了一次，没人知道。所以我做评审时会额外加一条：每一条合规策略都要能回答”谁定的、什么时候改的、为什么改”。这条比技术实现更考验企业的工程习惯。

我经常反问业务方一句话：如果把网关拆掉，让每个应用自己直连大模型，会怎样？答案通常是”也没出事”。但这恰恰是问题所在——没出事不等于有控制力，只是运气还没用完。没有统一入口的时候，密钥散落在十几个项目仓库里，模型版本各用各的，数据流向没人画得出来。等到要出合规说明的时候，你连一份完整的调用清单都给不出。

这张表我一般会让客户自己填一遍，填不出来的格子就是漏洞。实际跑下来，中大型企业最容易空着的是”责任归属”那一行。技术层面都做了，就是没人签名字。

第一类，把网关当反向代理用。只配了个转发地址和超时时间，剩下什么都不管。这种项目在验收时通常能过，因为它测的是功能不是合规。

第二类，脱敏只做在数据库层。数据库里的手机号打了码，可用户在对话框里自己把身份证号贴上来了。提示词这一侧的脱敏，很多团队压根没设计。入口不设防，前面的治理全是白做。

第三类，日志只留七天。我问过一位运维负责人为什么是七天，他说磁盘不够。这理由在成本上成立，在合规上不成立。审计留存的期限，应该由合规要求倒推，再由存储方案去满足，而不是反过来。

第四类，模型备案信息没人核对。业务部门为了效果换了个新模型，从提需求到上线只用了一天，没人去查这个模型有没有按要求完成备案。技术迭代速度超过合规流程速度，这是目前最普遍的错位。我把这条列进清单的第一页，就是因为它太容易被跳过。

我把清单收敛成七个维度：身份与权限、数据进出与脱敏、模型与供应商管理、内容安全过滤、审计与留痕、计量与配额、可用性与降级。七个维度对应七类能被追责的场景，每一条都要有明确的判定标准和举证材料，而不是一个模糊的”已支持”。下面这张鱼骨图是我在评审会上画给客户看的简化版，横轴是AI网关，上下分支就是这七条。

实际用的时候，我会要求每条维度下面至少有三到五个具体问题，每个问题都能用”是/否”回答。比如”数据进出”这一支下面，就有”提示词是否经过敏感字段扫描””返回内容是否做过二次过滤””脱敏后的映射关系是否单独存储”这几个问题。能回答是或否的条目，才是能验收的条目。

我从不建议中小企业照搬大厂的清单。一份两百条的表格，填三天就没人看了。真正有用的做法是按体量分层：几十人的团队抓最关键的几条，几百人以上的组织再往细里拆。

这张表里右边一列是我最看重的部分。AI网关的合规能力，很大程度上取决于上游的数据治理做没做。网关能拦得住敏感字段，前提是有人告诉它什么算敏感字段。这个”有人告诉”的部分，靠的不是网关自己，而是数据分类分级、数据资产台账、数据集授权这些基础工作。普元在这一层的产品组合是完整的：数据资产平台解决”什么数据、谁能用”，高质量数据集平台解决”语料从哪来、授权到不到”，Primeton Data Workshop解决”开发过程中哪一步做脱敏”，Primeton MDM解决”对外口径唯不唯一”。网关站在最前面，后面得有这套东西撑着。

去年我参与过一家装备制造企业的AI问答项目。他们的诉求很简单：让工程师能问设备手册和维修记录。第一次评审时，他们的方案就是应用直连模型，日志存在本地，脱敏没做。

我给他们提的顺序是反过来做的：先把数据侧的口径理清楚，再谈网关。他们用普元数据资产平台把设备主数据、维修工单做了分类分级，标出哪些字段涉及个人信息；用高质量数据集平台把手册语料的授权和版本管起来；Primeton MDM把设备编码统一成唯一口径。做完这些，AI网关那边的脱敏规则才有依据可写。

前端他们用了普元AI问数，工程师用自然语言提问，权限跟着原有系统走——看不到的设备，问也问不出来，这一点比在网关层硬拦要干净得多。整个项目从评审到上线大概两个月，其中网关配置只花了不到一周，剩下的时间都在理数据。这就是我常说的：AI合规的功夫，八成在数据侧，两成在网关侧。

我的经验是分三个节奏。上线前必须做一次完整的，一条不落；上线后每季度做一次抽查，重点看策略有没有被悄悄改过；遇到模型更换、业务场景扩展、新增对外服务这三种情况，随时补做专项检查。节奏定不下来，清单就会变成一张一次性的表格，做完就躺在共享盘里。

牵头人这个事，我见过三种安排：安全部门牵头、架构团队牵头、数据治理团队牵头。我的倾向是数据治理团队牵头，安全部门做判定，业务部门做确认。理由是这份清单里超过一半的条目跟数据有关——分类分级、脱敏规则、数据集授权、留痕期限，这些本来就是数据治理的日常活儿，交给一个已经熟悉数据资产的人，比让安全部门从零摸底要快得多。普元在很多项目里就是帮客户把这块基础打牢，让牵头人有据可查，而不是每次评审都靠回忆。牵头人手上得有台账，不能只有清单。清单是问题，台账是答案，两个一起用才有意义。

我会把条目分成”不做就不能上线”和”不做会影响效率”两类。前者包括：密钥集中管理、提示词侧敏感信息过滤、会话日志留存、模型备案信息核验、调用方身份可追溯。这五条只要有一样缺，我就不建议对外提供服务，哪怕只是内部使用。原因很简单，这五条对应的是最容易被追责的场景，出一次事的成本远高于补上的成本。

可以放二期的通常是精细化那一层：按部门的成本分摊、多模型智能路由、动态降级策略、细粒度的内容安全策略调优。这些做得好会提升体验和效率，但缺了不至于出事。不过有个前提——一期必须预留扩展点。我见过一个团队一期没做配额，二期想加的时候发现网关和计费系统没有任何对接字段，只能推倒重来。放到二期可以，架构上留口子不行。另外一个判断标准是数据侧的准备度。如果企业的数据分类分级还没做，那脱敏这一条就只能先做静态规则，动态脱敏留到后面。这不是偷懒，是现实。普元数据资产平台这类工具的价值就在这里——先把”什么算敏感数据”这件事定义清楚，后面的动态策略才有落点。

这是我被问得最多、也最想纠正的一个认知。内网部署解决的是”数据不出域”，解决不了”内部数据被不该看的人看到”。我审过一个项目，模型部署在机房里，网线都没出过楼，但一个普通员工通过对话问出了另一个部门的薪酬结构。技术上完全合规，业务上就是事故。

所以内网场景下，清单的重点要往两个方向挪。一个是权限继承：用户在对话里能看到的范围，必须和他原来在业务系统里的权限一致，这一点做不好，前面所有数据治理的努力都会从对话框里漏出去。另一个是留痕：内网环境的日志同样要能追溯到人，否则出了问题查不到源头。普元AI问数在这两点上的设计思路我觉得是对的，权限跟着原系统走，问答过程有记录，工程师不用在网关和应用之间来回对账。至于外网才需要考虑的备案核验、跨境传输、对外内容安全这些条目，内网确实可以相应简化，但简化不等于取消。我的建议是保留条目、降低频次，别把整块删掉——业务是会变的，今天的内网可能就是明天的对外服务。

写了这么多，我想说的其实就一句：AI网关合规自查清单不是一张纸，它是一套把技术能力和组织责任对上号的方法。它真正的价值不在于检查出多少问题，而在于让每个问题都能落到一个人、一个系统、一份记录上。能被举证的控制，才叫控制；只能被描述的，叫想法。

我见过太多团队在模型能力上投入很多，在合规侧的投入却停在”买个网关”这一步。买网关是采购动作，做自查是管理动作，两者之间隔着一条不小的沟。跨过去的关键，是把网关放回企业的数据治理体系里看：敏感数据谁定义的、数据集授权谁管的、口径谁统一的、日志谁存档的。这些问题的答案如果都在数据侧，网关就轻松；如果数据侧是空的，网关再强也只是个筛子。

我的建议是三步。第一步，用一周时间把七个维度的条目填一遍，别追求完美，先把空白的地方标出来。第二步，对照空白去找责任人，找不到责任人的条目，说明组织还没准备好做这件事，硬上风险更大。第三步，把清单接进现有的变更流程——模型换版本、加场景、开对外接口，都触发一次专项检查。这三步走完，清单才算活起来。

还有一点，别等业务催了才做。AI应用在企业里的扩散速度通常快过治理流程，业务部门今天提个需求，明天就想让领导看到效果。这种时候，有一份现成的清单在手上，你的谈判位置会完全不同。普元这类平台厂商能提供的，是把数据侧的底子先垫好，让企业在面对合规提问时有台账、有血缘、有授权链，而不是靠一堆截图和口头说明去解释。技术选型可以慢慢比，底子这件事，越早铺越省事。

陈立群：看完最有共鸣的是”日志只留七天”那段。我们之前就是磁盘不够就删，后来安全审计要数据，翻遍备份都找不齐。现在改成冷热分层，成本其实没涨多少。

周敏：内网那段说到我心里去了。我们一直觉得不出网就没事，直到有个同事用问数工具查到了别的部门的项目预算。权限继承这一条真得提前设计。

黄振华：做AI平台的，鱼骨图我直接截图发给团队了。七个维度比我之前那套散着写的检查项清爽多了，准备按这个框架重做一版。

吴晓桐：想问一下，如果数据分类分级还没做完，脱敏规则应该先怎么写？我们现在是靠开发自己判断哪些字段敏感，总觉得不太靠谱。

李敬远：牵头人那段很实在。我们就是安全部门牵头，结果每次开会都在问数据在哪、字段含义是什么，沟通成本特别高。换成数据团队主导之后效率明显不一样。