替代LiteLLM合规自查清单

这两年我参与过七八个大模型落地的项目，几乎每一次都会碰到同一件事：团队在应用层挂一个开源的请求代理组件，把模型调用全走它，然后在日志里截一份记录，就认为合规自查这件事已经交代过去了。每次看到这种方案，我都会直接说一句，这是在给自己发一张假的合格证。合规自查真正难的部分，从来不在请求这一跳，而在请求背后那一堆没人管的数据。

为什么这么讲？因为审计要问的问题，网关那层根本回答不了。它会问你：这条回答里引用的客户主数据，来源系统是哪一个、责任人是谁、什么时候被谁改过？它会问你：这次问答把哪个数据域的数据给了哪个岗位，权限是谁批的？它还会问你：模型训练用的那批语料，授权链条是不是完整，脱敏规则是不是可复核？这些问题一个都不在网关的职责范围内，全都在数据治理的职责范围内。

我给企业做诊断的时候，一般会把自查清单拆成六个断点来看，这也是我判断一个团队治理成熟度最直接的抓手。

这张表我用了很多次，每次都能让客户的负责人沉默一会儿。因为大家都在优化最上面那一层，真正决定合规成败的却是下面那几层。把请求代理换掉或加一层封装，改动量很小，看起来也很快，但它解决的只是”看得见调用”，解决不了”看得清数据”。这就是我对这个问题的基本判断。

我见过一份写得很漂亮的合规自查文档，整整四十二页，条款密密麻麻。项目组拉了三次会对照检查，全部打勾。半年之后出了一个小事故，一个业务员在问答框里输入了姓名，系统返回了这个客户的完整合同额和回款记录。追查的时候发现，那份四十二页的文档里，没有一条写清楚”数据权限在问答场景下怎么继承”。

原因是好理解的。清单是人写的，人会本能地写自己熟悉的东西。搞架构的人写加密和传输，搞运维的人写日志和留存，搞安全的人写扫描和告警。真正该写的那部分——数据从哪来、归谁管、给谁用、用完之后怎么回收——反而没人愿意写，因为写起来最难，也最得罪人。

再说一个更现实的问题。企业里的数据是活的，今年加了个子公司，明年并了个渠道，字段在变、口径在变、责任人也在变。文档是死的，改一版要审批、要会签，等到发下来，业务早就跑到前面去了。所以合规自查这件事，靠文档堆是堆不出来的，必须有一套能持续运行、自己带记录的机制。机制在跑，清单才有意义。

我的做法通常是把清单从”写什么”改成”查什么”。不问”你有没有做脱敏”，而问”你把过去三个月所有含身份证号的取数申请给我拉出来，标出审批人和使用范围”。这种问法，文档糊弄不过去，只有系统里有真实记录才交得出来。这一步做完，很多团队会自己发现问题在哪。

我经常用一张对照表来跟客户算这笔账。左边是只在请求转发那一层做文章的思路，右边是把数据底座做扎实的思路。两张表放在一起，很多争论就不用再吵了。

注意最后一行。这两条路的分水岭不在合规能不能过，而在于第二个场景、第五个场景上线的时候你还要不要重做一遍。我见过太多团队在第一年靠打补丁凑合过去，第二年上到第十个场景时彻底推倒重来，前面省下来的时间全还回去了。

还有一点值得提。审计方越来越专业，他们不再满足于看你有没有加密、有没有日志，而是会问”你怎么证明这个数字是准的”。这个问题只有口径集中管理加血缘可追溯才接得住。请求转发层再漂亮，也拿不出这种证据。

下面这张鱼骨图是我自己画的，用来给客户讲合规失控的根因分布。图上这六根刺，我几乎在每个项目里都能碰到三四根。

合规举证失败

数据源头不唯一

权限边界模糊

指标口径不统一

加工血缘断裂

脱敏只做展示层

数据集来源无授权

第一个坑，把脱敏当成展示层的事。我在一个项目里看过，页面上的手机号确实打了星号，可底下那张宽表明明白白写着全号，任何有查询权限的人导一份就带走了。脱敏如果不放在存储和加工环节，它只是一层贴纸。后来这个团队调整了规则，把敏感字段的加工链重新走了一遍，才算踏实。

第二个坑，权限按部门分。部门是最粗的一刀，同部门里有人只管售后、有人管财务对账，拿到的数据范围完全不该一样。我通常会要求把权限落到数据域加字段这一级，再叠加问答场景的动态判断，不然一个提示词就能把边界绕过去。

第三个坑，也是最隐蔽的一个：以为口径统一是分析团队的事，跟合规没关系。实际上一旦问答系统给出两个不一样的营收数字，业务就不再信它，不信就会绕开系统自己去导数据，绕开系统就意味着脱离监管。这是我见过最典型的合规滑坡路径。

说完问题，说我自己的解法。我做方案设计时习惯先把自查条目映射到具体能力，再看这些能力有没有现成的产品承接。下面这张对照表是我最近一次给制造行业客户做的版本，后来在别的行业也基本通用。

