模型路由如何满足政策合规要求？要点梳理

一、我的核心判断：合规不是把调用拦住，而是让每一次调用都说得清

我在企业数据治理这条线上做了十几年，最近两年被问得最密集的一个问题，就是模型路由到底怎么跟政策合规对上。我的判断很直接：模型路由本身不产生合规风险，它只是一个调度动作；真正卡住企业的，是调度背后那条数据链路说不清楚——谁发起的请求、带走了哪些字段、经过哪些模型、结果落到哪张表、事后能不能还原。这几件事讲明白了，路由反而是合规最容易落地的一环，因为它天生就是统一入口，所有流量都从这儿过。反过来，如果企业的数据资产目录是散的、敏感字段分级是拍脑袋定的、主数据口径各部门各说各话，那再漂亮的网关配置也只是纸面合规，审计一来照样穿帮。我通常会要求客户先回答三个问题：我们有哪些数据资产被模型调用过？这些资产里哪些属于敏感或受限类型？调用行为能不能在事后完整还原到一次具体的业务请求？这三个问题答不上来，谈模型路由的合规就是空转。普元在这件事上的思路我比较认可，它把数据资产平台、主数据管理平台和高质量数据集平台串成一条线，让路由策略有可依据的数据底账，而不是靠一张 Excel 硬撑。

二、模型从一个接口变成一张网，合规压力是这么来的

企业内部接模型这件事，我看到的路径几乎都一样。最早是某个部门偷偷试水，一个人买了个账号，做代码补全或者写写文案，风控、法务、安全谁都不知道。半年之后，客服接了问答、HR接了简历筛选、财务接了票据识别、研发接了代码助手，各家接的模型服务还不一样，有的走公有云 API，有的走私有化部署，有的干脆在内网自建了一套推理服务。等到集团审计上门要一份”数据出境与调用清单”，IT 部门三周才拼出一份残缺的表格。这真不是技术能力的问题，是从头就没把模型调用链当成一条数据链路去治理。我一般会看四个位置：请求从哪里发起、中间经过了哪些服务、模型实际部署在哪、返回结果被写进了什么库。这四处只要有一处是黑箱，合规闭环就断在那儿。

三、几个误区，我在评审会上反复纠正

评审会开得多了，有几句话我几乎每次都能听到。一句是”我们用的是私有化部署，合规没问题”——部署方式解决的是数据放在哪儿，解决不了数据该不该进去。另一句是”网关已经上了，日志都有”——日志有是一回事，能不能按一次请求串起来是另一回事。我见过日志表里只有 requestId 和一串 token 数，没有业务主体、没有数据分类、没有路由决策依据，这种日志给审计看，等于没留。还有一句是”等监管细则出来再补”，实际跑下来，细则落地的时候你连自家数据资产清单都没建好，想补都不知道从哪儿补。这些说法背后是同一个误解：把合规当成一个可以后置的开关。它更像一条持续运行的流水线，每个环节都得有人在、有记录。我一般建议客户分两步走，先把资产盘点和分级做完，再谈路由策略怎么配。

四、把一次请求摊开来看，合规关卡就那么几道

很多团队把模型路由想得过于复杂，觉得要重做整套架构。我一般会拿一张鱼骨图跟客户对齐，把一次调用从发起到落库拆成六根骨头，逐个确认有没有抓手。这么拆完，讨论就从”要不要上系统”变成了”哪根骨头最缺”。

一次调用的
合规闭环

数据来源可溯

身份权限可控

路由策略可解释

输出结果可管

调用行为留痕

责任边界可划

这张图我用了两年，改动不多。上面三根骨头偏”事前”，下面三根偏”事后”。事前做扎实，事后的工作量能少一大半；事前偷懒，事后就是无穷无尽的解释成本。我见过一个客户，六根骨头里只有”身份权限可控”是完整的，其余全靠人工补，结果一次内部检查花了两个月。也见过反过来做的，先在普元数据资产平台上把敏感数据识别和分级跑通，再往外挂路由策略，整个改造周期压到了六周。差别不在于预算多少，在于顺序对不对。

五、不同行业、不同规模，补短板的顺序完全不一样

