金发〔2026〕8号文解读 | 银行保险业AI应用进入“安全开发”新阶段：从用起来，到管得住、看得清、防得住

悬镜安全说
悬镜安全说

悬镜安全说

2026年6月26日 14:30
北京

在小说阅读器读本章

去阅读

2026年6月，金发〔2026〕8号文发布。32条，7个领域。

不是突然，是恰逢其时。

这份文件共32条，围绕治理架构、开发应用、数据治理、算力建设、风险治理、安全能力、保障监督七大领域，为银行业保险业人工智能安全开发应用划出了一条更清晰的路线。

《关于银行业保险业人工智能安全开发应用的指导意见》

如果用一句话概括这份文件的核心信号：金融机构应用AI，不再只是“能不能用、好不好用”的问题，而是必须回答“谁来管、怎么测、风险在哪里、出了问题能不能追溯和处置”。

这意味着，银行保险业的AI建设正在从“场景试点期”进入“安全治理期”。

为什么是现在？

AI已进入金融业务的深水区

银行保险业对AI的应用，已经不再停留在智能客服、营销推荐这类外围场景，而是逐步进入风控、反欺诈、反洗钱、理赔、投顾、运营决策等更关键的业务环节。

AI越靠近核心业务，风险也越不能被简单视为“技术问题”。模型输出不可靠、数据泄露、权限越界、提示词注入、第三方组件风险，都可能影响客户权益、业务连续性和机构合规责任。

因此，《指导意见》的重点并不是限制AI应用，而是要求银行保险机构在推进AI创新的同时，把治理、安全和审计机制同步建起来。换句话说，AI可以加速，但必须有护栏。

最值得关注的是？

不只“鼓励AI”，而是“要求全生命周期治理”

这份文件最重要的变化，是把AI安全开发应用纳入全生命周期管理。

从需求分析、数据准备、训练开发，到部署运行、维护迭代、评估退出，AI应用的每个环节都需要有人负责、有制度约束、有风险评估、有记录可追溯。

其中有几类要求尤其值得关注：
一是建立组织级AI治理机制，不能只由技术团队单点负责；
二是对高风险AI应用进行分级准入，尤其是涉及信贷、理赔、风控、客户权益的场景；
三是明确数据安全红线，敏感个人信息不能被随意用于模型训练和优化；
四是关注提示词注入、上下文污染、多模态攻击等AI原生安全风险。

这意味着，银行保险机构未来建设AI能力，不仅要看效果，更要看安全性、可解释性、可审计性和风险闭环能力。

银行保险机构真正要补的？

三类安全能力

从落地角度看，《指导意见》不是要求机构简单“买一个AI系统”或“做一次测评”，而是要求建立持续化能力。对银行保险机构来说，至少要补齐三类关键能力。

第一类，是AI资产看得清。
银行保险机构内部往往已经存在大量AI相关资产，包括模型、智能体、插件、知识库、向量库、API、MCP服务、AI开发工具、第三方组件等。如果这些资产没有统一台账，就很难知道风险在哪里，也很难在漏洞或投毒事件发生时快速判断影响面。

这就需要围绕AI应用建立资产识别和AI-BOM能力，把AI系统中的模型、组件、插件、数据流、调用关系和供应链依赖梳理清楚。

第二类，是AI风险测得出。
传统安全测试主要面向代码漏洞、组件漏洞、配置风险和运行时攻击。但AI应用多了语义交互、提示词、模型行为、智能体工具调用等新风险。仅靠传统规则和漏洞库，很难识别提示词注入、模型越狱、代理混淆、工具调用越权、敏感信息输出等问题。

因此，银行保险机构需要建立面向AI原生风险的测试能力，把静态检测、动态红队验证、模型行为评估、智能体调用链分析结合起来，让风险不仅“被发现”，还要“可验证、可复现、可整改”。

第三类，是风险闭环管得住。
AI安全不是一次上线前检查就结束。模型会更新，数据会变化，插件会迭代，第三方组件也可能不断出现新漏洞。银行保险机构需要把AI安全纳入日常运营，形成从发现、分级、处置、复测、审计到报告的闭环机制。