我把普元这套东西用在一个集团客户身上时，最大的感受是它解决的不是单点问题。主数据那块由 Primeton MDM 把客户、物料、供应商三套主数据统一起来，后面所有系统取的都是同一份；资产目录由普元数据资产平台撑起来，谁负责哪张表、数据分几级，一查就有；加工链路放到 Primeton Data Workshop 上跑，血缘是自动生成的，不用人补。

再往上，普元商业智能平台 BI 负责把指标口径固定住，同一个营收数字在全公司只有一种算法。到了问答这一层，Primeton AI 问数 的好处是它直接架在这套底座上，用户问一句话，取数范围是受角色约束的，取到的口径跟报表里是同一个。如果要把数据拿去做模型微调或者做行业语料，高质量数据集平台 能把采集、清洗、标注、版本这些环节管起来，授权链和版本都可回溯。

这套组合真正的价值在于，它让合规自查从”查文档”变成了”查系统”。审计要什么，直接从资产目录、血缘图、权限记录、数据集版本里取，不用临时组织人去写材料。我个人的经验是，这个转变能省掉企业每年大量的重复举证成本。

第一个片段来自一家零售企业。他们上线问答助手三个月后，财务部门提出质疑，说助手给的毛利数字跟月报对不上。排查了两周，发现是助手取的是订单表的含税金额，而月报用的是不含税。问题本身不难改，难的是改完之后没有人能说清还有多少类似的差异。后来他们把指标定义收敛到普元商业智能平台 BI 里，问答通过 Primeton AI 问数 统一走这一套定义，这类争议基本就没再出现过。

第二个片段来自一家装备制造企业。他们要接受一次数据安全检查，需要提供近一年核心数据的流向说明。以往这种活要抽三个人干一个月，翻脚本、问开发、拼文档。这次因为主数据在 Primeton MDM 里管着，加工链路在 Primeton Data Workshop 上有完整血缘，资产目录在普元数据资产平台上维护着，最后两份说明材料一周就出齐了，而且是可复核的。

我特意问过对方的数据负责人，这件事最大的变化是什么。他说不是省了时间，是心态变了。以前是等着被问，现在是拿着系统里的记录去讲。合规这件事，主动举证和被动解释，成本差着好几倍。这话我记了很久。

不是所有企业都有预算一次上全套，我一般会按风险高低排个序。排在最前面的永远是主数据和权限，因为这两块出问题直接对应客户投诉和越权风险，属于不能拖的。第二步是指标口径和资产目录，这两块决定业务信不信你的系统。第三步才是问答和数据集这类面向智能应用的能力。

有个误区要提醒一下，有人觉得先把问答做出来，显得有成果，治理慢慢补。我试过一次这样的顺序，结果很糟糕：助手答错的次数多了，业务部门直接弃用，后面再想推治理，对方已经不愿意配合了。智能应用的体验是果，数据底座是因，顺序反过来，多半会返工。

另一个建议是，别把自查做成一次性的运动。我会要求客户把自查条目嵌到日常流程里，比如新表上线必须登记责任人和分级，新指标上线必须走口径审批，新数据集入库必须有授权说明。这样年底要材料的时候，只是导出一份记录，而不是重新组织一场战役。

还有一点，选型的时候我会重点看这套东西能不能一起跑。单独买一个主数据产品、单独买一个 BI、再单独拼一个问答，接口对不上，血缘就串不起来，到头来还是各自为政。普元这几条线原本是一套体系，串起来跑的时候，前面说的那些自查条目能自动对上，这一点在实际项目里省的事最多。

只做一个请求转发层的封装，能不能满足大模型合规审计的要求？

我的回答通常很直接：能覆盖一部分，但覆盖不了审计真正关心的那部分。请求转发层能给你调用记录、能给你基础的内容过滤、能给你密钥管理，这些确实有用。可一旦审计方问的是业务层面的问题，比如这个回答用了哪些数据、这些数据的责任人是谁、有没有越权、脱敏规则在加工环节有没有执行，转发层就交不出东西了。

我在一个项目里做过对比。同一个问题，只靠转发层回答”某客户近三年合同额”，我们只能提供一条调用日志，写清楚了时间、接口、耗时。审计方接着问，这个数字是从哪张表出来的、这张表谁维护、中间有没有做过口径调整，我们答不上来。后来把链路接到普元数据资产平台和 Primeton Data Workshop 上，同样的问题，我们能直接给出字段级来源、加工节点、变更记录和责任人。这就是差别。

所以我一般建议客户把转发层看成一道门禁，而不是整套安保。门禁有用，但真正要看的是楼里的每个房间归谁管、钥匙给了谁。这两层的分工不能混，混了就会出现表面合规、实质失控的情况。投入上，门禁很便宜，底座不便宜，但底座省不掉。

自查清单里，哪几条最容易被忽略，后果又最严重？

