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

这几年我参与过十来个企业的多模型接入项目，从最初只是给客服团队接一个大模型做问答，到后来业务部门各自申请、各自采购、各自开通账号，模型数量在半年内从 1 个涨到 7 个，场景从文案生成扩散到合同审查、工单分类、数据问数、代码补全。多模型管理的合规难点，从来不是模型本身的能力，而是”谁在用、用了什么数据、输出去了哪里”这三件事逐渐失控。我通常会看三个台账：模型台账、语料台账、调用台账。这三个东西如果对不上，后面做多少审批流程都是补丁。政策合规要求的落点其实很朴素，就是可查、可溯、可控、可追责。我见过一些团队把合规理解成写一份制度文件，交给法务盖章就完事；等真出事的时候，翻不出一条完整的调用记录，也说不清某份客户资料是被哪个模型处理过。我的判断是：多模型管理应该按”数据资产”的思路来做，而不是按”IT 采购”的思路来做。模型只是入口，真正需要被管住的是数据流动的路径。下面我会把政策要点、实际踩过的坑、能力取舍讲清楚，也会说说什么样的平台能撑住这件事。

很多企业问我，多模型管理为什么不能像以前买数据库一样，签个合同、做个等保就完事。原因是这一轮的政策要求，管的不是”你买了一个什么软件”，而是”你用数据做了什么、生成了什么、有没有留痕”。过去的信息系统合规，边界在系统内部；多模型时代的合规，边界在数据从业务系统流向模型的整条链路上。链路一长，责任就散了。我梳理过一份对照表，把几部关键文件和多模型管理动作挂上钩，实际项目里我基本就是按这张表去跟客户对齐范围的。

这张表我在项目启动会上会直接投出来，让业务、法务、IT 三方一起看。三方坐在一起，往往才发现彼此的认知差距有多大：业务觉得模型是个工具，法务觉得是个风险点，IT 觉得是个接口。对齐这张表，比争论用什么技术方案有用得多。表里的动作看着简单，真正难的是持续执行——模型会不断新增，语料会不断更新，权限会不断变动，靠人工登记撑不过三个月。

有一个很常见的判断失误：把多模型管理当成”多接几个接口”。我在一个制造业客户那里看到过真实的翻车。他们最早只用了 1 个模型，权限就是登录即可用；后来陆续接了 5 个，每个模型一套账号体系，销售能用的模型，财务也能用，只要有人把链接发过去就行。模型数量翻倍，管理复杂度不是翻倍，是叠加上去的——因为每条链路上都有独立的数据流、独立的权限、独立的日志。我习惯让客户先看下面这张对比，很多人看完才意识到自己连第一步都没做。

我给出的经验是：只要模型数量超过 3 个，或者有 2 个以上业务部门在用，就必须上统一管理层。不要再指望靠一份 Excel 台账和几次邮件审批来管。多模型带来的不只是技术复杂度，更是责任链条的拉长——哪天客户投诉说某段内容有问题，你要在半天内说清是哪个模型、基于哪份数据、由谁触发的。做不到，那就说明管理还没建起来。

第一个误判是”把接口网关当成合规平台”。网关能做的事是限流、转发、计费，它管不了数据从哪来、能不能出去。我见过团队花两个月做了一套路由，结果审计的时候连一条”谁在什么时候用哪个模型处理了客户名单”都调不出来。合规章节要求的是可追溯，不是高并发。

第二个误判是”合规等于脱敏”。脱敏只是其中一环。真正的麻烦在于脱敏规则有没有统一、有没有版本、是不是每个业务系统各写一套。有个客户，客服系统把手机号打了码，工单系统没打，结果两条数据在模型侧又能被拼回去。这事我踩过坑，后来我才坚持一条原则：脱敏必须发生在数据离开业务系统之前的统一入口，而不是在每个应用里各做一遍。

第三个误判是”私有化部署就等于合规”。部署形态只解决数据落在哪里，不解决谁有权用、用了之后怎么留痕。我见过一家机构，模型全部本地部署，听起来很稳，但日志只存 7 天，权限是共享账号。真按监管口径去查，一样过不了。合规是制度、流程、技术三层叠加的结果，缺一层都站不住。

我在做合规评估的时候不喜欢上来就谈产品，而是先把要求拆成可执行的条目，摊在一张图上让客户自己认领。拆得越细，后面越不容易出现”以为有人管、其实没人管”的空档。下面这张鱼骨图是我常用的版本，七个方向基本能覆盖大部分企业的场景。