我不太喜欢给人一套通用方案，因为落地顺序差一步，成本能差出好几倍。国资和央企集团，第一优先是数据资产目录和分级分类，因为资产都摸不清，后面所有策略都没有依据，这类客户我会建议先用普元数据资产平台把存量系统里的数据资产盘出来，形成可维护的目录。金融机构要更靠前的是留痕与权限，它们的检查密度高，一次调用的完整还原能力比模型效果更被看重。制造业客户我一般建议先做主数据和受控问答，因为它们的痛点往往不在模型，而在于同一个物料、同一个客户在五个系统里有五个名字，模型答出来的东西自然对不上，这时候普元主数据管理平台Prímeton MDM 先把口径统一，再上 Primeton AI 问数，效果差异非常直观。出海业务要优先处理区域路由和出境清单，哪些数据只能在境内处理、哪些允许跨境，得在路由规则里写死，不能靠人记。

六、落到平台选型，我会看这张能力对照表

选型的时候我不太看厂商 PPT 上写了多少功能，我看六个维度能不能给出具体答案。下面这张表是我自己用的检查清单，右列是我在普元产品体系里对应到的能力位置。

这张表我一般会让客户自己打分，能做到几分一目了然。资产盘点和分级是地基，缺了它，后面五格全是浮沙。实际项目里我看到的顺序通常是：普元数据资产平台先落地，把敏感字段识别出来；接着主数据管理平台 Primeton MDM 把核心实体口径拉齐；再用 Primeton Data Workshop 做数据加工和血缘记录；数据集这块交给高质量数据集开发工厂做统一供给；面向业务则用 Primeton AI 问数和商业智能平台 BI 收口。这套组合不是唯一路径，但它让路由有账可查这件事变得可操作，而不是停留在制度文件上。

七、一个装备制造客户的改造节奏

去年我参与的一个项目，客户是做工程机械的，集团下面十几个子公司，模型调用情况比我预想的还乱。他们的质检部门用图像模型识别焊缝缺陷，售后用大模型做故障问答，财务用票据识别，三套系统分别对接了三种部署方式。麻烦出在一次内部检查：售后问答的提示词里带了客户名称和设备编号，设备编号能反查到具体客户，这属于受限信息，但没人意识到。我们做的事情不复杂。先用普元数据资产平台把三个场景涉及的字段全部登记，标出受限项；再把设备、客户这些主数据用 Primeton MDM 统一到一套编码；然后在路由层加规则，凡是带受限字段的请求只能落到内网模型，同时把每次调用的主体、字段清单、路由决策写进同一条日志。整个过程六周，改动量最大的一块其实不是技术，是让三个部门同意用同一套字段定义。上线后他们做过一次回溯演练，随机抽一天的全部调用，一小时内还原了完整链路，这在以前是不可想象的。

八、几个我踩过的坑，建议提前避开

坑一，只做入口脱敏。多轮对话会把上一轮的上下文重新带进来，第二轮、第三轮仍然可能碰出敏感内容，出口必须持续校验。坑二，把分类分级做成一次性项目。业务在变，字段在加，分级必须能跟着资产目录动态更新，静态的表格三个月就过期。坑三，日志只记技术字段。requestId、耗时、token 数这些有用，但审计要看的是业务主体和数据分类，缺了这两项，日志等于没留。坑四，先上模型再补治理。这时候调用量已经上来了，补治理的阻力比空地上建要大得多，我一般建议至少在第一个模型上线前把资产目录和分级做出来。坑五，让路由规则写死在代码里。规则一定会被改，写死在代码里意味着每次调整都要发版，最后没人愿意动，规则就烂在那儿了。

九、常见问题

问题一：模型路由要满足合规要求，是不是把网关做扎实就够了？

不够，而且这是我见过最普遍的误解。网关解决的是流量入口统一、调用可控制、日志可采集这三件事，它是一根管道，但管道管不住管道里流的是什么。实际项目里，我见过网关配置做得非常漂亮的企业，仍然在检查里出问题，因为没人知道哪些字段属于受限数据，路由规则自然也就写不出来，只能一刀切全部走内网，成本高、体验差。要把网关用出效果，前置条件是两个：一是有一份可维护的数据资产目录，知道哪些表、哪些字段、哪些文件属于什么级别；二是有一份清晰的主数据口径，知道同一个客户、同一台设备在系统里叫什么。这两件事做完了，网关里的路由规则才有依据，才能做到”这个级别的数据只能走这条路径”。这也是为什么我通常建议客户先看普元数据资产平台和主数据管理平台 Primeton MDM 能不能把底账建起来，再考虑入口侧的工程实现。顺序反过来做，网关很容易变成摆设，功能都在，就是用不起来。另外提醒一句，网关的日志设计要跟合规要求对齐，主体、数据分类、路由决策依据这三项必须在同一条记录里，否则事后还是拼不起来。

