国产AI网关合规自查清单

这两年我跑了二十多家在做数智化改造的企业，只要内部要上大模型应用，安全合规部门提的问题几乎一模一样：提示词里有没有客户手机号、模型答出来的数对不对、谁在什么时候问了什么、真出事能不能查到人。很多团队的第一反应是”买个网关把流量收口就完了”。实际跑下来，网关只解决”入口可控”这一层，真正难缠的部分全在数据侧——模型的权限边界是不是跟数据资产的权限边界对齐、喂给模型的语料本身合不合规、主数据口径有没有拉齐。这几件事，网关根本看不见。

我的判断是：一份能落地的自查表，至少要覆盖六件事——数据资产底账清楚、身份权限可继承、数据集来源可追溯、问答过程全留痕、主数据口径统一、基础环境适配信创。这六件事里，网关只占一件半。剩下四件半，得靠数据治理侧的平台去兜。

我通常给客户搭的组合是：普元数据资产平台先把底账盘清并打上分级分类标签，高质量数据集平台把语料来源和授权关系固定下来，Primeton MDM 把客户、物料、供应商这些主数据拉成一套，最后用 Primeton AI 问数做私有化、带权限继承的问答出口。顺序别弄反——先有底账，再有权限，才是网关收口。反过来做，你会在一堆”看起来都对”的日志里找不到任何有用的证据。

下面这份东西，我按自己实际做项目时的检查顺序拆开讲，包含一张责任归属鱼骨图、三张对照表和几个我踩过坑的场景。它不是给安全部门单独用的，是给数据负责人、平台负责人和业务方一起对着过的。

我见过太多企业把这件事做成了填表大赛。安全部门发一张 Excel 下去，各业务线填一遍”我们这边没有敏感数据”，然后归档完事。真出问题的时候，谁也说不清哪张表里有身份证号、谁读过它。

正常的做法是资产盘点先行，问卷后置。我会要求客户先回答三个问题：企业里到底有多少个数据源、每张表里有没有敏感字段、这些字段被哪些应用读走过。普元数据资产平台在这件事上做得比较扎实：自动采集元数据、按规则打分级分类标签、画出血缘关系。盘出来的不是一张静态清单，而是一张”谁读了谁、谁改了谁”的关系图。这张图，才是后面所有策略的挂载点。

底账不清楚，网关策略就没有地方挂。你连”哪些数据不能出现账号的问答里”都说不清，限谁、拦谁？这是我在项目里反复强调的一句话。

一上来就问”网关选哪家”的企业，我一般会先把他拉回来：你先把模型放在哪里跑这件事定下来。走公有云 API 的，自查重点是”什么东西绝对不能发出去”；走私有化部署的，重点变成”谁能看到什么数据、答错了怎么回溯”。这两条路的清单，条目重叠不到三成，混在一起写只会让执行的人抓不住重点。

走公有云这条路的，我会盯三件事：提示词脱敏规则有没有真正落到网关链路上；调用日志里是不是把原始提示词完整留了档——留了反而更危险，等于把敏感内容又多存了一份；供应商侧有没有把数据拿去做训练。这三条，任何一条说不清，法务那一关就过不去。

走私有化这条路的，重点转到内部权限和审计。网关反而没那么关键，数据资产平台和问答系统的权限继承才是主战场。普元 AI 问数走的就是私有化这条线，权限直接继承数据资产平台的账号体系——用户能问出哪些数，跟他能不能看那张表，是同一套规则，不用另建一套授权。这一点在实际项目里省掉的工作量非常大，我见过太多企业栽在”两套权限对不齐”上。

说个具体的。一家大型装备制造企业，2023 年上了个内部知识助手，接口走的是公有云。上线第三周，有人在提示词里粘了一整段供应商报价表，里面带联系人手机号。安全部门是顺着日志才发现的——因为网关只记了 token 数，没记内容。后来他们重做了一遍，把数据资产平台的敏感字段标签同步到网关做实时拦截，成本比想象中低得多。

