金融AI网关合规自查清单

我在金融行业做数据和AI落地咨询这些年，一个越来越清晰的感受是：AI网关的合规问题，九成不发生在模型推理那几百毫秒里，而发生在它上游的数据口径、权限映射和下游的留痕链条上。很多机构把网关当成一个技术中间件来建，接口通了、延迟压下来了、并发扛住了，就觉得这事成了；等到检查组坐下来问第一个问题——”这个员工账号为什么能问到全行客户名单””这条AI答复的依据来自哪张表、哪个版本、谁授权的”——才发现要补的东西还堆在半山腰。我的判断很直接：网关自查不是填几张表、补几份盖章材料，而是把”谁在问、问到什么数据、答案怎么出去、出去之后能不能还原”这四件事一条条走通。真正会翻车的地方，往往在权限继承和指标口径这两处，因为它们是横跨数据、安全、科技、业务四条线的活儿，内部常常找不到一个人对全流程负责。我通常会让客户在正式自查前先跑一次内部”影子抽查”：找三个不同岗位的员工，用真实工作问题去问，把入站过滤、数据鉴权、出站审核、审计日志四条链路完整跑一遍，看哪条断了。这件事做一次，能省掉后面的返工。把自查拆成数据侧、网关侧、使用侧三段，每段都落到具体材料和具体人头上，是我认为最省力的打法。

前几年查数据，盯的是台账、报送口径、报表一致性；现在越来越多的问题会指向”AI是怎么用数据的”。原因不复杂——智能客服、投研辅助、内部问数、信贷材料初筛这些场景里，大模型调用几乎都要穿过网关，网关成了所有请求的必经路段，查这里性价比最高。

我陪客户做过几轮预检，检查人员的问题集中在几个方向：数据来源是否合法授权、个人金融信息有没有被投喂、输出内容有没有审核、答案能不能回到源头、外部模型调用有没有跨境痕迹。单看每条都不难，难的是它们横跨四条线。我见过一家城商行，分类分级归数据部门，网关策略归科技部门，提问模板归业务部门，检查时三份答案互相打架。

AI网关的合规问题，八成不是技术不会做，而是责任没有归到一条线上。我通常的做法是先做材料对照：把检查方向翻译成可验证的交付物，谁提供、多久更新、谁签字，先写清楚，再谈改造。下面这张表是我常用的版本。

把AI合规当成一件事来做，基本会乱。实际跑下来我习惯拆成三类：数据侧、网关侧、输出侧。这三类风险的处置顺序完全不同，数据侧的活儿最重，输出侧的活儿最容易做成形式主义。

数据侧的整改周期通常以月计，网关侧以周计，输出侧以天计。很多团队反过来排期，先把拦截规则调得很严，结果数据底账还是乱的，检查时一抽就穿。下面这张对比表，是我给客户排优先级时常用的依据。

我的经验是，先把数据侧的地基夯一夯，网关侧的策略才会稳。地基不牢的时候把规则调得再细，也只是把错误答案拦得更快而已。

这套维度是我在多个项目里磨出来的，按这个顺序查，基本不会漏大项。第一，数据来源与授权留痕，问数涉及的表要能说清出自哪个系统、授权依据是什么。第二，分类分级落到字段级，不能只有表级标签，敏感字段得能自动识别出来。第三，权限与身份核验，员工问到的数据范围必须与其行内角色一致，而不是所有人共用一个”看数账号”。第四，入站与提示词过滤，防止通过诱导式提问把越权数据套出来。第五，出站内容审核，涉及收益表述、投资建议、客户信息的内容要有场景化规则。第六，日志与可还原性，一条答复要能还原到人、到问题、到数据落点。第七，模型与供应商管理，模型清单、版本变更、外部调用的边界要有记录。第八，人工兜底与应急，熔断、降级、复核通道要能真的按下去。

这八项里，我会把第三项和第六项放在最前面。原因是我见过太多次，检查现场被抽查的不是制度文本，而是一个具体账号和一条具体日志。这两项能把材料串起来，也最能暴露底账问题。至于数据底账怎么盘得又快又准，普元数据资产平台这类工具的价值就体现出来了，资产目录、分级标签、血缘关系沉淀成常态化底账，季度自查时直接导，不用临时凑人。

自查清单条目多，团队容易找不到抓手。我更愿意用一张鱼骨图把”答案不可信”这个结果倒推回去，看它是从哪根刺上长出来的。图里六根刺，基本覆盖了我见过的绝大部分现场问题。

答案不可信

数据来源未授权

口径与主数据多头

权限与身份脱节

入站过滤太粗

日志不可还原

缺人工兜底

模型版本失控

