思科Al Chen：AI进银行，改版本号、跑完备份、遮住界面都不够

思科AI可观测性软件团队负责人Al Chen在2026年10月的AI Engineer大会上做了一个类比：他十年级的数学老师Mr. Huff要求答案精确到小数点后第四位，但大部分分数来自证明过程。银行的安全和合规团队像Mr. Huff，只不过手里握着数百万美元的合规预算。Chen的团队把AI可观测性软件部署到全球最大的几家银行，他们发现缩短审查周期的真正杠杆不是让模型更强，而是让每一步都能被检查。

以CVE修复为例。一个平台有多个镜像，每个镜像包含多个CVE，不同银行运行不同版本，使用不同扫描工具，各自有严重性策略和修复时限。常规做法是升级包版本或重建基础Docker镜像，扫描工具（Sysdig、Wiz、Prisma等）确认版本号已变更后即放行。Chen指出这远远不够：版本号变了，不代表那个具体漏洞在应用代码中仍然无法被利用。他的团队用Harbor任务框架构建额外证据——让agent基于旧版本编写exploit，在新版本上尝试，再写测试验证exploit是否仍然成功。Harbor可以并行运行多个容器或沙箱，提供多次试验。Chen同时承认边界：一次失败的尝试是关于那个特定exploit的证据，不是所有可能exploit都不存在的证明。

灾备遵循同一模式。Chen描述ClickHouse部署中，银行必须自行安排跨区恢复，因为该平台没有托管的跨区域故障转移服务。他们用开源项目clickhouse-backup将主区数据库备份到存储桶，再在灾备区执行恢复任务。工具日志能显示任务是否完成，但Chen说这个状态不能说明数据现在是否正确——坏磁盘、节点故障、迁移问题或复制延迟都可能让数据与任务执行时不一致。他追加了表行数检查和区域内副本收敛检查，把验证对象从'任务是否跑完'转向'数据是否正确'。

第三个例子最容易被忽视。SDK层、网关层或中间件的脱敏处理让面向用户的界面看起来干净，但LLM-as-a-judge创造了另一条泄露路径：裁判对agent输出打分并生成解释供人工复核，如果裁判看到的是原始trace，其推理过程可能重现个人身份信息或重大非公开信息。Chen建议检查裁判提示词和trace中的泄露，并提出分离方案：分数始终持久化用于评估，推理经过敏感信息检查后才决定是否展示；如果银行仍需要解释，就运行第二个裁判，输入已经过脱敏处理。代价是同一请求多一次LLM调用。

Chen的结论是：合规速度取决于银行自身的就绪程度——是否已有从镜像仓库拉取镜像的流程、GPU是否到位、安全审查和访问配置是否就绪。这些延迟更多来自组织对齐而非技术。他的团队把客户问题当作自己的问题，分为工程、流程和人员组织三条线，能自动化的尽量自动化。

值得注意的边界：Chen描述的是大型厂商向多家银行部署同一产品的场景，其工程投入（维护Harbor测试框架、运行双裁判、跟踪开源上游依赖）未必能直接迁移到小团队或单一客户的部署。他提到的'从一年缩短到几周'是相对值，实际时间仍取决于银行基础设施和审批流程的成熟度。