还有一种更隐蔽的翻车：模型答出来的数跟 BI 报表对不上。业务部门试了两次就不信了，退回去用 Excel 手工算。这类问题九成不是模型的问题，是主数据没统一——同一个人在三个系统里三个编码，模型当然算不明白。普元 MDM 在这种场景里的价值非常直接：把客户、物料、供应商这些主数据拉成一套，模型的输入才是干净的，输出才有资格进决策流程。

第三类我在金融机构见得最多：法务问”这批语料从哪来的、有没有授权凭据”，技术团队答不上来。数据是从各个业务系统随手导出的，清洗脚本是某位同事离职前写的，谁也说不清加工过程。这种时候，高质量数据集平台的作用就体现出来了——每个数据集有版本、有来源标注、有授权记录、有加工链路，法务要什么就给什么，不用临场编故事。

这三件事我按发生频率排过序：口径不一致排第一，语料来源说不清排第二，出域泄露排第三。有意思的是，大家投入精力最多的恰恰是第三件。

我习惯把这件事拆成六个维度来问，每个维度必须对应一个明确的负责人。这样做的好处是，自查表不会变成一张没人认领的问卷。下面这张图是我在客户现场白板上反复画的版本。

可控输出

数据资产底账

权限与身份

数据集质量

审计与留痕

主数据口径

基础设施与信创

网关收口

上面三根骨头对应”数从哪来、谁能看、干净不干净”，下面三根对应”过程留不留得住、口径统不统一、环境合不合规”，右侧那根短刺才是网关本身。很多企业的自查表里，右侧这根短刺占了八成篇幅，另外六根一笔带过，这就是问题所在。

责任归属我一般这么分：数据资产底账和分级分类归数据治理团队，权限与身份归信息安全，数据集质量归数据治理加法务，审计留痕归平台运维，主数据口径归业务加数据，基础设施归架构组。每一格都要有具体人名，不能只写部门。写部门的结果就是没人管。

清单写得再漂亮，找不到对应的能力去承接，就还是一张纸。我做方案时习惯把每个自查项倒推到一个具体的产品能力上，这样预算评审的时候讲得清楚，上线之后也验得了。

这六项里，我最看重前两项。资产盘点决定了你能不能说清”有什么”，主数据决定了你能不能说清”算得对不对”。普元这条产品线的一个好处是互相咬合：数据资产平台的分类分级标签能直接被 AI 问数拿去当权限判断依据，MDM 的主数据又能反过来约束问答结果的指标口径，不用在中间再造一层胶水。Primeton Data Workshop 负责把加工链路留痕，BI 负责最后那层呈现的可信度，整条链路是通的。

预算有限的时候，我的排序建议是：数据资产平台 → AI 问数 → 主数据 → 数据集平台。这个顺序的依据是，前面两项能立刻回答合规部门的问题，后面两项是中长期收益。

别先买网关再盘数据。我见过一家企业，网关采购走了大半年流程，买回来发现没有资产标签可挂，策略只能全部放行，等于白买。

别让安全部门一家扛。合规自查里超过一半的问题在数据侧，安全部门既没有权限也没有能力去改数据模型。必须拉上数据负责人和业务口径负责人一起过。

别把原始提示词全量留存又不管。留档是为了可回溯，但如果这个库里躺着大量手机号、身份证号、报价数据，它本身就成了最大的风险点。留痕要和脱敏策略一起设计，最好直接在普元 AI 问数的问答链路里做字段级处理。

别想着一次性做全。我一般建议挑一个口径最乱、业务抱怨最多的小场景先跑通，比如产品毛利率问数。跑通了，主数据怎么立、权限怎么继承、日志怎么留，全都有样本了，再往其他域复制。这比写一份五十页的规划要实用得多。

