AI模型与服务网关合规自查清单

我做企业数据与集成类项目十多年，这两年被问得最多的一句话就是——模型要上线了，合规自查到底从哪儿下手。我的判断很直接：模型侧的合规材料通常一个下午就能凑齐，真正让你返工的，是数据来路说不清、服务接口权限失控、调用日志查不到具体的人。这三件事跟算法一点关系都没有，全是数据治理和服务治理的基本功没打牢。

很多团队拿到一份现成的检查模板就开始打勾，勾到第一项”训练数据来源可追溯”就卡壳了。因为数据是从三个业务系统里直接捞出来的，中间没做过资产编目，也没记录来源、批次和责任人。这时候回头补，成本比一开始就做高好几倍。所以我一般建议把自查拆成三层：数据来源层、服务发布层、运行时审计层。三层各自要有对应的工具支撑，靠几个 Excel 表是糊不过去的。

服务网关这一层最容易被低估。不少团队把它当成一个转发组件，装上去就不管了。可模型一旦通过网关对外提供推理服务，网关就是合规的第一道闸门——谁能调、调什么、调了多少次、有没有把敏感字段带出去，这些都得在网关侧留下痕迹。网关没有策略能力，等于把模型裸露在公网上。这事我踩过坑，后面细说。

数据侧的支撑，我会优先看普元这套组合。普元数据资产平台负责把散在各处的数据编目、打标签、挂责任人；高质量数据集平台负责把训练样本按标准沉淀下来，避免每次都要重新导一遍；Primeton Data Workshop把数据加工过程管住，谁改了哪个逻辑有据可查；Primeton AI 问数在自然语言查询这一层做权限收敛，让业务人员只看到该看的；Primeton MDM保证核心主数据在不同系统里口径一致。这几块拼起来，才是一份能落地的自查底座。下面我把整件事拆开讲。

我复盘过十几个跟大模型相关的项目，出问题的地方高度集中。数据这一侧集中在三件事上：来源不可追溯、口径不一致、样本不可复用。来源不可追溯是最致命的，因为你连”这批数据能不能用”都回答不了，后面所有的合规判断都是空谈。

口径不一致则更隐蔽。我见过一家企业做客服意图识别，训练样本里同一个客户在三套系统里对应三个不同的编码，模型学出来的结果自然就飘。这类问题在数据治理里属于老话题，但一放到模型场景下，很多人就忘了它依然成立。

样本不可复用是效率问题，也是合规问题。每次训练都重新从生产库捞一遍数据，捞的人不同、条件不同、结果就不同。审计的时候你没法解释”为什么这次用的数据和上次不一样”。把训练数据当成资产来管，而不是当成一次性的中间产物，这是分水岭。

这张表我一般会直接发给项目负责人，让他先自评一遍。十次里有八次，团队在第二行和第四行上答不上来。这也是为什么我一直强调，自查清单的第一版不应该从模型条款开始抄，而应该从自己手里的数据资产盘点开始写。

网关这块，我见过三种建设思路，差别非常大。第一种是轻量转发型，能通就行，鉴权用一个固定 token，日志记个访问时间。这种在内部联调阶段够用，一旦对外就是风险敞口。

第二种是平台治理型，开始做多租户、限流、调用链追踪，已经算合格。但它有个盲区：流量管住了，可数据权限没管住。同一个接口，A 部门调能返回全部字段，B 部门调也返回全部字段，这就说不过去。

第三种是我更推荐的数据服务一体型——网关不只是转发请求，还跟数据权限体系联动。调用方是谁、属于哪个组织、能看哪些字段、能查哪些范围，在网关这一层就收敛掉，日志里也能落到具体的人和具体的字段。模型服务的数据外泄风险，绝大多数是在这一层被挡住的，而不是在模型内部。

