Al Chen：银行部署 AI 的证据、容灾与数据保护

我十年级的数学老师要求答案精确到小数点后四位，但大部分分数来自证明过程。银行的风险与合规团队在更大的规模上提出类似要求：不仅要给出答案，还要展示推导过程。

将 AI 部署到银行生产环境需要时间。我说的是数百万客户使用的应用，而不仅是原型或内部效率工具。我们的团队帮助大型银行部署软件和工程流程；我会分享我们用来缩短部分项目上线时间的方法。

带有外向互联网访问的常规 SaaS 部署，可能与银行的敏感数据边界冲突。我把问题分为三部分：构建流水线中的漏洞处理、灾难恢复，以及防止敏感信息从意想不到的路径泄露。

单个 CVE 可以通过公开数据库查询，但真实平台在多家银行运行许多镜像和依赖。每家银行可能使用不同版本、扫描工具、严重性政策和修复期限。

部分问题位于开源传递依赖中，工程团队无法直接修复。我们跟踪上游发布，并向银行安全团队解释依赖关系。可以修复的部分可能通过升级包或基于新基础镜像重新构建处理，同时必须验证应用仍能运行。

不同银行还可能要求不同的软件包版本。一个技能可以帮助研究和报告 CVE，指出团队能修复的部分，并解释哪些问题依赖上游维护者。

扫描器检查软件包版本，本身不能证明某个漏洞利用是否仍然对应用有效。Chen 描述了一个 Harbor 任务：提供指令、应用容器镜像和测试，让智能体尝试在据称已修复的版本上重现旧漏洞。

这些试验可以在不同容器或沙箱中运行。重点是为特定问题提供证据，而不是只说版本号变了。一次漏洞测试未成功，只能为该测试提供证据，并不能证明应用没有其他漏洞。

灾难恢复是银行的核心要求。Chen 介绍了客户环境中 ClickHouse 跨区域恢复的挑战，并提出一种模式：从主区域备份到对象存储，再恢复到灾备区域。

示例使用开源 ClickHouse backup 项目，并可在恢复区域建立副本。备份或恢复日志显示成功，并不能单独证明恢复数据既新又正确；磁盘故障、迁移或复制延迟都可能造成影响。

额外检查可以比较表的行数，并检查副本是否收敛。这些检查有助于评估数据正确性，但不构成完整保证。灾备架构也必须考虑数据驻留要求。

例如，一种设计可以跨区域复制 ID 和追踪元数据，同时把底层追踪数据保留在允许的区域。这样的做法是否合适，取决于数据本身、适用要求和银行自己的控制措施。

第三部分是敏感数据泄露。脱敏可以在 SDK、网关或中间件完成，但即使用户界面正确遮盖信息，应用仍可能通过其他路径暴露个人信息或重大非公开信息。

一个例子是用于评价智能体的 LLM 裁判。提示词要求它解释评分时，裁判的推理或追踪记录可能重新包含敏感细节，即使前端记录看起来已经脱敏。

Chen 提议让裁判读取原始追踪数据，但不保存其推理，同时保留评分。系统可以检查解释是否适合展示；如果发现敏感信息，就抑制该解释。

对于需要解释的团队，他还介绍了让第二个裁判读取脱敏输入的做法。这会增加一次模型调用和成本。脱敏与检查可以降低暴露风险，但必须针对实际系统验证，不能据此保证零泄露。

向安全与合规团队展示证据有助于建立信任。供应商承诺几周内上线时，需要结合具体银行的基础设施、安全状况和集群配置来检验。

已有的镜像审批与拉取流程、可用 GPU 等条件能够加快部署。正式安全审查、自定义模型网关或基于角色的权限配置可能延长时间；如果缺少镜像审批或 GPU 采购流程，延迟可能更长。

许多进度风险来自组织协调，而不只是技术。Chen 的团队把客户问题分为工程、工作流与人员协调几个方面，再尽可能自动化。目标是解决银行的实际问题，并展示结论如何得出。

银行业务涉及支票账户、抵押贷款和信用卡，这也解释了为什么审慎的流程仍然存在。最后，Chen 邀请从业者分享各自解决客户难题的方法，正如同学们曾在考试后交流数学解法。