金融 AI 智能体上岗前，先把客户数据关进可审计的密态边界 (2026)

这一次，金融 AI 的问题不只是「能不能答」

过去几天，金融服务行业的 AI 讨论出现了一个值得合并观察的信号：一边是世界经济论坛与埃森哲在 2026 年 6 月发布《The AI Playbook for Financial Services》，把金融机构规模化使用 AI 的障碍明确落到数据安全、模型输出、第三方风险和治理准备不足上；另一边，面向企业的 AI 数据泄露防护、欧盟 AI 法案落地、企业 AI 智能体上下文治理等文章密集出现，说明问题正在从「试一个模型」转向「让 AI 接触真实业务数据后，谁来负责、如何追踪、怎样补救」。1 2 3 4

对银行、券商、保险、消费金融和企业财务部门来说，AI 智能体的吸引力很直接：它能读合同、查账单、汇总客户沟通、生成授信材料、辅助投研、自动补齐风控说明。但金融数据不是普通 prompt。客户身份信息、账户流水、交易偏好、信用记录、保单资料、投研底稿和内部审批意见，一旦进入不可控的模型链路，泄露的后果通常不是「回答错了」这么简单，而是合规责任、客户权益、商业秘密和监管问询一起到来。

本期选择金融场景，并不是因为金融行业最适合被 AI 自动化，而是因为它最能暴露 AI 隐私治理的底层矛盾：AI 越能办事，越需要在它办事之前，把客户数据关进一条可审计、可追责、可撤回的密态边界。

客户数据不是普通 prompt：金融 AI 的风险链更长

WitnessAI 在 6 月 28 日发布的企业 AI 数据泄露文章中，把风险路径概括得很清楚：敏感组织数据可能通过员工粘贴、未受管控的 Shadow AI 账户、权限过宽的助手检索能力，以及模型或 agent 的输出而暴露；传统 DLP 或 CASB 往往难以处理这类交互，因为风险不只取决于文件本身，还取决于对话语义、用户上下文、模型输出和 agent 行为。2

放到金融业务里，这条链路会更具体：

客户经理把企业授信材料交给大模型，让它生成尽调摘要；
投研人员上传会议纪要和交易数据，让模型提炼观点；
理赔专员让 AI 读取病历、保单和历史沟通记录，形成初步判断；
财务团队让智能体连接邮箱、网盘、ERP 和报销系统，自动查找异常；
合规团队让模型比对制度、法规和内部审批记录。

每一步都可能提升效率，也都可能把原本分散在不同权限域里的数据，重新汇聚到一个模型接口、供应商环境或 agent 工具链里。风险不只发生在「输入」时，也可能发生在检索、推理、缓存、日志、输出、供应商模型更新和后续审计环节。

自制配图：金融机构在引入 AI 之前，需要先确认客户数据、权限、模型接口和审计责任的边界。

这也是 WEF 报告反复强调数据基础的原因。报告提出，金融机构要把数据变成可用于 AI 的产品，需要明确数据目的、所有权和生命周期，并通过语义框架帮助系统正确理解数据含义，而不是把零散数据直接交给模型处理。1

换句话说，金融 AI 的第一道门槛不是模型能力，而是数据能不能在被使用时仍然保留「是谁的数据、为什么能用、能用到哪里、用完如何留痕」这些上下文。

WEF 给出的治理框架，可以翻译成一条「密态边界」

WEF 报告把金融 AI 的规模化基础分成几类：安全、可靠、可用的数据基础；面向员工能力和工作方式的重塑；嵌入企业风险管理主干的 AI 风险管理；以及真正落进治理结构的负责任 AI。1

如果把这些要求转译成金融机构可以检查的隐私治理问题，大致可以落在六个控制域：

