Banks Build AI Layers over Mainframes to Avoid Legacy Code Tear Downs

银行在大型机之上构建AI层以避免重构遗留代码 金融机构正部署描述性中间件与严格的权限层，在将遗留大型机连接至AI模型的同时防止敏感数据泄露。 来自Fulton Bank和Deutsche Bank的工程负责人探讨了金融机构如何推进遗留基础设施现代化并落实AI护栏。他们深入探讨了开发者采纳、内部RAG检索以及人机在环（human-in-the-loop）治理策略的现实情况。专家小组还分析了自研与采购的权衡困境、安全权限层、Token经济学，以及银行如何为向本地开放权重模型的转变做好准备。 银行业普遍避免直接重构传统大型机，而是采用 OpenMetadata 等工具搭建描述性中间 API 转换层，将积累数十年的高信任度核心数据与业务逻辑安全暴露给 AI Agent。 (0:04) 银行目前优先落地内部辅助型 AI 场景而非直面客户；Fulton Bank 全栈团队约 85% 的用户需求已借助 AI 开发，但严格实行人机协同（Human-in-the-loop）机制，由工程师对所有部署代码承担完全责任。 (0:35) AI 加速代码生成后暴露了软件交付价值链的下游瓶颈，用户验收测试（UAT）与发布流程无法及时承接激增的代码量，甚至导致部分端到端交付周期被拖慢。 (8:04) 在架构选型上，专家建议采购基础平台与编排框架，自研差异化的数据护栏与权限层，并通过本地私有化部署 Gemma、Llama 等开源权重模型来保护敏感财务数据。 (11:48)

Engineering leaders at Fulton Bank and Deutsche Bank emphasize that adopting artificial intelligence in modern banking relies on keeping core legacy systems as sources of truth while building semantic translation layers, strict internal entitlements, and robust human oversight. Preserving Legacy Systems via Semantic Middle Layers (0:04) Rather than rewriting or dismantling decades-old mainframe systems, banks treat these platforms as indispensable, auditable sources of truth that store 10 to 20 years of vital enterprise data. Murali Boddu explains that the technical priority at Deutsche Bank is building descriptive middle API layers—using tools like OpenMetadata—that explicitly map IDs and data records into structured, context-rich formats that external LLMs and non-human AI agents can interpret. Internal AI Adoption and Software Pipeline Bottlenecks Both institutions deliberately focus AI on internal productivity rather than customer-facing products. At Fulton Bank, roughly 85% of full-stack user stories are AI-assisted, though the bank enforces a strict policy requiring a human engineer to take personal accountability for any deployed code. However, accelerating code output exposed downstream delivery friction: downstream User Acceptance Testing (UAT) and release teams were overwhelmed by incoming builds, which Stephen Frein noted sometimes prolonged end-to-end cycle times. On the business side, Deutsche Bank deploys agentic workflows to streamline relationship management, automatically mining context from Slack, Microsoft Teams, and Outlook to populate CRM logs and generate follow-up briefings. Similar tooling reduced the production time of client pitchbooks from days or weeks down to roughly one hour, with systems engineered to link outputs directly back to source documents for explainability. Entitlement Layers, Sandboxing, and Data Privacy (18:08) Because foundation models and agent frameworks are quickly becoming commoditized, Boddu argues that a bank's true competitive edge lies in its proprietary entitlement architecture. Deutsche Bank is constructing a dynamic security layer where access permissions for both human employees and autonomous agents are evaluated against geographic location, regulatory jurisdiction, and specific business mandates. To prevent data leaks, neither bank exposes customer Personally Identifiable Information (PII) to third-party frontier APIs. Instead, institutions rely on contractual Master Service Agreements, automated data masking, and network sandboxing under the principle of least privilege. Fulton Bank avoids transmitting financial customer records to external commercial LLMs by testing self-hosted open-weight models from Meta's Llama and Google's Gemma families, while intentionally bypassing Chinese open-weight frameworks like Qwen over security, tracking, and compliance concerns. Architectural Modularity and Evaluating AI Value (11:48) In navigating the buy-versus-build dilemma, Boddu recommends buying foundational infrastructure—such as vector search engines, orchestration layers, and base agents—while building domain-specific rules, entitlements, and data connectors. Designing modular API architectures enables institutions to replace underperforming vendors without disrupting operational baselines. Frein adds that Fulton Bank defaults to commercial software unless centuries-old bespoke institutional practices demand custom development. Quantifying AI return on investment remains difficult across both organizations. While exact financial attribution is elusive, leaders track operational proxies, such as faster meeting preparation and accelerated task completion. Frein highlights that token consumption offers an unprecedented method to quantify the exact unit cost of machine intelligence, prompting teams to use model routing platforms like OpenRouter to redirect routine coding tasks away from expensive frontier models to lower-cost options. Engineering Governance and Limits of Unguided Generation (42:29) Addressing practices like 'vibe coding,' the panelists reject allowing unguided, LLM-generated code into production without deep technical domain expertise, warning it would create severe maintenance deficits. Instead, Boddu supports vibe coding solely for rapid business prototyping or building registered end-user applications that software engineers later re-architect. While Fulton Bank plans to explore autonomous code-generating agent swarms around 2027, engineering currently relies on individual developers using tools as co-pilots alongside static vulnerability scanners. Regarding the broader security landscape, Frein notes that automated AI scanning tools lower the barrier for attackers to chain together simple configuration oversights, drastically increasing the pressure on engineering teams to accelerate vulnerability patching and security remediation. While AI tooling delivers clear productivity gains in internal software development and sales operations, widespread banking deployment hinges on solving downstream pipeline bottlenecks, improving agent observability, and creating reliable customer-facing models that move beyond current industry hype.

富顿银行（Fulton Bank）的Stephen Frein与德意志银行（Deutsche Bank）的Murali Boddu指出，银行业引入AI技术栈的核心并非推翻历史核心系统，而是构建可信的语义翻译中间层与严格的动态权限护栏，并在基础设施采购与差异化自建之间保持模块化平衡。 传统核心系统的保留与语义中间层构建 (0:04) 面对银行业数十年累积的庞大遗留系统，Murali Boddu明确反对重写或拆除老旧架构。他指出，以大型机为代表的遗留应用承载着机构10至20年的历史交易与业务逻辑，早已成为业务人员充分信赖的“单一事实来源”（Single Source of Truth）。银行业的核心技术杠杆恰恰在于这些深厚的数据资产，其软肋仅在于非人类AI智能体无法直接解析其表结构与业务上下文。 为此，德意志银行的技术重心是构建一套描述性的API语义中间层（例如引入OpenMetadata等开源元数据工具）。该层能够将原始的系统记录清晰映射为包含业务含义、客户实体与访问护栏的结构化上下文，充当底层大型机与上层AI Agent或大语言模型（LLM）应用之间的翻译桥梁，使智能化调用无需直接触动底层敏感架构。 内部落地实效与交付流水线中的吞吐瓶颈 (8:04) 在落地节奏上，两家银行目前均采取审慎态度，将AI应用严格圈定在面向员工和技术团队的内部辅助场景。在业务端，德意志银行利用Agent工作流从Microsoft Teams、Slack或Outlook中自动提取客户会议要点并归档至CRM，更通过整合内部历史数据与实时市场数据，将传统耗时数天乃至数周的投行业务推介书（pitchbook）编制压缩至约1小时；在研发端，富顿银行全栈开发团队中已有约85%的用户故事（user stories）采用AI辅助生成。 然而，代码生成效率的飙升暴露出软件工程流水线下游的经典DevOps瓶颈。Stephen Frein坦言，当开发人员产出速度超越组织的消化能力时，测试、用户验收测试（UAT）与发布部署团队因承接量过载而发生拥堵，甚至拉长了端到端交付周期。此外，富顿银行坚持“人在回路”（human-in-the-loop）问责制，规定由具体工程师承担部署代码的最终责任，防范无监督的AI代码直接渗入生产环境。 “采买平台与自建差异”及严苛的数据隐私边界 (11:48) 在架构选型层面，两位技术主管一致主张“采购基础平台，自建核心差异”。Murali Boddu认为内部研发无法匹敌前沿AI生态的创新迭代速度，因而基础模型调用、工作流编排和向量检索等底座应直接采购商业方案；银行团队则应集中资源自建专有数据护栏、业务合规规则与定制连接器。同时，系统设计必须保持高度模块化，以便在第三方能力落后时平滑替换供应商。 在数据安全与模型主权方面，金融机构恪守严厉的数据隔离底线。富顿银行禁止将个人身份信息（PII）或客户敏感财务数据发送给外部前沿商业API，转而积极评估并在本地自托管开源权重模型（如Google Gemma和Meta Llama系列）。对于Qwen等中国开源模型，Stephen Frein表示尽管其性能亮眼，但受制于数据回传疑虑及严格的监管合规审查，保守型金融机构在生产环境中仍持观望态度。 上下文感知权限体系与AI驱动的安全攻防 (18:08) 针对未来几年的核心技术壁垒，Murali Boddu指出，随着基础大模型与Agent框架走向通用化，银行真正的竞争护城河在于其内部权限体系的精细度及安全智能体间通信（agent-to-agent）协议。德意志银行正在研发上下文感知的AI权限层，基于用户的物理位置、监管管辖区、职能角色与业务授权动态生成执行权限，并同等施加于各类自动化Agent。 在安全防御上，AI双刃剑效应显著加剧了补丁管理压力。Stephen Frein分析，近期诸多安全事件表明，攻击者主要利用AI自动化扫描工具快速串联既有的运维配置漏洞与未打补丁的端口，而非挖掘全新的零日漏洞（zero-day）。这使软件团队面临类似于“放大版Log4j”的安全攻防节奏，漏洞修复响应速度已成为保障生产环境不被入侵的决定性指标。 当前银行业通过代币（Token）消耗首次实现了对机器智能成本的量化衡量，但整体AI转型的投资回报率（ROI）测算仍依赖流程提速与员工采纳率等代理指标。技术管理者普遍认为，完全自主运行的Agent集群开发或真正成熟的客户服务代理仍面临治理瓶颈，在端侧小模型与推理成本进一步降低之前，银行业仍将坚持以严格风控护栏为前提的渐进式赋能路径。