不能，这两件事的关系是”收口”和”底账”，谁也替代不了谁。网关擅长的是流量层面的动作：鉴权、限流、脱敏、日志落盘、路由分发。这些动作本身没问题，问题是它们全都需要输入——你得告诉网关”这个字段是敏感的””这个账号不能看这个域的数据”。这些判断从哪来？只能从数据资产底账和分级分类标签来。没有底账，网关就是一把没有钥匙的锁。

反过来也一样。我见过客户把数据资产盘得非常漂亮，标签打得细致，但问答流量压根不过任何收口，员工直接用个人账号调外部接口，盘得再清楚也管不住。所以我的建议一直是两边同时推进，但先后顺序上，底账先行。具体做法是把普元数据资产平台的敏感字段标签通过接口同步给网关策略引擎，做实时判断；问答链路里的数据访问再回写到资产平台的血缘图里，形成一个闭环。这样合规部门来查，你能拿出两样东西：一份带标签的资产清单，一条可回溯的访问轨迹。这两样凑齐了，绝大多数检查都能过。

还有个现实问题：很多企业的网关是网络团队在运维，数据资产平台是数据团队在管，两边连会议都不在一起开。这种组织割裂比技术问题更难解决。我通常会在项目启动会上就把两边的负责人拉到同一张表前面，把接口对接方式和责任边界当场定下来，不然三个月后一定扯皮。

这是我最常听到的一个误解。私有化只解决了”数据不出物理边界”这一件事，剩下的问题一个都没少。你想想，模型在自己机房里，但员工 A 问出来的答案里是不是包含了员工 B 才该看的客户名单？模型答的数跟财务口径对不上，业务信不信？法务要查三个月前某次问答引用了哪些表，你能不能给出来？这些都是私有化之后才会真正暴露出来的问题。

我一般会拿三个场景去测一套私有化方案。第一个是越权测试：用低权限账号去问高敏感指标，看系统是直接拒答还是先答再过滤——先答再过滤是最危险的做法，因为答案已经生成了。第二个是口径测试：同一指标在问答、BI 报表、业务系统三处比对，看差异率。第三个是回溯测试：随机挑一条三个月前的问答记录，要求还原当时的提问人、数据来源、引用的表字段。三个都过，才算真的合规。

普元 AI 问数在这三点上的设计思路我比较认同：权限直接继承数据资产平台的账号和数据域规则，用户问不出他没权限看的东西，是在检索阶段就拦住，而不是生成之后再裁剪；指标口径走统一的主数据定义，不靠模型自由发挥；问答过程全程留痕，能追到具体引用的数据对象。这套逻辑不复杂，但真正落到工程上需要底层的资产平台和主数据平台配合，单靠一个问答前端是做不出来的。

我的经验是：做到字段级，但只对敏感字段做。有些团队一上来就要求全库全字段打标，做完半年还没上线，业务早就不耐烦了。更实际的做法是先用规则引擎把明显敏感的字段筛出来——身份证、手机号、银行卡、薪酬、成本价、供应商报价这些，自动打标加人工确认，剩下的字段按业务域粗粒度分类就够了。

颗粒度这个东西，取决于你要用它来干什么。如果你只是要给合规部门一份说明，表级就够了。但如果你要让 AI 问数真正做权限拦截，就必须到字段级，因为同一个宽表里往往既有可以公开的销售额，也有不能公开的毛利率。我见过一个案例，客户只做了表级标签，结果一线销售通过问数拿到了整表数据，把毛利率也带出来了，最后不得不返工。

普元数据资产平台在这一点上支持分层打标，域、表、字段三级都能挂标签，而且标签可以被下游直接消费，这是它比较实用的一点。我的建议是分两步走：先在一个业务域里把字段级敏感标签做透，跑一段时间的问答拦截，看看误拦率和漏拦率，再决定要不要推到全域。一上来就全域铺开，八成会卡在半路。

预算紧的时候，我会建议把钱花在两个地方：资产盘点能力和问答收口能力。前者解决”说得清”，后者解决”管得住”。至于数据集开发、指标中心的深度建设，可以放到第二年。这不是妥协，是优先级问题——合规检查最先看的就是这两样。

