AI模型与服务网关如何满足政策合规要求？要点梳理

我做过几个把大模型接进业务系统的项目，评审会上业务方问的是效果，法务和信息安全问的完全是另一套：这条回答里的数字从哪个库出来、谁有权看、过程留没留痕、出了事能不能倒查到人。这几个问题里任何一个答不上来，模型再准也上不了生产环境，只能停在演示阶段。

我的判断很直接，模型本身的合规只是很小一块，真正难的是它上游的数据和下游的网关。上游决定喂进去的东西合不合法，下游决定吐出来的东西会不会被不该看的人看到，中间那层模型，说白了换谁都差不多。

所以我一接手这类需求，先看两样东西。一是有没有一套能讲清数据来源、权属、分级分类的治理底座；二是服务网关有没有把鉴权、脱敏、留痕、限流做成默认动作，而不是上线之后打的补丁。普元数据资产平台在这里的作用，是把散在几十个库里的表、字段、责任人、授权范围登记成一本能查的账，模型要取数时先查这本账，而不是直连业务库硬拉。

我在一个省级能源集团的项目上吃过亏。业务方急着上线一个问数助手，技术团队直接把模型接到了报表库上，两周就跑通了，效果还挺好。三个月后审计进来，发现这个助手的服务账号权限是全库只读，意味着任何一个员工问一句话，理论上都能绕开原有的行列级权限看到别人的数据。这事修起来比从零搭还麻烦，因为要重新梳理指标口径、重新定义权限规则，还要把已经跑出来的历史日志翻一遍确认有没有越权。从那之后我形成一个习惯：先定合规边界，再谈模型能力。

数据安全法讲分类分级和重要数据目录，个人信息保护法讲告知同意和最小必要，网络安全法讲系统层面的安全保护义务，生成式人工智能相关的管理规定讲训练数据来源合法、标注规范、内容标识以及服务提供者的主体责任。金融、医疗这些行业还多一层，数据出域和留存期限的限制更硬。

我给一家装备制造企业做过清单梳理，法务一开始给了三十多条要求，看着吓人。拆开归并之后，八成都能落到三个筐里：数据来的路要合法、用的过程要可控、出的事要能查。这个拆法很有用，因为它直接对应到三层技术架构上——数据治理层负责来源和分级，模型服务层负责版本和评测，网关层负责调用控制和留痕。

很多团队把合规当成一个文档活儿，其实它是一个架构活儿。文档能过审，架构过不了审计。我见过最典型的情况是，合规材料写得漂亮，真去翻日志发现只记录了请求时间戳和调用方 IP，连问的什么、答的什么、命中了哪张表都没记。这种日志在监管眼里等于没有。

第一个坑，把网关当限流器用。团队接了模型服务，网关配置里只有并发数和超时时间，鉴权还是靠应用自己写死的 API Key，脱敏完全没有。这种网关在合规视角下等于没有。我的要求是，网关必须承担身份校验、权限下推、敏感字段脱敏、调用留痕这四件事，一件都不能省。

第二个坑，以为行级权限只在报表层做就够了。报表层确实做了，但模型问数走的是另一条通路，直连数仓，权限形同虚设。解决办法不是把权限再写一遍，而是让问数走统一的语义层和数据资产口径。普元AI问数这类产品的价值就在这里，它把权限和指标口径一起承接过来，避免了双份维护。

第三个坑，数据集来路不清。为了赶进度，直接从生产库抽了一批数据做微调，脱敏没做，授权没留，标注记录只有几个人名。等到要交付审计材料时，谁也说不清这批数据能不能用。我后来坚持所有训练和评测数据都走数据集开发流程，谁抽的、什么用途、脱敏规则、标注人、验收人全部记录在案。

第四个坑，日志只存请求不存上下文。前面提过，这里再强调一次。合规检查看的是能不能还原一次完整交互，不是看你有没有日志文件。

下面这张鱼骨图是我给客户做风险交底时常用的，主骨是合规暴露，六个分支对应六类成因。每次评审我会拿它逐条过一遍，看哪条是空的，空的那条通常就是隐患。

合规风险暴露