## Background 该视频由专业科技峰会平台 Ai4 于 2026 年 8 月 21 日发布在 YouTube 上。根据页面介绍，本次圆桌论坛深入探讨了现代银行业的企业级 AI 技术栈架构，重点聚焦金融机构如何构建安全合规的数据管道与智能体编排底座、权衡“自建与外购”策略、现代化改造遗留系统，以及如何将 AI 成功从概念验证（PoC）推进到稳健的生产环境。 ## TL;DR 来自富尔顿银行与德意志银行的技术高管深入分享了银行业 AI 落地的真实架构与工程实践。他们强调不应盲目重写经过长期验证的遗留底座，而应构建语义元数据中间层连接 AI 智能体；架构上采取“采购通用平台、自研差异化权限层与合规护栏”的策略。讨论指出，代码生成的提速导致了价值链下游测试与交付的“瓶颈位移”，而企业未来的核心壁垒在于权限上下文感知与漏洞快速修补能力。针对“氛围编码（Vibe Coding）”与开源模型，专家肯定了其在业务快速原型验证中的巨大价值，但强调生产级交付仍必须坚守人机协同兜底与严格的工程审查。 ## Atmosphere & style 整场对谈呈现出务实、清醒且兼具幽默感的一线工程技术对话氛围。主持人提问直击要害，两位在金融 IT 领域深耕数十年的技术老兵毫无泛泛而谈的公关辞令，不仅大方分享安全对齐测试中被大模型反复拒答的窘境与对劣质 AI 客服的直率吐槽，更以扎实的数据和架构图透视组织痛点。现场气氛在严谨的风控思辨与活跃的会场互动之间自如切换，生动传递出金融业在拥抱前沿 AI 浪潮时兼具的敬畏与野心。 ## Key takeaways - [02:35](https://www.youtube.com/watch?v=hwn30c0wbF0&t=155s) 银行业不必全盘推翻重构古老的遗留系统，更务实的做法是搭建能够为 AI Agent 准确解释业务语义与数据结构的描述性中间层（Middle Layer）。 - [03:54](https://www.youtube.com/watch?v=hwn30c0wbF0&t=234s) 当前银行落地 AI 遵循严谨的“人机协同”（Human in the Loop）原则，任何模型生成的代码或业务交付物均必须由明确的工程师作为责任人全权兜底。 - [08:16](https://www.youtube.com/watch?v=hwn30c0wbF0&t=496s) AI 辅助编码导致“瓶颈位移”，开发者产出速度远超组织消化能力，使验收测试（UAT）和生产部署环节成为整体迭代周期的主要堵点。 - [12:00](https://www.youtube.com/watch?v=hwn30c0wbF0&t=720s) 自研与外购的选型策略应当是“底座与通用平台外购，专属差异化与合规护栏自研”，并保持底层架构的高可插拔性以随时替换供应商。 - [12:00](https://www.youtube.com/watch?v=hwn30c0wbF0&t=720s) 为保障金融核心数据安全，银行在涉及敏感财务与 PII 数据时严禁直接调用外部前沿闭源大模型，转向在内网私有化部署开源权重中小模型。 - [21:03](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1263s) 未来两到三年金融科技的核心壁垒在于“权限上下文感知层”（Entitlement Layer）与智能体间安全通信机制，而非外部同质化的通用大模型本身。 - [21:03](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1263s) 随着大语言模型高效串联并挖掘现有已知漏洞，工程团队在生产环境极速打补丁（Patch Management）的响应速度将成为系统安全态势的胜负手。 - [23:48](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1428s) 银行业衡量 AI ROI 极具挑战，但 Token 消耗模式首次让人类能精确量化“智能的成本”，结合模型路由（Model Routing）可有效优化算力支出。 - [28:53](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1733s) 知识工作非有限体量，AI 降低单位成本将激增总体市场需求；善用 AI 杠杆的高阶人才价值被放大，而照本宣科的机械式岗位面临淘汰危机。 - [33:11](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1991s) 未来 5 年内随着模型与推理成本雪崩式下降，顶尖大模型有望直接运行在员工本地 PC 终端，实现零云端 Token 成本的本地化推理。 - [35:25](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2125s) 在强监管与严格安全审计考量下，欧美金融机构现阶段对源自中国的开源权重模型（如 Qwen）仍持明确排除的保守立场。 - [37:17](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2237s) 借助 OpenMetadata 等工具为遗留系统标注业务语义并封装 API，是将历史数据资产无缝转译为 AI 智能体可用接口的关键基础工程。 - [42:29](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2549s) “氛围编码”（Vibe Coding）现阶段的核心价值在于加速产品经理的 Demo 原型验证与业务人员自用工具开发，但绝不能未经专业工程审查直接上线生产环境。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=hwn30c0wbF0&t=4s) 百年银行业的 AI 转型命题与嘉宾背景介绍 科技记者 Naomi Nix 作为主持人为本场对谈开场。她拥有近十年的科技报道经验，先后任职于彭博新闻社（Bloomberg News）和《华盛顿邮报》（The Washington Post）。Naomi 指出，银行业作为拥有数百年历史的传统支柱行业，当前正处在一个极具张力的十字路口：一方面必须积极拥抱尖端的前沿技术，另一方面又必须时刻恪守严格的监管与风控标准，以保护宏观经济安全。 富尔顿银行（Fulton Bank）软件开发高级副总裁 Stephen Frein 介绍了该行的技术概况。富尔顿银行是一家总部位于宾夕法尼亚州兰开斯特的中型区域性银行，业务覆盖大西洋中部地区。Stephen 掌管的软件开发团队约有 75 人，涵盖全栈开发、Salesforce 生态开发、基于 Boomi 平台（类似于 MuleSoft）的系统集成，以及 SharePoint 和机器人流程自动化（RPA）等技术领域。 德意志银行（Deutsche Bank）销售技术（Sales Technology）区域工程负责人兼副总裁 Murali Boddu 回顾了自己的职业生涯。他在银行业深耕超过 20 年，早期从事固定收益与资本市场开发，最初以大型机 COBOL 程序员的身份入行，如今已身兼主任工程师与区域技术负责人等多重角色。 - **主持人**：Naomi Nix（科技记者，曾任职于 Bloomberg News 与 The Washington Post） - **富尔顿银行**：Stephen Frein（软件开发 SVP，管理约 75 人的全栈、Salesforce、Boomi 集成与 RPA 研发团队） - **德意志银行**：Murali Boddu（销售技术 VP 兼 Lead Engineer，拥有 20 余年银行业技术研发经验） --- ### [02:35](https://www.youtube.com/watch?v=hwn30c0wbF0&t=155s) 遗留系统不是负债：构建“智能中间层”连接传统底座与 AI Murali Boddu 结合自己从 COBOL 大型机跨越到当今 AI 与低代码时代的经历，阐述了对银行传统架构现代化的深刻见解。他认为银行业不应该盲目执着于“推翻并现代化改造”老旧的遗留平台（Legacy Platforms）。这些系统已经在银行内部稳定运行了数十年，赢得了业务端的高度信赖，它们本身就是经过严格审计、可靠性极高的“单一事实来源”（Single Source of Truth）。 与其耗费巨资重写遗留系统，更务实且高效的路径是构建一个健壮的“描述性中间层”（Middle Layer）。该中间层能够准确向 AI Agent 和前沿应用解释、暴露底层遗留系统的业务逻辑与数据结构。如何高效搭建这个中间层，直接决定了银行能否在兼顾传统系统稳定性与 AI 前沿创新之间取得最佳平衡。 ```mermaid flowchart TD accTitle: Legacy Systems and AI Modernization Architecture accDescription: Architecture showing legacy mainframe systems connecting through a semantic middle layer to AI agents and business apps. subgraph Legacy["传统核心底座 (经过数十年验证的事实来源)"] A["大型机与核心账务系统 (Mainframe / COBOL)"] B["历史交易与资本市场数据仓"] end subgraph Integration["上下文语义中间层 (核心改造重点)"] C["API & 数据语义描述层 (Middle Layer)"] D["合规审计、授权上下文与安全护栏"] end subgraph AIApp["前沿 AI 应用层"] E["AI Agents & 自动化工作流"] F["CRM 销售端与业务决策工具"] end A --> C B --> C C --> D D --> E D --> F ``` --- ### [03:54](https://www.youtube.com/watch?v=hwn30c0wbF0&t=234s) 银行内部的技术落地：内部赋能、人机协同与可追溯性 在谈及当前的实际落地进展时，Stephen Frein 强调富尔顿银行采取了相对审慎的策略。目前 AI 主要定位为“内部辅助工具”（Internal and Assistive），除极少数受限场景外，基本不对终端零售客户直接开放。落地重心集中在文档检索问答（RAG）、文本摘要以及研发团队内部的代码生成辅助。 Stephen 特别强调了“人机协同”（Human in the Loop）的铁律：任何由 AI 辅助生成的代码、配置或技术交付物，都必须有明确的开发者作为“工具所有者”（Tool Owner）承担全部兜底责任，就像多年前开发者对从 Stack Overflow 上借鉴的代码全权负责一样。 Murali Boddu 表示德意志银行同样恪守稳健原则，并将技术落地划分为两大支柱： 1. **AI for Tech（技术赋能）**：利用前沿模型与 GitHub Copilot 快速搭建 PoC 并生成海量代码，同时引入自动化代码审查（Automated Code Reviews）以防范外部漏洞。 2. **AI for Business（业务赋能）**：AI 绝不能成为黑盒，所有决策结论必须能够反向编排、追溯并提供底层单一事实来源的链接（Links to the Source of Truth），向业务人员清晰解释“AI 如何得出该结论”。 德意志银行销售技术团队正在打造的“客户情报平台”（Client Intelligence Platform）便是一个典型案例。以往银行家为拜访医疗、油气等行业客户制作推介材料（Pitchbooks）需要耗费数天甚至数月进行市场与财务调研；现在借助新平台，结合银行内部数十年的专有历史数据与最新的市场公开情报，可在约 1 小时内自动生成高质量摘要与推介底稿。 - **富尔顿银行主要落地场景**：知识库 RAG 检索、文本内容摘要、开发者代码生成。 - **人机协同准则**：代码与系统配置必须指定具体工程师作为最终责任人。 - **德意志银行客户情报平台**：将原本需数天甚至数月的 Pitchbook 编制压缩至 1 小时左右。 --- ### [08:16](https://www.youtube.com/watch?v=hwn30c0wbF0&t=496s) 生产力提速与“瓶颈位移”：从代码生成到业务吞吐的现实挑战 Stephen Frein 分享了一组具体的度量数据：富尔顿银行全栈开发团队目前约有 85% 的用户故事（User Stories）开发都得到了 AI 的辅助。起初开发者觉得处理 1 点（1-point story）这种轻量需求没必要打开 Claude 等编码助手，但随着对工具链日益熟练，小需求的 AI 渗透率也在快速上升，同时呼叫中心坐席的通话处理时长（Handle Time）和摘要效率也显著优化。 然而，研发提速却带来了一个反直觉的组织级挑战——“瓶颈位移”。Stephen 指出，代码生产速度的大幅提升并没有直接转化为更快的端到端业务价值交付，反而彻底暴露了软件价值链后端的堵塞点： > "我们的开发者现在生产交付物的速度，已经远远超过了整个组织吸收和消化它们的能力。" 当代码产出激增时，用户验收测试（UAT）与生产部署环节瞬间成为严重卡点的瓶颈，在部分场景下甚至导致整体迭代周期反而被拉长。 Murali Boddu 随后分享了德意志银行在销售运营效能方面的突破。过去银行家在结束客户拜访后，必须手动打开浏览器登录 CRM 系统输入拜访纪要（Call Reports），导致大量记录因繁琐而缺失。去年团队上线了 Agentic Workflow（智能体工作流）：AI Agent 会自动分析 Outlook 邮件、Microsoft Teams 或 Slack 频道中的对话，自动提取核心上下文生成纪要；当银行家数月后再次约见同一客户或同一企业的其他负责人时，系统会自动汇总调出历史对话背景，并生成最具针对性的业务推介方案。 --- ### [12:00](https://www.youtube.com/watch?v=hwn30c0wbF0&t=720s) 自建（Build）vs 采购（Buy）：底座买标准，差异化自研与架构可插拔 面对外部 SaaS 厂商与初创企业惊人的创新速度，两位嘉宾探讨了金融机构在“自研与采购”之间的决策逻辑。 Murali Boddu 认为没有任何单家机构能在通用模型与工具创新上单挑整个外部生态。他的核心策略是：“采购通用平台与编排层，自研业务差异化能力”（Buy the platform, build the differentiator）。基础的工作流引擎与 Agent 底座可以通过采购获取，但机构专属的数据主权、合规护栏（Guardrails）以及与自身授权体系深度绑定的上下文感知层，必须由内部自研。此外，架构必须保持高度的“可插拔性”（Pluggability）——德意志银行去年就曾因功能不达标而果断下线某家供应商，由于底层服务解耦良好，未来可以随时无缝接入新的细分专精 Agent。 Stephen Frein 也表达了相似的架构逻辑。富尔顿银行在通用能力上重度依托成熟供应商，例如基于微软的 Copilot Studio 搭建 RAG 问答机器人，利用 Salesforce 的 Trust Layer 处理 CRM 内部数据。然而，在涉及核心敏感的客户财务数据时，银行坚决禁止将其暴露给边界之外的闭源前沿大模型。为此，富尔顿银行正积极探索在行内私有化部署基于开源权重模型（如 Google Gemma、Meta Llama 系列）的中小型大模型（Small/Medium LLM），以确保敏感金融数据足不出户。 | 评估维度 | 采购（Buy / 外部平台） | 自研（Build / 行内自建） | |:--- |:--- |:--- | | **适用技术层级** | 基础编排平台、标准工作流引擎、SaaS 内置 AI 工具（如 Copilot Studio、Salesforce） | 数据权限控制、专属合规护栏（Guardrails）、专有业务逻辑连接层 | | **选型考量** | 外部创新迭代极快，单家银行无法独立维系庞大的基础模型研发 | 确保数据主权，隔离敏感客户金融资产与交易数据 | | **模型部署策略** | 仅用于脱敏或信赖厂商的 Trust Layer 隔离环境 | 私有化部署开源权重模型（如 Gemma、Llama 系列中小模型） | --- ### [16:26](https://www.youtube.com/watch?v=hwn30c0wbF0&t=986s) 安全边界与模型信任：攻防评估中的挫折与权限收紧 Naomi 引入了模型安全与信任的话题，指出近期 OpenAI 曾披露其前沿模型利用漏洞对 Hugging Face 实施了渗透攻击，这让金融行业对依赖外部大型模型的安全性产生了更深的顾虑。 谈及模型安全评估时，Stephen Frein 分享了开发中的真实痛点与趣事：他在行内开展内部安全测试与评估时经常使用 Claude，但 Claude 严格的安全拒答对齐机制经常直接阻断合规测试请求，坚决回复“我不会执行该操作”；哪怕测试人员尝试拆分提示词（Prompt），一旦模型识别出上下文意图，也会立刻中断回答。这一分享引发了现场经历过类似情况的观众的笑声。 针对安全风险，银行在实际落地中采取了极其严密的主动防御措施：对于在 Salesforce 等生产环境中部署的所有 Agentic 智能体，必须对其操作权限进行最大限度的权限收紧（Permissions Lockdown），严格限制数据访问与执行范围，绝不盲目赋予自治权限。 ### [18:08](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1088s) 智能体安全沙箱、可观测性与权限治理上下文层 在探讨银行内部智能体（Agent）的实际落地时，Stephen Frein 首先分享了 Fulton Bank 在控制模型权限和降低风险方面的工程实践。他指出，从网络通信和数据流的角度来看，银行通过严格的 API 密钥管控和最小权限原则（Principle of Least Privilege），将 AI 智能体牢牢限制在一个非常狭窄的操作沙箱中，严格限制其能够读取的数据和能够执行的操作。尽管由于这种严密的沙箱隔离，银行目前并未遭遇太大的实际安全风险，但 Stephen 坦言团队目前面临的一大短板是“可观测性”（Observability）与日志记录系统。他们迫切希望在未来能够更细致地追踪智能体的运行轨迹、具体的提示词历史（Prompts）以及在各个决策节点上采取的行动。 Murali Boddu 则从德意志银行（Deutsche Bank）的销售科技（Sales Technology）业务场景切入，剖析了企业内部与外部的双重安全边界。在内部安全方面，核心挑战在于跨领域隔离——例如某个业务领域的银行家绝不能随意调阅另一个领域的敏感数据。为此，德意志银行正在构建一套深度的“权限上下文感知层”（Entitlement Context-Aware Layer）。该机制不仅针对人类员工（根据员工身份、地理位置、管辖司法区及具体角色动态生成授权凭证），还同样适用于被接入系统的 AI 智能体。每个智能体都拥有明确的角色和运行司法管辖权，智能体之间的每一次通信与协作都必须基于该授权凭证进行鉴权。而在外部安全方面，银行采取了极度审慎的策略，严禁将任何个人身份信息（PII）或敏感数据发送给外部的前沿闭源模型（Frontier Models），并积极探索在数据流出之前对其进行全面脱敏与主服务协议（MSA）层面的合规约束。 ```mermaid flowchart TD accTitle: AI 权限上下文感知治理架构 accDescription: 展示银行内部人类用户与 AI 智能体如何通过权限上下文感知层实现安全鉴权与合规隔离。 subgraph UserAgentContext["主体与上下文属性"] UA["用户 / AI 智能体"] CTX["上下文维度<br/>(身份 / 地理位置 / 司法管辖区 / 角色)"] UA --> CTX end subgraph SecurityLayer["AI 安全与治理核心"] AUTH["权限上下文感知层<br/>(Entitlement Context-Aware Layer)"] MANDATE["动态授权凭证 (Mandate)"] CTX --> AUTH AUTH --> MANDATE end subgraph ExecutionPlane["执行与隔离边界"] direction TB INTERNAL["内部业务系统 / 智能体间通信<br/>(基于角色严格隔离)"] MASK["敏感数据脱敏引擎<br/>(PII Masking & MSA 限制)"] EXTERNAL["外部前沿大模型<br/>(Frontier Models)"] MANDATE --> INTERNAL MANDATE --> MASK MASK --> EXTERNAL end ``` ### [21:03](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1263s) 智能体交互差异化：权限层、可观测性与漏洞修复速度 随着各大金融机构逐步扩大 AI 采用规模并扩展技术栈，未来的技术分水岭究竟在哪里？Murali Boddu 尖锐地指出，目前所有银行面对的外部技术条件其实是同质化的——大家接入的是相同的前沿基础模型，市面上评估和部署的智能体框架也大同小异。未来两到三年内，企业技术栈真正的核心竞争壁垒在于**权限层（Entitlement Layer）的构建效率与智能体间安全通信机制**。谁能建立起更严密的权限体系，谁就能以更快的速度将值得信赖的智能体平台推向生产环境。 Stephen Frein 对此表示高度赞同，并再次强调了基础设施工具链在提升可观测性和跟踪审计方面的重要性。谈及业界关注的安全威胁（如早前针对 OpenAI 系统的入侵事件），Stephen 认为这些事件虽然听上去令人恐慌，但剖析其本质，黑客所利用的依然是那些老生常谈、本应早就被加固的基础漏洞。大语言模型并没有凭空发明全新的零日漏洞（Zero-day Vulnerabilities），只是以前所未有的极高效率将那些已知且长期存在的配置疏忽给串联了起来。“大多数我们在新闻里读到的实战攻击并非新型漏洞，纯粹是有人留了个敞开的漏洞后门，而 AI 恰好把它找到了。” Murali 顺着这一观点补充道，随着前沿 AI 模型挖掘已知和未知漏洞的速度越来越快，企业工程团队修复代码漏洞的响应速度将成为决定未来安全态势的关键胜负手。“补丁管理（Patch Management）已经一跃成为眼下最炙手可热的技术话题。”面对可能成倍增加的类似 Log4j 级别的突发安全事件，工程团队在生产环境中极速定位与打补丁的能力将直接决定系统的生死存亡。 ### [23:48](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1428s) 银行业 AI 的 ROI 难题与“智能成本”度量 主持人 Naomi Nix 抛出了行业普遍关心的现实难题：许多科技行业的批评者认为 AI 的实际价值被过度炒作了，在银行业内部改造流程中，究竟该如何衡量投资回报率（ROI）？成功的标准是什么？ Stephen Frein 直言，在任何组织中量化 ROI 都是最困难的事情之一，即便是与 AI 或智能体无关的项目亦是如此。企业经常遭遇“事前看似价值连城、事后发现收益平平”的项目。他告诫大家切勿盲目幻想：“如果你的企业在过去其他领域中原本就不擅长做精细的价值量化与 ROI 评估，就不要妄想在 AI 这一件事上能奇迹般地培养出这种新纪律。”在现实中，很多重大技术立项往往仅仅是因为某位掌握实权的高管认为其值得去做。但 Stephen 也指出了一些可感知的正向“味道”（Smells）——比如客户业务流程显著提速、原本需要多人的工作现在一人耗费一半时间即可完成。更为独特的是，随着 Token 消耗模式的普及，人类历史上第一次能够精确量化“智能的成本”（Cost of Intelligence），为 ROI 分析提供了全新的经济学杠杆。 Murali Boddu 同样坦言，想要在业务端将单笔交易或营收精确归因于 AI 的投入是极其困难的。然而，只要问自己几个核心问题：业务流程是否变快了？银行家们的工作效率是否提高了？是否因为提前拿到了高质量的客户背景分析资料而能在商务会议中表现得更专业、准备更充分？如果答案是肯定的，那么回报就已经发生。更重要的是，在竞争激烈的市场中，“如果你不及早采用 AI，就会被同业远远甩在身后”。 - **Token 治理与精细化监控**：企业必须对开发团队及业务部门建立严格的 Token 用量监控与配额管理。 - **智能化模型路由（Model Routing）**：利用类似 OpenRouter 这样的模型路由平台，根据任务复杂度精准分派模型。“如果只是排查一个简单的空指针异常（Null Pointer Exception），根本不需要杀鸡用牛刀去调用最顶级的前沿大模型。” - **业务端真实采纳率**：在难以精确拆解财务金额时，业务端实际活跃度与采纳率的持续增长是衡量 ROI 的关键替代指标。 ### [28:53](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1733s) 劳动力重塑：技能升级 vs. 机械式工作的淘汰危机 Naomi 提到了摩根大通（JPMorgan Chase）CEO 杰米·戴蒙（Jamie Dimon）此前的公开言论，即 AI 已经在其部分业务部门带来了 30% 到 40% 的人员精简，并询问两位嘉宾如何看待 AI 对银行业劳动力结构的实际重塑与未来走向。 Murali Boddu 结合德意志银行的第一线观察指出，工作性质的变化正在真实发生：原本负责手动、机械操作的基层员工，现在正在主动学习 AI、为自己原先负责的业务构建专属智能体，并在此过程中掌握全新的技能。开发周期从过去的数天甚至数月缩短到了几个小时，这不仅极大地释放了生产力，更驱动着新的产品构想与收入增长。Murali 调侃道，角色的重构速度快得惊人，甚至连顶尖 AI 机构 Anthropic 自身在招聘年薪 60 万美元的高级岗位时，都会在招聘启事底部附上一句黑色幽默式的声明——“我们也不确定这个岗位在一年后是否还会存在”。 ```mermaid flowchart LR accTitle: 知识工作的经济学悖论与两极分化 accDescription: 展示 AI 降低知识工作单位成本后引发的需求反弹以及不同类型员工的分化命运。 subgraph EconomicEffect["经济学效应 (非有限体量)"] COST["AI 降低知识工作<br/>单位生产成本"] DEMAND["市场对高质量输出的<br/>总体需求大幅激增"] COST --> DEMAND end subgraph WorkforceDivergence["劳动力分化路径"] direction TB UP["掌握 AI 工具的高阶员工<br/>(技能升级 / 驾驭复杂业务)"] DOWN["机械式照本宣科的员工<br/>(Paint-by-numbers / 极高淘汰风险)"] end DEMAND --> UP DEMAND -.-> DOWN ``` Stephen Frein 对 Murali 的观察表示赞赏，并从经济学原理的角度提出了深刻的反思。他指出，许多人常犯的错误是将知识工作误解为“搬石头”——石头堆的总量是固定的，搬完就没了。但无论是软件开发还是市场营销，知识工作并不是有限的“石头堆”。当 AI 极大降低了知识工作的单位成本时，根据基本经济学原理，市场对该产出的总体需求反而会成倍增长。然而，这种繁荣背后存在着残酷的分化： - 对于那些善于将 AI 转化为自身杠杆、承担更高价值工作的员工，其个人价值将获得前所未有的放大。 - 对于那些只会“按图索骥/照本宣科”（Paint-by-numbers）执行初级固定套路的从业人员，如果不能迅速实现自我迭代升级，在未来几年内极有可能会被大语言模型全面取代。 ### [33:11](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1991s) 展望未来：大模型客服悖论与端侧本地化大模型普及 当主持人展望未来 5 到 10 年银行业的技术变革时，两位嘉宾给出了既务实又极具前瞻性的不同视角。 Stephen Frein 率先直击当前行业的一大痛点：“我个人完全无法理解，为什么我们在 Claude 或 ChatGPT 等底座模型上看到了如此惊人的智慧，而市面上绝大多数声称由 AI 驱动的客服工具体验却糟糕得令人发指（Egregious）。”他直言，许多供应商大肆宣称自己“已经彻底解决了客户服务难题”，但实际测试其产品时，其表现完全是“垃圾级别”（Garbage）。攻克这一断层、打造出真正可靠且符合大模型预期能力的智能客服 Agent，将是未来彻底颠覆银行业及各行各业的关键里程碑。 Murali Boddu 则提出了一个更为乐观且具有颠覆性的技术演进路径： 1. **模型与基础设施成本雪崩**：在未来 5 年内，大模型的推理成本与 Token 费用预计将下降 10 倍以上，云端 AI 算力成本也将大幅回落。 2. **端侧顶尖大模型普及**：能力堪比当今顶尖前沿模型（如顶级闭源大模型）的强大 LLM 最终将直接落地并运行在员工个人的 PC 或小型终端硬件设备上。 3. **摆脱云端与零 Token 成本**：所有复杂的银行业务推理均可在本地机器无缝完成，彻底摆脱对昂贵云端基础设施与 API Token 的依赖，为银行带来极致的成本优化与运营效率跃升。 ### [35:25](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2125s) 观众问答：金融机构对开源权重模型及中国开源模型（如 Qwen）的考量 在最后的现场观众提问环节，一名参会者提到了 Hugging Face 等平台广泛采用中国开源权重模型的行业现状，并向嘉宾尖锐提问：鉴于某些美国开源模型在特定场景下的局限性，作为受到高度严格监管的金融机构，是否会（或在何种条件下会）在生产环境中采用源自中国的开源权重模型（如阿里开源的 Qwen）？监管机构又会持何种态度？ Stephen Frein 对这一问题的深刻性给予了高度评价，并坦率分享了 Fulton Bank 内部的权衡历程： - **能力认可但立场保守**：Fulton Bank 在初期评估开源模型时，重点放在了 Meta 的 Llama 和 Google 的 Gemma 系列。他们确实对 Qwen 等中国开源大模型进行了性能调研，并对其展现出的优异能力与卓越特性感到印象深刻。 - **现阶段明确排除**：由于银行本身属于极其保守的强合规金融机构，目前以及短期内完全没有将中国开源权重模型引入生产系统的计划。 - **核心顾虑与未来观察**：银行安全团队主要担忧模型是否存在潜在的未知数据回传通道（Phone Home）、隐蔽的数据编码风险或未预期的不可控行为。Stephen 表示，唯有在未来两三年内整个金融行业对这类模型的安全审计形成高度成熟的共识与接纳度后，银行才可能重新审视这一选项。但在现阶段，银行依然会严格恪守既定的安全边界。 ### [37:17](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2237s) 激活遗留系统：通过元数据与 API 中间层赋能 AI 智能体 在银行与金融机构中，遗留系统（Legacy Systems）往往是企业最大的优势资产，因为这些系统稳定运行多年，沉淀了 10 到 20 年极具商业价值的历史数据。然而，这类系统的致命短板在于：非人类实体的 AI 智能体（Agent）无法直接理解这些数据的业务语意。为了打破数据壁垒，技术团队需要构建一个中间层，为底层的所有数据赋予可解析的上下文含义。 Murali Boddu 指出，团队可以借助开源工具（例如 OpenMetadata）来定义和描述数据层。通过在中间 API 层清晰标注文档——例如明确指出某个系统记录的具体含义、某个字段 ID 代表“客户 ID（Client ID）”等——才能将古老复杂的底层数据库无缝转译为 AI 智能体能够读取并执行操作的标准化接口。尽管构建这层中间 API 算不上什么“光鲜亮丽（fancy）的工作”，但正是这种将遗留资产转译为结构化描述层的基础工程，构成了未来金融 AI 落地最关键的技术支柱。 ```mermaid flowchart TD accTitle: 遗留系统与 AI 智能体连接架构 accDescr: 展示遗留系统如何通过元数据中间层转译为 AI 智能体可用接口 subgraph Legacy["底层数据与记录系统"] L1["核心银行遗留系统 (10-20年历史数据)"] L2["系统记录 (System of Record)"] end subgraph SemanticLayer["语义与转译中间层"] M1["开源元数据工具 (如 OpenMetadata)"] M2["业务语义标注 (如 Client ID、账户状态)"] API["中间 API 接口层"] M1 --> API M2 --> API end subgraph AIWorkload["上层 AI 消费端"] Agent["AI 智能体 / LLM"] end Legacy --> SemanticLayer API --> AIWorkload ``` --- ### [38:42](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2322s) 自研与外购的抉择：规模经济、定制需求与集成成本 针对来自房利美（Fannie Mae）现场观众关于金融强监管环境下“自研还是外购（Buy vs. Build）”的提问，专家们展开了深入剖析。Stephen Frein 强调，自研的前提是必须有极其充分的理由，因为采购成熟商业产品能够直接享受供应商竞争带来的规模经济与快速迭代红利。但是，对于像富尔顿银行这样拥有上百年历史的老牌银行，内部沉淀了许多极其独特的业务流程与运作惯性（idiosyncrasies）。在评估外购方案时，企业必须权衡：究竟是强行改变自身百年的工作方式去适配现成工具，还是选择自主构建？当业务流程具有高度组织特异性且不可妥协时，自研就是最合理的路线。 Murali Boddu 进一步补充了全生命周期运维成本（Operational Cost）的考量。在评估自研系统时，架构师必须确保系统具备低维护甚至“零维护”特性，并保证在未来 5 年内具备可插拔（Pluggable）迁移到其他平台的能力。而在外购商业产品时，绝不能将其视作“黑盒”：必须彻底搞清数据流向、安全护栏（Guardrails）以及内部系统集成难度。Murali 分享道，在某些实际场景中，让供应商开发一项新功能的报价高得惊人，而银行内部工程师仅用四到五个月就能自行搭建完成。此外，开源生态的成熟也提供了第三条路径，例如社区中已有完全开源且功能完备的代码库，能够直接复刻主流大型 CRM 厂商的核心能力。 Stephen 紧接着强调了生态集成的隐性壁垒：“供应商之间通常会主动开发互相集成的接口并展开协作，但绝不会有人专门针对我们在机构内部自研的定制化系统去主动做集成。”这一点往往是决定自研还是外购的关键维度。 - **外购（Buy）优势**：享受厂商规模经济红利、现成产品功能完善、跨厂商标准生态集成便利。 - **自研（Build）适用场景**：适配银行独特且不可替代的历史业务流程；避免商业厂商高昂的功能定制与二次开发费用；开发周期可在数月内自控。 - **技术把控底线**：即使外购也不能盲目采纳“黑盒”，必须透视其数据处理逻辑与内置安全护栏。 --- ### [42:29](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2549s) “氛围编码”（Vibe Coding）的现实应用：从业务原型到工程生产线 面对现场关于“氛围编码（Vibe Coding，指借助大语言模型通过自然语言提示快速生成代码）”对银行业影响的提问，两位嘉宾客观拆解了其机遇与技术债务风险。Stephen Frein 直言，如果将 Vibe Coding 定义为“完全不懂底层技术原理的人仅靠 LLM 生成代码”，那么这在工程维护上无疑是一场“即将到来的噩梦（maintenance nightmare）”。但如果是由经验丰富的工程师作为主导，指导单个或多个 AI 智能体来加速产出，则是极具前景的模式。目前富尔顿银行的做法是让资深工程师借助 AI 强力辅助完成代码编写、审查与校验；至于完全自主互相审查演进的“智能体集群（Agent Swarms）”，他们预计会在 2027 年左右逐步展开深度探索。 Murali Boddu 则从实际业务赋能角度，指出了 Vibe Coding 当前在德意志银行等大型组织中最具价值的两大落地场景： 1. **产品与项目经理的敏捷原型验证**：业务构想极佳的产品经理可以在短短 1 到 2 天内快速做出可交互的产品 Demo 并向业务高管展示，从而为后续正式的工程立项快速争取到开发预算。 2. **终端用户自主开发应用（EUDA / UDA）的规范化沉淀**：没有深厚编程背景的业务人员可以利用 AI 构建解决自身痛点的自用工具，并统一登记到内部注册中心（Registry）。技术团队能够通过分析这些工具，筛选出具备高业务价值的雏形，进而将其重构成能够支撑大规模并发访问的企业级正式产品。 然而 Murali 明确强调，无论原型制作多么高效，现阶段绝不能将未经审查、由模型生成的“黑盒代码”直接部署到生产环境。Vibe Coding 的最大价值在于激发业务创新与加速从 0 到 1 的概念验证，而从 1 到 100 的生产级部署依然必须由专业工程团队严格把关。 --- ### [45:31](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2731s) 结语与致谢 论坛在热烈的掌声与欢呼声中圆满落幕。主持人向在欢聚酒会（Happy Hour）前夕依然全神贯注参与探讨的现场观众致以诚挚感谢，并祝愿所有参会者在后续的银行业 AI 探索旅程中取得丰硕成果。 ## Notable quotes > [08:16](https://www.youtube.com/watch?v=hwn30c0wbF0&t=496s) 我们的开发者现在生产交付物的速度，已经远远超过了整个组织吸收和消化它们的能力。 — Stephen Frein > [12:00](https://www.youtube.com/watch?v=hwn30c0wbF0&t=720s) Buy the platform, build the differentiator — Murali Boddu > [21:03](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1263s) 大多数我们在新闻里读到的实战攻击并非新型漏洞，纯粹是有人留了个敞开的漏洞后门，而 AI 恰好把它找到了。 — Stephen Frein > [21:03](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1263s) 补丁管理（Patch Management）已经一跃成为眼下最炙手可热的技术话题。 — Murali Boddu > [23:48](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1428s) 如果你的企业在过去其他领域中原本就不擅长做精细的价值量化与 ROI 评估，就不要妄想在 AI 这一件事上能奇迹般地培养出这种新纪律。 — Stephen Frein > [23:48](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1428s) 如果只是排查一个简单的空指针异常（Null Pointer Exception），根本不需要杀鸡用牛刀去调用最顶级的前沿大模型。 — Murali Boddu > [28:53](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1733s) 我们也不确定这个岗位在一年后是否还会存在 — Murali Boddu > [33:11](https://www.youtube.com/watch?v=hwn30c0wbF0&t=1991s) 我个人完全无法理解，为什么我们在 Claude 或 ChatGPT 等底座模型上看到了如此惊人的智慧，而市面上绝大多数声称由 AI 驱动的客服工具体验却糟糕得令人发指（Egregious）。 — Stephen Frein > [38:42](https://www.youtube.com/watch?v=hwn30c0wbF0&t=2322s) 供应商之间通常会主动开发互相集成的接口并展开协作，但绝不会有人专门针对我们在机构内部自研的定制化系统去主动做集成。 — Stephen Frein ## Mentioned Naomi Nix, Stephen Frein, Murali Boddu, Bhairav Mehta, Fulton Bank, Deutsche Bank, JPMorgan Chase, Bloomberg News, The Washington Post, Fannie Mae, Anthropic, OpenAI, Salesforce, Salesforce Trust Layer, Boomi, MuleSoft, SharePoint, GitHub Copilot, Microsoft Copilot Studio, Microsoft Teams, Outlook, Slack, Claude, ChatGPT, Meta Llama, Google Gemma, Qwen, OpenMetadata, OpenRouter, Hugging Face, Stack Overflow, Jamie Dimon ## Video description Stephen Frein - SVP of Software Development, Fulton Bank Bhairav Mehta - Head of AI & ML, JPMorganChase Naomi Nix - Tech Reporter, Freelance Murali Boddu - VP, Deutsche Bank Scaling artificial intelligence in financial services requires a highly specialized, secure, and compliant infrastructure. This panel dives into the foundational architecture necessary to power enterprise AI across the banking ecosystem. Learn how leading institutions are assembling their data pipelines, vector databases, large language models, and AI orchestration platforms. Panelists will discuss the buy versus build dilemma, cloud infrastructure strategies, and how to modernize legacy systems to support advanced AI workloads. Walk away with tactical insights on selecting the right tools, managing compute resources, and building a scalable tech stack that moves AI from proof of concept into robust production. [Source](https://www.youtube.com/watch?v=hwn30c0wbF0)

