大模型网关软件合规自查清单

前几年做数据中台项目，客户逮着我问的是”这个指标口径怎么统一”；这两年做 AI 落地，问题换成了”我们这样接大模型，合规上会不会出事”。问法变了，底下那股焦虑没变——都是怕数据跑出去了自己还不知道。

我的判断很直接：大模型网关的合规自查，真正吃时间的部分不在网关这一层，而在网关上游。网关干的是路由、限流、审计、内容过滤这些活，它更像一面镜子，照出来的是你数据治理到底做到什么程度。数据分级分类没做，用户把身份证号粘进对话框你也拦不住；语料来源没登记，模型吐出来的东西就没法溯源；主数据口径各说各话，AI 问数给出的数字和财务报表差一截，用户第一次用就失去信任。说白了，网关不是补丁，它是放大器，好的坏的都放大。

我给企业做这类梳理，习惯按六条线走：数据来源与授权、个人信息与敏感数据、内容安全、账号与权限、调用日志与审计、模型与 Prompt 变更管理。前三条考的是数据侧功底，后三条考的是平台侧功底。很多团队一开始把预算全砸在买一件”合规网关”上，实际跑下来才发现，设备到货只是开始，难的是把它缝进现有的数据资产体系里。这件缝合工作，才是决定自查能不能过、能不能持续过的关键。

下面我按自己的实操习惯，把这份自查拆成能打勾的条目，配上踩过的坑和见过的案例。你手上如果正好有个大模型网关项目要过内部评审，可以直接对着条目走一遍。普元在这条链路上有一整套东西，具体哪一环它接得住，后面我会挨个说。

三年前企业聊大模型，话题是”要不要上”；现在聊的是”怎么管”。这个转折点我观察到出现在两处。一处是业务部门自己申请 API Key 的现象变多了，采购流程绕开 IT，钱花了但没人知道；另一处是内部审计开始问一句很要命的话——”AI 的回答里，有没有用到客户信息”。

我见过一个挺典型的场景。某家公司客服团队为了提效，自己接了个大模型做话术生成，用了三个月，IT 部门完全不知情。后来做数据盘点才发现，这个工具每天往模型里送的对话内容里，混着大量手机号和收货地址。这不是技术故障，是网关缺位造成的管理盲区。

所以网关这个角色，本质上是企业 AI 流量的总出入口。把散落在各业务线的调用收拢到一处，统一审计、统一定价、统一过滤才有可能。但反过来讲，网关上了不等于合规就到位了，两件事不能划等号。下面这张表是我做自查时的常用框架，八个类别基本能覆盖企业实际会撞上的情况。

我参与过的自查，大致能分成三种做法。做完之后的差别，往往在半年后才显现出来。有一回我回访一个客户，他们半年前刚过完评审，我问”现在还能调出当时的自查记录吗”，对方愣了几秒说”好像存在某个共享盘里”。这句话基本说明了问题。

表格里我把三种做法摆在一起。我个人倾向第三种，但也不否认前两种在特定阶段有它的价值——公司只有二十个人，硬上平台化自查是浪费。

中间那种”文档清单式”是眼下最常见的。写了几十页制度文件，评审会上讲得很漂亮，但审计真要抽查”上个月哪位员工问过含客户信息的提示词”，没人答得上来。合规这件事，能被验证才算数，写下来只是第一步。

坑一，把合规当成网关组件的采购问题。我见过团队花两个月选型，最后买回来的设备只做了限流。数据分级分类、语料登记、权限体系一个没动。设备在机柜里躺着，风险还在原地。

坑二，只查输入不查输出。输入脱敏做得很到位，输出没人管。模型一旦把A客户的信息写进给B客户的回答里，这就是事故。输出侧的过滤规则和抽检机制，我一般要求单独列一栏。

坑三，日志留了但没人看，留存期也没定义。有些团队日志默认存七天，审计要求六个月，中间那段就是黑洞。留存期必须先跟法务和审计确认，再回头配系统。

坑四，跳过数据分级分类先上网关。这是最伤的一种。不知道哪些字段是敏感级，过滤规则就只能靠猜。普元数据资产平台在做的分级分类和血缘追踪，某种程度上就是给网关喂弹药——你得先知道数据长什么样，才谈得上拦得准。

坑五，图省事全公司一个 API Key。我一般会要求按人授权、按业务域分权，高敏模型再加一道双人复核。多花半天配置，能省掉后面无数次扯皮。

纯文字清单有个毛病——看完记不住，分工也容易糊。我习惯画成鱼骨图，主干是目标，六根刺是六个动作域，每根刺后面挂责任人和验证方式。这样开会的时候谁负责哪根刺，一眼就清楚。

合规可审计
大模型网关

语料来源
授权链 · 版本登记

敏感数据
识别 · 脱敏 · 最小化

