金融机构 AI 治理的紧迫窗口：从调用链路到合规闭环

最近半年，金融科技圈子里关于 AI 安全治理的讨论明显在升温。不是没有原因——行业监管文件密集出台，强制性国家标准正式立项，金融 AI 的安全治理正在从"建议关注"变成"必须做到"。

跟几个银行和券商的朋友聊了一圈，发现一个挺有意思的现象。大家对趋势本身不算意外——金融行业被强监管又不是一天两天了。真正让人皱眉的是：对照最新要求自查了一圈之后，发现当前 AI 使用的实际状态和合规要求的差距，比想象中大得多。

监管在要求什么：从建议到强制

近期的指导意见覆盖了 AI 全生命周期治理。从治理架构的搭建、数据安全、风险分级、模型审计，到应急处置，每个环节都明确了要求。具体到技术层面，直接点到了几件事：姓名、身份证号、银行卡号等个人信息不得用于生成式 AI 模型训练和优化；提示词注入、上下文污染等攻击必须有防御机制；模型与数据供应链须纳入风险管理。

与此同时，强制性国标也在加速推进——六大安全能力里，资产盘点、身份与权限管理、知识库管控、多模态安全防护、全链路审计、应急处置一个不能少。而"18 个月"这个时间线，意味着不是"先试点、再慢慢推"。试点本身就会消耗时间，算上选型、测试、部署、整改，每一周都算得出来。

差距在哪：金融机构当前 AI 使用的真实状态

聊下来，几个典型问题几乎每家都有，只是程度不同：

账单一锅粥。 多个模型混着用，每个模型单独出账单，OpenAI 归 OpenAI、Claude 归 Claude，怎么按部门、按项目、按人去拆分？很多机构现在的答案就是"拆不了"。每个月看到的是一个总数字，多了少了都讲不清为什么。

谁调了什么，查不出来。 一个员工用 AI 写了什么、传了什么数据、调了哪个模型——没有完整的记录。不是不想记，是当前的技术架构里就没有这条链路。监管来查的时候，拿不出一份经得起推敲的调用审计报告。

Key 像办公室钥匙，人手一把还乱放。 API Key 散落在代码仓库里、CI 脚本里、各种工具配置文件里。泄露了不知道，知道了也不知道从哪儿泄的。轮换一次 Key 要改几十个地方，所以大家默契地选择不换。

核心业务被 AI 调用挤占。 有些机构的 AI 调用和核心交易跑在同一套网关下面。大模型一次请求可能持续十几秒甚至更久，并发一上来，核心业务的响应时间就被拖垮。

合规包是空的。 脱敏规则、敏感词库、行业合规策略——大部分机构还是靠人肉审核。员工在对话里传了什么数据，只能靠事后抽查，效率低且不可靠。

三个先做的事

面对差距，做全套方案当然是最理想的。但现实是，大部分机构的科技部和合规部需要在有限的时间和预算内，把最关键的缺口先补上。

第一，把调用链路先跑通。 全链路审计不是锦上添花，是监管的硬要求。每笔 AI 调用——谁、什么时间、传了什么、模型回了什么——必须有完整记录。这不是为了应付检查，而是在出事的时候，可以定位到具体哪一笔调用出了问题、责任人是谁、影响面多大。

第二，Key 收敛到控制面。 下游业务和开发者不再直接接触真实 API Key，改为通过统一的控制面下发虚拟凭证。虚拟凭证可以设额度、设白名单、设生效时段，出了事可以分钟级撤销。这不是什么新技术，但在 AI 场景里迟迟没有落地。

第三，合规检测前置，而不是事后补救。 监管明确要求个人信息不得进入模型训练链路，加上对提示词注入防御的要求，这些不该依赖业务方的自觉。更合理的方式是：在请求真正发出的前一刻，自动识别身份证号、银行卡号等敏感信息并脱敏，同时拦截已知的注入攻击模式。合规包可以随监管要求持续更新，而不是每次出新的规则就搞一次系统改造。

这三件事做完，一家机构的 AI 治理就算有了基础框架。不是"做完就高枕无忧"，但至少不在一份检查单上全是空白项。

别把治理当"最后再补"的事

过去企业上云的节奏里，安全往往是"先用起来，出了问题再补"。这个模式在 AI 时代不太行得通了——不是因为态度变了，而是监管节奏变了。最新的文件并没有给"先上再说"留太多空间。

而且退一步讲，金融机构本身对风控和合规的理解比大多数行业都深。那些在交易系统、信贷系统里已经跑得很成熟的身份鉴权、操作留痕、风险阻断机制，完全可以用在 AI 治理上。差别只是多了一层：需要理解模型调用的特殊性，需要接住不同 Provider 的协议，需要在网关层叠加路由和降级逻辑。

好消息是，这些工作不需要推倒现有基础设施。已有的 IAM、网关、网络边界，都可以复用。治理层叠加上去，业务代码几乎不动。

过去聊 AI 治理，总觉得是"下一阶段的事"。现在，这个下一阶段已经变成现在了。