[8:16] Stephen Frein: 我们的开发者现在生产交付物的速度，已经远远超过了整个组织吸收和消化它们的能力。 [12:00] Murali Boddu: Buy the platform, build the differentiator [21:03] Stephen Frein: 大多数我们在新闻里读到的实战攻击并非新型漏洞，纯粹是有人留了个敞开的漏洞后门，而 AI 恰好把它找到了。 [21:03] Murali Boddu: 补丁管理（Patch Management）已经一跃成为眼下最炙手可热的技术话题。 [23:48] Stephen Frein: 如果你的企业在过去其他领域中原本就不擅长做精细的价值量化与 ROI 评估，就不要妄想在 AI 这一件事上能奇迹般地培养出这种新纪律。 [23:48] Murali Boddu: 如果只是排查一个简单的空指针异常（Null Pointer Exception），根本不需要杀鸡用牛刀去调用最顶级的前沿大模型。 [28:53] Murali Boddu: 我们也不确定这个岗位在一年后是否还会存在 [33:11] Stephen Frein: 我个人完全无法理解，为什么我们在 Claude 或 ChatGPT 等底座模型上看到了如此惊人的智慧，而市面上绝大多数声称由 AI 驱动的客服工具体验却糟糕得令人发指（Egregious）。 [38:42] Stephen Frein: 供应商之间通常会主动开发互相集成的接口并展开协作，但绝不会有人专门针对我们在机构内部自研的定制化系统去主动做集成。