WEF 控制域	金融 AI 隐私落点	企业应追问的问题
数据治理	数据收集、使用、共享、保留和删除要合法、适用、可追踪、受控。1	哪些客户数据可以进入 AI 流程？是否有脱敏、分级、最小必要和保留期限？
董事会与高管监督	明确风险偏好、问责机制，并要求报告 AI 暴露、事件、合规和性能。1	AI 项目是业务部门自行试用，还是已经进入风险委员会和合规审查？
治理与合规领导	定义审批门、独立挑战、政策标准和可审计性，包括二线风险合规监督和三线内审测试。1	上线前谁批准？上线后谁复核？发生争议时谁能调取证据？
安全与韧性	用安全控制、韧性测试、事件响应和第三方保证保护 AI 系统及其依赖。1	模型接口、网关、日志、密钥和供应商链路是否经得起攻击与故障？
人工交互与补救	确保输出安全用于工作流，受影响方可以覆盖、申诉和补救。1	AI 给出的拒贷、理赔、风控建议，是否能被人类复核和解释？
模型治理	发布前和发布后监控、验证、受控变更，确保模型符合性能与风险阈值。1	模型更新后，是否重新验证隐私、偏差、准确性和业务影响？

这张表背后的核心不是多设几道审批，而是建立一条「密态边界」：业务可以调用 AI，数据可以支撑决策，但明文、权限、用途、输出和责任不能在模型链路里失控。

Agentic AI 让权限问题变成执行问题

过去，企业担心员工把敏感资料粘贴进公共 AI 工具；现在，更复杂的问题是智能体可以自己调用工具、读取系统、组合数据、触发动作。CIO 采访 Informatica 相关负责人的文章指出，当 AI agents 开始作用于企业数据时，metadata 不再只是目录或合规材料，而会成为业务上下文来源；仅有技术元数据还不够，还需要政策、业务流程、业务语言等机器可读的治理上下文。4

金融场景下，这意味着「能不能访问」不能只靠一个静态权限表。一个投研 agent 也许可以读取公开财报，却不应读取尚未公开的内部会议纪要；一个客服 agent 可以查客户购买的产品，却不应把完整身份证件、资产余额和历史投诉记录同时带入外部模型；一个财务 agent 可以生成异常报销提示，却不应自动向外部收款方发送含敏感信息的邮件。

自制配图：当智能体能够调用系统和工具时，企业需要在检索、推理、输出和动作执行前设置检查点。

这也是为什么单纯「禁用公共 AI」不是长期答案。更可行的方向是把 AI 使用拆成几层：

入口层：识别用户、部门、任务类型和数据敏感度，先判断能否进入 AI 流程；
数据层：对敏感字段做脱敏、过滤、加密或密态处理，限制明文暴露；
模型层：按数据等级选择本地模型、私有化模型、可信第三方模型或拒绝调用；
agent 层：限制工具权限，给高风险动作设置人工确认和多模型复核；
输出层：检查模型响应是否泄露个人信息、内部资料或违规建议；
审计层：保留必要日志，支持事件追溯、合规证明和客户申诉。

WitnessAI 提到的 discovery、intent-aware classification、tokenization、policy enforcement、model routing、prompt/response 实时检查，本质上就是把这些控制点前置到 AI 交互发生的瞬间。2

第三方模型风险，不能只靠一份合同解决

WEF 报告还点出了金融机构使用生成式 AI 时一个容易被低估的问题：很多机构会采用第三方模型和方案，但传统供应商审计很难端到端追踪供应商的数据与算法，供应商也可能在软件更新上缺少充分协商空间。报告给出的缓解思路包括第三方网关、检查点、防火墙、独立测试和更严格的审计。1

金融机构尤其要关注三个具体问题。

第一，prompt 和文件是否会被供应商保留、用于改进模型，或者进入难以解释的日志链路。WEF 报告在数据与隐私风险中提到，AI 可能处理敏感或专有数据，输出可能泄露或推断出本应受保护的个人信息；模型提供商也可能未经允许保留 prompts，用于或误用于模型性能改进。1

第二，供应商模型更新后，原有的风险评估是否仍然成立。一个模型从旧版本升级到新版本，可能改变输出风格、拒答策略、幻觉率、上下文处理能力和数据保留策略。对金融机构来说，这不是技术细节，而是合规和模型风险管理问题。

