2026 年 6 月 18 日，国家金融监督管理总局发布《关于银行业保险业人工智能安全开发应用的指导意见》（以下简称《指导意见》），从治理架构、开发应用、数据治理、算力建设、风险管理、能力提升、保障与监督七个方面提出 32 项指导性意见。

这份文件释放出的信号很明确：金融 AI 的关注点，正在从“模型能不能用”，转向“整个系统能不能被管理、被追溯，并且长期稳定地运行”。

过去讨论 AI 助手，大家最先问的往往是模型效果：回答准不准、是否支持中文、推理速度够不够快。进入银行和保险等生产场景后，问题会迅速变成另一组：知识从哪里来？敏感数据保存在哪里？不同岗位能看到什么？每次检索能否追溯？节点故障后业务多久恢复？

这些问题并不发生在模型参数里，而是落在模型背后的数据与检索基础设施上。向量数据库也逐渐成为金融 AI 知识工程和检索治理的重要底座。

一、从“模型能力”走向“全生命周期治理”

《指导意见》提出，金融机构开发应用人工智能应坚持谁使用谁负责、自主可控、务实高效和安全发展，并要求建立人工智能全生命周期管理体系。

其中，与 AI 数据和检索基础设施关系最密切的内容主要集中在四个方面。

这意味着，金融 AI 项目不能只完成模型接入和应用界面。数据治理、知识检索、权限控制、日志审计、高可用和灾难恢复，都需要在系统设计阶段一并考虑。

二、AI 助手为什么绕不开向量数据库？

大多数企业 AI 助手采用 RAG，也就是检索增强生成架构。模型回答问题之前，系统先从企业知识库中检索相关内容，再把这些内容作为上下文交给大模型。

一条典型的数据链路如下：

企业数据源
    ↓
文档解析、清洗与分块
    ↓
Embedding向量化
    ↓
向量数据库：检索、过滤、权限、审计与高可用
    ↓
大模型生成
    ↓
客服、投研、风控、合规等业务应用

模型最终“看到了什么”，首先取决于检索层“找到了什么”。如果知识库中混入过期制度，模型可能引用旧规则；如果权限过滤缺失，客服人员可能检索到只有风控部门才能查看的材料；如果检索没有留下日志，事后就很难解释某次回答使用了哪些知识。

所以，在金融 AI 场景中，向量数据库至少要回答五个问题：

1. 数据能否按照要求保留在指定环境中？
2. 大规模知识能否持续、稳定地检索？
3. 权限条件能否随检索同时生效？
4. 查询与数据操作能否记录和追溯？
5. 节点故障、升级或灾难发生时，业务能否恢复？

三、从监管要求到技术架构：艾体宝 Qdrant 可以提供哪些支撑？

需要先明确一点：《指导意见》没有指定金融机构必须使用某一种向量数据库，Qdrant 也不能替代完整的 AI 治理体系。它主要位于知识与检索层，可以为数据驻留、知识检索、权限过滤、操作留痕和业务连续性提供技术支撑。

 支撑高质量数据集与企业知识工程

《指导意见》提出，要持续推进高质量数据集和知识工程建设，并支持金融机构构建企业级知识管理体系。

金融材料中既有适合语义理解的长文本，也包含产品名称、制度编号、金额、日期等需要精确匹配的信息。只使用单一路径检索，往往难以同时兼顾语义相关性和关键词准确性。

Qdrant 支持稠密向量、稀疏向量和混合检索，可以将语义召回与关键词匹配放在同一查询流程中；Payload 则可以保存部门、文档类型、生效时间、产品线、密级等结构化信息，并参与过滤和排序。

不过，向量数据库只能保证数据被正确存储和检索。数据是否准确、分块是否合理、Embedding 模型是否合适、旧版本是否及时下线，仍需要由知识接入和数据治理流程共同保障。

让数据留在合适的环境中

金融机构对数据驻留、外包管理和网络边界的要求并不完全相同，因此部署方式不能一概而论。

Qdrant 提供三种主要交付形态：

在 Hybrid Cloud 中，数据库、计算和存储运行在客户环境内，管理组件通过出站 HTTPS 连接 Qdrant Cloud 控制平面；在 Private Cloud 中，系统不连接 Qdrant Cloud 管理控制台，由客户在自己的 Kubernetes 和网络环境中完成部署与管理。

因此，选择部署方式时不能只问“能不能私有化”，还要进一步确认：业务数据是否允许离开客户网络、是否接受外部控制平面、遥测信息能否出站，以及安全责任由谁承担。

让权限条件跟着检索一起生效

金融知识并不是“进入知识库后所有人都能看”。客服、风控、投研和合规人员面对的可能是同一套 AI 助手，但能够访问的资料范围并不相同。

Qdrant 支持 API Key、只读 Key 和基于 JWT 的 Collection 级访问控制。对于更细的文档级权限，可以把部门、租户、用户组或文档密级保存为 Payload，再由业务系统根据当前用户身份生成过滤条件。

Qdrant 的 Filterable HNSW 会在 HNSW 图遍历过程中应用 Payload 过滤，而不是先查出一批相似结果再做事后筛选。这种方式能够减少“检索结果已经产生，权限过滤才开始”的性能损耗和越权风险。

但 Filterable HNSW 并不是一套独立的身份管理系统。用户属于哪个部门、具有什么角色，仍然应由银行现有的 SSO、IAM 或业务权限系统判断；权限条件也应由服务端强制加入查询，不能交给前端用户自行填写。