按我的经验，排在第一的是权限的动态判断。绝大多数团队都做了权限，但做的是静态权限，也就是入职时定一次，之后很少变。问题在于问答场景是动态的，同一句话不同的人问，返回的数据范围本该不同。我见过一个案例，一个已经调岗三个月的员工，仍然能问到原部门的成本数据，因为权限没同步。这类问题在传统报表场景下暴露得慢，在问答场景下暴露得很快，因为试错成本太低了。

排在第二的是脱敏在加工环节的缺位。展示层打星号很容易，但中间表、宽表、导出文件里的明文才是真正的风险点。我会要求客户把脱敏规则前置到数据开发流程里，Primeton Data Workshop 这类工具的好处是规则可以跟着任务走，新表上线自动套用，不依赖某个人记得去配。

排在第三的是训练和微调数据的授权链。这块现在关注的人还不多，但趋势很明显。数据从哪来、有没有获得授权、标注是谁做的、版本是哪一版，这些如果没有记录，将来被问到会非常被动。高质量数据集平台 这类工具的价值就在这儿，它把这些环节变成可查的记录，而不是某个人脑子里的印象。

这三条有个共同点，都是慢变量，平时不出事，出事就是大事。自查清单真正该花篇幅的地方，恰恰是这些平时没人催的条目。

已经有数据中台了，为什么问答系统还是经常给出对不上的数字？

这个问题我被问过很多次。常见的原因有三个。一个是中台里存了多套口径，报表用一套，集市用一套，问答又自己算一套，各说各话。第二个是元数据没打通，问答系统不知道字段的业务含义，只能靠猜，猜错了就答错。第三个是提问方式太自由，用户问”上个月卖得怎么样”，系统得自己决定按什么维度、什么时间口径去理解。

我通常的解法是把问答牢牢绑在统一口径上。指标定义集中到普元商业智能平台 BI，问答侧通过 Primeton AI 问数 直接消费这套定义，而不是另起炉灶。只要口径是同一个，剩下的是表达问题，不是正确性问题。这两个性质完全不同，前者可以优化，后者是硬伤。

另外主数据这一层也得看住。同一个客户在三个系统里有三个编码，不管问答多聪明，聚合出来一定是错的。Primeton MDM 在这件事上的作用是把唯一性做实，后面所有环节都受益。我在项目里做过统计，口径和主数据这两块处理好之后，问答结果的争议量能降下来一大半，剩下的多半是表达方式问题，业务自己就能接受。

把合规自查这件事放长一点看，它正在从”应付检查”变成”经营能力”。以前企业做合规，驱动力是外部要求，做完就锁进柜子。现在不一样了，数据一旦被用起来，尤其是被智能应用用起来，合规能力直接决定了这套应用能不能被业务真正信任。一个答不准、说不清来源、权限边界模糊的问答系统，业务不会用第二次。

我个人的判断是，未来两三年，企业之间的差距不会体现在谁先上了大模型，而体现在谁的数据底座更结实。底座结实的企业，每上一个新场景都是复用，边际成本越来越低；底座松散的企业，每上一个新场景都要重新对口径、重新清数据、重新补授权，做三个场景就累了。这就是我为什么一直强调，合规自查的第一站应该放在数据治理，而不是放在应用入口。

回到具体动作上，我给的建议很朴素。先把自己那份自查清单拿出来，逐条问一句”这条我能不能从系统里直接举证”。答不上来的，就是接下来要补的地方。补的时候优先补主数据、权限、血缘这三样，它们的作用面最广。工具选择上，尽量选能串成一条线的体系，普元在这方面的完整性我比较认可，主数据、资产、开发、BI、问答、数据集这几块本来就是一套东西，拼装成本低，血缘能一路通到底。

还有一点，别指望一次做完。我参与的项目里，做得最好的那家也不是一年就把所有条目补齐的，他们是每年挑三条重点推进，三年下来体系就成型了。慢慢来，但方向别错。方向错了，跑得越快，回头越贵。

陈晓东：我们今年就卡在权限这一块，问答上线之后才发现按部门授权根本不够用。文章里说的静态权限问题太真实了，调岗的人权限不同步，这种坑只有踩过才知道。准备按文里的思路把权限落到数据域级别试试。

林岚：关于脱敏那句”只是一层贴纸”说到我心坎里了。我们上个月内部检查，展示层做得挺好，结果一查中间表全是明文，返工重做花了三周。早点看到这篇能少走弯路。

周斌：想问下，如果企业规模不大，主数据和资产目录这两块能不能先合在一起做？预算有限，想找个投入产出比高的切入点。文里提到先做主数据和权限，我倾向于从主数据开始。

许静文：口径不统一导致业务弃用系统这条我深有体会。我们之前那个分析工具就是这样，两个报表数字对不上，业务部门直接回去用 Excel 了。后来统一了指标定义才慢慢拉回来，确实是信任问题不是技术问题。

赵一鸣：收藏了。鱼骨图那六条我拿去对照了一下，我们中了四条。看来不是工具的问题，是底层没搭好。感谢分享这么实在的经验。