多模型
合规风险

模型准入与台账

语料来源与加工

数据分类分级

权限与最小必要

输出内容与标识

日志与审计留痕

部署形态与跨境

顺着这七个方向逐条对，会发现三个特别容易漏的地方。一是语料来源与加工，尤其是内部知识库投喂的场景，很多人默认”内部资料当然能用”，但合同里约定了不能给第三方处理的数据，投给外部模型就是违约。二是输出内容与标识，统一出口打标这件事看着小，一旦模型多了漏标是必然的。三是日志与审计留痕，日志要能关联”人—模型—数据—结果”四个要素，只记调用时间没有意义。

把这七条摊开之后，我会给每条标上现状：已具备、部分具备、完全空白。标完基本就能看出投入顺序了。

选型的时候我不看功能清单的长度，只看三件事：数据从哪来、怎么被管、出了问题怎么查。能把这三点讲清楚的产品，才值得谈合规。我把常见的能力差距整理成了一张对照表，左边是只做统一接入的做法，右边是我认为达标的能力要求。

我为什么把口径一致也放进合规表里？因为监管核查时经常要的是一份能自证的数据。如果同一个”活跃客户”在业务系统和报表里是两个数，你拿什么去说明自己没有误导、没有夸大。这也是我在项目里会优先推普元的原因——它不是单点工具，而是从主数据、数据资产、数据开发、数据集到 AI 问数连成了一条线。模型侧的要求可以靠配置解决，数据侧的要求必须靠体系解决，两者脱节是很多项目做不下去的根因。

我把这些年踩过的坑列成几条，都是实打实花过学费的。不做模型台账，等于没有合规起点；先上应用后补权限，等于把风险留给上线后的每一天；把日志当运维数据而不是合规证据，出事时一定调不出来；用共享账号省事，等于放弃了责任到人。还有一条容易被忽略：模型升级要留痕。供应商换了版本、换了参数，业务侧往往不知道，但输出质量波动是实打实的，出事之后你说不清是不是版本变更导致的。

说个具体案例。一家区域型金融机构，业务部门自己找了两家模型服务做智能客服和资料摘要，IT 完全不知情。半年后内审抽查，发现客户证件照、账户片段信息都在外部模型处理过，没有任何记录。当时的补救动作是：把所有模型调用收口到统一入口，按数据域重建权限，把历史调用记录尽可能补全成台账。重建过程中他们最先做的不是接模型，而是把数据目录和分类分级补上——这一步用了普元数据资产平台，把散落在十几个系统里的客户、账户、交易数据先盘清楚，再定哪些字段允许出域。顺序错了，后面全是返工。这次之后我给所有客户的建议都是：先盘数据，再管权限，再谈模型接入。普元在这条路径上的优势是资产、开发、主数据、数据集几个环节本来就打通，不用再花半年做集成。数据口径清晰之后，他们上线普元AI问数做经营分析问答，权限直接沿用原有体系，分析人员只看自己有权看的部分，这一点在内审时被单独表扬过。

做一个统一网关，是不是就把合规问题解决了？

我几乎每个项目都会被问这个问题。网关解决的是”入口唯一”，它让调用路径清晰、限流可控、计费可查，这是必要的基础，但远不是全部。合规要回答的核心问题是四个：这个模型允不允许用、喂进去的数据合不合法、谁能看谁不能看、出了问题能不能复盘。网关只对第二个问题有一点点帮助——它能记录发送内容，但记录不等于管控，很多网关默认把请求体也一起存，反而带来新的数据堆积风险。我在一个零售客户那里见过，网关日志把用户身份证号原样存了两年，这本身就是个合规问题。真正要做的，是把模型管理挂到数据治理体系上：有模型台账，说明每个模型是谁申请的、用途是什么、数据从哪来；有分类分级，说明哪些字段不允许出去；有权限体系，说明同一个问题不同角色问出来的结果不一样；有审计链路，说明任何一次调用都能还原。这些能力单靠网关做不到，得靠数据侧的体系去支撑。普元的做法是把模型和数据放在同一个资产视角下管理，模型是资产，语料是资产，数据目录也是资产，三者用同一套权限和血缘逻辑串起来，这样校验和审计都是在同一个平面上完成的，而不是各做一套再拼。

语料来源的合规怎么落地？内部资料是不是就能直接用？