让每次操作有迹可循

《指导意见》强调人工智能应用的透明度和责任可追溯。对于 RAG 系统来说，除了记录模型最终回答，还需要记录检索层发生了什么。

Qdrant 的审计日志可以记录需要认证或授权的 API 操作，包括：

• 操作发生的时间；
• 使用 API Key 还是 JWT 完成认证；
• 访问的 Collection；
• 执行的是查询、写入、删除还是管理操作；
• 操作成功还是被拒绝；
• 用于关联应用链路的 Tracing ID。

在实际金融系统中，Qdrant 审计日志还应与应用日志、用户身份日志和企业 SIEM 平台结合。只有这样，才能把“某位用户提出问题--应用发起检索--Qdrant 访问知识--模型生成答案”串成一条完整链路。

支撑运营韧性与业务连续性

业务连续性不是购买一项“高可用功能”就自动实现，而是由容量、节点、网络、存储、备份和支持机制共同决定。

在 Qdrant 中，不同能力解决的问题也不同：

需要特别注意，复制因子不等于 Multi-AZ。即使一个分片有多个副本，如果副本都位于同一可用区，该可用区发生故障时仍可能同时受到影响。

Qdrant Private Cloud 提供 Operator 管理、自动分片再平衡、滚动升级、备份与灾难恢复等企业能力。但由于底层服务器、Kubernetes、网络和存储由客户掌握，Private Cloud 没有公开统一的 99.9% 可用性承诺，而是根据实际架构和支持范围约定自定义 SLA。客户负责基础设施，Qdrant 负责数据库软件与合同约定的技术支持，双方共同确定 RTO、RPO 和故障责任边界。

四、为什么艾体宝 Qdrant 适合金融 AI 的知识与检索层？

从《指导意见》强调的方向看，Qdrant 的适配性并不来自某一个单独功能，而是核心检索能力和企业级交付能力能够衔接起来：

• Qdrant 不是把结构化过滤放在向量检索之外，而是通过 Filterable HNSW 将过滤条件带入检索过程，适合多部门、多租户和文档权限复杂的场景。
• Qdrant 在开源核心引擎之上提供 Managed、Hybrid 和 Private 三种交付方式。客户可以根据数据驻留、控制面和运维责任要求选择部署形态，而不必更换数据库接口和核心数据模型。
• 分片、副本、量化、快照和磁盘存储等能力，使系统能够从小规模验证逐步扩展到生产环境。进入企业部署后，Operator、自动再平衡、滚动升级、灾难恢复和企业支持又进一步降低了长期运维门槛。

不过，“适合金融场景”不等于“使用后自动合规”。合规结论仍然取决于完整的系统架构、数据分类分级、权限设计、运维流程和合同责任。

五、艾体宝 Qdrant 不能替代哪些能力？

金融 AI 安全是一个系统工程。Qdrant 主要负责知识存储与检索层，不能单独解决以下问题：

• 模型幻觉和输出内容验证；
• 模型公平性、透明度和可解释性；
• 高风险 AI 应用的准入与分类分级；
• 关键业务环节的人工监督与干预；
• 企业完整的用户身份与组织权限管理；
• 模型、插件、数据源和第三方服务的整体供应链治理。

这些能力需要由模型平台、AI 网关、身份管理系统、安全平台、业务系统和管理制度共同完成。更准确的产品定位是：

Qdrant 不是金融 AI 治理的全部，但可以成为知识工程、权限检索、操作审计和业务连续性的重要数据底座。

六、金融机构选型向量数据库前，可以先回答七个问题

1. 当前和三年后的向量数量分别是多少？
2. 向量维度、查询并发和延迟目标是什么？
3. 哪些数据必须保留在境内或客户自有环境？
4. 权限需要控制到 Collection、部门、用户组还是单篇文档？
5. 是否需要记录每次查询、写入、删除及其调用身份？
6. 可用性、RTO、RPO 和厂商响应时间分别要求多少？
7. 集群由客户自行运维、厂商托管，还是双方共同负责？

这些问题的答案，往往比单纯比较一张向量数据库性能排行榜更接近生产环境的真实选型。

结语：金融 AI 真正的门槛，正在从模型转向系统

《指导意见》的发布意味着，金融 AI 已经不能停留在模型接入和 Demo 验证阶段。高质量知识如何建设、敏感数据如何保存、检索权限如何执行、操作行为如何追溯、系统发生故障后如何恢复，都会影响 AI 应用能否真正上线。

向量数据库处在企业数据与大模型之间。它不决定模型应该说什么，却直接影响模型能够看到什么、哪些内容不该看到，以及这些访问能否被记录和控制。

Qdrant 通过混合检索、Filterable HNSW、灵活部署、审计日志和分布式高可用能力，为金融 AI 的知识与检索层提供了较完整的技术支撑。真正的安全落地，则需要向量数据库与数据治理、身份管理、模型治理、安全平台和业务流程共同配合。

我们是艾体宝科技，Qdrant 企业级合作伙伴，可为金融及其他对数据驻留和安全合规要求较高的客户提供架构设计、POC 验证、私有化部署和生产上线支持。

如果您正在规划银行、保险或持牌金融机构的 AI 应用与数据平台，欢迎联系我们，获取《金融机构向量数据库落地自查清单》。