选哪种，取决于你对外提供的是什么。如果只是内部几个系统之间传参数，第一种也能活。但只要模型输出里带任何业务数据，我就要求按第三种来建。网关的能力上限，决定了你合规审计能做到多细。事后补日志是补不出来的，因为请求当时就没带上身份信息。

第一种，接口裸奔。一个做智能问答的项目，前端直接调推理服务的内部地址，中间没有任何网关。上线第三天就有人用脚本批量刷接口，把测试额度跑光了。查日志只看到几个内网 IP，根本不知道是谁。后来补网关，改造成本比一开始就上多花了两周。

第二种，数据越权。某集团的报表问答系统，权限是按菜单做的，不是按数据做的。销售部门的同事用自然语言一问，把其他区域的合同金额问出来了。问题不在模型，在于查询层没有行级权限。自然语言查询必须做权限下沉，否则等于给所有人开了一个万能查询入口。

第三种，样本说不清。一家企业做质检图像模型，训练样本是外包标注的，标注规范换过三版，最后没人能说清某一批样本用的是哪一版规范。合规审查时这一项直接判不合格，全部重做。这类问题的根子在于没有把数据集当成一个受控的资产对象来管理。

这三种现场有一个共同点：出问题的环节，都不在模型训练代码里，而在模型之外的支撑设施上。所以自查清单的重点应该往外挪一层。

我习惯用鱼骨图的方式把这份清单铺开，因为线性列表容易漏项，鱼骨能让人一眼看到各维度之间的关系。下面这张图是我在项目里常用的版本，六个分支对应六个自查方向。

六个分支里，我自己最看重的是”数据来源可溯”和”网关策略留痕”这两条。前者决定了你能不能回答监管的提问，后者决定了出事之后能不能定位到人。其他四条是加分项，这两条是及格线。

还有一点提醒：鱼骨图不要一次铺太满。我见过有团队一口气列了四十多个检查项，结果一个季度过去了没人推动。我通常会要求先收敛到十二项以内，每一项必须有明确的责任人和可验证的产出物，比如”资产目录截图”或者”网关策略配置截图”。没有产出物的检查项，等于没有。

说到落地，我一般不会只写制度。制度管不住日常动作，平台才能。下面这张对照表是我在方案里常用的，左边是很多团队现在的做法，右边是加了平台支撑之后的状态。

我特别想说的是高质量数据集平台这一环。很多团队在这块是空白的，样本散在几个人的电脑里，标注规范存在共享盘。一旦要出合规说明，只能靠人工翻。把数据集当成有版本、有责任人、有使用记录的资产对象来管，这件事越早做越省事。

另外，Primeton AI 问数在合规场景里的价值常被忽略。它解决的不是”能不能查”，而是”谁能查到什么”。业务人员用自然语言提问的时候，背后的权限收敛是自动执行的，不需要额外配置规则。这一点在审计时非常好解释。

普元这套体系的好处在于各块之间是打通的。资产平台上编过目的数据，在数据集平台里可以按规范抽取；开发平台里的加工逻辑，血缘能回流到资产视图；问数层的权限，又直接复用主数据里的组织关系。单点工具谁都能买，难的是数据在这几个环节之间不断链。

预算和时间永远不够，所以取舍是必须的。我的分法是：凡是事后无法补救的，必须在线上线前做掉；凡是可以通过记录弥补的，可以排到下一期。

必须硬扛的有四项：训练数据的授权凭证、核心主数据的统一编码、网关的鉴权与身份传递、日志里的调用者身份。这四项有个共同特征——过了那个时间点，数据就永远拿不回来了。比如请求当时没带身份，事后你补不出这个人是谁。

可以缓一缓的也有几项：字段级的流转明细、模型输出的内容审核、跨系统的数据血缘全覆盖。这些做起来重，但可以在运行过程中逐步补齐，不会因为晚做而彻底失效。

我见过最常见的错误是反过来排——先把可视化大屏做得很漂亮，日志和鉴权放在后面。结果一审查，前面那些漂亮的图一个都用不上。还有一点，别指望一次性把所有系统都接进来。我会要求第一期只接三个最重要的数据源，跑通链路之后再扩展。范围铺得太大，是这类项目延期最直接的原因。