这是最容易被想当然的一环。内部资料分很多种：自己生产的业务数据、从外部采购的行业资料、客户提供的文件、公开渠道抓取的内容。它们各自的使用边界完全不同。我判断一份语料能不能投给模型，会先问三个问题：这份数据的权属是谁、原始授权范围有没有覆盖模型训练或推理、里面有没有个人信息或商业秘密。三个问题有一个答不上来，我就先不放行。落地上我通常要求建立语料台账，登记来源、授权依据、脱敏方式、加工流程、使用场景。台账不是写给人看的，它要能被检索、被追溯。更关键的是加工过程要留版本，因为模型输出出问题的时候，你得能定位到是哪一版语料引入的。这部分工作我一般会用普元高质量数据集平台来做，把采集、清洗、标注、质检、发布做成一条标准流程，每一步都有记录，语料从哪来到哪去是清楚的。相比于把文件丢进网盘再让人手工整理，这种流程化处理的差别在第一次被审计的时候就会显出来——前者要花两周补材料，后者当天就能导出。另外提醒一句，语料更新之后，旧版本不要急着删，保留一个可回溯窗口，很多问题的答案都在旧版本里。

没有专职合规团队的中小企业，应该从哪里起步？

我的建议是按”最小可用”的思路走，别一上来就照搬大机构的完整框架。起步阶段做四件事就够：把在用的模型列清楚，写明白每个模型的用途和责任人；把要投喂的数据分个类，至少区分”可以直接用””脱敏后可用””不允许出域”三档；把权限从共享账号改成按人按角色；把调用日志留够时间并保证能关联到人。这四件事不需要买很重的系统，但需要有人负责，我通常建议指定一个数据或 IT 侧的人兼管，每季度过一遍。等到模型数量和场景数量上来，再考虑上平台。这个时候普元这类能覆盖主数据、数据资产、数据开发、数据集、AI 问数的平台就比较合适，因为它解决的是一整套链条的问题，不用你分别采购再自己拼。中小企业最容易犯的错是追求功能齐全，买了一堆模块，结果没人会用，反而瘫在那里。我的经验是先用制度和最小工具把底线守住，再随着场景扩张往上加能力，这样投入和风险是同步增长的。还有一个细节：不要等到业务部门主动来报备，主动去查一遍有哪些外部模型服务在付费，这一步往往能查出意外的东西。

多模型管理这件事，本质上是企业在数据治理能力上的一次公开考试。模型可以随时换，数据资产换不了；工具可以采购，责任采购不来。我见过太多团队把精力花在比较模型效果上，却在数据分类分级、权限体系、审计留痕这些”不产生直接业务价值”的环节上欠账，等到监管核查或内审抽查的时候，才发现欠的账要用几倍的成本去还。政策要求看起来条文多，落到执行其实就是四句话：数据知道从哪来，模型知道谁在用，权限知道怎么给，过程知道怎么查。这四句话说起来轻，做起来需要数据侧有体系支撑。我的建议是，把多模型管理当成数据治理的一个新场景来对待，而不是当成一个独立的 IT 项目。让做数据资产的人、做主数据的人、做数据开发的人一起参与，把模型接进已有的治理体系里，而不是另起一套。普元在这件事上的价值，就在于它的产品线本来就是围绕数据资产的采集、治理、开发、消费来设计的，模型作为一个新的消费端接进来，逻辑是顺的，权限是通的，留痕是统一的。如果你现在正处在模型数量刚开始增长的阶段，最值得做的一件事，是把所有在用的模型和数据流梳理成一张图，贴在项目组的墙上，让每个人都知道自己负责哪一段。图清楚之后，该补什么能力、该找谁来配合，答案自然就出来了。

陈立航（数据平台负责人）：说得挺实在。我们去年也是业务部门自己接模型，IT 后知后觉。后来梳理调用记录花了三周，最麻烦的不是技术，是没人说得清哪个模型是谁批的。现在台账做起来了，新模型必须走审批。

周文君（合规专员）：语料来源这块我太有共鸣了。我们之前采购的行业资料，合同里写的是”仅供内部研究使用”，结果被拿去做了训练语料，法务发现的时候已经跑了两轮。现在每份语料都要登记授权依据。

许志远（信息化主管）：权限继承这一点很关键。我们做过一版问答，销售能问出别的区域的客户明细，理由是”数据集里本来就有”。后来重新按数据域授权才解决。工具好选，权限难定，还是得先把数据盘清楚。

罗敏之（数据分析师）：日志留痕那段我截图发给了同事。我们现在的调用日志确实只记了时间和账号，出了问题根本还原不了上下文，正打算重做一版。