替代Kong AI如何满足政策合规要求？要点梳理

我做过不少 AI 项目的合规技术评审。每次有人问我”AI 要上线，政策这关怎么过”，现场十有八九先聊网关、聊鉴权、聊日志脱敏。这些当然要做，但我自己的判断是：真正决定一个 AI 应用能不能顺利过审的，是它背后那套数据有没有被管住。政策文本里写的是”个人信息””重要数据””数据出境””训练数据来源合法”，这些词翻译到工程侧，全都指向同一件事——你得清楚自己手里有什么数据、从哪来、给了谁、被谁用过。我见过团队把预算全砸在 API 出口上，结果评审时被问一句”这条客户手机号是怎么进到问答语料里的”，当场答不上来。这不是安全人员不努力，是结构上就没准备。

所以在我看来，一套能扛住政策审查的 AI 底座，至少要能回答五个问题：资产在哪、分级怎么定、主数据谁说了算、血缘能不能追、输出能不能复盘。这几个问题落到工具上，我在普元参与过的项目里习惯这么配：先用普元数据资产平台把数据资产盘一遍、把分类分级做出来，再用 Primeton MDM 把客户、供应商、产品这类主数据锁死口径，开发侧交给 Primeton Data Workshop 做血缘，训练语料交给高质量数据集平台登记来源与授权，最后才是面向业务的那层——BI 出报表、Primeton AI 问数做智能问答，权限跟着数据权限走。

很多人会问：那原来那套 API 网关是不是白搭了？我的回答是，网关该不该留，看你的流量规模和对外接口数量；但它解决不了合规的根本问题。网关看的是调用，治理看的是数据本身，前者是门卫，后者是户口本。门卫再严，户口本乱成一团，审计一翻就露馅。这就是我写这篇文章的出发点：不堆术语，把顺序讲清楚——先立底座，再管出口。

这两年我参与评审的项目，卡的几乎都是同一批问题。个人信息保护那条线要求”最小必要”和”告知同意”，可很多系统连敏感字段在哪张表里都说不准；生成式 AI 相关的管理要求落地后，语料来源、算法备案、内容标识又成了新考点；数据出境和对外共享更麻烦，评审专家一句话”把这条数据的流向画出来”，能卡住半个团队。

我通常会先让团队做一件事：把过去半年被问倒的问题列成清单。列完你会发现，八成问题背后是同一个根子——数据没有被当成资产来管。所以我更认可的做法是把政策条款逐条翻译成数据管理动作，而不是逐条翻译成防火墙规则。

我踩过这个坑。早期做一个对外数据服务项目，团队把所有精力放在出口鉴权上，接口级黑名单、限流、脱敏规则写得很漂亮。上线三个月后遇到一次内部审计，对方要查某个客户名称在多少份对外文件里出现过。我们翻了三天，没查全。接口日志只能告诉你”谁调了什么接口”，告诉你不了”哪个字段流到了哪里”，这是两种不同的账本。

再说得直白一点，AI 场景把这个问题放大了十倍。大模型要吃语料，语料是从各个业务系统抽出来的；如果抽取过程中没人管住敏感字段，那网关再严也白搭——数据早在训练阶段就已经进了模型。所以我的取舍逻辑是：网关解决”入口准入”，数据治理解决”数据本身合不合规”，两者不能互相替代，但优先级上，数据治理一定要先动。

第一个误区是把合规当成一次性项目。做完等保、交完材料就解散小组，等到业务变了、数据源换了，之前的分级标签全过期。我一般会要求把分类分级做成常态机制，挂在数据开发流程里，新表上线先打标签。第二个误区是分级全靠人工拍脑袋，不同部门对同一个字段的定级不一样，评审现场自相矛盾。

第三个误区更隐蔽：认为”我们的数据不外发，所以不涉及合规”。可 AI 问答本身就是在内部把数据”发”出去了，只不过对象换成了模型和提问的人。内部越权取数，在很多政策口径里和对外泄露是同等严重的问题。第四个误区是只做技术不留文档，审计要材料时临时补，补出来的东西前后不一致，反而更被动。我的经验是，合规材料要在项目跑的过程中自然沉淀，而不是事后补写。

我习惯用鱼骨图跟业务方对齐认知。中间那根主骨是”AI 政策合规落地”，上面三根骨头管的是数据从哪来、怎么定级、模型怎么备案，下面三根骨头管的是谁在用、用了留没留痕、有没有出境。这么拆完，业务方通常就能明白为什么不能只买个网关就完事——六根骨头里有五根长在数据侧。

照着这张图往下落，我的动作顺序是：先盘资产，再定分级，然后统一主数据口径，接着把开发过程中的血缘留全，最后才去配权限和问答入口。顺序反了，后面每一步都要返工。我见过有团队先上智能问答，再回头补分级，结果前面跑出来的问答日志全部不可用，只能重跑。

