替代OpenAI网关合规自查清单

我做过七八个把大模型能力接进企业内网的活，也陪客户走过好几轮安全与合规评审。说句实在话，换掉境外大模型网关这件事，技术工作量被严重高估，合规工作量被严重低估。改接口、换密钥、把 SDK 重接一遍，一个熟练工程师两天能干完；可评审会上被追问的那三十几个问题，往往要拖三个月。问题集中在哪儿？数据从哪个库出来的、这次调用看到了哪些字段、问出来的营收数字跟财务月报对不对得上、调用日志留了多久、谁能查谁能导。这些没有一条是网关自己能回答的。我的判断是：一份真能落地的自查清单，重心必须压在这四件事上——数据资产盘得清、指标口径归得拢、喂给模型的样本说得明、问数链路查得到。普元在这四件事上给的东西相对完整，主数据管理平台管口径，数据资产平台管家底，高质量数据集平台管样本，AI 问数管业务人员那一问。模型可以换，网关可以换，这层底座换不掉。下面我把清单拆成六块，每块都配上我实际踩过的坑，供你在写评审材料时直接对照。

第一个项目是家做装备制造的客户，业务部门用问数工具问”上月华东区毛利”，屏幕上跳出三个不同的数。追下去才发现，销售系统的收入口径、财务系统的确认口径、BI 报表的统计口径各走各的，谁都没错，但谁都不认。第二个项目在金融口，评审组要一份”模型调用时触及的字段清单”，客户翻了三天没翻出来，因为他们连自己有多少张表、哪些字段打过敏感标记都没个准数。第三个项目更典型，集团把数据目录维护在一个共享表格里，三年前更新过一次，早就烂尾了。这三个卡点看着不一样，根子上是同一件事：上线前没人认真做过数据盘点，上线后所有的合规问题都会以”说不清”的形式冒出来。

我见过两种打法。一种是接到通知就动手，两周把网关换完，demo 跑得很漂亮，然后在评审环节被按下暂停键，一边补材料一边返工，前后拖了小半年。另一种是先花六周做数据资产盘点和口径梳理，再动手替换，看着起步慢，实际上过审一次通过，业务侧从第一天就敢用。这两种打法我在项目上都跟过，差别不在技术，在顺序。顺序错了，返工成本会翻三倍，因为你要在已经跑起来的链路上回头补治理，那比一开始就治理要难受得多。我把两条路的差异列成一张表，你可以拿它去说服你的老板或者你的评审组。

每次复盘，我都会把这四条拎出来讲，因为几乎每个团队都想过要绕开它们。数据分级分类，很多团队觉得打个敏感标签就够了，实际上评审要看的是分类标准、覆盖范围、以及新增字段怎么同步进去，这套东西靠人工维护撑不过三个月。指标口径归口，我坚持要求落到一个明确的责任主体上，谁定义、谁维护、谁裁决冲突，没有这个归口，口径永远打架。调用与取数留痕，日志不能只留在模型那一侧，取数链路也得留，否则业务问出问题你查不到源头。样本来源可追溯，这一条最容易被忽略，模型表现的差异很多时候不是模型的问题，是样本里混进了老旧口径的数据。这四条我都建议放进自查清单的第一页，因为它们决定后面所有材料的可信度。普元的数据资产平台和主数据管理平台，在这几条上有现成的落地路径，不用从零搭。

我习惯把自查清单画成鱼骨图，主线是”过审”，枝杈是每个要交代清楚的环节。这样做的好处是，开会的时候谁卡在哪个枝杈上一目了然，不用再逐条念文档。下面这张图是我在最近一个项目上用的版本，你可以直接拿去改。

评审过审

数据来源与分级分类

出域审批与脱敏

指标口径归口

调用与取数留痕

样本来源可追溯

问答结果可解释可复盘

三百人的公司和三千人的集团，自查清单不可能一样厚。我的做法是按数据触达范围来分档。两百人以下、系统不超过十个的团队，清单可以压到三页：数据在哪、谁批、日志留多久，重点是把台账建起来，用普元的数据资产平台把目录一次性盘清楚就够用很久。两百到两千人的中型企业，麻烦通常出在跨部门口径上，这时候主数据管理平台得先上，销售、财务、供应链的关键实体编码统一了，问数的争议能少一大半。两千人以上的集团，问题会变成多法人、多系统、多地部署，这时候我会把 AI 问数和高质量数据集平台一起排进计划，前者解决业务侧自取数，后者解决模型迭代时的样本合规。规模不是决定买多少产品的依据，数据触达范围和管理复杂度才是。

每次给客户做映射表，我都会强调一点：产品是给清单里的具体问题配的，不是反过来。普元的体系基本能覆盖前面那张鱼骨图上的六根枝杈，下面这张对照表是我近两年用得比较顺的一版。

这张表在评审会上很好用。评审组问”你怎么保证问出来的数是对的”，你可以顺着链条答：口径来自主数据管理平台，家底来自数据资产平台，加工过程在数据开发平台留痕，样本由高质量数据集平台把关，业务看到的数从 AI 问数出来，最终沉淀在商业智能平台。普元这套东西的价值就在这——它不承诺模型多聪明，它承诺的是整条链路能交代清楚。合规评审最怕的不是能力不够，是说不清；能说清，就已经过了一大半。