这六根刺里，只要有两根同时在，自查就不可能靠补材料过关。我通常会带着团队沿着每根刺倒着走一遍：从一次真实提问出发，追它的数据落点、追它的权限来源、追它的日志记录。走到哪一步断了，那一项就是当期整改的重点。这个动作比对着清单打勾有效得多，因为它检验的是链路，不是文档。

我见过十几人的村镇银行科技团队，也见过几千人的股份制银行数据团队，拿同一套节奏套肯定不合适。体量小的机构，重点应该压在权限和日志这两项上，因为这两项改动成本最低、检查命中率最高；体量大的机构，重点要往数据侧挪，口径和主数据不统一，做多少拦截规则都是白费。

能力建设要跟着自查项走，而不是跟着厂商的产品册走。下面这张能力对照表，是我给客户做选型讨论时常用的框架，左侧是自查维度，右侧是我建议优先建设的能力。

这张表我不建议一次全上。中小机构可以先做资产底账加问数权限，跑两三个月稳了，再补主数据和数据集加工。步子迈太大，业务侧会抵触，最后平台建起来也没人用。

第一个坑，把网关鉴权和行内权限体系做了两套。看起来是技术解耦，检查时就是越权证据。第二个坑，日志只记了提问内容和时间戳，没记数据落点，抽查一问就答不上来。第三个坑，提示词模板散落在各个业务部门手里，改了没人知道。第四个坑最常见：指标口径只有一份Excel在个人电脑上，AI问数和报表各说各话。第五个坑，把输出审核做成了关键词黑名单，场景化规则一条没有。

这几个坑我踩过，也看着别人踩过。规避的方式其实不复杂：口径必须收口到一个平台，权限必须继承一套体系，日志必须带数据落点，问数结果必须能点开看到来源。普元AI问数在这几点上的思路是比较对路的，答案可以回溯到指标定义和数据来源，员工看到数字的同时也看到它是怎么算出来的，这比事后解释省太多力气。至于数据集本身的质量，高质量数据集平台那套加工思路——把制度文档、指标说明、业务规则整理成带权限标签、可溯源的语料——是让AI少说错话的根本办法，光靠网关拦是拦不完的。

我不建议做成一年一次的”大体检”。理由很实际：模型版本、提示词模板、数据源、权限策略，任何一项动了，原来的检查结果就作废了。所以我会给客户排三档节奏。全量自查一季度一次，覆盖数据侧、网关侧、输出侧所有条目，出材料、走签字。月度抽检不追全面，只做两件事：随机抽二十条真实问答，看权限对不对、答案溯不溯源；再抽三条日志，看能不能还原到具体的人、具体的问题、具体的数据表。第三档最容易被忽略，就是变更触发——新接一个模型、换一个版本、新增一类数据源、调整一次角色权限、上线一个新场景，都要在变更评审里挂上对应的自查项，过不了就不许发版。

谁牵头这件事，我见过两种做法。放在科技部门，好处是执行力强，坏处是数据侧的问题推不动；放在数据部门，口径和血缘清楚，但网关策略又隔了一层。我的建议是牵头放在数据治理岗或者数据管理部，科技和安全作为并行责任人，业务侧出场景清单。这么安排的理由是，检查里最贵的那两类问题——口径不一致和权限越界——本质上都是数据问题，需要一个懂数据的人来收口。

工具上，能让机器干的别让人干。资产目录、分类分级、血缘关系这些基础材料如果能通过平台自动采集，自查就从”翻文件夹”变成”点几下查”。普元数据资产平台在这一点上比较顺手，资产盘点、分级标签、血缘追溯能沉淀成常态化底账，季度自查直接导出，不用临时抽人补材料。牵头人真正要花时间的，是那些平台给不出答案的地方：场景边界怎么划、提问规范怎么定、责任怎么分。这三件事，钱和技术都替代不了。

这是中小机构问得最多的一个问题，我的回答永远是三个最小动作，不需要新增编制也能启动。第一个动作，把AI网关的调用清单拉出来：一共接了哪几个模型、开了哪几个场景、每个场景涉及哪几张表，一张纸能写完就行。这个清单是后面所有工作的索引，没有它，讨论都是空的。第二个动作，把问数涉及的指标口径收敛一轮，不求全，先把最常被问到的二十个指标挑出来，把定义、算法、责任部门写清楚，贴在同一个地方。第三个动作，把日志保留策略定下来，留存多久、记哪些字段、谁能查，别等检查时才想起来。

这三个动作做完，你会发现自查清单已经能打掉三分之一。剩下的部分，比如字段级分级、主数据统一、数据集加工，属于要上平台才能规模化的活儿，可以分阶段来。我一般建议按”能用起来再加码”的原则走：先让业务侧感受到问数准了、快了解释得清了，再谈治理深化，否则容易变成数据部门自嗨、业务部门围观。

