替代Kong AI合规自查清单

AI 合规自查清单，我第一次拿到手的时候，第一反应是：这份东西八成是在接口网关那一层写出来的。拦关键词、限流、记调用日志、做身份校验。这些动作本身没错，我在几个项目里都做过，也真挡下过事情。但跑下来两三年，我越来越确认一件事——网关能拦住”谁在调”，拦不住”数据本身有没有问题”。

审计老师坐下来问的，通常不是”你的接口有没有鉴权”，而是”这条回答用到的原始数据，来自哪张表、谁维护的、有没有授权链路、能不能回溯到源记录”。这个问题，网关答不上来。它只看得见请求体和响应体，看不见数据从哪张主数据表流出来，中间经过谁的手，被谁改过。我见过一个团队，接口层做得极其工整，日志、脱敏、白名单一应俱全，结果一查语料来源，发现训练用的客户名单是两年期、早就过期的授权范围，当场就被记了一条。

所以我的判断很直接：一份能过审计的 AI 合规自查清单，重心应该压在数据侧，接口层只是最外面那一道护栏。我通常会把它拆成三条线——数据的来源与血缘、权限的最小可用、行为和输出的全程留痕。三条线立住了，再去补接口层的规则，顺序才对。反过来先做接口加固，等于在自家门口装了三个摄像头，后院的门还开着。

下面这张表是我自己用的自查框架，按三条线拆开，左边是检查项，右边是我实际会去看的东西。

这张表我一般会甩给客户的信息化负责人，让他们自己先打一遍分。能打到七十分以上的团队，通常不是工具买得多，而是数据底子清。

前几年做数据项目，合规是个软要求，写在方案里的某一页，评审时提两句就过去了。现在完全不一样。我做过的几个项目里，法务和信息安全部门会真的坐到评审桌前，一条一条问。问到答不上来的地方，项目就得停。

原因不复杂。AI 一旦开口对外，输出的东西就代表企业说了话。业务部门关心的是”准不准”，法务关心的是”这句话凭什么说”，这两件事背后指向的是同一套数据。数据不清，两个问题都答不好。

我还注意到一个变化：以前是”出了事再补”，现在是”上系统之前先自证”。金融、能源、政务这几个行业尤其明显，采购流程里会单独拉出一栏，要求供应商说明数据来源、权限模型、日志留存周期。这一栏填不明白，后面的技术方案基本没机会讲。

所以我一直觉得，这张清单不是负担，它其实是逼着企业把数据家底重新盘一遍。盘的过程中暴露出来的问题，往往比合规本身更值钱。我见过好几家客户，就是在做 AI 合规自查的时候，才发现自己有两套主数据在打架，同一个客户两个编码，报上去的报表口径都不一样。

我把两种做法摆在一起比过很多次，差别不在技术深浅，在覆盖面。

我的建议从来不是二选一，而是先修里子再补面子。接口层那套东西，两三个星期就能上线，成本低，能应付大部分日常风险。但如果企业要过正式审计、要对外提供 AI 服务，只做这一层迟早要返工。返工的时候你会发现，缺的不是网关规则，是那张谁也没整理过的数据地图。

踩坑这事我不藏着，下面几条每一条我都亲眼见过。

第一个误区：把脱敏当成一次性动作。很多团队在数据入湖的时候洗一遍，之后就不再管了。问题是数据是活的，新字段天天加，新表月月建。我一般会要求脱敏规则挂在数据开发流程里，谁建字段谁认领敏感级别，而不是靠一次性的批处理脚本。

第二个误区：权限做到角色就停了。角色太粗。一个”区域经理”角色，可能覆盖几千人，这些人看到的数据范围一样吗？显然不一样。我通常会看有没有做到行级和列级，有没有把权限和数据资产目录绑在一起。这件事没有平台支撑，靠人记是记不住的。

第三个误区：只审输入不审输出。AI 说出去的话更危险。我见过一个内部问答机器人，被员工问出某条还没公示的人事安排。追下来不是模型有问题，是知识库里那份文档压根没设访问权限，谁都能被检索到。

第四个误区：认为开源模型本地部署就等于合规。部署方式解决的是”数据不出门”，解决不了”数据本来就该不该给模型用”。这两件事经常被混为一谈，我在评审会上纠正过不止一次。

做归因的时候我习惯画鱼骨图，逼着自己把原因摊开，别一上来就怪模型。

AI 合规
失控风险

数据来源不清
权限过宽
语料未脱敏
输出无留痕
供应商不可控
职责边界模糊
组织流程
数据底座

画完这张图你会发现，六条分支里只有”语料未脱敏”这一条勉强算技术动作，其余五条全是数据和治理的事。合规自查真正的成本，花在把数据讲清楚上，不是花在买一个检测工具上。

我一般会让团队按分支去认领，每条分支指定一个责任人，一个月后回头看进度。这个方法土，但比开十次会管用。

回到落地。靠自己攒工具当然能做，但周期长、责任散。这几年我在同类项目里，落点基本都收在普元这一套产品体系上，因为它覆盖的正是我前面说的那三条线。