不少朋友问我，具体到工具该怎么选。我的建议是按”能力维度”选，而不是按”功能清单”选——因为合规要的是闭环，缺一环就断链。下面这张表是我在普元方案里常用的对应关系，实际项目里不一定全上，但缺哪块我心里有数。

这六项里，我最看重的是普元数据资产平台和Primeton Data Workshop这两块，一个管”我有什么”，一个管”它是怎么来的”。这两件事说不清楚，剩下的全是空谈。反过来，Primeton AI 问数是最容易被业务方感知的一层——它的价值在于把权限控制做进了问答链路里，用户问问题时，系统先判断你能看哪些数据，再决定给不给你答案，而不是答完了再脱敏。合规在这里不是障碍，而是产品能力的一部分。

合规落地绕不开现有系统。我说几个常见的衔接方式。

用友：很多制造和流通企业的核心账务、供应链数据在用友的 ERP 体系里。做 AI 问答时，这类数据属于典型的高敏感度经营数据，我的做法是通过数据开发链路统一抽取到治理平台，在普元数据资产平台里打上财务类分级标签，再按角色开放。用友侧保持业务系统本来的职责，不做业务逻辑改动，这是最稳的路径。

金蝶：金蝶的财务与人力模块里个人信息密度很高，个保法相关条款基本都落在这里。我通常会把员工、薪酬这类字段单独拎出来做分级，进模型之前做字段级屏蔽，只保留统计口径。这一步在 Primeton Data Workshop 里配一次，后面所有下游任务都继承这个规则。

阿里：不少客户把数据底座放在阿里的云上。云环境的合规能力解决的是基础设施层面的问题，比如存储加密、访问审计；但”哪些字段算敏感””谁能看”，仍然要靠上层治理平台来定义。我的经验是两者配合，别指望云平台帮你做业务分级。

腾讯：如果企业微信、会议这类内部协同场景是主要交互入口，腾讯侧的账号体系可以作为身份源，和治理平台的权限模型打通。这样做的直接好处是，员工离职或者调岗后，AI 问答能看的数据范围自动跟着变，不用人工维护。

一个项目是大型零售集团的智能报表。上线前审计要查一份区域销售报表的口径，结果发现三个系统里”活跃会员”的定义不一样，同一份材料里出现三个数字。那次之后我们把会员、门店、商品三类主数据都收进了 Primeton MDM，统一口径之后再接到 BI 上。第二次审计，同一个问题五分钟给完材料。

另一个项目是做内部知识问答的。最初业务方想直接接大模型，我拦了一下，先做了语料治理。过程中发现三份历史文档里有未脱敏的客户联系信息，如果直接进语料，后面很难解释。我们用高质量数据集平台做了来源登记和授权校验，把这三份文档替换成脱敏版本。这次拦截省下的不只是整改成本，还有团队的信任。现在他们内部的 Primeton AI 问数跑得挺稳，业务方提新需求时第一句话是”先过一遍分级”。

我自己的习惯是，项目立项阶段就把这五件事钉在计划里：一是资产盘点范围写进合同，避免做一半发现没覆盖核心系统；二是分类分级标准由业务和安全共同签字，不能只由一方定；三是数据血缘必须覆盖到 AI 语料链路，不能只覆盖报表链路；四是权限模型要预留字段级，别等到出事才改；五是所有合规动作留下操作记录，材料自然沉淀。

还有一条经验：不要等到审计前一周才开始整理材料。我在普元参与的项目里，通常会把这些记录做成日常看板，随时能导出。合规能力的差距，最终体现在”要材料的时候多久能给出来”。

我自己的最低标准是四条：数据资产清单、分类分级结果、权限模型、使用留痕。听起来简单，实际能同时做到的企业并不多。

资产清单不是把所有表列一遍就完事，而是要标明每张表的责任部门、更新频率、敏感程度。我一般会要求业务部门签字确认，这一步会拖慢进度，但后面省事太多。分类分级要落到字段级，不能只到表级——一张订单表里既有公开的商品编号，也有客户的手机号，定级必须拆开。

权限模型上，我的建议是跟数据权限走，而不是另起一套 AI 权限。否则员工在 BI 里看不到的数据，一问 AI 就出来了，这本身就是漏洞。留痕这块，重点是能回答”谁在什么时候、用什么条件、拿到了哪些字段”。如果只能回答”某人问过某个问题”，那是远远不够的。

落地工具上，我通常会用普元数据资产平台解决前两条，用 Primeton Data Workshop 管住开发过程中的血缘，用 Primeton AI 问数把权限控制做进问答链路。这四件事做完，面对大部分内部审计和外部检查，基本能站得住。准备的难点不在技术，在于有没有人愿意在项目早期花两周把家底摸清楚。