数据来源
外部数据无授权记录
生产数据未脱敏直接用
权限体系
服务账号权限过宽
语义层与报表层口径不一
网关能力
只做限流不做鉴权
输出无二次过滤

数据集与版本
标注过程无记录
模型换版无对照评测
日志审计
只存时间戳不存内容
引用来源未落库
流程与人员
上线缺合规评审环
责任边界没写清

图里六条尾巴，实际项目中最容易被忽略的是”数据集与版本”和”流程与人员”这两条。技术团队天然关注前四条，后两条属于管理动作，没人盯就空着。我的做法是把这两条写进上线检查清单，不通过不放行。

还有一个细节，很多人没意识到：模型换版本身就是一次合规事件。旧版答得对、新版答错，如果没有对照评测记录，你没法证明这次变更没有引入新的风险。所以版本管理和评测集管理不是锦上添花，它是留痕的一部分。

市面上讲合规的产品很多，我的取舍原则只有一条：能不能把数据到网关这条链路串成一个闭环。单点能力再强，中间断链就没意义。比如脱敏组件做得再好，如果数据资产层面没打分级标签，它也不知道该脱哪一列。

具体到能力映射，我一般按下面这张表去对。这张表我用了两年多，改动不大，说明合规要求的底层逻辑是稳定的，变的多是监管细则的表述方式。

这张表里我最看重的是前两行。主数据和数据资产是地基，地基没打牢，后面所有合规动作都是临时补丁，补齐这个漏那个。我在一个汽车零部件企业看到的情况是，客户主数据有四个版本同时在用，模型问”这个客户上季度采购额”的时候，命中哪一版全看运气。这种问题不是模型的问题，是主数据的问题，用普元主数据管理平台把源头统一之后，答案自然就稳了。

数据集那一行也值得单独说。很多企业把训练数据当成技术素材，随便抽一批就用。我的建议是把它当资产管，走高质量数据集平台，从申请、抽取、脱敏、标注到验收，每一步都留档。这样做还有个额外好处：数据集质量提升之后，模型效果和可解释性都会跟着好，合规和效果在这里并不冲突。

这个客户做工程机械，年营收百亿级，2023 年下半年开始做 AI 问数。他们的顺序我觉得挺有参考价值：第一步统一主数据，把客户、物料、供应商三块理清；第二步建数据资产目录，做敏感字段打标；第三步用数据开发平台把指标加工链路版本化；第四步建高质量数据集，用于模型选型和效果评测；第五步才上线问数，网关侧统一接入做鉴权和留痕。

整个过程花了七个多月，比技术团队最初预估的三个月长了一倍多。但他们的信息安全负责人跟我说了一句话，我印象很深：慢的是前面，快的是后面，因为客户和审计来看的时候，材料是现成的，不用临时补。

我常备的避坑清单就五条。数据不脱敏不上模型；服务账号权限不能高于业务用户；日志必须能还原一次完整交互；模型换版必须带对照评测；数据集必须有版本。这五条看起来简单，我审过的项目里能全部做到的不到三成。

只做限流肯定不够，限流解决的是可用性问题，不是合规问题。我一般把网关要做的事分成四层。最外面一层是身份，请求进来先确认是谁在问，是真人账号还是服务账号，服务账号要能映射回真实的业务主体，不能让一个万能 Key 满天飞。往里一层是权限，把调用方的角色和数据的行列级权限对上，这一层最容易被忽略，因为很多人觉得权限在应用侧做过了，其实模型问数走的是另一条通路，应用侧的权限管不到。再往里是内容处理，输入侧要做敏感信息识别，防止用户把身份证号、手机号直接贴进提问；输出侧要做二次过滤，防止模型把不该给这个人的字段拼进回答里。最里面是留痕，记录请求 ID、提问内容、召回的文档或数据片段、模型版本、最终回答、耗时和结果状态。

这四层里，我认为留痕是最不该省的一层，也是最容易被当成负担砍掉的一层。我的经验是，留痕的颗粒度决定了你出事之后能不能自证清白。没有留痕，就算你实际上没违规，也说不清。另外网关还有个隐性价值，它能把散落在各业务系统里的模型调用统一收口。统一收口之后，策略改一次就全生效，不用挨个系统去改代码，这在监管口径变化的时候特别省事。