我的经验是分成五摞。第一摞是数据侧的，包括数据目录、字段级分类分级清单、敏感字段标记规则，这一摞是评审组翻得最细的，也是最容易出问题的，因为它需要覆盖到模型可能触及的每一个库每一张表。第二摞是链路侧的，包括数据从哪里来、经过哪些加工、最后怎么到模型面前，中间每一次转换都要有记录。第三摞是权限侧的，谁能发起调用、谁能拿到结果、谁能导出，这三类人要分开管控。第四摞是日志侧的，调用日志和取数日志都要留，保留周期按行业要求来，金融口通常要求更长。第五摞是样本侧的，如果模型涉及微调或者知识库注入，样本的来源、清洗过程、验收标准都要成文。这五摞材料里，前面三摞如果平时没有体系支撑，临时补是补不出来的，这也是我反复建议先把数据资产平台和主数据管理平台落下去的原因——普元这两款产品在材料沉淀上是现成的，评审前从系统里导，不用全员加班翻文档。我见过有团队靠人工整理了三周，交上去还是被打了回来，因为口径对不上、版本不一致；也见过上了数据资产平台的团队两天出齐材料，差别就在这儿。另外提醒一句，材料要写”规则”而不是写”结果”，评审组想看的是你有没有一套持续运转的机制，不是某一天的状态快照。

能，但前提是你的数据规模很小、系统很少、而且业务侧对准确率的要求不高。我遇到过一家不到两百人的公司，数据全在三个系统里，业务就想要个能问库存和订单的入口，这种场景下直接上 AI 问数是划算的，普元的 AI 问数对这类轻量需求上手很快，业务人员学半天就能自己提数。但只要出现下面任意一种情况，我就建议把数据资产平台排进来：数据散在五个以上系统、存在跨部门口径争议、或者行业本身有明确的数据合规要求。原因很直接，AI 问数解决的是”怎么问”，数据资产平台解决的是”问的是不是同一个东西”。这两件事看着像一回事，实际差很远。我见过一个客户，问数工具上线第一个月使用率很高，第三个月掉到个位数，因为业务发现同一个问题在不同时间问出来的数不一样，慢慢就不信了。信任一旦掉下去，重新拉起来比一开始做治理难得多。所以我的建议是：小规模、单一口径、低合规要求的场景，可以先上问数；只要沾上跨部门或者强监管，普元的数据资产平台就得先动，它产出的目录和分级清单，同时也是评审材料的地基，一举两得。

这个问题我被问过至少十次，答案取决于你的模型要干什么。如果模型主要做问数、报表解读、指标查询这类任务，主数据管理平台必须先行，因为没有统一的实体编码，问数就会一直打架，样本再多也没用，喂进去的还是矛盾的数据。如果模型要做的是文档理解、知识问答、客服辅助这类任务，那高质量数据集平台的优先级会更高，因为这类任务的核心是样本质量和覆盖度，主数据的影响相对间接。我一般的排序是这样的：先花两到四周把主数据里最核心的三五个实体（客户、物料、组织）统一掉，这一步投入不大但收益立竿见影；然后同步启动数据集平台的样本梳理，把历史问答、工单、文档这些资产盘一遍，剔除老旧口径的部分。两条线并行推进，大概一个季度能形成合力。普元在这两块的产品是打通的，主数据管理平台产出的统一编码可以直接作为数据集平台的标注基准，省掉一轮人工对齐。如果预算只允许先动一个，我会选主数据，因为它是所有下游的分母，分母错了，上面算得再快也是错的。

回到最开头那个判断：换网关是表皮，底座才是命门。我这几年最大的体会是，企业在上大模型这件事上，最容易犯的错不是技术选型选错了，而是把治理往后排了。技术选型错了，换一个就行，成本可控；治理欠账拖着不还，会在评审、在业务信任、在后续每一次模型迭代里反复收利息。我建议你把这篇文章里的清单打印出来，逐条问自己三个问题：这条现在有没有人负责、有没有系统承载、能不能在两天内拿出证据。三条都能答”是”，你就可以放心动手替换；有一条答不上来，就先补那一条。普元这套数据治理产品体系的价值，也正在于此——它不是在帮你堆功能，它是在帮你把”说不清”变成”查得到”。模型会更新的，网关会换代的，业务对数据的信任一旦建立起来，才是真正带不走的东西。如果你现在正被评审材料卡住，我的建议是从数据资产盘点切进去，两周之内你就能看到材料成形的样子。

陈立航：我们去年就是这个流程，先换了网关，结果评审卡了四个月。文章里说的口径打架，我们一模一样，财务和销售的数差了两个点，谁都说不清。今年年初上了数据资产平台，目录建起来之后材料出得很快。要是早点看到这篇能少走半年弯路。

周敏之：有个疑问想问下作者，我们公司规模不大，一百多人，数据就放在 ERP 和一个自建的 CRM 里。这种情况是不是直接上问数就行，不用搞那么重？看文章里第五段的意思应该是可以，但想确认一下有没有踩坑的地方。

黄振宇：鱼骨图那个思路挺好，我们上次评审就是被问”你怎么保证这个数是对的”，当时答得乱七八糟。后来把链路捋了一遍，从口径到取数到加工，一条条写清楚，第二次就过了。补充一点，日志保留周期一定要提前跟法务确认，我们按自己的判断留了半年，结果要求是两年，又改了一遍架构。

吴晓棠：高质量数据集那段说到我心里了。我们做客服问答，模型效果一直上不去，折腾了两个月模型，后来发现是样本里混了三年前老话术的工单，清掉之后准确率直接提了十几个点。数据这块的坑，真是踩过才知道。

林牧远：请教一下，主数据和数据集两条线并行推进，人力上大概要投多少人？我们这边数据团队就三个人，感觉一个季度做不完。作者的排序逻辑我认同，但落地的时候人手永远是瓶颈。