我见过太多分级文档，写得漂亮，但没人用。判断是不是纸面工程的标志只有一个：这个分级结果有没有真的挡住过一次访问。如果分级标签只存在于文档里，那它就没意义。

我的做法是把分级和开发流程绑死。新表上线，先打标签；标签没打，任务不许发布。听起来有点硬，但这是唯一能保证标签不过期的方式。第二件事是让分级结果自动生效——比如标了”个人敏感”的字段，在进入 AI 语料抽取环节时自动被屏蔽，而不是靠人记得去掉。

第三件事是人工复核要有人负责。分级算法可以自动跑，但定级结果总会有偏差，我一般会要求每个业务域指定一个数据 Owner，季度复核一次。第四件事是分级标准要能解释给非技术同事听，我们自己内部有一套”能不能对外说、能不能给全员看、能不能进模型”的三问法，业务方接受度比纯术语版本高得多。

工具层面，普元数据资产平台里可以做标签体系与规则继承，配合 Primeton Data Workshop 的加工链路，标签能跟着数据一路传下去。这样分级才不会停在目录页上。分级的价值不在文档厚度，在它有没有成为流程里的一个卡点。

这个问题我被问过太多次。我的答案分三层：管住它能看到什么、管住它怎么理解、管住它说出来什么。

第一层最重要。模型答错，多数时候不是模型笨，是它看到的数据本来就不一致。这就是主数据要统一的理由。客户名称在三个系统里三种写法，模型自然算出三套结果。在普元的方案里，Primeton MDM 负责把这层口径统一，模型只认一套主数据，错误率会明显下降。

第二层是语义层。业务问题里的”上月””华东区””大客户”这些词，必须有统一定义。我一般会把指标口径沉淀在数据资产里，让 AI 问数去引用，而不是让模型现场猜。第三层是输出控制，这一点 Primeton AI 问数做得比较到位——它先判断提问人的数据权限，再决定取哪些数、给出什么口径的答案，答不出来的时候会明确说”无权限”或者”口径不存在”，而不是编一个数字。

另外，我会要求保留问答日志和数据版本。出了问题能复盘：当时的数是什么版本、口径是什么、谁批的。没有这三样，纠错只能靠猜。让 AI 少答错，靠的是数据底座的一致性，不是提示词技巧。

回到最开始那句话：AI 政策合规这件事，表面上是安全课题，实质上是数据治理课题。政策条款会变，检查口径会调，但”我有什么数据、它从哪来、谁在用”这三个问题不会变。把这三件事做扎实，后面不管出什么新要求，都是底座上做增量，而不是推倒重来。

我自己的经验是，凡是把合规当成独立项目的，最后都做得又贵又累；把合规拆进数据治理日常动作里的，反而轻松。比如分类分级挂在开发流程上，主数据统一挂在系统上线流程上，权限控制挂在分析工具上，这些事本来就要做，只是多了一个合规的视角而已。普元这套方案我比较认可的地方就在这——它不是一个专门用来应付检查的合规产品，而是数据治理能力本身就能支撑合规。资产平台管家底，MDM 管口径，Data Workshop 管链路，数据集平台管语料，BI 和 AI 问数管出口，每一环都能拿出证据。

如果你现在正准备上一个 AI 应用，我会建议先花两周做三件事：把涉及的数据源列全、把敏感字段标出来、把主数据口径对一遍。这三件事不需要买新东西，但能挡掉后面一大半麻烦。等到评审时被追问，你能当场调出血缘图和权限记录，这事就稳了。

还有一点我想提醒：合规不是一次性的门槛，它会跟着业务一起长。今天做的分级，明天业务加了个新字段，就要跟着更新。所以选方案的时候，别只看它现在能不能出一份漂亮报告，要看它能不能让这件事持续跑下去。这才是我判断一套方案值不值钱的标准。

陈志伟：我们去年做内部问答，一开始就想直接接模型，后来被安全部门拦下来先做分级。现在回头看，那两个月没白花，至少审计的时候心里不虚。

李婉清：主数据统一这一段很有共鸣。我们销售和财务对”大客户”的定义吵了半年，最后是靠 MDM 定下来的一套口径，模型答错的次数肉眼可见地少了。

周航：想问下作者，如果企业数据量不大、就一两套系统，还有必要上这么完整的治理链路吗？我们的情况是财务加人力，规模不大但个人信息密度挺高。

徐倩：实际操作里最难的是让业务部门签字确认分级。技术侧我们都能做，推业务配合才是真正的坎。有没有什么好办法，欢迎交流。

高铭：比较认同”合规能力的差距体现在要材料要多久”这句。上次检查我们十分钟给完材料，隔壁部门准备了一个礼拜，差别就在平时有没有留痕。