第三，供应商链路出现问题时，金融机构能否向客户、监管和内审说明发生了什么。Docker 在欧盟 AI 法案合规文章中提醒，AI 治理需要被工程化，而不是只停留在原则层；欧盟 AI 法案按风险层级设置义务，相关要求将持续推进到 2027 年。3

自制配图：金融 AI 的供应商治理需要能追溯模型接口、数据去向、版本变化和人工复核记录。

因此，金融 AI 的第三方管理不能只问「对方是不是大厂」或「合同里有没有保密条款」，而要问：客户数据是否隔离，prompt 是否保留，模型输出是否可检查，供应商更新是否可控，异常事件是否可追溯。

国内 AI 隐私平台的价值：把「可用」和「不可见」同时放进流程

在国内市场，荆华密算近期围绕 AI 隐私平台和「墨镜熊」公布了新的公开材料。中华网转载的公开报道显示，平台域名为 [www.mojingxiong.com](https://www.[mojingxiong.com](https://mojingxiong.com))，覆盖法律咨询、医疗健康、心理咨询、职场事务、金融分析、科研工作等高敏感场景，并提到全链路加密、密态存储、本地持钥、服务端仅保存密文、阅后即焚等能力。5 荆华密算公众号在 6 月 26 日发布的文章中也称，其 AI 隐私平台用户量和 Token 消耗在近期增长。6

这些材料有宣传属性，不能把厂商自述直接等同于独立验证结论；但如果把它放回金融 AI 隐私治理框架里看，它对应的是一个清晰的工程方向：让业务仍然可以使用 AI，同时减少明文数据在平台、模型和服务端暴露的机会。

以金融分析场景为例，理想的 AI 隐私平台不应只是「换一个聊天界面」，而应至少承担四类能力：

输入前防护：识别客户身份、账户、合同、流水、投研底稿等敏感信息，对不必要字段做过滤或脱敏；
传输与计算防护：在输入、传输、计算、推理和结果返回过程中，降低明文暴露面；
存储防护：会话记录、上传文件、知识库内容以密文形式保存，密钥由用户本地持有，服务端只保存密文；5
流程防护：把 AI 使用纳入权限、审计、删除、复核和事件响应，而不是只靠员工自觉。

这里需要特别克制：密态计算、全链路加密和本地持钥能显著降低数据暴露面，但它们并不自动替代金融机构自己的数据分类、DPIA、供应商审计、模型验证、人工复核和客户申诉机制。真正有效的隐私平台，应该被放在企业治理流程里，而不是被包装成一键消除所有风险的工具。

给金融机构的 5 个落地检查问题

如果一家金融机构准备让 AI 智能体进入真实业务流程，可以先用下面 5 个问题做内部体检。

数据是否已经分级？ 哪些字段属于个人信息、敏感个人信息、商业秘密、未公开投研信息或监管限制数据，是否写进了机器可执行的策略？
模型调用是否可路由？ 不同敏感等级的数据，是否能被分流到本地模型、私有化模型、可信第三方模型或直接禁止调用？
agent 权限是否最小化？ 智能体能读哪些系统、调用哪些工具、执行哪些动作，是否按任务动态授权，而不是继承员工全部权限？
输出是否可复核和补救？ 涉及授信、理赔、投资建议、客户权益或监管申报的输出，是否有人审、复核、申诉和回滚路径？
供应商链路是否可审计？ prompt、文件、日志、模型版本、接口调用和异常事件，是否能被追踪到足以应对内审、监管和客户争议？

金融 AI 的下一阶段，竞争点不会只是谁接入了更强的模型，而是谁能在真实业务里证明：客户数据可以支撑智能决策，但不必裸奔穿过模型、供应商和日志系统。对金融机构来说，「密态边界」不是额外的安全装饰，而是 AI 从试点走向生产的入场条件。

金融 AI 智能体上岗前，先把客户数据关进可审计的密态边界