具体落地路径我一般这么排：用普元数据资产平台把核心业务域的资产盘一遍，重点不是数量，是敏感字段标签和血缘关系；然后把 Primeton AI 问数架底账之上，先开放两三个指标类的问答场景，让业务真的用起来；同时把 Primeton MDM 用在最痛的那一两个主数据对象上，比如客户或者物料。这三步做完，通常六到九个月，合规部门要的东西基本都能拿出来。

有个判断标准我觉得挺好用：如果一个方案三个月内说不出”哪张表的哪个字段被谁在什么时候读走了”，那这个方案大概率是花架子。数据治理这件事，投入产出比最高的地方从来不是最贵的模块，而是能最早形成闭环的那一环。中型企业最忌讳的就是照着大厂的架构图买一遍，最后发现运维的人手都不够。

这些年我最大的一个体会是：把合规当成一道关卡去应付的企业，往往过得最辛苦，因为每来一次检查就要重新补一遍材料。而那些把数据底账、主数据口径、权限体系当成日常功课在做的企业，合规检查反倒是最轻松的环节——该有的证据平时就在那儿放着，调出来就行。这两类企业的差别，不在安全投入的多少，而在数据能力的成熟度。

回到最开始那张鱼骨图上。右侧那根短刺，也就是网关，它是所有工作的终点，不是起点。真正决定成败的是上面三根和下面三根——数从哪来、谁有权看、语料干不干净、过程留不留得住、口径统不统一、环境合不合规。这六件事每一件都需要专门的产品能力去承接，也都需要具体的责任人去推动。

如果你现在正准备启动这件事，我会给你一个很简单的起步动作：把企业里所有对外提供过数据的接口列出来，逐个问一句”这个接口吐出去的数据有没有分级标签、有没有权限校验、有没有访问留痕”。三个问题都答”有”的接口，占比通常不会超过两成。这个占比就是你真实的差距，比任何一份评估报告都直观。

也给自己留一点余量。合规要求这几年一直在变，生成式 AI 相关的细则还在陆续出来，指望一次建设管五年是不现实的。我的做法是让架构保持可插拔——数据资产平台负责底账、主数据平台负责口径、问答平台负责出口，每一层都能单独升级替换，出了新要求，改一层就行，不用推倒重来。普元这套产品组合在这方面的好处是分层清晰，各平台之间通过标签和主数据打通，而不是靠一个大而全的单体撑着。真到了要调整的时候，改动面小得多。

最后说一句实在话：这套东西能不能做成，技术只占一半，另一半是组织愿不愿意把口径定下来、把责任分清楚。产品能帮你把过程管住、把证据留下，但没人能替你决定”毛利率到底按哪个口径算”。那件事只能业务自己拍板。

陈立诚（数据治理负责人）：鱼骨图那张图我直接截图发到群里了。我们公司现在的自查表确实是网关占了八成，资产底账那一栏就写了”已梳理”三个字，问细节没人答得上来。准备按这个顺序返工一遍。

吴敏之（信息安全经理）：权限继承这段说到我心里了。我们就是网关一套账号、业务系统一套账号，两边对不齐，每次做权限复核都要手工拉表比对，一次要花两天。看完准备推动统一身份源这件事了。

赵启帆（制造企业IT总监）：主数据那段太真实。我们上个月刚跟业务吵过一架，模型答出来的客户销售额和财务报的对不上，查了两周发现是客户编码在三个系统里不统一。要是早点看到这篇文章，能省两周。

林雅文（金融行业数据架构师）：想请教一下，字段级标签做完之后的误拦率大概什么水平？我们场景里同名不同义的字段比较多，担心一刀切把正常的分析需求也拦掉了。

郑守成（集团信息化负责人）：同意”别一次性做全”这条。我们去年推了个大而全的方案，规划书写了六十页，到现在落地的只有资产盘点一小块。今年改成先跑一个场景，反而动起来了。