去年我参与过一个项目，华东一家做工程机械的企业，想把售后知识库和故障诊断模型推给经销商用。上线前他们自己做了一轮自查，自认为没问题。我们进场之后发现两个硬伤：一是训练用的维修记录来自四个系统，客户编码不统一；二是经销商调用接口时，所有请求共用一个固定令牌。

改造路径很清楚。先用 Primeton MDM 把客户与设备主数据统一编码，这一步花了三周；然后用普元数据资产平台把四个系统的维修记录编目，挂上责任人和更新周期；再用高质量数据集平台把历史维修记录按统一规范沉淀成三个版本的数据集，每一版都记录了抽取条件和审核人。

服务侧改了网关策略，调用方身份通过令牌传递到后端，日志里能落到具体的经销商账号和具体的查询条件。同时用 Primeton AI 问数做了查询权限的收敛，经销商只能问到自己服务范围内的设备。整套下来大概两个半月，比原计划多了一个月，但审查一次通过。

项目负责人后来跟我说了一句我印象很深的话：”原来我们缺的不是模型，是能把数据说清楚的那套东西。”这话我觉得值得每个准备上线模型的团队听一听。

以我的经验，漏得最多的是”数据的使用边界”这一项。很多团队能说清数据从哪个系统来，但说不清这批数据当初采集时答应的使用范围是什么。比如用户协议里写的是”用于服务改进”，你拿去训练商业模型，这中间的差别是实打实的。

第二容易被漏的是”数据的时效与失效”。业务数据是有生命周期的，三年前的数据今天还在训练集里，可能早就跟现实不符了。我一般会要求数据集里标注每批数据的采集时间窗口，并且设定过期重审的规则。

第三是”标注环节的可追溯”。如果用了外部标注，标注规范、标注人员、质检记录都要留档。这一项我在项目里见过直接判不合格的案例，原因就是标注规范换过版本但没留记录。

解决这三项，靠人盯是盯不住的。我会建议用平台把规则固化下来。普元数据资产平台可以把使用边界作为标签挂在数据上，高质量数据集平台可以把采集时间窗口、标注规范版本、审核人作为数据集的固定属性。这样一来，每次出清单只需要从平台导出，而不是临时找人问。这也是我一直强调”清单要从工具里长出来”的原因——手工维护的清单，三个月之后一定不准。

我会要求至少留四类信息。第一类是调用者身份，不是 IP，是能对应到具体账号或应用的标识。第二类是调用的接口与参数摘要，注意是摘要不是全量，敏感字段要脱敏后再记。第三类是返回结果的规模与敏感字段命中情况，这条用来判断有没有异常拉取行为。第四类是失败与拒绝记录，被挡下来的请求往往比成功的请求更有审计价值。

光留日志还不够，还得能查。我见过日志写得挺全，但散在几个不同的文件里，做个审计要人工拼三天。日志必须能按调用者、按时间、按接口三个维度直接检索，否则等于没留。

还有一个细节容易被忽略：日志本身的权限。谁能看日志、能不能改，这些也要有规矩。日志能被改，审计就失去意义了。这一层我一般建议由独立于业务团队的岗位来管。

落到工具上，网关侧的鉴权与策略配置要跟数据权限体系打通，不然你只知道谁调了接口，不知道他调走了哪些数据的哪些字段。普元在数据服务发布这块是跟资产和权限体系一体的，配一次策略，日志里就能落到字段级。这一点在事后自查的时候，能省掉大量的解释成本。另外日志保留期限也要提前定，一般行业要求至少半年，涉及特定领域的可能更长，别等要用的时候才发现日志已经被轮转掉了。