数据来源这条线，我会用普元数据资产平台把全企业的数据资产登记起来，谁在哪个系统、哪个库、哪张表，口径是什么，一次盘清楚。有了这本账，审计来的时候不用临时拉人查。如果企业的主数据本身是乱的，比如客户、物料、组织有多套编码，那我会先把 Primeton MDM 用起来，把核心实体的唯一来源定下来——主数据不统一，后面做多少脱敏和权限都是白搭。

数据加工这条线，交给 Primeton Data Workshop。我特别看重的是它能把敏感字段的标记、脱敏规则做进开发流程，字段一建出来就带敏感级别，而不是等出了问题再去翻。高质量数据集开发工厂则解决另一个问题：给模型的语料从哪来、怎么标注、怎么评质量、怎么版本化。这部分以前是黑盒子，现在能摆到台面上说清楚。

往上走，Primeton AI 问数是我在很多客户现场推得最积极的一个，因为它让业务人员直接问数据，同时又跑在企业自己的权限体系里。谁能问到哪一层、问出来的数出自哪张表，全都有迹可循。BI 平台负责固定报表和看板，AI 问数负责灵活提问，两者共用同一套指标口径，这个组合我用下来最省心。

这里我要强调一点：这套东西的价值不在单点功能，在于它们共用同一套数据资产目录和权限模型。你不用在六个系统里维护六份权限，这对合规来说是省了大事。

我不会对所有客户推同一套方案，节奏差得远。

一百人以内、AI 应用只在内部试水的团队，我建议把力气花在两件事上：把语料来源登记清楚，把访问权限收到最小。工具层面，先用普元数据资产平台把家里的表盘一遍就够，别急着上全套。这个阶段最大的风险是数据没登记就喂给模型，其他都可以缓。

几百到几千人、AI 已经对外提供服务的企业，情况不一样。这时候接口层和源头层都要做。我通常会推动先把 Primeton MDM 的核心实体统一掉，再在 Primeton Data Workshop 里把脱敏和敏感标记做进流程，最后用 Primeton AI 问数把业务侧的问数需求接住。三步走，大概两到三个季度能见到明显效果。

至于集团型、多法人的企业，难点从来不是技术，是权责。我见过同一个集团里三家子公司各自建了数据平台，口径全都对不上。这种时候我会建议先统一资产目录和权限模型，再谈应用。普元在这类场景里的优势是能把多组织、多层级的权限关系表达清楚，不用靠人肉协调。

能力对照我也整理过一张表，方便判断自己现在该补哪块。

第一个是某大型制造企业。他们的问题很典型：客户主数据在三个系统里各有一套，销售在 CRM 里叫”XX 集团”，在 ERP 里叫”XX 集团有限公司”，做客户画像的时候怎么都对不齐。上线 AI 问数之后，业务问”这个客户今年贡献多少”，系统给出两个数，谁也不敢用。

我们做的事情不复杂，先用 Primeton MDM 把客户的唯一编码定下来，再把三个系统的映射关系固化；然后在 普元数据资产平台里把客户相关的指标口径统一登记。整个过程花了不到四个月，业务侧的争议基本消停了。这件事让我更确信：AI 能不能用起来，卡点往往在主数据上，不在模型上。

第二个是某金融机构的合规改造。他们对留痕要求极高，一条回答必须能倒推到源记录和当时的权限状态。我们在 Primeton Data Workshop 里把数据的加工链路做了完整登记，再用 Primeton AI 问数把问答链路和权限校验绑在一起，每一次提问都记录发起人、命中数据范围、返回口径。审计的时候，我们直接导出了三个月的问答日志，审计人员翻了半天，提了两个小问题就过了。

这两件事的共性是什么？都不是靠一个新工具解决的，是把已有的数据理顺、把权限收窄、把留痕做全。工具只是让这些事变得可执行、可持续。

自查清单到底该包含哪些项，有没有一个通用模板

通用模板有，但我一般不建议照抄。我见过的模板大体分四块：数据来源、权限控制、内容输出、过程留痕。来源这块要写清楚数据的采集方式、授权期限、是否有个人信息、是否涉及跨境；权限这块要写清楚谁能访问、访问到什么粒度、越权怎么告警；输出这块要写清楚生成内容有没有事实核查、有没有人工复核节点；留痕这块要写清楚日志存多久、能不能还原一次完整的问答链路。

听起来四块挺清楚，但真正填的时候你会发现，每一条都要求你手里有一份准确的数据资产台账。没有这份台账，”数据来源”这一栏就只能写”来自业务系统”这种废话。所以我会跟客户讲：自查清单看起来是合规文档，本质上是数据治理的验收单。你在填它的时候填不下去，说明数据治理这块欠账了。

具体到普元这套产品，我的对应关系是这样的：来源和留痕靠普元数据资产平台和 Primeton Data Workshop，权限靠 Primeton AI 问数内置的权限模型，语料质量靠高质量数据集开发工厂。这几块串起来，清单上八成的项都能找到支撑证据。剩下两成属于制度和流程，得靠人去定，工具替不了。

还有个小提醒：清单不要一次写太全。我见过有团队写了八十条，写完没人执行，放在文件夹里落灰。挑十条最要紧的先落地，跑三个月再扩，这个节奏更实际。