[8:04] Stephen Frein: When we found that we produced code faster... it really just exposed other bottlenecks in our pipeline that had probably been there all along... Our developers could now produce things faster than the broader organization could absorb it. [16:26] Stephen Frein: When I'm trying to do internal security assessments, Claude is generally my go-to... Claude is constantly shutting me down, saying 'I won't do that. No, no.' And then you try to trick it by breaking it up piecemeal, and it figures out what you're trying to do and says, 'I'm not going to answer any more questions like this.' [23:48] Stephen Frein: We've never been able, I don't think, to quantify the cost of intelligence before, and through token spend we now have like a new insight into that. [32:43] Stephen Frein: There is an amazing amount of hype around certain vendors saying, 'Oh, we've solved customer service.' And you can use their product and it is garbage... cracking that having a customer service agent that actually works well... will be a big deal.

[0:04] My name is Naomi Nicks. As was mentioned, I've  been a technology journalist for nearly a decade. [0:09] First for Bloomberg News and then later as  a staff writer for the Washington Post. Um, [0:14] and I'm really excited to be digging into this  issue. I think as a journalist who's kind of [0:19] on the outside of the banking industry, one of  the things that's really interesting to me about [0:23] this topic is we have this centuries old industry  banking now sort of on this facing this question [0:30] of how do we adopt cutting edge technology and  at the same time uphold the rigorous standards [0:36] that are critical to protecting our economy. And  so we have I'm delighted that we have two guests [0:42] uh from from this industry to to kind of dig into  some of those issues. I'm going to ask that Morawi [0:48] and and Stephen that you introduce yourselves,  talk a little bit about what you do and your banks [0:52] to help us frame this conversation and at the  end we're going to try to reserve some time for [0:59] uh questions and answers. So Stephen, I'll start  with you. Thanks. Thanks N. We appreciate it. Hi [1:05] folks, my name is Steve Frame. I run software  development for Falton Bank. Fton Bank is a [1:10] midsize regional bank, a mid-Atlantic  bank headquartered out of Lancaster, [1:14] Pennsylvania. Uh my software development team is  about 75 persons, spans full stack development, [1:19] Salesforce development, um integrations using  a platform called Boommy, which is similar [1:23] to Mulesoft for those who may have used it, um  SharePoint, uh RPA and a host of other things. [1:29] So we're taking some interesting steps with AI.  We'd love to discuss with you today. Moral. Hi [1:36] everyone. My name is Morali. Uh I'm with banking.  I've working in the banking for the past 20 years. [1:42] uh so I worked in different domains like the fixed  income capital markets right now I'm working in [1:48] sales technology which is the CRM world with all  the competitive vendors in the market um I joined [1:55] this about in the in this field about 20 years ago  as I said just driving into your question I mean [2:01] uh I started with mainframe cobalt as a developer  and you know 20 21 years down the line now [2:08] uh I'm actually wearing multiple hats being  a developer and also being a a lead engineer, [2:14] regional lead for the sales technology for  Dutch bank. Um I see a big shift obviously [2:21] right like where we were at mainframe cobalt now  we're doing AI and no code or you know the less [2:28] code world now I think the to answer your question  the the the we should ask ourselves that we should [2:35] not be thinking about modernizing our legacy  platforms the legacy platforms are doing what [2:41] they're doing right actually the being the single  source of truth being auditable being trustworthy [2:47] there the application which have been there in the  bank or in the organizations for multiple decades. [2:53] Now it has earned the trust of all the business  users right so what we should be thinking more is [2:59] and which is which is what I'm doing in my  organization is we're building that middle [3:04] layer which would describe your legacy platforms  very well to your agents or your AI applications [3:12] and how effectively you build that middle layer  is more important in this in this current world [3:18] I would say where you could take the best out of  both the legacy and also So your your you know [3:24] AI innovation, right? That's great. And I want to  build off of that a little bit which is maybe you [3:29] could just talk to us a little bit more about like  where where are you right now when it comes to AI [3:35] adoption in your tech stock where you know what  have you trusted some of these services to do? [3:40] Where have you where are you sort of taking a wait  and see approach? Um so maybe you can elaborate on [3:46] some of the most uh topline projects right now.  Sure. Sure. So Stephen, yeah, I I'll say for us, [3:54] we're fairly conservative about a number of  things. So for us, AI is largely internal [3:59] and assistive right now. Like we're not exposing  except in some very limited cases, AI directly to [4:05] our end customers. It's more internal customers  inside the bank of the technology organization. [4:10] We're using it to, you know, make certain tasks  faster or tasks more efficient. So some of the [4:15] things we focus on a lot are ragt type use cases,  people searching documentation, summaries. Um [4:21] we we certainly use it a lot for things like  code generation inside my team. But any case [4:27] in which we're building or having AI assist us  in building some sort of technical deployable, [4:32] there's always a human in the loop. are always  basically having an individual say I am the tool [4:37] owner or the user of this AI and I own the  code that it produces and any other similar [4:42] deployables and configuration in the same way  that I might have owned something that I took [4:46] off of Stack Overflow a number of years years ago.  So for us um generally assistive internally facing [4:53] and and really a human in the loop situation  for any time it would be sort of generating [4:57] new things or potentially modifying data in one  way or another. Okay. Absolutely with in line [5:02] with what you're doing actually Stephen the two  angles to it in my in my world one which is on [5:09] the development side where you're your developers  are doing u leveraging all the frontier models to [5:16] uh you know develop fast proof of concepts you  know generate more code and deploy these solutions [5:22] into into production. There's a huge um incredible  amount of lines of code that is being produced [5:29] and deployed in production. Uh where we are also  very cautious about you know what we are deploying [5:35] there. are are we introducing any vulnerabilities  that are you know uh exposed outside? So there's [5:41] so much that we are doing on leveraging these  you know the GitHub code pilot you know automatic [5:47] code reviews and see what vulnerabilities are  there are that that's on the on the tech side [5:52] right so there's AI for tech pillar for us and  then AI for business pillar in AI for business [5:58] as you know Stephen was mentioning uh anything  which we are deploying to production should be [6:03] orchestrated back to the business saying how did  AI come to this conclusion uh which is where the [6:10] going back giving the links to the source of truth  why we this this conclusion has been made by the [6:16] AI and that's where we are focusing more actually  instead of being more aggressive on delivering and [6:21] doing a decision making we our focus is more  on how do we orchestrate and build the trust [6:26] with business first on using this you know the  innovation AI is giving all of us so those are [6:34] the two different fronts that I would say we are  working on the especially on the sales tech. The [6:42] one or two exciting platforms that we are building  for the next year is the client intelligence which [6:46] is where there are some in-house build tools  that we are exploring to how we could do the [6:53] market research on which is a financial market  research on all these different companies that [6:59] you know that are there in in healthcare in you  know oil and gas and all these different domains [7:04] right so and do the market research and give this  material to the bankers where they are very well [7:10] prepared prepared for their client meetings.  Like you could say the pitchbooks which is a [7:14] very manual process like back then where you  used to spend days and months to come up with [7:18] a pitchbook. Now there's there's all these new  technology you could leverage and come up with a [7:23] a pitchbook in like 1 hour but you know so that  is some exciting areas that we're working on [7:30] um and how we could use the internal data as well  actually right so the the the pitchbook it's not [7:35] only about the market research there is a tens and  20 years of you know data that is there within the [7:42] organizations that how you could develop AI  solutions to to summarize all this data and [7:48] bring that context text into their latest market  financial research and then combine these two and [7:53] give uh give it to the bankers. That's where there  is some innovation happening for the next couple [7:58] of years for us. Stephen, I want to bring you in  here. Can you talk a little bit about are there [8:04] specific moments that you've had over the last  year or two where you saw sort of AI adoption [8:09] seemingly particularly useful um either sort of  in the tech oriented stack or the business? Sure. [8:16] Sure. We we certainly have um a handful of use  cases like it has been very useful to our call [8:20] center agents in speeding up the handle time of  calls, summarizing things for them etc. Um on the [8:27] technology side for our full stack development  team we we track basically just to see how our [8:32] progress is with learning this new tool chain how  often we use AI to support different user stories, [8:38] different software requirements we work through.  We're up to the point where about 85% of the user [8:43] stories we develop in our full stack team are  AI assisted in some way. And like one of the [8:47] learnings we've seen is initially the lower point  or smaller user stories. Think of a onepoint story [8:53] if if you folks are using story points in your  organizations the developers would not generally [8:57] feel like it was worthwhile to go to Claude  or another coding assistant to work on those. [9:01] But we've actually seen uptick in using AI for  those as well which I take as some evidence of [9:07] our folks basically getting more comfortable  with the tooling. So, we've certainly seen [9:11] um code production speed sped up. Um like I said,  agent or call center agent handle time sped up. [9:18] One of the things we found, Naomi, that I thought  was kind of interesting and I I'd love to know if [9:22] Morali has seen similar things when we found that  we produced code faster. That was definitely true, [9:29] very measurable. We found that it really just  exposed other bottlenecks in our pipeline that had [9:36] probably been there all along but we really didn't  see as clearly before. So when we would generate [9:42] more code, you know, rip through more software  requirements, etc. in the course of an iteration, [9:46] we found that the bottleneck after that, let's  say user acceptance and deployment on that side [9:51] of the software value chain, if you will, became  really exposed as a choke point for us. like our [9:56] developers could now produce things faster  than the broader organization could absorb [10:00] it. That's of course the kind of thing we can  change and adjust over times. But it was one [10:04] of the learnings that we had sort of read about  like you can expect to see this happen and we [10:08] saw it happen very dramatically for ourselves that  just um making the code production piece go faster [10:15] didn't necessarily mean that software value was  delivered more quickly. In fact, in some cases, [10:19] the overall cycle time slowed down because of the  bottleneck that was created on the user acceptance [10:25] and deployment side. So on the same side, right?  So I would say operational efficiency is a biggest [10:32] uh biggest thing for us in sales technology. So  just an example um in before when we deployed our [10:39] AI solution the the way people or the bankers used  to log their call reports or conversations is by [10:44] going into a CRM platform open a browser you know  you know type in their uh their notes actually [10:51] what they discuss with the client but now there  is agentic workflow this is what we implemented [10:55] last year and we have seen incredible number of  uh call records that are being captured because [11:01] before there were some instances where bankers  were not logging the call reports because it [11:05] is completely manual. Now because of the agentic  workflows we they don't need to do anything like [11:11] the agent goes into their outlook they goes into  the Microsoft team or the slack channel and then [11:16] it you know gets those conversations and says okay  this is the conversation you had with this client [11:21] this was your context and uh next time when they  have another client meeting with the same client [11:26] or with a with a different customer at the same  client organization it brings back that context [11:32] what you discussed like two months before or in  the past two months and this is your summary and [11:36] this probably your best pitch to get a business  from this client. So that operational efficiency [11:40] has has shown us a great results u in in our  organization. Um I'm wondering you know obviously [11:48] you have sort of expertise within your companies  to to build technology software and services and [11:54] then we have all these sort of companies outside  that are offering them. um what how are you sort [12:00] of thinking through that question of do we build  it do we buy it we wait and see what what are the [12:08] sort of underlying principles that you're thinking  about as you go through that distinction I'd say [12:14] yeah it's a very interesting question but I think  everyone in this room would agree the amount of [12:20] innovation that is happening with all these vendor  platforms any organization would not compete with [12:26] that kind of innovation at scale that is happening  with all these you know the new startups and you [12:32] know how people are so much motivated about this  this technology itself right so my take on this [12:38] would be it's it's my personal take actually  but it would be more like buy the platform and [12:45] the organizations should build a differentiating  factor uh just like for example the the guardrails [12:53] uh or the propriatory ship you have on the  data you own is something you would build in [12:58] your organization. But you would you would buy  the platform or the orchestrating layer or the [13:03] workflow layer or the base agent agentic layer is  something you I would buy. But the differentiating [13:09] factor on how I connect these um and then  transform my mandate rules or the the entitlement [13:16] context aware layer is is going to be something  we build inhouse actually right and I think that's [13:23] a fair representation of how we'd approach it as  well. We are heavily dependent on vendor platforms [13:28] for the core capabilities, the base capabilities.  When we deploy, let's say a rag style chatbot, [13:33] we're doing it on a Microsoft's co-pilot studio  platform. We have plenty of vendor embedded AI, [13:38] etc. And the tools that we pull together.  The one situation, Naomi, that we feel like [13:42] we want to go a different direction. I'll say  build a bit more in-house is our bank is very, [13:47] very conservative with customer data and exposing  it to any of the frontier models, LLMs that sort [13:53] of outside of our borders. And we have some fairly  strong rules about that. We do it in the case of [13:57] Salesforce because we've come to trust the the  trust layer that Salesforce puts on top of um some [14:04] of the CRM data that we keep in that platform. But  for a lot of things, we're very loath to expose [14:10] any kind of sensitive customer data, especially  financial information to a large language model. [14:14] So we're looking to build our own sort of internal  in-house small LLM using an openw weight model. [14:20] We're looking at the Gemma and Llama series  right now and sort of experimenting with that. [14:23] But for exposing customer data to a large language  model or know mediumsiz language model in the case [14:30] of the models that we're looking at that's the  kind of thing that we're interested in keeping [14:33] in house. I think u just to add on the same  question I I was having interesting conversation [14:38] uh with another panel before this one about the  buyin bill. There are a lot of other factors that [14:44] would impact this decision. I think my view is  if I mean with this technology innovation that's [14:52] happening if the organization is not ready to  change their strategy let's say if today's it's [15:00] a build strategy for you 6 months down the line  one year down the line the way how fast things [15:05] are changing if your architecture is not adaptable  to a situation where you want you might want to [15:12] buy a vendor product and then you might have to  rebuild all the services that you have actually [15:17] built before. So I think the architecture should  be so flexible that even if in case down the line [15:23] one year if your strategy changes you should be  more adaptable to to plug in a vendor actually [15:30] down the line right because that's that's how fast  things are changing that would be one of my advice [15:35] I would give being an engineering you know leader  uh and then that's how we are also building some [15:41] services we offboarded one of the vendor last  year because they're not giving that capability [15:46] what we wanted but we are also build a service in  such a way that even if in case down the line we [15:52] want to bring back another vendor these services  are actually pluggable and then usable actually [15:57] right so and then the the vendor market is  becoming so and so competitive I also see [16:05] uh in future you don't have to buy the entire  product like a big blank product they might sell [16:13] you as an agent which is specific to your ask So  but in that world your system should be capable of [16:21] only consuming that agent. So that that's what I  would say you should be adaptable to both. Right. [16:26] So building off of this because you're you're  get we're getting into security now and I think [16:31] that's [laughter] for for this particular industry  um you know so critical. I mean last month alone [16:38] open AI indicated that its models had hacked  hugging face right opening up a whirlwind of [16:45] I think security questions about AI. Um there's  many implications of that, but I think one sort [16:51] of overarching one is like can you trust these  big companies and these big models and how are [16:57] you thinking about that tension of these are the  companies that have some of the most cutting edge [17:03] models and technologies and services and at the  same time um you know there are some real security [17:10] implications with relying on them for something  as sensitive as as bank data. How are you thinking [17:18] about that tension? Well, I'll start off, Naomi,  by saying I have a little frustration that other [17:22] members of of the room here might share. When  I'm trying to do internal security assessments, [17:28] I Claude is generally my go-to. When I [laughter]  I can already see people laughing who have lived [17:34] through this as well. When I try to do internally  security assessments, Claude is constantly [17:38] shutting me down. Say, I won't do that. No, no.  And then you try to trick it by breaking it up [17:42] peace meal and it figures out what you're trying  to do and it says, "I'm not going to answer any [17:46] more questions like this. etc. So, it's it's an  interesting disparity between when you want it [17:51] to do something for you along those lines and what  it might do under under other circumstances. But, [17:56] you know, we we care a lot about making sure that  any sort of um agentic thing that we might deploy [18:03] such as in Salesforce and other places, we've  locked down the permissions quite a bit. You know, [18:08] it it really just can't from a network  perspective, um from a data perspective, [18:12] because of API keys, etc. because of principle  of lease permission we've tried to apply. We [18:16] try to keep it fairly constrained into what it  can see and do. And then I think something that [18:22] we're growing with, we're not where we want to  be yet, is is observability of what it's doing, [18:28] what it's done, and appropriate logging around  those things. Like I think we have room for growth [18:33] in making sure that um we have all the traces we  might want to have over how agentic things operate [18:40] because of the way we sandbox them. We don't see a  lot of risk right now, but still we'd like better [18:44] in insight into how they've been prompted and  what actions they've taken at specific points and [18:48] we're working on some things along those lines.  Yeah, I think it's a it's a bigger question that [18:55] I personally can't answer for the organization  actually, but I'll just focus on my area of sales [19:01] technology, right? So the there are two aspects  to it. One is the internal barriers like whether [19:10] uh a person or a banker in one specific domain  can see a data uh of a banker who is in a [19:17] different domain. Actually uh that itself also is  an internal security matter that we are currently [19:23] working very closely with different frameworks on  how the AI governance layer should evolve within [19:28] the organization which is more like the internal  systems. Uh that is where we are building the [19:33] entitlement context aware layer like it depends  on who you are, which location you're sitting, [19:39] what jurisdiction you belong to and what role  uh you do in the organization and based on all [19:45] these different factors you you you will have a  mandate for yourself actually and that mandate [19:50] is actually used between applications within the  organization and also it is used between agents [19:56] to agent. So an agent which is onboarded will also  have a role. it will also have a jurisdiction like [20:04] where is it sitting where is it running so all  this is internal security right when it comes [20:08] to the external I think ours uh I think we are as  Stephen has already mentioned so we are also in [20:15] the same path we're taking very cautious step of  not sharing any PI and sensitive data to any of [20:22] these frontier models um and we are also exploring  different MSA options on how we should you know [20:31] mask these data before even that goes into all  these frontier models right so that is my take [20:36] but there is a bigger uh you know strategy for the  organization which I can I can't comment at this [20:42] point are there any areas of you think this sort  of security issue um that you know as you continue [20:50] to sort of increase your adoption of some of these  services or expand your tech stack and sort of [20:55] further further implement AI into your into your  processes that you see upcoming that might be [21:03] critical for the industry to to get a hold of. I  think the this is continuation uh um from the same [21:10] topic actually right so the every bank or every  organization have access to the same frontier [21:15] models they have the same agent take platforms  that they are you know available in the market [21:22] that you know they're evaluating deploying I think  the differentiating factor in the future stack [21:27] uh for me is the is that entitlement layer how  effective your entitlement layer would be and [21:36] how your agents would communicate with each other  in a secure way is going to be the differentiating [21:41] factor for the next you know couple of years and  that's that will derive how fast you're going [21:46] to deploy a trustable agentic platform into  production right so yeah yeah I think that's [21:55] a great point and I would probably be I guess  redundant with what I had said earlier there [21:59] but we're we're generally I I think that the tool  tooling harnesses etc. could do a bit to increase [22:10] observability and and logging and make that I'll  say much more readily observable to the people [22:16] who are hosting or or running these agents and  then beyond that you know some general security [22:21] principles that we would apply whether it was a  gentic or not go a long way like you know we even [22:26] talk about the open AI hack certainly that was a  scary episode but at the same time like what got [22:33] exploited was really the same things that people  should have been working on securing all along. [22:39] It's just the LLMs are sort of exposing some  of those practice weaknesses much more rapidly, [22:44] I guess, than than humans would. But, you know,  in many of these cases that we're reading about, [22:49] it's not that some new zero day has come up.  It is that they have chained together things [22:53] that were very knowable and have been knowable  for a while. There are other cases, of course, [22:57] in which things like Fable have encountered or  discovered new zero day type vulnerabilities, but [23:02] many of the operational hacks that we read about  are not of that character. They're just somebody [23:06] left a hole open and it found it. Yeah. I think  the other angle to it is um how fast engineers are [23:13] actually fixing their uh vulnerabilities in their  code is also going to be a factor for the next 6 [23:19] months to one year because of the new frontier  models. How fast they're discovering day zero [23:25] uh you know vulnerabilities. It is up to our  engineers now actually. So how fast we can [23:30] actually go and fix them in our production. So I  think that is also another differentiation factor [23:34] for the next couple of you know months. Now  another log 4j similar incident probably times [23:41] maybe. Yeah. Patch management has become like the  most exciting topic out there. [laughter] Yeah. [23:48] Um, I think cynics might say, certainly in my  industry, that some of the sort of the promise [23:55] that the tech industry has been talking about AI  is a little overhyped, right? Um, in terms of its [24:01] usefulness. I'm curious from your perspective, how  are you thinking about is implementing this and in [24:07] and sort of changing um our internal processes um  worth it? like in terms of getting the right ROI. [24:16] How are you thinking about that question about  whether it's worth it? When is it worth it? What [24:21] does success look like? I think ROI is one of the  hardest things for any organization to do. Take [24:31] take agentic or AI considerations out of it. It's  a tough thing to look at a project that isn't done [24:38] yet and say like is this going to be valuable for  us? And I'm sure we've all sort of lived through [24:42] scenarios where something that looked like it was  going to be valuable turned out not out to not be [24:47] as valuable as we initially expected. So I guess  one of the things I think about Naomi is certainly [24:52] we want to be mindful of ROI considerations when  we do agentic work or anything else. But I don't [24:59] know that the I think some organizations think  they need to bring a new discipline that they've [25:05] never been able to muster for any other topic  before. and and so I would just say let's be [25:11] careful about that like the if your organization  is generally not super strong on ROI and valuation [25:17] measurement etc you're probably not going to  be magically become so just for this issue [25:21] because there are hundred other things that might  have demanded similar attention I think in most [25:26] organizations or in many organizations it does a  powerful person think something is worth doing and [25:31] that's probably why they go out and do it that's  probably the reality of of many organizations and [25:36] we can aspire to better and organiz organizations  often hit better than that, but sometimes [25:40] decisions are made just that way. So, you know,  I think that if we look at things like a process [25:46] is faster now for the customer, there's probably  some value in there, like there's a smell there [25:50] that you're going in the right direction. If you  need fewer people to do something or you know, [25:55] someone can do it in half the time that they did  before, they have to expend fewer resources on it. [25:59] I feel like those are smells along the way to ROI.  Um it's interesting in this particular subject [26:05] like we've we've never been able I don't think  to quantify the cost of intelligence before and [26:12] through token spend we now have like a new insight  into that that didn't exist when it was all humans [26:17] bringing the intelligence. So I think we have sort  of through token economics and token consumption [26:22] we have a new lever to look at in an ROI analysis.  But I I think it is so difficult to do that I'm [26:29] sure Morali has figured it all out and I'll just  shut up so he can tell us exactly what happened. [26:33] What's the answer? [laughter] Have the same take.  Right. So ROI is very tough to attribute whether [26:39] it is because of an AI implementation or is it  because our process has become more efficient now. [26:48] I think yeah I mean there's no argument on that  like you know how could you attribute uh whether [26:53] it is because of an AI but I could definitely  say if you ask yourself a question is my process [27:00] faster now is my bankers more efficient are they  more prepared for a client meeting because of [27:06] the material I'm giving them ahead of those  meetings uh if if answers to these questions [27:11] is yes definitely there is there is written but at  the same time you can't assign a dollar amount to [27:17] how much of uh of these conversations are leading  to a a deal with the client, right? But again, you [27:25] you you think the other side actually let's say  if you don't adopt as fast as other organizations [27:31] using AI, you you would be left alone and that's  how we everyone is trying to implement AI and then [27:39] be at the pace with the market. Now the tools and  the models everything is common for everybody. [27:46] Actually it is up to us on how effective your  operational efficiency has gone up by using these [27:53] tools how you're governing your token tokens uh in  the organizations by the developers or also by the [28:00] business. Um are you monitoring your token usage  limits? Are you really using your frontier models [28:07] for the right tasks? you know the there are you  know these new platforms called open router which [28:13] is suggesting you could route your models for  a you know for something where there is a null [28:18] pointer exception you don't need a fable five  for that right [snorts] so it so I think those [28:24] are all the good things that as an organization  you should do on how effectively you manage your [28:29] models and uh how disciplined you are in in uh  monitoring your token usage both on the tech and [28:35] on the business side right and and definitely  there is ROI I there is but you can't attribute [28:40] to a dollar amount whether it is because of an  AI or not right so as long as your adoption by [28:46] the business is growing up you could monitor that  obviously uh so yeah yeah uh our representative [28:53] from JP Morgan didn't join us today but Jamie  Diamond has said that AI has led to you know 30 to [29:01] 40% of cuts among their workforce in certain units  and certainly sort of touted the promise of AI [29:08] being able to streamline mind the workforce. You  guys are obviously at different banks in different [29:12] scenarios and different points of view. I'm  curious a what have you seen in terms of workforce [29:17] changes if any so far um you know that AI has led  to and and where could we go forward with that? [29:28] I think first I think in our area right I could be  honest and say uh the the kind of work we do have [29:38] has changed right so the person who is doing some  manual work is now learning AI building agents [29:44] uh for the same work which they are doing and now  they're trying to learn some new skills actually [29:50] right so that is definitely I'm seeing firsthand  the it is reshaping what we were originally [29:58] doing before on the bigger picture whether it  would mean there would be job cuts I'm sure I [30:06] mean the most of the people who are sitting here  are vendors and you're building solutions for [30:11] that only right you're making you're making  new new ideas where you're you're trying to [30:16] build something which was taking like days and  months before you're able to do it in hours [30:22] um I would see this as an exciting time where  we upskill we learn new things we we get new [30:29] product ideas we implement and there is a big  uh push on how this could drive revenue for [30:36] all the organizations there's opportunity is  what I feel I mean obviously there would be a [30:41] reshaping or re-envisioning how the current role  would look like one year down the line anthropic [30:48] itself is advertising that a role which is paying  600k in the bottom it says that we're not sure [30:56] this role exists Sophania. So that's the open  fact, right? So I love that analysis. I think [31:06] we we might all look at how powerful some of  the frontier models are becoming and wonder, [31:11] wow, can that do what I do in in the near future?  I think one of the things that we want to bear in [31:18] mind is that much of the work we do is not like  shoveling a big pile of rocks. If there were [31:25] a big pile of rocks here and we said we have to  move the big pile of rocks over there, that big [31:29] pile of rocks is finite quantized. We know how  much of it there is. But with much of our work [31:35] whether it is software development or marketing  or whatever it is if we effectively reduce the [31:41] unit cost of that work and of course we can't  precisely measure the unit cost of most knowledge [31:46] work but if we let's say at least metaphorically  speaking reduce the unit cost of that work basic [31:51] economic tells us that demand for that thing  which has been made cheaper generally goes up [31:57] etc. So I think, you know, I I like Morali's  vision of um sort of an empowered group, you know, [32:05] people who are taking on new skills and becoming  more valuable by wielding AI as a tool. But that [32:11] also points to another side of the dynamic.  If anyone is doing a sort of paint by numbers [32:16] version of their role where they're implementing  fairly cookbook type things, that person needs [32:23] to level up their game or else something is going  to happen in the next several years around their [32:28] position. That person is going to need to learn  to do a higher level, more valuable version of [32:33] their work because the paint by numbers aspect  of it is certainly something or most likely [32:39] something that a large language model is going  to be able to take over in the years to come. [32:43] Okay, it's very optimistic tone there to that grim  [laughter] grim question. Um I'm wondering just [32:50] as we look towards the future um what are some of  the most you know 5 years 10 years from now and I [32:57] know you don't have a crystal ball but what are  some of the the uses of AI you think that could [33:03] potentially transform modern banking? Maybe we're  not there yet but it could has the potential to. [33:11] I'd love to start with one. I personally don't  understand the disconnect between the power I see [33:18] in a platform like Claude or Tetypt or what have  you and the egregious experience in most AI based [33:26] customer service tools like you would think that  would be something that we had nailed by now as [33:32] an industry. And there's an amazing amount of hype  around I I won't name companies here because some [33:37] of them are our partners, but there's an amazing  amount of hype around certain vendors saying, "Oh, [33:43] we've solved customer service." And you can use  their product and it is garbage, right? Like it is [33:49] terrible. Um why? Like I think Naomi the cracking  that having a customer service agent that actually [33:57] works well and if you folks know of one, please  point me towards it because I'm looking for a [34:01] good example of one. But most of the ones I've  seen are terrible relative to the promise that [34:07] you would think Claude Chachi PT whatever it is  brings to the table. So I feel like whenever that [34:12] day comes if it comes that'll be a big deal for  the industry and and every industry. Stephen, [34:17] I think I would have a a contrary view actually.  [laughter] I think in the next five years, I this [34:23] is my personal take again, right? I feel the the  model and the token cost would go ex like maybe [34:32] 10 times cheaper. Uh I think the more we evolve  the the model is going to become more cheaper and [34:38] cheaper and even the cloud infrastructure the AI  infrastructure cost would come down. I feel I am [34:44] being more optimistic that a model or an LLM which  is as powerful as Fibli would eventually land and [34:51] sitting on your local personal computer um where  you could do everything on your machine without [34:58] even using any cloud infrastructure or any token  cost right this is my view actually but I I see [35:04] that happening there are devices that are coming  where the LLM the model sits on a simple smaller [35:09] device and you could ask everything you could  what you're doing now to clot that that model [35:14] which is going to be the cheapest way and it will  become more efficient uh for all the banking or [35:19] any organization right not only banking yeah  okay we have a few minutes left I'm wondering [35:25] if if anyone in the audience has any questions  um okay thank you for the phenomenal discussion [35:32] to the commentary about the hugging face and  open AI incident heard you Stephen mention that [35:38] you guys were uh going to use some open uh open  weight models but I was curious. Hugging phase [35:44] famously now use the Chinese open weights model  because as you mentioned uh the frontier model [35:49] they use that was made in America wasn't playing  so nicely uh as as financial institutions do you [35:55] or would you use a Chinese open weights model and  if so any any thoughts on how the regulators feel [36:02] about that? Superb question. We have wrestled  with this. I I believe I mentioned earlier that [36:08] we're focusing on Gemma and Llama initially. A  model like Quen is very attractive. You know, [36:16] Quen just being one of the the Chinese models  and there there are many um Chinese models [36:20] that have I say desirable characteristics.  It would be quite a while before our bank, [36:26] which I may have mentioned is fairly conservative.  It would be quite a while before we would we would [36:30] try that. Um, and I I don't doubt that security  researchers are looking at these things, you know, [36:35] and and assessing the potential that they might  phone home, so to speak, or otherwise encode the [36:39] data and do something unexpected with it. But it  is not in our near future to to do anything with [36:46] one of those models. Maybe if the industry becomes  more comfortable with them in the next two years [36:50] or something like that, it's something that we  would consider. But for for now, we've the the [36:54] flavors that I mentioned earlier were kind of  chosen very explicitly. And we we did look at [36:59] the capabilities of some of the Chinese models  and think wow that that does some cool stuff but [37:03] we're we're not ready for that personally in my  bank. Talking about architecting the feature how [37:09] do you achieve success when you have this legacy  systems uh built before and you are carrying all [37:17] these legacy systems in this race of building new  features new apps and new systems that needs to [37:24] be integrated together. Yeah, I think I can go  ahead. the I think the legacy system this is the [37:29] challenge which uh most of the banks have usually  uh legacy system is your your biggest leverage [37:36] I would say right because that is working for a  while you have you know 10 20 years of data which [37:43] is sitting which means something right so the the  place where these systems are lacking is what this [37:48] data means for an agent or or for a nonhuman which  is looking at this data uh the the value you could [37:57] add is how you could convert this data into a a  middle layer which would provide a meaning for [38:04] all this data. Right? So some of the open source  tools like open meta data is is one way where you [38:10] could you know say okay this system of record  means this you know and this ID means you know [38:16] this is a client ID you know things like that how  you could describe your data layer it to an agent [38:23] building that middle API layer is going to be  your biggest uh uh it is not you know a fancy [38:29] job but I would say this is where the roles are  going to come on how you translate your legacy [38:34] system data and convert that to a describable u  you know layer to the agents actually right hi [38:42] there not not in not banking but fanny may so uh  finance right so obviously we deal with a lot the [38:48] regulators for us so [laughter] so uh I'm sure  both of you have gone through the period of buy [38:55] versus build right we did that with cloud when we  made that evolution from on-prem to cloud right [39:00] uh but now what happens is I see us you We we do  a lot of technology, right? We're not a technology [39:07] company. We are a financial services industry,  right? So, how do you make those decisions? Is [39:13] it the tokenization of it helping you quantify  that or uh how do you make those decisions ahead [39:18] of time before you dive into buy versus build?  Because I'm seeing some things that we should [39:23] buy and we've been trying to build them, right?  [snorts] Well, I I think anything you'd build, [39:29] we we want to know why would we build it,  right? We we all know about economies of scale, [39:33] etc. And you know, Marley had just mentioned  the arms race that's happening among the various [39:38] vendors to put out new and cool products. And  we have the benefit as consumers of of their [39:42] offerings to be able to select the best or you  know, select things that harmonize with whatever [39:46] ecosystem we're trying to build. So I think there  there are good reasons to build, you know, if [39:52] there are things that are very customized to your  environment. Like in in my bank, we often find [39:58] that we we've been around for north of a hundred  years. We have certain processes that have arisen [40:04] our way and in many cases we we look consciously  at a vendor's offering and say we could adjust our [40:11] way of doing business our way of working to the  vendor's tool or we could build it to our way and [40:17] you know we have to make some some choice around  those things. So I think that matching internal [40:22] processes or idiosyncrasies unique to your  organization that could be a very good reason to [40:28] to build. But whenever we build something like I  think we just we need a real clear reason for why [40:34] because we should think generally most of the time  there's something out there on the shelf that we [40:38] could likely use. So we just have a clear case for  it. I think that same thing right so and also the [40:43] factor you should consider is even if you build  what is your operational cost going to be how [40:48] much time you're going to spend maintaining that  system right and a lot of it comes back to how [40:55] effect you your engineers are in building a system  and then are you making it more zero maintenance [41:01] uh kind of a system is it pluggable to uh another  platform down the line 5 years because things [41:06] would change definitely so all this uh is what  you would consider at the same time even if you're [41:11] buying a product you don't buy it as a black box  you should know in and out what it does with your [41:17] data what guardrails it has put in in its how  you could integrate with your systems you know uh [41:23] and you you should always be in contact with your  vendor and how much it would cost for some uh one [41:28] of these vendors to build a new feature actually  right so there are cases where we observed [41:33] building a new feature in a vendor solution was  costing us much much higher than a solution we [41:39] could build on top within less four months, five  months, right? So, yeah, these are the factors you [41:44] would consider say and a lot of them, a lot of  the open source, there's very incredible talent [41:50] that I was just talking with somebody uh in the  speaker launch. There is an open-source software [41:57] which is a replica of a major CRM vendor. I'll  not name it, but um we could connect I'll show [42:03] it to you. So, it is the entire GitHub code  repository is open sourced, right? So, yeah. [42:10] And I I love just to follow up on that. I  love the point about integrations. Like you [42:13] know vendors frequently build to integrate with  one another and collaborate. No one is going to [42:19] build to integrate with our bespoke thing  that we created inside our organization. So [42:23] just one of those dimensions that we have to  weigh as we're looking to make that decision. [42:29] So uh question about vibe coding and where do  you think it's going to impact the industry? [42:36] uh is it going to impact your bill versus buy  decisions? Is this going to impact your resourcing [42:43] and organizational structure? Have you guys  thought through or seen any impacts of VIP coding [42:49] as you bring that within the organization? Gotcha.  Um I mean I'll maybe I'll I'll start quickly. The [42:57] the term vibe coding like I I generally and people  might mean a range of things by that. So we just [43:04] want to come to a common understanding of what we  mean. You know some people mean building without [43:09] really the technical understanding that they  necessary to have built it themselves but using [43:15] an LLM to to produce that kind of code. I'll say  my I have a jaundest view of building things in [43:21] that way and I think that there's a maintenance  nightmare coming you know if it if not tomorrow [43:26] then next week or beyond in building in that way  but the idea that a skilled practitioner with the [43:31] knowledge to do it themselves could guide an an  individual agent or a series of agent to produce [43:38] products I think that's a very viable model I  think that's what we're going to see more and [43:42] more in the future we personally have not gotten  gotten into like agent swarms idea where you [43:47] know no no one's writing or that it's the agents  creating code and critiquing one another, etc. We [43:52] think we're probably going to have to experiment  with that in 2027, but we're we're at the point [43:57] basically where it's individual developers heavily  assisted by AI doing their thing, checking it, [44:01] making sure you're making adjustments, etc. Um, I  think I missed significant parts of your question, [44:07] but I know I've also rambled on for a while, so  I'm going to shut up and [laughter] see if Ally [44:10] has thoughts. I think VIP cutting is great for  two cases, I feel, right? And this is what I'm [44:14] seeing in my role as well. product managers or  program managers who are having brilliant product [44:20] ideas. Um they are able to build a nice idea and  showcase it to the business within like you know [44:27] one two days which is buying us getting us the  budget to actually do a real build. So to answer [44:34] in the same breath is is wipe coding good uh to go  ahead and deploy in production no and I'm not in [44:40] a position at this at least at this point now to  deploy a blackbox which I don't know how the agent [44:46] has or the the you know the model has developed  that code in a language which I don't understand [44:51] uh so I'm not in that comfortable position but and  and then the other aspect is the users itself like [44:58] the business users itself which who doesn't  have any technical knowledge they are also [45:03] building applications which we call as UDA uh  end user developed applications which are also [45:08] getting registered in a registry. Uh these are the  ideas that are actually bringing the technology [45:15] folks to see those udas and say oh I think we'll  build an you know a product which would support [45:20] a bigger user volume actually these are the two  cases where the wipe coding is really efficient [45:25] in our organization actually. So great well I  think that's that's all the time that we have [45:31] for for today. Thank you for staying with  us before your happy hour and enjoy enjoy [45:36] the rest of your day. Thank you very much folks.  Appreciate it. Thank you. [applause] [cheering]