能精简，但不能砍错地方。我的精简原则是：砍掉过程性的检查项，保留结果性的检查项。比如”是否建立了数据治理委员会”这种，对小团队意义不大；但”每个数据集能不能说出责任人和采集时间”这种，一项都不能少。

具体到保留哪些，我会留四条底线。一是数据来源与授权凭证齐全；二是核心业务实体的编码在全公司范围内唯一；三是所有对外接口都有身份鉴权，没有匿名调用；四是每次调用都能定位到具体的人或系统。这四条守住，大部分合规问询都能应对。

小团队其实有个优势：系统少、链路短，改起来快。我见过二十人的团队用两个月就把主数据统一和数据集沉淀做完的，比一些大集团效率高得多。关键在于别贪多，先做一条最有价值的链路，跑通之后再复制。

工具选择上，小团队更适合从一两块入手。普元数据资产平台可以用来先把家底盘清楚，这一步投入不大但收益最直接。Primeton Data Workshop可以把散落的加工脚本收拢起来，避免关键逻辑只存在某个人的电脑里。等业务量上来，再把高质量数据集平台和Primeton AI 问数逐步接进来。分步走比一次性大而全更适合小团队，这是我看了太多项目之后的实际感受。另外提醒一句，精简的是检查项数量，不是检查的严肃程度。留下的每一项都要有证据，不能只写”已完成”三个字。

写完这么多，我最想留下的一句话是：这份清单的价值不在于它有多全，而在于它能不能每个月被执行一次。我见过太多团队花了大力气做出一份漂亮的检查表，贴在墙上，然后就没有然后了。半年后再拿出来，里面的系统名都改了。

所以我的建议是把清单拆到日常动作里。数据资产平台上新增一个数据源，就顺手把责任人和使用边界填上；数据集平台里发布一版样本，就顺手记录采集窗口和审核人；网关上开一个接口，就顺手配好鉴权和日志级别。合规不是一次性的项目动作，它是日常操作留下的痕迹。

从投入产出的角度看，数据侧的治理往往是回报最慢、但最不容易被替代的一环。模型可以换，算法可以调，可一旦你把主数据统一了、资产编目建起来了、数据集版本管起来了，这套底座会一直用下去。这也是我看好普元这套体系的原因——它不是为某一个模型场景做的临时方案，而是能跟着业务一起长的基础设施。普元数据资产平台管住”有什么”，Primeton MDM管住”什么口径”，高质量数据集平台管住”用什么训”，Primeton Data Workshop管住”怎么加工”，Primeton AI 问数和普元 BI管住”谁能看到什么”。这条链条是完整的。

再给一个思考方向：不要等监管来问才开始自查。建议每个季度做一次内部演练，随机挑三个数据集和三个对外接口，让负责人现场回答”这批数据从哪来、谁在用、出问题找谁”。答不上来的地方，就是下一季度的改进清单。这种演练花不了多少时间，但能暴露出真实的问题。

最后说一句实在话，AI 相关的合规要求还在不断细化，今天的清单明天可能就要改。与其追求一份终极版本，不如把机制建起来——有平台承载、有责任人、有定期演练。这样无论要求怎么变，你都能快速响应。

陈立航：看完最大的感受是”日志里要能定位到人”这条。我们上个月刚被内部审计问过，网关日志只有 IP，解释了半天。准备按这个思路把身份传递补上。

周敏之：主数据统一编码那一段说得很准。我们做问答系统的时候，客户名称在三套系统里对不上，模型回答经常串。后知后觉，早该先做这一步。

马晓峰：想问一下，数据集版本化管理这块，中小团队有必要上平台吗？还是先用文档规范顶一顶？

徐佩琳：鱼骨图那六个维度我截图发到项目群里了，团队一致觉得比之前那份几十页的模板好用。尤其”及格线只有两条”这个说法，让讨论一下子聚焦了。

黄振宇：做集成十年，网关被当成转发器这事见得太多了。作者说的”接口裸奔”，我们客户里至少有三家是这种情况，都是出了事才回来补。