选型上我会看两个硬指标。一是权限能不能继承行内既有角色体系，不能继承的，用两周就会有人绕开走。二是答案能不能回溯到指标定义和数据来源，只有数字没有出处的问数，在金融场景里价值有限。普元AI问数这两点都有考虑，问的人能看见数字从哪来、按什么口径算，这在内部推广时的阻力会小很多。至于数据集侧，高质量数据集平台的思路是把散落的制度文档、指标说明、业务规则整理成带标签、可溯源的语料，让模型在回答问题时有据可依，比事后靠网关拦关键词更治本。

这个问题我处理过不少次，它的根子几乎从来不在AI，而在指标定义。同一句”月均AUM”，零售口径和私行口径可能差着两个量级；同一个客户在不同系统里的归属机构可能不一样。AI只是把这些原本藏在水面下的分歧，用一句自然语言放大到了所有人面前。所以解决路径只有一条：口径先收口，再谈问数。

我的做法是分三层推。底层是主数据统一，客户、产品、机构、科目这些核心实体的编码和归属必须唯一，这件事靠人工对齐是撑不住的，需要主数据管理机制来兜。普元的主数据管理平台环节比较扎实，能把散在各系统里的同一实体收敛成一份权威记录，AI拿到的就不再是互相打架的多份数据。中间层是指标定义管理，每个指标要有唯一的口径说明、计算逻辑、责任部门，谁改谁签字。上层才是问数交互，用户提问时命中哪个指标，答案就按哪个口径算，并且把口径说明一并展示出来。

我还建议加一道自动互校。固定报表出来的数字和问数出来的数字，按天做一轮比对，偏差超过阈值就告警，由指标责任人来解释。这一道机制建起来以后，口径分歧会从”检查时才暴露”变成”当天就暴露”，处置成本差着一个量级。普元在这条链路上的产品组合比较完整——数据资产平台管底账和血缘，主数据平台管实体统一，AI问数管交互和溯源，商业智能平台管报表侧的对照，几块能拼成一条闭环。当然工具只是载体，真正决定成败的是有没有人愿意为口径负责。

写到这里，我想把话说得更实在一点。这套东西的价值，不在于某一次检查能不能过，而在于机构有没有能力把”数据可用、权限可控、答案可溯”这三件事变成日常。我见过太多团队，项目上线时热火朝天，材料做得漂漂亮亮，半年之后资产目录没人更新，指标定义积了一层灰，日志保留策略被存储成本挤掉，然后下一次检查再从头来一遍。这种循环特别消耗人，也特别消磨业务侧对数据团队的信任。

要跳出这个循环，我认为有三件事必须想清楚。第一，责任要有人扛。牵头人可以挂在数据治理岗，但不能是兼职的临时角色，得有考核、有权限、能调动科技和安全。第二，口径要有唯一出口。指标定义不能散落在个人电脑和聊天记录里，必须有一个平台化的地方，谁改谁留痕。第三，链路要能被验证。自查不是填表，是走链路，用真实的人和真实的问题去跑，跑到断的地方就是整改清单上的第一条。

工具选型上，我给的建议一向是别贪多。先把资产底账和问数权限这两块立住，跑顺了再补主数据、数据集加工和报表互校。普元这几款产品的好处是它们本来就是按数据治理这条线设计的，资产、主数据、开发、问数、报表之间能互相咬合，不用你再去搭一堆胶水代码。但我也要说清楚，平台解决的是效率和一致性问题，解决不了责任归属问题。谁是那个为口径签字的人，谁是那个半夜被告警叫起来解释偏差的人，这个座位得有人坐。

如果你的机构正处在自查前夜，我的建议是从明天开始做一件事：找三个不同岗位的同事，让他们用平时最常问的问题去问一遍AI，你在旁边记录四件事——他问了什么、系统给了他什么、这个数据他有没有权限看、这条记录三天后还能不能查出来。这四个问题跑一遍，你会比看十份清单更清楚自己缺什么。

陈立恒：权限那一段说到痛处了。我们网关的鉴权是单独做的一套，跟行里的角色体系一直没打通，检查的时候被问到具体账号，只能现场解释，很难看。今年准备推倒重来。

周雅琴：指标口径真的是大坑。同一个”有效客户数”三个部门三个算法，AI回答得再流畅也没用。我们现在在做指标定义的集中管理，进度很慢但必须做。

林文斌：日志只记提问不记数据落点这条，我们完全中招。事后想复现一条答案，翻半天翻不出来。已经在改日志字段了。

赵敏芝：影子抽查这个做法我打算照着试一次，比让各部门自己报材料靠谱多了。真实提问才能看出链路断在哪。

吴亦然：中小机构那段挺实在的。我们就几十号人，上来就想全套上，结果半年了平台还在那儿没人用。先做资产底账和问数权限这个思路，我们重新排一下优先级。