这也是监管文件中强调风险监测、年度评估、监督检查和人才建设的原因。

面向银行保险业

安全建设可切入的场景

结合银行保险机构的业务特点，AI安全建设不必一开始就“大而全”，可以从高价值、高风险、高合规压力的场景切入。

1. AI原生安全测试：先解决“AI应用能不能安全上线”
对智能客服、智能投顾、理赔辅助、营销内容生成、风控分析助手等生成式AI应用，建议在上线前开展AI原生安全测试，覆盖提示词注入、越狱攻击、敏感信息泄露、幻觉输出、违规内容生成、上下文污染、MCP工具调用风险等问题。

这类测试的价值在于，把AI应用从“功能可用”推进到“安全可用”。

2. 智能体安全评估：重点管住工具调用和权限边界
银行保险业正在探索智能体在运营、风控、客服、开发、数据分析等场景中的应用。智能体一旦具备调用系统、访问数据、执行操作的能力，就必须评估其权限边界是否合理，工具调用是否可控，是否存在代理混淆、越权调用、危险命令执行等问题。

智能体安全评估应重点覆盖Agent、Skill、MCP、Tool、模型依赖和数据访问链路，确保智能体不是“黑盒自动化”，而是可控、可审计、可追溯的业务能力。

3. AI Coding安全治理：防止AI生成代码把风险带入研发链路
银行保险机构的软件研发规模大、系统复杂，AI Coding工具正在提升研发效率。但AI生成代码可能带来不安全函数、硬编码密钥、恶意依赖、许可证风险、逻辑缺陷等问题。

因此，需要把AI Coding安全治理前移到开发环节，对提示词、生成代码、依赖引入、Agent自动修复、PR/MR提交等过程进行安全检测和审计，避免风险流入CI/CD流水线和生产环境。

4. AI供应链安全治理：防止模型、插件、组件成为隐蔽入口
银行保险业越来越多地引入开源模型、第三方插件、AI框架、向量数据库、MCP服务和工具组件。供应链风险一旦进入AI系统，往往更隐蔽、更难排查。

机构需要建立AI-BOM和供应链情报联动能力，对模型、组件、插件、Skill、MCP服务进行持续识别、漏洞匹配、投毒预警和影响面分析，避免在重大漏洞或投毒事件发生时陷入“有没有用、哪里用了、谁受影响”的被动排查。

从合规到韧性

AI安全建设的关键，是把安全嵌入AI生命周期

《指导意见》释放出的信号非常明确：AI不是不能用，而是要安全地用、负责任地用、可持续地用。

对银行保险机构来说，下一阶段的重点不是简单追求“大模型能力有多强”，而是要建立一套能支撑长期发展的AI安全底座：

有清晰的治理架构，知道谁负责；
有完整的资产台账，知道AI在哪里；
有持续的安全测试，知道风险是什么；
有供应链监测，知道外部依赖是否可靠；
有闭环处置机制，知道问题如何修；
有审计和评估报告，知道如何向监管和管理层交代。

AI正在重塑金融服务，但金融行业最重要的底色始终是稳健、可信和安全。

当AI从“创新工具”走向“生产基础设施”，安全能力就不能再是上线前的补丁，而必须成为AI开发应用的内生能力。这也是银行保险业真正迈向智能化深水区前，必须补上的一课。

最新推荐阅读

部分标杆客户

关于“悬镜安全”

悬镜安全，起源于北京大学网络安全技术研究团队“XMIRROR”。作为新一代数字供应链安全开拓者，首创基于“AI 原生安全+ DevSecOps敏捷安全+多模态 SCA+AI 供应链安全情报预警”技术的新一代数字供应链安全治理体系。

智能情报驱动，以AI治理AI！从源头治理大模型开发、训练、部署到智能体运营等关键环节面临的 AI 原生安全风险，帮助企业用户构筑一套从传统软件供应链到 AI 原生供应链全生命周期的内生安全治理体系，持续守护新一代数字供应链安全。