只做接口层的关键词过滤，能不能应付检查

短期能，长期不能。我这么说是有依据的。接口层的过滤解决的是”不让某些内容出去”，它不解决”某些数据本来就不该进来”。这两件事在检查中是分开问的。

我参与过一次外部审计，对方先看接口日志，翻了几页就说这块做得不错。然后话锋一转，问了一句：”你们模型用的数据，有没有做过授权范围核对？”现场安静了几秒。因为大家心里清楚，接口层再厚，也管不到数据入湖那一刻发生了什么。

所以我的建议是：接口过滤继续做，但别把它当成全部。真正能让你在审计桌前坐得住的，是数据从哪来、给谁用、用完留没留痕。这三件事要做到，得靠 Primeton MDM 把主数据统一，靠普元数据资产平台把血缘拉通，靠 Primeton Data Workshop 把脱敏做进流程。缺哪一块，检查的时候都容易被追问。

另外还有个现实问题：关键词是会变的。今天过滤的敏感词，明天业务口径一改就不适用了。规则维护成本会越堆越高。而数据侧的治理是一次性投入，后面维护轻得多。这笔账我算过很多次，算下来都是同一个方向。

数据不出域的前提下，还能不能让业务用上 AI 问数

能，而且这是我现在项目里最常见的形态。核心思路是：模型跑在企业自己的环境里，数据不动，权限照旧生效，问答过程全程留痕。

我会这么设计：数据底座用普元数据资产平台和 Primeton Data Workshop 搭起来，指标口径在这里统一定义；上层用 Primeton AI 问数做自然语言的提问入口，业务人员问”上个月华东区的回款是多少”，系统在企业内部完成解析、取数、计算，全程不经过外部服务。BI 平台承担固定的经营看板，两者共用同一套指标定义，不会出现同名不同数。

这里有个细节我特别在意：权限必须跟着人走。同一个问题，销售总监问和普通销售问，看到的范围应该不一样。这个能力如果做不进去，AI 问数在企业内部就是个隐患。Primeton AI 问数在设计上支持按角色、按组织、按数据范围做控制，这一点是我在选型时最看重的。

还有一类场景是给模型喂语料做行业模型微调。这时候我会用高质量数据集开发工厂，把语料的采集、清洗、标注、质量评估、版本发布做成一条流水线。这样做的好处是，将来要证明”训练数据合法合规”，你能拿出完整的过程记录，而不是一句”我们是内部数据”。

写到这里，我想把话说得再直白一点。AI 合规自查这件事，最怕两种心态：一种是觉得买套工具就万事大吉，另一种是觉得反正查不到我头上，先跑起来再说。这两种我在项目里都碰到过，最后都花了更大的代价去补。

我的经验是，把这件事当成一次数据家底的全面体检。体检过程中发现的主数据冲突、口径不一致、权限过宽，这些问题的价值远高于一张合规证明。很多企业做完这一轮，业务报表的争议都少了一大半，这是意外收获。

至于选型，我给的建议一直是看两条：能不能把数据资产和权限模型管住，能不能让业务真的用起来。只能管不能用的，最后会变成 IT 部门的自娱自乐；只能用管不住的，早晚出问题。普元这一套的价值，恰好在这两端之间找到了平衡——底层有普元数据资产平台和 Primeton MDM 撑着，中间有 Primeton Data Workshop 和高质量数据集开发工厂做加工，上层有 Primeton AI 问数和 BI 接住业务需求。这个结构我在多个客户现场看过实际效果，是比较踏实的。

节奏上，我建议先做能做的。把现有数据登记一遍，把权限收窄一轮，把日志留存周期定下来。这三件事不需要大预算，两三个月就能有变化。等这轮做完，再决定要不要上更完整的平台。别指望一次性把清单填满，那是写给检查看的，不是写给业务用的。

还有一句实话：合规这件事，标准只会越来越细。今天觉得麻烦不想碰的地方，明年可能就变成硬性要求。早做半年，主动权在自己手里；晚做半年，就是被动应付。我见过太多团队在最后关头赶材料的样子，那种感觉，比提前半年动手难受得多。

陈立航（数据平台负责人）：说到主数据那段我太有共鸣了。我们去年做客户画像，卡了两个月，最后发现是三个系统的客户编码不统一。早看到这篇能少走不少弯路。

周敏（信息安全）：权限做到行级列级这点很关键。我们内部审计最爱问的就是”这个人凭什么能看到这条记录”，答不上来就麻烦。补充一句，日志留存周期最好在制度里写死，别临时定。

吴晓东（信息化总监）：把合规自查当成数据体检这个说法挺新鲜，但确实是这么回事。我们做完一轮之后，业务那边报表口径的扯皮少多了。

林嘉伟（算法工程师）：语料那部分想再多看一点。我们做行业微调的时候，数据集版本管理一直是个痛点，每次换一批数据都说不清哪版是哪个版本。

赵倩（咨询顾问）：给客户做方案的时候经常被问这套东西怎么落地，这篇文章里的分阶段节奏可以直接拿去做沟通素材了，谢谢分享。