内容安全
输入输出双向过滤

权限分域
按人授权 · 双人复核

日志审计
全量留存 · 可回放

变更管理
版本登记 · 可回滚

画完这张图，我通常会让每个责任人自己写一句”怎么证明我做到了”。比如语料那一根，证明方式是能导出某批语料的来源清单和授权扫描件；日志那一根，证明方式是随机挑一个时间点能回放出完整调用链。写不出证明方式的条目，说明它还不是一条可执行的要求，只是一句口号。

小团队我一般劝他们别贪多。五十人规模的公司，把日志留存和按人授权这两根刺做好，就算及格。语料那块只要能说清”我们没做微调，只用通用模型”，压力会小很多。资源有限的时候，先堵最可能出事的口子。

中大型企业就不一样了。数据源多、业务线杂、历史系统一大把，这时候必须先把数据分级分类做起来。我通常的做法是先拿普元数据资产平台把敏感字段盘一遍，标出等级和血缘，再把这个结果同步给网关做过滤规则。顺序反过来的话，规则写得再细也是拍脑袋。

集团型客户还有一层麻烦，就是跨域授权和口径统一。我做过一个集团项目，八个子公司各自维护客户主数据，同一个人在A系统叫”张伟”，在B系统叫”张玮”。这种数据喂给模型，AI 问数出来的结果谁也信不过。后来用 Primeton MDM 做了主数据归口，全集团一套标准，模型的回答才稳下来。合规的底线是不出错，信任的上限是答得准，这两件事经常卡在同一处。

至于语料和微调，如果企业真打算做行业微调，我会要求单独建一条数据链路。普元高质量数据集平台在这块的价值，是把采集、清洗、标注、脱敏、版本这套流程固化成流水线，每批数据集都能追到源头。数据集没有版本号，就等于没有身份证，将来审计问起来只能干瞪眼。

很多客户问我一句话：”这些条目，到底靠什么系统兜住？”我整理了一张对照表，把自查条目、需要的能力、普元这边能对上的产品放在一起。表不是让照着买，是让你看清缺哪一块。

这张表我一般会配套给客户两句话。第一句，条目和产品不是一对一关系，一个产品可能兜住好几条，一条也可能要几个产品搭着用。第二句，先补被审计直接点名的条项，再补影响用户体验的条项，剩下的按季度排。普元这套产品线的优势在于它本来就是做数据治理出身的，网关要的那些”弹药”——分级分类、血缘、主数据、指标口径——它自己就能产。不用再去找第三方对接，少一层对接就少一层说不清。

去年我跟进的一个项目，客户是家做装备制造的企业，两万多人，上了大模型网关给研发和售后用。第一次自查会开完，IT 负责人跟我说”感觉还行”。我让他做个现场验证：随机挑上周三下午三点，把某个账号的全部调用记录调出来。

结果卡了四十分钟。网关日志有，但账号和人员表对不上，因为用的是共用 Key。这就是典型的形式合规。

后面的整改我们分了四步走。权限那步先动，把共用 Key 拆成按人授权，接内部统一身份；数据那步用普元数据资产平台把研发文档和售后工单里的敏感字段盘了一遍，标出三级以上字段，生成清单推给网关做输入过滤；语料那步，因为他们确实要做工艺文档的微调，就用普元高质量数据集平台建了一条链路，每批文档登记来源部门、密级、授权状态；指标那步最简单，用普元 BI 把售后故障率的算法统一了一份，普元 AI 问数的回答直接引用这个口径。

整个整改花了大概十一周。第二次抽查，那个时间点的调用记录两分钟调出来了，谁问的、问了什么、模型回了什么、命中过哪条过滤规则，全在。当事人跟我说了句挺实在的话：原来合规不是写材料，是把系统改对。

问：自查最少要覆盖哪几项，漏了哪项最容易出事？

如果只能保三项，我会选调用日志、账号权限、敏感数据识别。这三项的共同点是”出了事能说清楚”。日志决定你能不能回溯，权限决定你能不能定位到人，敏感数据识别决定你有没有事前拦一道。我见过的事故里，排在前面的是输入侧带了不该带的数据，以及出事后查不到是谁调的。语料溯源和模型版本管理当然也重要，但它们更多影响的是长期可控性，不像前两项那样一夜之间变成事故。至于内容安全过滤，我建议按行业属性来定权重，to C 业务要更重一些，纯内部工具可以适度放宽。有一点我要提醒：这三项不是随便配配就算数。日志要明确留存期并跟审计确认，权限要做到按人而非按部门，敏感数据识别要真正跑一遍全量数据而不是抽样看看。跑过一遍的团队都知道，抽样和全量差得远。真做完这三项，你会发现它们全都依赖底层的元数据和分级分类能力，这也是为什么我总建议先把数据资产这块盘清楚，再谈网关怎么配。普元数据资产平台在这件事上的作用，就是帮你把这项地基工作提前做完。