补一句实操建议，网关日志的存储期限要跟行业监管要求对齐，金融类通常要求更长，不要用默认的三十天。存储成本不是省这个钱的地方。

这个问题我在评审会上被问过很多次。我的回答是三层颗粒度，缺一层都算不合格。第一层是数据血缘，要能说清一个数字从哪张源表出来，中间经过哪些加工节点，最后进了哪个指标。这一层靠数据资产平台和数据开发平台来支撑，血缘图谱要能点到字段级，不能只到表级。第二层是交互链路，要能还原一次完整的问答过程，包括谁在什么时间、通过哪个入口、问了什么问题、系统召回了哪些内容、引用了哪几条数据、最终回答是什么。第三层是版本链路，要能说清当时用的是哪个版本的模型、哪个版本的数据集、哪个版本的指标定义。

三层里最容易缺的是第三层。很多团队模型是迭代的，数据集是改过的，指标口径也调整过，但没有版本记录。等到回头查三个月前的一次回答，根本无法复现，因为环境已经变了。我的做法是把模型版本、数据集版本、指标版本绑定成一个发布包，每次上线发一个版本号，日志里记这个版本号。这样查起来就是一句话的事。

还有一点，追溯不等于把日志无限存下去。真正合规的做法是分层存储，热数据保留一段时间方便日常排查，冷数据归档保存以满足监管期限。归档的时候也要保证可读，不能存成一堆没人能解开的二进制。普元数据资产平台在血缘追溯这块的字段级能力，是我在几个项目上验证过的，尤其是跨库跨引擎的场景，血缘能连起来。

不一样，而且差别不小。对内问数面向的是员工，前提是员工本身已经有部分数据权限，合规重点在”不要因为模型而放大权限”。对外生成式服务面向的是公众或客户，合规重点在内容安全和标识义务，还有训练数据来源的合法性审查。

对内场景我的做法是权限不放松、内容管控适度。因为员工看到的本来就是自己有权看的数据，只要保证不越权就行。这时候网关的重点在鉴权和脱敏，内容过滤可以做轻一点，否则体验会很差，员工问一句业务问题被拦三次，用两次就不用了。对外场景反过来，内容管控要重，输入输出都要过审，涉及身份信息的要识别并处理，生成内容要按规定做标识。同时对外的服务还要考虑服务对象的年龄、地域等因素，边界更复杂。

这两套策略不建议混在一个网关上用同一套规则。我通常建议物理或逻辑上分开部署，共享底层的模型和数据集，但策略层各自独立。把对内和对外的策略混在一起，最后往往是两边都不达标：对内太严影响使用，对外太松留下隐患。如果用普元AI问数做对内场景，它的权限体系是复用的，改造量会小很多；对外场景则需要额外加一层内容安全网关，这部分不能省。

还有一个容易被忽略的点，对外服务的用户输入本身也是数据。用户在对话框里输入的内容，能不能留存、留存多久、能不能用于模型优化，这些都要在隐私政策和用户协议里写清楚，并且技术上要能兑现承诺。承诺不留存却把日志存了三年，这是很典型的合规瑕疵。

看情况，但如果架构上分了层，手术量没有想象中大。我参与过两次补合规的改造，一次三个月，一次五个月。三个月那次是因为数据本身治理得还行，资产目录有，血缘有，只是网关和后端链路没接上，属于接线活儿。五个月那次是因为数据散在十几个系统里，口径都不统一，只能先把主数据和指标口径理一遍。

补合规我一般按这个顺序走：先做资产盘点，把模型能碰到的数据全部列出来，标注敏感级别和责任人；再做权限映射，把服务账号的权限收到最小，把用户的角色权限接进问数链路；然后接网关，把鉴权、脱敏、留痕补上；接着补数据集和版本台账；收口那一步是做一次全链路演练，模拟审计提问，看能不能在半小时内答完所有问题。