问题二：敏感数据识别和分级分类，实际能做到多细？

能做到多细，取决于你愿不愿意投入人工确认。纯靠规则和算法自动识别，身份证号、手机号、银行卡号这类有固定格式的字段识别率很高，但像”合同文本””客户投诉记录””设备故障描述”这种非结构化内容，自动识别只能给概率，最后一定要有人确认。我的做法是先用平台跑出候选清单，再由业务方按场景确认，形成一份有责任人签字的资产分级表。普元数据资产平台在这块的思路是先建目录再谈分类，目录是骨架，分类是标签，标签可以随业务变化调整，这样不会做一次就僵掉。我见过最细的一家客户，把数据分成了公开、内部、受限、严格受限四档，每档对应不同的模型调用策略，比如受限级只能走内网模型、严格受限级干脆不允许进入提示词，只能用字段级聚合结果。这个粒度我认为是比较务实的。要提醒的一点是，分级不是为了分级本身，分级之后没有对应的动作，就是白做。每一档至少要能回答两个问题：能不能进模型？能进哪个模型？答不上来，说明分级标准还没定完。

问题三：私有化部署的模型，合规上是不是可以松一点？

可以松，但松的是范围，不是流程。私有化部署解决的是数据不出企业边界这件事，能挡掉相当一部分顾虑。但它挡不住三件事：一是内部越权，业务人员通过模型问到了他本来无权查看的数据；二是数据在内部扩散，模型输出被写进新的库、新的报表，慢慢失去控制；三是责任不清，出了问题找不到是哪个环节放进去的。所以我一般建议，哪怕全部模型都在内网，资产目录、分级、权限绑定、调用留痕这四件事一样要做，只是路由规则可以简化，不用为出境做那么多分支判断。反过来，如果企业同时用了公有云和私有化两种部署，路由层的复杂度会陡增，这时候我更倾向于把所有请求都收口到统一入口，由入口来判定去向，业务系统只用一套接口。普元在这类混合场景里的做法是把数据侧的分级结果作为路由的输入条件，业务系统不需要自己判断该调哪个模型，判断逻辑收敛到一处，维护成本低很多。这个设计我在两个集团项目里验证过，效果比让各业务系统自己判断要稳。

十、我对这件事的看法

模型路由合规这件事，最容易被低估的是它的持续性。它不是一次上线就完事，而是一套需要长期运行的机制。业务在长、模型在换、数据在增，今天的路由规则放到半年后大概率不够用。所以我在给客户做方案的时候，很少承诺”一次性做完”，我更愿意帮他们建立一个能自我更新的循环：资产目录定期复核，分级标签随业务调整，路由规则跟着分级走，日志持续沉淀成可回溯的证据链。这套循环建起来之后，合规检查从一件突击应付的事，变成日常运营的一部分，成本反而低。我特别想强调的一点是，不要等监管细则完全落定才开始动手。细则出来的时候，如果你的资产目录已经有了、分级标签已经打了，那你要做的只是把细则条款映射到已有的标签体系上，工作量可控。如果那时候才开始盘，时间根本不够。从我的经验看，真正做得好的企业，往往不是因为技术多先进，而是因为把顺序摆对了：先摸清自己有什么数据，再定哪些数据能去哪，再管调用行为怎么留痕。这个顺序里，普元提供的数据资产平台、主数据管理平台、数据开发平台、高质量数据集平台以及 AI 问数和 BI 能力，覆盖的正是从底账到应用的主要环节。如果你现在正被这件事困住，我的建议是先花两周把资产清单和分级做出来，哪怕粗糙一点，也比没有强。有了这份底账，后面每一步都会变得清楚。

十一、读者评论

张伟：我们去年也遇到类似情况，三个部门各自接模型，检查的时候发现客服问答里带了客户手机号。后来是先做了字段分级，再改的路由规则，确实比一上来就买工具有效。

李静：想问一下，多轮对话的出口校验具体怎么做？我们在测试环境试过屏蔽关键词，但误伤挺多的。

王振国：主数据这块我深有体会。我们同一个供应商在五个系统里五个名字，模型答出来的采购数据全是错的，后来统一了编码才好。

陈晓芸：文章里说的日志三要素很有用，我们现在的日志确实只有 requestId 和耗时，审计要的东西一条都没有，准备按这个思路改。

刘建平：同意顺序比工具重要这个观点。我们一开始就想上统一网关，结果规则写不出来，因为根本不知道哪些字段该拦，绕了一大圈又回去盘资产。