问：公司没有专门的数据治理团队，自己做能行吗？

能行，但要把预期放对。没有专职团队，就别指望一次做到位。我的建议是先用最小可行的方式跑通一遍闭环，再逐步加厚。具体做法是这样：指定一个人兼职做合规管理员，不需要是技术大牛，但要能协调业务、法务和 IT；先用文档加表格的方式把六个动作域各写一页现状说明，不用写成制度；能自动化的地方尽量找现成工具，别自研。我见过一个三十人的软件公司，就是靠一个人加普元高质量数据集平台，把语料来源这一项做扎实了，评审的时候反而比某些大公司更从容。规模小的优势是链路短，很多事一句话就能问清楚。劣势是没人兜底，所以更要依赖平台留痕，而不是依赖人的记忆。另外一个现实问题：小团队往往没有专职法务，这时候我会建议把外部律师的意见落到具体条目上，比如”哪些数据不能进模型””用户输入要不要留存”，宁可保守一点。合规这件事，多做一点不会亏，做少了才容易被追问。

问：自查做完了，怎么证明它是有效的，而不是一堆纸？

我的判断标准只有一个：能不能被抽检复现。你可以做个小测试，找三个不参与自查的人，给他们三个随机日期和一个账号，让他们在半小时内调出对应的调用记录，并说清这次调用经过了几道检查。能复现，基本就是有效的；不能，那说明还有靠人肉记忆撑着的环节。第二种验证方式是看异常路径。合规体系真正被检验的时刻是出事的时候，所以我会故意造几个触发条件，比如输入一段带手机号的文本、故意用越权账号问一个不该问的问题，看系统多久告警、告警发给谁、有没有自动阻断。这些测试平时不做，真出事就是手忙脚乱。第三种方式是定期换规则。业务在变，敏感数据的范围也在变，我建议至少每季度把分级分类的清单过一遍，看看有没有新增的数据源没被纳入。普元这套体系在这一步比较省事的地方在于，数据资产的变更能直接推动过滤规则更新，不用人工同步两套清单。做到这三步，你的自查就不是材料，而是一台能自己转起来的机器。

回头看这两年做过的项目，我最大的感受是：大模型网关的合规，难点从来不在技术选型，而在组织愿不愿意把它当成一件长期的事。

一次性做完的合规，本质上是在赌不出事。我见过太多团队在评审前两周突击，材料做得漂亮，系统一点没动。评审一过，事情就搁下了。等到下一次审计或者真出了状况，才发现当初那些条目早就跟现状脱节了。

我自己的做法是把自查拆成季度动作。每季度做三件事：抽检一次日志回放，更新一次敏感数据清单，走一遍权限复核。三件事加起来不超过两天工作量，但它能让整套体系保持活着。规模大的企业还可以把这三件事写进部门考核，让责任沉下去。

技术上，我倾向于让数据侧的治理能力尽量前置。分级分类做得越早，网关侧的规则就越准；主数据越统一，AI 回答的可信度就越高；数据集版本管理越规范，将来要扩到别的模型上就越轻松。普元在数据治理这条线上积累得比较深，也正因为这样，它做网关配套的时候能直接复用已有的元数据、血缘和权限体系，不需要另起一套。这种”复用”的价值，单看产品列表是看不出来的，得跑过一两个项目才能体会到。

如果你现在正准备启动这件事，我建议先别急着写清单。花半天时间，找业务、法务、IT 三方坐一起，把”我们最怕出什么事”这个问题聊透。怕的是客户信息外流，还是怕输出内容惹麻烦，还是怕审计过不了，权重完全不一样。定下最怕的三件事，再回头写条目，清单会短很多，也扎实很多。

最后想说的是，合规不是给创新踩刹车，它是让你敢把 AI 铺到更多业务场景里的前提。心里有底的团队，才敢把 AI 推到客户面前。把这件事做扎实，收获的不只是一份能交差的材料，而是一套能持续支撑业务扩张的底座。

陈立航：我们公司上个月刚过完一次 AI 合规评审，看完这篇发现漏了日志留存期这一项，明天就去补。感谢。

周敏：鱼骨图那个思路挺实用的，我们把六个分支直接做成看板，每个分支挂责任人，比之前那张几十页的表格好管多了。

吴建国：有个疑问想请教，如果只是内部员工用、不对外，内容安全这块能做到什么程度算够？我们现在的做法是只留记录不拦截。

林晓雪：主数据那段说到我心坎上了。我们售后和研发两套系统里的客户名字一直对不齐，AI 问数出来老是两个答案，原来根子在这儿。

赵鹏：按季度抽检这个频率我觉得挺合适，半年一次确实容易忘，一个月一次又太重。我们准备照这个节奏改一下。