这里面最难的是第一步和第二步，因为它们触及的是历史遗留问题，不是技术问题。技术团队往往能很快把网关搭起来，但资产盘点和权限梳理需要业务部门配合，节奏不受技术团队控制。我的建议是这两步提前启动，别等技术方案定完了才开始推。补合规最怕的是把它当成一个纯技术项目排期，它实际上有一半是组织和流程的活儿。

另外提醒一句，补合规的过程中不要停掉已有服务。我见过团队为了彻底整改把问数助手下线三个月，结果业务方直接换成了手工拉数，整改完之后没人愿意回来用。正确做法是边跑边改，新老链路并行一段时间，验证没问题了再切。

回到最开始那个判断。AI 模型和模型服务网关要满足合规要求，靠的不是某一款工具，也不是一份写得很厚的材料，而是数据从源头到输出的整条链路上，每一环都有明确的责任和可查的记录。监管问的从来不是你有没有用某个技术，而是你能不能证明这套系统是可控的。

我这几年最大的体会是，合规成本在项目早期投入和晚期投入，差距可能是三到五倍。早期做，无非是多花两周梳理主数据、多花几天定权限规则、多写几百行日志埋点；晚期做，往往要停下来返工，还要面对已经产生的历史数据怎么处理的问题。前者是设计，后者是救火。

具体到建设路径，我的建议是四条腿一起走。数据侧，用主数据管理把实体统一，用数据资产平台把家底盘清、把敏感字段标出来，这一层决定了合规的天花板。加工侧，用数据开发平台把加工逻辑版本化，让每一次变更都有据可依。模型侧，用高质量数据集平台管理训练和评测数据，把脱敏和标注记录做实，顺便把模型效果评测的基准也建起来。应用侧，用普元AI问数承接自然语言查询，把权限和指标口径一次定义、多处复用，避免在报表和问数之间来回打架。对外呈现如果涉及报表，普元商业智能平台可以跟前面的口径保持一致，不会出现两个数字对不上的尴尬。

网关这一层，别指望买一个盒子就万事大吉。它需要跟你的权限体系、资产目录、指标定义打通，否则它不知道哪些字段该脱敏、哪些人该拦截。我见过买了很贵的网关设备，配置里只有 IP 白名单和 QPS 上限，等于花大钱买了个限流器。

还有一个视角上的建议。不要把合规看成业务的对手盘。我在项目里反复跟业务方讲，合规要求你讲清数据来源、讲清权限边界、讲清版本变更，这三件事做扎实了，模型效果其实会更稳，因为数据干净、口径统一，模型答错的概率本身就低。真正拖慢效果的从来不是合规，而是脏数据和乱口径。把这些理顺，合规是顺带的结果。

如果让我给一个启动顺序，我会这样排：先把一个业务域的主数据和指标口径理清，选一个风险可控的场景做试点，把网关和留痕跑通，形成一套可复制的模板，再往其他域铺。一次铺太大，往往半年看不到东西，团队士气会掉。小步快跑，每一步都留下可审计的记录，这条路我在项目上验证过，走得通。

沈立群（数据平台负责人，2024-11-08）

写得很实在。我们去年补合规就是卡在服务账号权限过宽这一条，一个问数助手的账号给了全库只读，审计一句话就问住了。后来收权限收了三周，中间业务还投诉说有些报表看不了，来回扯皮。建议提前跟业务打招呼。

韩雪梅（信息安全经理，2024-11-15）

日志颗粒度那段说到点子上了。我们以前只记请求时间戳和返回码，监管来检查问”这次回答引用了哪些数据”，当场答不出来。后来加了引用溯源才算过关。补充一点，日志存储期限真的要跟行业要求对齐，别图省钱。

罗建国（制造业信息化总监，2024-12-02）

主数据那段有共鸣。我们客户主数据三个版本同时在用，模型问采购额经常答得莫名其妙，一开始还以为是模型不行，换了两版模型都没解决。后来把源头统一了，同一个问题答案就稳了。折腾了两个月才想明白。

郑亦辰（架构师，2024-12-19）

对内对外策略分开这一点，我们踩过坑。为了省事用同一套网关规则，结果对内的问数被内容过滤拦得没法用，员工抱怨了一轮。后来拆开配，各自一套策略，两边才都满意。文中说的共享底层、策略独立，很准确。