Enterprises Scrap Half of AI Pilots as Tool Sprawl Masks Data Gaps

工具泛滥掩盖数据缺陷 企业放弃半数AI试点项目 企业AI项目之所以停滞，是因为组织在确定具体的运营瓶颈和建立基础数据治理之前，便已部署了自主工具。 尽管整个企业界进行了大规模的资本投资，但由于技术可行性与业务价值之间脱节，绝大多数生成式和智能体AI项目仍陷入停滞。为了克服这种“冻酸奶综合征”（Frozen Yogurt Syndrome），Nirmayee Dighe提出了“时序自动化框架”（Sequenced Automation Framework），这是一种旨在工程开发启动前确立组织就绪度的结构化方法。该框架按顺序依次推进：发现运营痛点、标准化业务分类体系、建立“双人一盒”（two in a box）转化层、审计基础数据架构，并通过迭代共创来建立信任。在摩根士丹利（Morgan Stanley）、汇丰银行（HSBC）、星展银行（DBS Bank）和美国银行（Bank of America）的案例研究支持下，演讲强调了要从孤立的技术项目转变为具有生命力且由产品主导的能力。 有效的AI战略必须直接运作于技术可行性与对业务利益相关方的商业价值这两者的交界点上。 (0:04) 企业级AI正在从辅助型、以人为本的范式（聊天机器人和Copilot）转向自主、AI优先的智能体，后者可执行完整的工作流，且仅在出现异常时进行上报。 (1:46) 尽管投入了巨额资本并在企业中开展了广泛尝试，但由于“价值鸿沟”和“智能体鸿沟”的存在，仅有1%的组织实现了成熟的投资回报率。 (6:06) “冻酸奶综合征”指组织被繁多的工具和供应商选择所压垮，在没有明确先后顺序或未能解决实际瓶颈的情况下，混合了互不兼容的技术。 (10:11) AI项目必须始于“痛点认知”——揭示具体的决策延误和手动工作流程中的阻碍，而不是征求以工具为先的建议。 (11:37)

Data and AI strategist Nirmayee Dighe argues that massive enterprise investments in artificial intelligence frequently stall due to 'Frozen Yogurt Syndrome'—a paralysis of choice where organizations accumulate disconnected tools without clear operational readiness. To achieve measurable business returns, she advocates replacing reactive implementations with a sequenced five-step framework prioritizing problem identification, shared language, translation governance, core data infrastructure, and iterative co-creation. The Enterprise AI Paradox and Choice Overload (6:06) Enterprises are allocating unprecedented capital toward artificial intelligence, with global AI spending projected to reach $2.59 trillion by 2026 and $4.8 trillion by 2030. Although 88% of surveyed U.S. organizations report deploying AI across at least one business function by 2025, Dighe notes that actual organizational maturity remains rare: only 1% have achieved mature development with realized return on investment. Furthermore, 50% of generative AI proofs-of-concept are abandoned, and analysts project that more than 40% of agentic AI initiatives will be cancelled by 2027. Dighe attributes this high attrition rate to 'Frozen Yogurt Syndrome.' Pressured by competitive anxiety and vendor marketing, enterprise leaders encounter an overwhelming array of platforms, dashboards, copilots, and models. Much like customers mixing mismatched ingredients at a self-serve frozen yogurt shop, organizations assemble fragmented, disjointed technology stacks that fail to address genuine operational bottlenecks. Shifting from Assistive Tools to Autonomous Agents (1:46) Enterprise capabilities have rapidly evolved from human-first assistive tools toward AI-first autonomous agents. While early chatbots merely synthesized information and copilots generated recommendations that required human review and execution, agentic systems independently plan, access core databases, and complete end-to-end workflows. In an agentic paradigm, human professionals are engaged solely when ambiguous exceptions or out-of-bounds errors arise. However, Dighe warns that jumping directly to autonomous agents exposes enterprises to two failure modes: the 'Value Gap,' where technically sophisticated projects fail to produce measurable commercial impact, and the 'Agent Gap,' where organizations attempt to deploy autonomous workflows before establishing the data hygiene, semantic context, and technical architectures necessary to support them. Aligning Pain Points, Taxonomy, and Translation (11:37) To build organizational readiness, the initial stages of the Sequenced Automation Framework mandate thorough pre-work before any engineering begins. Step 1 requires 'painpoint literacy,' directing teams to uncover specific operational delays rather than asking where AI can be applied. When Morgan Stanley targeted a verified bottleneck—advisors placing clients on hold to cross-reference disconnected records—their unified internal conversational tool achieved a 98% adoption rate. Step 2 establishes a shared business language taxonomy to eliminate cross-departmental semantic confusion regarding basic terms like 'client' or 'policyholder,' mirroring Goldman Sachs' shared platform for lineage and definitions. Step 3 introduces a dedicated translation layer using a 'two in a box' leadership model pioneered by DBS Bank. By pairing a business leader with a technical leader, organizations ensure that system permissions, rollback protocols, and project roadmaps remain continuously aligned with changing business priorities. Securing Infrastructure Foundations and Trust-Based Adoption (22:53) Step 4 of the framework requires an infrastructure readiness assessment. Comparing advanced models to high-performance vehicles, Dighe observes that deploying agentic AI without data pipelines, unified storage, safety rules, and monitoring leads to stranded assets. For instance, DBS Bank paused new AI deployments for 12 to 18 months solely to construct its data foundation, which subsequently supported over 1,500 models across 370 use cases. Similarly, HSBC rebuilt its core data architecture before launching financial crime detection models, resulting in a 4x improvement in detection and a 60% reduction in false positives. Step 5 centers on trust-based adoption by shifting from one-off projects to continuous, product-led lifecycles. Rather than working in isolation, technical teams must build directly with stakeholders from Day 1 using early prototypes and wireframes. This iterative feedback loop—demonstrated by Bank of America piloting its 'Erica' assistant internally before rolling it out to retail customers—ensures systems adapt effectively as operational workflows evolve. Dighe concludes that enterprise AI success relies on resisting premature tool adoption in favor of disciplined operational sequencing. Realizing sustained returns requires organizations to bridge the divide between technical capability and commercial value, which depends on their willingness to invest in shared definitions, cross-functional translation, and foundational data infrastructure before deploying autonomous solutions.

数据与AI策略师Nirmayee Dighe指出，当前企业在AI领域投入巨资却面临极高失败率，核心症结在于陷入技术选型过载、随意拼凑工具的“冻酸奶综合征”；企业必须转向按序推进的五步自动化框架，在技术开发前完成痛点梳理、语言统一与基础设施奠基，才能跨越落地鸿沟。 交互范式演进与企业落地悖论 (1:46) Dighe指出，生成式AI正从辅助性的“以人为主”模式（如问答型Chatbot、草拟内容的Copilot）加速迈向具备端到端执行能力的“AI优先”自主智能体（Agent）。在保险理赔等流程中，智能体已能自主调取缺失材料并更新核心系统，仅在出现异常时交接给人工。与此同时，技术界正进一步探索由总控智能体协调多个子智能体编写并部署软件的“AI原生工程师”模式。 然而，巨大的市场资本投入与企业实际收益之间出现了尖锐矛盾。数据显示，全球AI支出预计将在2026年达到2.59万亿美元，企业投资年增长率达47%，且2025年已有88%的美国受访机构在至少一项职能中采用AI；但同时，仅有1%的企业实现了带来成熟投资回报的深度应用，50%的生成式AI概念验证（POC）被中途废弃，更有预测指出超过40%的智能体项目将在2027年前被取消。Dighe将此归因于技术与核心商业指标脱节的“价值鸿沟”，以及在缺乏数据与语义底座时盲目部署技术的“智能体鸿沟”。 冻酸奶综合征与痛点及语义对齐 (10:11) 面对海量工具与平台，企业管理层在时间压力下往往盲目堆砌技术，陷入Dighe所称的“冻酸奶综合征”——如同在自助酸奶店被琳琅满目的配料与限定口味诱惑，最终调制出无法下咽的大杂烩。企业常常将商业智能（BI）、分析看板、Copilot与底层大模型杂乱拼凑，将智能体视为最新的“时髦配料”，却忽视了其是否解决真实业务瓶颈。 为破解该困境，Dighe提出的序列化自动化框架首先要求建立“痛点认知”（步骤1），严格区分主观的技术推荐与具体的业务摩擦，优先聚焦决策延误或耗时数小时的繁琐环节；例如Morgan Stanley通过整合CRM与分散文档构建内部AI助手，实现了98%的顾问采纳率。其次，企业须在工程启动前建立“业务语言分类法”（步骤2），消除跨部门沟通中的语义歧义（如营销称“客户”、运营称“终端用户”、财务称“保单持有人”、信贷称“借款人”）；例如Goldman Sachs通过共享分类平台让业务人员直接追踪数据谱系与命名规范，大幅减少了跨部门的技术排查损耗。 跨职能翻译层与双盒领导模型 (21:57) 针对业务端与技术端长期缺乏共同话语体系的痛点，框架要求设立明确的“翻译层”（步骤3）。该角色负责严格评估识别出的痛点是否真正需要智能体，还是仅凭BI看板、报表或基础自动化脚本即可解决；当确认采用智能体方案时，翻译层需制定治理规范，界定系统读写权限、输入歧义时的回退机制，以及模型失效时的人工追责归属。 Dighe引用DBS Bank的实践指出，解决业务需求与工程实现脱节的关键是采用“双盒”（Two in a Box）联合领导机制。在该模式下，每个平台项目均由一位业务负责人与一位技术负责人协同挂帅。业务领袖充当双语翻译，在“具备商业价值”与“技术工程可行”的交汇点平衡商业目标与系统开销、治理防线及回滚机制等底层约束。当企业战略目标变动时，双盒机制能保障技术路线图动态调整，确保工程团队始终对准真实的业务问题。 基础设施底座与产品化信任构建 (22:53) 在完成对齐与翻译后，框架推进至技术就绪阶段。Dighe运用“汽车与道路”的比喻强调，在缺乏底层管道与治理机制时盲目构建智能体，犹如购置顶级豪华轿车却无公路、燃料及交通法规可用。DBS Bank曾专门投入12至18个月专注底层数据基础设施与迁移而未发布任何新AI工具，后续成功支撑了超过1500个模型及370多个业务用例；HSBC在暂停初期项目并全力夯实底层数据后，金融犯罪侦测率提升了4倍，误报率降低了60%。 框架最后强调从“为利益相关者构建”转向“与利益相关者共同构建”（步骤5）。技术团队应在项目初期通过粗糙表格或原型界面尽早暴露不完善之处，以此建立互信并吸纳业务知识进入模型训练闭环。上线后，团队应摆脱一次性交付的“项目思维”，转为持续迭代的“产品思维”，通过微调界面或数据库架构适应新业务；正如Bank of America的虚拟助手Erica最初仅作为内部生产力工具反复打磨，最终才演进为服务数百万外部客户的成熟系统。 Dighe总结指出，破解“冻酸奶综合征”的关键在于克制盲目追逐新技术的冲动，严格按痛点挖掘、语义统一、翻译协同、基建夯实与共同迭代五步推进；但如何在业务部门对短期可见成效的急切诉求，与底层数据基础设施所需的长期沉淀之间维持平衡，仍是企业在AI落地过程中需要持续博弈的难题。

## Background 该视频由 Ai4 频道于 2026 年 8 月 20 日发布在 YouTube 平台上。内容为主讲人 Nirmayee (Nemo) Dighe（Group 1001 旗下 Delaware Life Marketing 商业智能副总监）的主题演讲，页面简介指出，本次分享旨在剖析企业因工具过多且缺乏时序规划而陷入的“冻酸奶综合征”，并提出一套四步数据战略框架，帮助企业克服数据成熟度与治理障碍，从盲目实验迈向具有可衡量商业回报的 AI 规模化落地。 ## TL;DR 演讲首先揭示了 AI 淘金热背后的残酷现实：尽管高达 88% 的企业声称在业务中使用 AI，但真正实现成熟落地并带来明确 ROI 的仅有 1%，核心症结在于组织陷入了“冻酸奶综合征”——盲目堆砌前沿工具却缺乏清晰的落地先后时序。针对“价值鸿沟”与“Agent 鸿沟”，Nemo 提出了“时序自动化框架”，强调 AI 应是组织就绪后的自然产物而非跟风起点。该框架通过痛点识别（如摩根士丹利案例）、统一业务语言分类（如高盛案例）、设立技术与业务翻译层（如星展银行双盒模型）、夯实数据与基础设施底座（如汇丰银行实践），最终转向与利益相关者共建的产品思维（如美国银行 Erica 助手），形成持续演进的闭环。 ## Atmosphere & style 演讲整体呈现出幽默风趣、务实清醒且极具亲和力的基调。开场以“寻找尼莫”的自嘲幽默迅速破冰，随后用扎实的麦肯锡与 Gartner 行业数据打破了全场的 AI 泡沫幻想，形成强烈的认知冲击。主讲人擅长将晦涩的企业级架构问题转化为生动的日常比喻——从自助冻酸奶店的“选择瘫痪”到跑车驶向泥泞土路的基座危机，娓娓道来间既有对一线协作痛点的深刻共情，又有清晰从容的框架解法，让听众在会心一笑的同时获得切实落地的战略定力。 ## Key takeaways - [01:42](https://www.youtube.com/watch?v=QjzYEHkJet4&t=102s) AI 交互范式已从以人为中心的 Chatbot、Copilot 演进为以 AI 为中心、自主驱动工作流并仅在异常时引入人工的 AI Agent 模式。 - [06:06](https://www.youtube.com/watch?v=QjzYEHkJet4&t=366s) 企业 AI 落地面临严重断层：虽有 88% 的企业使用 AI，但仅 1% 达成成熟落地并带来真实 ROI，且 50% 的生成式 AI PoC 演示后被废弃。 - [06:06](https://www.youtube.com/watch?v=QjzYEHkJet4&t=366s) AI 落地受阻的核心在于价值鸿沟（技术与商业 ROI 脱节）与 Agent 鸿沟（组织缺乏支撑复杂 AI 的底层数据与架构就绪度）。 - [09:39](https://www.youtube.com/watch?v=QjzYEHkJet4&t=579s) “冻酸奶综合征”形容组织面对海量工具与网红技术选项时陷入选择过载，盲目跟风堆砌工具而缺乏清晰的落地先后次序。 - [13:36](https://www.youtube.com/watch?v=QjzYEHkJet4&t=816s) 第一步聚焦“痛点素养”：必须严格区分技术方案建议与真实业务痛点，从一线员工被拖慢的具体业务流程中寻找真实的 ROI 机会。 - [17:47](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1067s) 第二步构建“业务语言分类体系”：统一不同部门对同一实体的术语定义与数据度量标准，避免因上下文缺失导致 AI 输出失效。 - [20:22](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1222s) 第三步设立“翻译层”：借鉴星展银行的双人成组（Two-in-a-box）模型，由兼通业务与技术的跨职能主管研判技术选型边界与治理权限。 - [22:53](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1373s) 第四步夯实“运营与数据基础设施”：如同高性能汽车需要平整公路，复杂的 AI Agent 必须依托集中治理的数据管道与成熟的回滚流程。 - [25:25](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1525s) 第五步坚持“与业务共建（Build with）”：技术团队从第一天起就应让业务方参与粗糙原型的验证迭代，以注入充足上下文并建立信任。 - [26:13](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1573s) 组织需从一次性交付的“项目思维”转向持续演进的“产品思维”，通过敏捷反馈闭环使 AI 工具随业务优先级调整而持续进化。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=QjzYEHkJet4&t=4s) 引言与个人背景：站在技术与业务的交叉点 Nemo（Nirmayee Dighe）以一个轻松的幽默开场，打趣自己的名字就像《海底总动员》里的“尼莫”一样，不过大家不用担心，“尼莫已经被找到了，我就在这里”。作为一名数据与 AI 战略专家，她将自己的工作定位在两个截然不同的世界的交汇处：一端是深刻理解商业逻辑、明确业务痛点与需求的业务团队；另一端则是掌握实现路径、技术可行性、底层架构与基础设施的技术团队。她的职责正是穿梭于“技术可能实现的事情”与“对业务真正有价值的事情”之间，寻找两者的平衡点。 在给出观点之前，Nemo 首先做出合规声明，强调本次分享仅代表个人观点，与所在雇主无关，并幽默地表示如果有任何异议“请直接怪 Nemo，不要怪我的公司”。紧接着，她为全场梳理了本次分享要解答的三大核心问题：当前 AI 市场正在发生什么？为什么巨额投资未能转化为实际落地采用？组织究竟应该如何做出改变？通过现场举手互动，确认了参会观众涵盖了均衡分布的业务决策者与技术工程团队。 ### [01:42](https://www.youtube.com/watch?v=QjzYEHkJet4&t=102s) 从 Chatbot、Copilot 到 Agent：AI 演进与交互范式的根本转变 回顾 AI 的发展轨迹，市场最初始于大语言模型（LLM）驱动的聊天机器人（Chatbot）。Nemo 回忆自己在 2022 年底读硕士期间初次接触 ChatGPT 时的震撼，它不仅能写代码，还能辅助文献检索和信息提炼。这一阶段，企业开始跟风探索，核心疑问是“AI 还能做什么、我该怎么用它”；随后，演进进入 Copilot（副驾驶）时代，企业开始尝试将 AI 嵌入具体工作流，利用其进行内容摘要、草稿撰写以及下一步操作建议。然而，无论是 Chatbot 还是 Copilot，其交互本质依然是“以人为中心（Human-first）”，AI 始终处于被动响应、协助或建议的位置。 当前市场全面转向具备高度自主性的 AI Agent（智能体），其交互逻辑彻底逆转为“以 AI 为中心（AI-first）”——由 Agent 自主驱动工作流，仅在必要时才调用人类介入。Nemo 以保险行业的理赔客服场景生动对比了三者的断代差异： ```mermaid flowchart TD accTitle: Chatbot、Copilot 与 AI Agent 在客服场景中的工作模式演进 subgraph Chatbot["Chatbot 模式（人为主导）"] C1["客户来电反馈保单延期"] --> C2["人工客服询问 Chatbot"] C2 --> C3["Chatbot 总结：资料未齐备"] C3 --> C4["人工查找文件并邮件跟进"] C4 --> C5["人工更新系统并放款"] end subgraph Copilot["Copilot 模式（人机协同）"] CP1["客户来电反馈保单延期"] --> CP2["Copilot 关联保单与历史沟通"] CP2 --> CP3["Copilot 定位缺失并起草邮件"] CP3 --> CP4["人工审核发送并触发放款"] end subgraph Agent["AI Agent 模式（AI 自主驱动）"] A1["客户发起会话"] --> A2["Agent 自主诊断并对接客户补件"] A2 --> A3{"是否超出处理边界？"} A3 -- 否 --> A4["Agent 自主更新系统并直接放款"] A3 -- 是 --> A5["Agent 自动转接人工处理"] end ``` 在 Agent 模式下，客户直接与 AI 对话，AI 自动核实缺失材料、指导客户补充、审核后自主更新核心系统并发起付款，全程无需人类介入，只有当问题超出边界无法理解时才会转接人工。Nemo 感慨这“既令人兴奋又让人害怕”，甚至在大会其他环节已有供应商提出了由超级 Agent 调度其他 Agent 编写代码的“AI 原生工程师（AI-native engineer）”概念，技术迭代带来的紧迫感正席卷整个行业。 ### [06:06](https://www.youtube.com/watch?v=QjzYEHkJet4&t=366s) AI 淘金热下的冰冷现实：价值鸿沟与 Agent 鸿沟 当前企业正身处一场狂热的“AI 淘金热”。管理层感受到的上马压力来自各个方向：软件供应商的大肆推销、竞对的动作、董事会的质询以及一线员工的自发使用。支撑这种焦虑的是极其庞大的市场预测数据，但表面的繁荣背后却隐藏着极其残酷的落地现实： - **Gartner 预测支出**：到 2026 年底，全球 AI 支出将达到 2.59 万亿美元，年复合增长率高达 47%。 - **McKinsey 普及率调研**：到 2025 年，88% 的美国企业已经在至少一个业务职能中使用 AI；预计到 2030 年，AI 市场价值将达到 4.8 万亿美元。 - **McKinsey 成熟度真相**：在上述 88% 声称使用 AI 的企业中，仅有区区 1% 实现了“成熟落地（Mature development）”（即 AI 用例明确绑定了商业成果，并带来真实的投资回报率 ROI）。 - **Gartner 废弃与取消率**：高达 50% 的生成式 AI PoC（概念验证）在 Demo 展示后被彻底废弃，无法走向生产环境；预计到 2027 年底，超过 40% 的生成式 AI / Agent 项目将以取消告终。 Nemo 指出，这种高投入与低采用率脱节的现象，根源在于两大核心鸿沟： 1. **价值鸿沟（Value Gap）**：技术上令人惊叹、华丽炫目的工具，如果未能与具体的业务成果和商业 ROI 深度绑定，就无法产生真正的商业价值。 2. **Agent 鸿沟（Agent Gap）**：组织在焦虑中迫切想要引入复杂的 AI Agent，但底层完全缺乏支撑高度精密 AI 工具所需的数据就绪度与技术架构基础设施。 | 评估维度 | 概念验证阶段（PoC / Demo） | 成熟落地阶段（Mature Development） | |:--- |:--- |:--- | | **技术特征** | 演示炫酷、技术先进、局部单点实验 | 具备完善的数据治理基座与生产级架构支撑 | | **商业关联** | 脱离实际业务指标，缺乏投资回报测算 | 紧密绑定核心业务结果（Business Outcome）与明确 ROI | | **组织现状** | 50% 项目被废弃，40%+ Agent 项目面临取消 | 仅 1% 的企业真正达成该阶段 | ### [09:39](https://www.youtube.com/watch?v=QjzYEHkJet4&t=579s) 冻酸奶综合征与序列化自动化框架的前期构建 当咨询机构深入调研为何 AI 落地如此举步维艰时，发现企业领导者普遍陷入了极度焦虑与选择过载的状态——在有限的时间窗口内，面对海量工具、技术栈与供应商推销，往往只能仓促拍板。Nemo 将这种现象形象地比喻为“冻酸奶综合征（Frozen Yogurt Syndrome）”： > “想象一下你走进一家自助冻酸奶店。刚进门时你非常清楚自己想要什么。但走近柜台，你看到了琳琅满目的配料、选择和口味；而在柜台最正中央，赫然写着‘本月限量版风味’。一瞬间，你什么都想来一点，感到不知所措，最终端走了一大杯你最初根本不想要的混合物。” 当今的 AI 市场正是如此：企业把 AI、BI、数据分析、报表看板、Copilot 和各类模型胡乱堆砌在一起，而 Agent 成了最新的“网红配料”；然而，“最新的配料并不意味着适合你的组织”。 为破解这一困局，Nemo 提出了“序列化自动化框架（Sequence Automation Framework）”，主张将 AI 视为组织准备就绪后的自然产物，而非盲目跟风的起点。该框架的前期准备工作涵盖三大核心步骤： - **第一步：痛点认知（Pain Point Literacy）**：回归商业本质寻找 ROI，深入业务利益相关者之中，挖掘真正的业务痛点与商业机会，提出正确的问题。 - **第二步：业务语言分类法（Business Language Taxonomy）**：建立统一的共享定义空间。不同业务团队对同一实体可能有完全不同的称呼（例如同一个对象，被不同部门分别称为客户 Client、消费者 Customer 或投保人 Policyholder）。AI 的输出质量高度取决于输入的数据与上下文，必须先统一业务语意。 - **第三步：翻译层（Translation Layer）**：由于业务团队与技术团队往往存在天然的沟通壁垒，必须设立由跨职能角色或团队组成的“翻译官/解释层”，负责在双方语言之间进行精准转译，确保技术实现与业务诉求严丝合缝。 在完成上述业务梳理、语意对齐与跨职能协同等前期准备后，流程才会推进至第四步——**运营基座（Operating Foundation）**，即真正开始动手构建支撑 AI 落地的数据与架构基础设施。 ### [13:36](https://www.youtube.com/watch?v=QjzYEHkJet4&t=816s) 步骤一：痛点素养（Pain Point Literacy）与摩根士丹利的落地实践 很多团队在开启 AI 项目时，往往习惯先问“我们在哪里可以使用 AI Agent？”，但这仍然是一种“技术优先”的思维误区。正确的出发点应当是与利益相关者（无论是 C-suite 高管、业务主管、日常同事还是业务案例合作伙伴）进行深入沟通，去探寻真正的业务瓶颈：哪些流程已经损坏？哪些业务决策正在被延误？业务端最核心的痛点是什么？有哪些决策因为缺乏数据访问权限而无法做出？为什么原本 30 分钟就能完成的任务实际需要耗费某人 3 小时？这种沟通并不需要大张旗鼓地组织正式研讨会或会议，只需带着好奇心主动询问同事：“是什么拖慢了你的进度？哪件事占用了你 4 个小时，导致手头的其他海量任务全被延后？”这样的提问会瞬间打开对方的“话匣子”，暴露出所有令人沮丧的低效环节。 在收集痛点时，必须严格区分“方案建议”与“真实痛点”。例如，如果有人说“我们应该在客户服务中使用 AI Agent”，这只是一项方案建议；但如果对方反映“客户在电话另一端等待时，我们的客服代表需要花整整 35 分钟在系统里翻找保单信息”，这才是值得深入挖掘的实质痛点。摩根士丹利（Morgan Stanley）就曾面临这一典型难题：客户致电财务顾问咨询问题时，由于内部数据高度碎片化，分散在各个不同业务单元、数据集和 CRM 系统中，财务顾问不得不让客户稍作等待，自己在多个系统间手忙脚乱地查找。为此，摩根士丹利构建了一个覆盖所有底层数据库、内部文档和 CRM 数据的 AI 助手。财务顾问只需在 Chatbot 中输入客户状态与查询需求，即可实时获取全貌信息，该方案最终在财务顾问群体中达成了高达 98% 的采用率。 ```mermaid flowchart TD accTitle: 痛点识别与摩根士丹利AI助手架构 subgraph S1["痛点识别 (Pain Point Literacy)"] A["技术优先思维 (错误)"] -.->|转变为| B["业务痛点优先 (正确)"] B --> C["方案建议: '想在客服用AI'"] B --> D["真实痛点: '客服查保单需耗时35分钟'"] end subgraph S2["摩根士丹利实践"] E["底层碎片化数据<br/>(CRM / 内部文档 / 多源数据库)"] --> F["统一 AI 助手"] F --> G["财务顾问即时查询"] G --> H["98% 采用率 & 提升客户体验"] end D --> S2 ``` --- ### [17:47](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1067s) 步骤二：构建业务语言分类体系（Business Language Taxonomy） 在日常工作中，当人们被拉进一个毫无背景信息的邮件链时，往往需要打个 5 分钟的电话去补齐上下文。人类本身极其依赖上下文来理解信息，自然也不能奢望 AI Agent 能够凭空理解一切业务内涵。构建 AI 解决方案与智能体的技术团队，必须与终端业务用户使用同一种语言进行沟通；若业务端缺乏认同感而不愿采用工具，AI 投资就无法持续，更无法带来预期 ROI。 为了消除不同部门之间的壁垒，企业必须建立“业务语言分类体系”，统一通用术语、定义、数据归属权以及工作流上下文。在实际业务中，不同单元对同一实体的称呼往往大相径庭：市场部门可能称之为“客户（Client）”，运营部门叫“终端客户（End Customer）”，财务部门称作“保单持有人（Policyholder）”，其他部门可能叫“借款人（Borrower）”，但它们本质上指的是同一个人。高盛（Goldman Sachs）就曾遇到跨多个业务部门的技术团队沟通成本极高的问题，业务用户不断就“在哪里查找客户/保单信息”与技术人员反复拉扯。高盛通过联合构建业务语言分类体系并集成到数据平台中，让业务人员可以直接自助查询数据血缘（Lineage）、存储位置、访问方式、更新机制以及其他团队的对应命名，彻底免去了反复向技术团队求证的繁琐沟通。 --- ### [20:22](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1222s) 步骤三：设立业务与技术翻译层（Translator/Interpreter Layer） 由于业务语言与技术术语之间长期存在鸿沟，企业必须设立专门的“翻译/解释层（Interpreter Layer）”。这一角色承上启下，负责推进前两个步骤：他们深入业务一线对接利益相关者，梳理出真实痛点并协助编纂业务语言分类体系；更关键的是，他们负责研判问题的技术属性——明确这究竟是一个需要 AI Agent 解决的问题，还是一个简单的商业智能（BI）看板、常规数据报表，或是几行 Python 脚本就能搞定的需求。 如果经过评估确实适合采用 AI Agent 方案，翻译层将进一步与业务部门界定系统的权限与治理边界：该赋予该工具何种程度的自主权？开放何种级别的读写访问（Read/Write Access）上下文？一旦 Agent 决策失误，责任由谁来承担？星展银行（DBS）为了解决业务部门提完需求后与技术团队逐渐脱节的问题，推出了“双人成组（Two-in-a-box）”模型： - **联合领导机制**：每一个平台项目的构建，均由一位业务主管与一位技术主管共同领导。 - **跨界沟通与价值把控**：其中的业务主管兼通业务与技术双重语言，站在“业务价值（What's valuable）”与“技术可行性（What's possible）”的交汇点上。 - **技术治理与业务对齐**：业务主管能够充分理解技术团队对于底层架构、回滚流程（Rollback Processes）和数据治理的诉求，并将其转化为业务决策；同时紧跟不断变化的业务优先级，确保技术团队交付的成果始终聚焦于核心业务目标。 --- ### [22:53](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1373s) 步骤四：基础设施检查（Infrastructure Check） 完成前序梳理并确认立项后，第四步是对底层基础设施进行全面检查。构建 AI 解决方案就好比驾驶一辆汽车：即使拥有一辆极其奢华、精密的高性能汽车，如果缺乏平整的道路、充足的燃料、完善的交通安全措施以及清晰的路权规则，这辆车也根本无法上路行驶。AI 同样如此，在构建复杂的 AI Agent 之前，必须耗费扎实的精力去夯实基础：数据管道是否就绪？数据是集中治理还是分散在 25 个不同的数据孤岛中？监控机制、准确率评估以及回滚流程是否健全？ 星展银行（DBS）与汇丰银行（HSBC）均在底层基础设施上进行了长期投入，甚至花费整整一年到一年半的时间专门打磨底层底座、完成系统迁移，期间完全不急于开发上层 AI 应用。这种克制带来了巨大的后续成效： - **星展银行（DBS）**：在坚实的底层基础上，成功支撑了 1,500 多个模型在 370 多个业务场景中的规模化落地。 - **汇丰银行（HSBC）**：此前曾因缺乏坚实底座而无法高效构建金融犯罪监测系统。在重构基础设施后，其 AI 金融犯罪识别率提升高达 4 倍，同时误报率（False Positive）大幅降低了 60%。 --- ### [25:25](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1525s) 步骤五：通过持续学习建立信任（Build Trust-Based Adoption） 构建 AI 方案的核心原则是“与利益相关者共同构建（Build with），而非单纯替他们构建（Not for）”。业务利益相关者是工具的最终使用者，拥有不可替代的业务上下文认知。 因此，技术团队绝不能在看完最初的需求演示后就闭门造车“消失 6 个月”，然后直接甩出一个成品系统；而是必须从第一天起就将业务方纳入迭代循环中。哪怕第一周只是同步一个简单的 Excel 文件，第二周只是展示一个界面尚不完善的粗糙 UI Demo，也要持续让业务人员介入验证。越早将业务方深度绑定在开发流程中，系统吸收的业务上下文就越全面，最终的信任度与采纳率也会越高。 ### [26:13](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1573s) 从项目思维转向产品思维：美国银行 Erica 案例与持续反馈循环 在工具或系统构建与发布之后，与利益相关者的协作绝不能戛然而止。企业必须在系统上线后持续保持沟通，密切监控其准确性并收集第一线反馈。随着业务优先级的动态调整——比如新产品的发布或旧产品的下架——工具本身也需要迅速做出相应调整。因此，建立健全的反馈循环至关重要，必须让业务人员能够顺畅地表达“哪些功能好用、哪些不好用、哪些结果值得信任、哪些仍然存疑”。获得反馈后，团队应当进行“有意识的迭代（iterate intentionally）”。优化并不意味着每次都要推倒重来，有时候可能仅仅是用户界面（UI）的一个微调，或是底层数据库的一次快速更新。团队的思想观念必须实现根本转变：从单一的“项目思维（project thinking）”转向“产品思维（product thinking）”，从一次性的开发与交付，转向打造一个持续演进的“生命力资产（living capability）”，做到“与利益相关者共同构建（building with），而非仅仅为他们构建（not for）”。 ```mermaid flowchart TD accTitle: Feedback Loop and Product Thinking Model accDescr: Diagram showing how continuous feedback drives intentional iteration from internal capability to enterprise scale. subgraph Culture ["思维转变"] A["项目思维 (一次性交付)"] -->|转变为| B["产品思维 (持续演进的生命力资产)"] C["为业务构建 (Building For)"] -->|转变为| D["与业务共建 (Building With)"] end subgraph FeedbackCycle ["持续反馈闭环"] E["系统上线监控"] --> F["收集业务反馈与优先级变化"] F --> G["有意识的迭代 (UI微调/数据更新)"] G --> E end subgraph CaseStudy ["美国银行 Erica 演进路径"] H["技术团队内部实验"] --> I["单一业务单元试用并整合反馈"] I --> J["推广至税务福利等多个业务团队"] J --> K["演变为全行级客户交互助手"] end ``` 美国银行（Bank of America）的虚拟助手 Erica 正是这一理念的绝佳典范。许多人以为 Erica 一开始就是面向终端客户设计的，但事实恰恰相反——Erica 最初完全是为内部员工打造的辅助工具。当时技术团队在为一个业务部门进行原型开发与实验时，它并非什么惊天动地的技术突破，只是一个能够帮到业务团队的实用工具。技术团队在演示和测试过程中与业务部门紧密配合，持续产出结果、收集意见并迅速将反馈融入系统。随后，税务与福利（tax benefit）等其他业务团队也发现了它的价值并提出需求。技术团队通过逐一吸纳各部门反馈、赢得多方支持，最终让这款原本服务于内部员工的工具，演变成为今天千百万客户每天在手机银行 App 中使用的 Erica。甚至直到今天，用户在 App 中使用 Erica 后依然能看到即时反馈入口，这正是美国银行将业务与用户反馈置于核心地位的直接体现。 - **持续维护与监控**：系统交付不是终点，必须持续监控模型准确度并适应业务增删产品等战略变化。 - **敏捷且有针对性的迭代**：避免盲目重构，优先通过 UI 细节改良或数据库字段更新来解决核心诉求。 - **内部孵化到外部赋能**：美国银行 Erica 证明了“内部共建验证 — 跨部门口碑推广 — 最终推向客户”路径的可行性与力量。 --- ### [28:50](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1730s) 全景总结：时序自动化框架的五大基石与行动倡议 演讲最后系统回顾了最初提出的三大核心命题。首先，当前 AI 领域的投资规模与行业紧迫感空前高涨，然而这种紧迫感并未转化为实际的落地成效——业内呈现出“88% 的组织在使用 AI，却仅有 1% 达到成熟落地阶段”的巨大鸿沟。其次，导致这一脱节的核心症结正是“冻酸奶综合征（Frozen Yogurt Syndrome）”，即工具与选项泛滥成灾，却缺乏清晰的落地先后顺序。最后，针对企业如何破局，演讲完整串联了“时序自动化框架（Sequence Automation Framework）”的五大核心步骤： ```mermaid flowchart LR accTitle: Sequence Automation Framework Five Steps accDescr: A five-step sequential framework for data strategy and AI readiness. S1["1. 业务痛点<br/>(聚焦业务阻碍与ROI)"] --> S2["2. 业务语言分类法<br/>(统一指标与术语定义)"] S2 --> S3["3. 翻译层<br/>(双盒模型/技术与业务协同)"] S3 --> S4["4. 运营底座<br/>(坚固的数据管道与基础设施)"] S4 --> S5["5. 基于信任的采纳<br/>(早期共建/反馈闭环/有意识迭代)"] ``` 1. **业务痛点（Pain Point）**：从利益相关者出发，以好奇心主动询问“是什么拖慢了你们的节奏？哪些流程正在出现故障？”。这些未被解决的痛点才是真正的业务机会和投资回报率（ROI）所在，并不需要大张旗鼓地召开正式研讨会才能获取。 2. **业务语言分类法（Business Language Taxonomy）**：技术与业务团队必须共同确立统一的名词与度量定义。明确“客户（Client）”、“消费者（Customer）”与“终端用户（End User）”的具体异同，并清晰定义业务函数的逻辑节点（例如：留存率的精确算法是什么？一笔销售到底是在保单签署时确认，还是在收到首期保费时才算达成？），并将这些标准正式固化为文档。 3. **翻译层（Translation Layer）**：组建由技术主管与业务主管共同领导的联合团队，借鉴星展银行（DBS）成熟的“双盒模型（Two in a Box Model）”。只有当工具构建者与业务使用者使用同一种语言交流时，开发出来的工具才能真正理解业务；翻译层能够确保项目在明确技术局限性的同时，紧跟业务优先级的动态变化。 4. **运营底座（Operating Foundations）**：如同“跑车需要平整公路”的比喻，高级 AI 和自主智能体（AI Agents）必须依托坚实的数据底座与数据管道。如果基础设施尚不健全，应当尽早与高管层展开切实坦诚的对话。 5. **基于信任的采纳（Trust-Based Adoption）**：坚持“与业务共建”的原则，从一开始就引入利益相关者以注入业务上下文——因为更丰富的上下文才能让 AI 发挥更佳性能。不需苛求展示完美无瑕的成果，坦诚展示未完善之处反而能尽早赢得信任与买单；在交付后继续保持顺畅的反馈通道，并进行有针对性的敏捷迭代。 演讲在全场热烈的掌声中结束，演讲者向坚持参与完第二天峰会全程的与会观众表达了感谢与祝贺，并正式开放现场问答互动。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=QjzYEHkJet4&t=4s) 尼莫已经被找到了，我就在这里 — Nemo > [00:04](https://www.youtube.com/watch?v=QjzYEHkJet4&t=4s) 请直接怪 Nemo，不要怪我的公司 — Nemo > [09:39](https://www.youtube.com/watch?v=QjzYEHkJet4&t=579s) 想象一下你走进一家自助冻酸奶店。刚进门时你非常清楚自己想要什么。但走近柜台，你看到了琳琅满目的配料、选择和口味；而在柜台最正中央，赫然写着‘本月限量版风味’。一瞬间，你什么都想来一点，感到不知所措，最终端走了一大杯你最初根本不想要的混合物。 — Nemo > [09:39](https://www.youtube.com/watch?v=QjzYEHkJet4&t=579s) 最新的配料并不意味着适合你的组织 — Nemo > [13:36](https://www.youtube.com/watch?v=QjzYEHkJet4&t=816s) 是什么拖慢了你的进度？哪件事占用了你 4 个小时，导致手头的其他海量任务全被延后？ — Nemo > [25:25](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1525s) 与利益相关者共同构建（Build with），而非单纯替他们构建（Not for） — Nemo > [26:13](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1573s) 从单一的‘项目思维（project thinking）’转向‘产品思维（product thinking）’，从一次性的开发与交付，转向打造一个持续演进的‘生命力资产（living capability）’ — Nemo > [28:50](https://www.youtube.com/watch?v=QjzYEHkJet4&t=1730s) 是什么拖慢了你们的节奏？哪些流程正在出现故障？ — Nemo ## Mentioned Nirmayee (Nemo) Dighe, Delaware Life Marketing, Group 1001, Gartner, McKinsey, Morgan Stanley, Goldman Sachs, DBS (星展银行), HSBC (汇丰银行), Bank of America (美国银行), Erica, ChatGPT ## Video description Nirmayee (Nemo) Dighe - Associate Director, Business Intelligence, Delaware Life Marketing, A Group 1001 Company Most organizations are suffering from what I call Frozen Yogurt Syndrome: too many tools, too many options, and no clear sequencing. In this session, I will explain why AI initiatives stall when data maturity, governance, and stakeholder readiness are ignored. I will introduce my four-step framework for designing a data strategy that enables AI adoption as an outcome of organizational readiness, not as a starting point. Through real-world examples, I will show how to convert stakeholder pain points into functional use cases, evaluate whether a problem truly requires AI, and scale responsibly with measurable impact. If you are responsible for AI, data, or transformation strategy, this talk will give you a practical structure to move from experimentation to sustained business value. [Source](https://www.youtube.com/watch?v=QjzYEHkJet4)

[0:04] Nemo: 尼莫已经被找到了，我就在这里 [0:04] Nemo: 请直接怪 Nemo，不要怪我的公司 [9:39] Nemo: 想象一下你走进一家自助冻酸奶店。刚进门时你非常清楚自己想要什么。但走近柜台，你看到了琳琅满目的配料、选择和口味；而在柜台最正中央，赫然写着‘本月限量版风味’。一瞬间，你什么都想来一点，感到不知所措，最终端走了一大杯你最初根本不想要的混合物。 [9:39] Nemo: 最新的配料并不意味着适合你的组织 [13:36] Nemo: 是什么拖慢了你的进度？哪件事占用了你 4 个小时，导致手头的其他海量任务全被延后？ [25:25] Nemo: 与利益相关者共同构建（Build with），而非单纯替他们构建（Not for） [26:13] Nemo: 从单一的‘项目思维（project thinking）’转向‘产品思维（product thinking）’，从一次性的开发与交付，转向打造一个持续演进的‘生命力资产（living capability）’ [28:50] Nemo: 是什么拖慢了你们的节奏？哪些流程正在出现故障？

[0:04] Nirmayee "Nemo" Dighe: I'm Nemo like the fish. So don't worry I've been found and I'm right here. [0:04] Nirmayee "Nemo" Dighe: the intersection of what's possible and what's valuable. [0:04] Nirmayee "Nemo" Dighe: blame Nemo and not my employer. [1:46] Nirmayee "Nemo" Dighe: How can I use AI? [1:46] Nirmayee "Nemo" Dighe: What else can AI do? [11:37] Nirmayee "Nemo" Dighe: Where are business decisions getting delayed? [11:37] Nirmayee "Nemo" Dighe: What strategic decisions cannot be made due to inaccessible data? [11:37] Nirmayee "Nemo" Dighe: Our customer service reps spend 35 minutes searching fragmented policy files while a client is on hold [21:57] Nirmayee "Nemo" Dighe: two in a box [25:25] Nirmayee "Nemo" Dighe: building for stakeholders to building with stakeholders

[0:04] So today we are going to be talking about why  AI investment is not matching AI adoption and [0:10] I'm going to introduce you to a concept that  I call frozen yogurt syndrome and just wanted [0:16] to introduce myself. I'm Nemo like the fish. So  don't worry I've been found and I'm right here. [0:22] Uh professionally I'm a data and AI strategist.  I sit at the intersection of two very different [0:29] worlds. At one hand, you have the business team  who knows what the business is, what they need, [0:35] what the problems are. And on the other end,  that's the technical team. They know what can [0:41] be built, what's possible, what infrastructure  you need, what architecture you need. So, [0:46] I work at the intersection of what's possible  and what's valuable. And just to get the formal [0:53] disclaimer out of the way, by the way, the views  here are representative of my of my own and not my [0:58] employer. So if you disagree with anything that  I say, please blame Nemo and not my employer. [1:05] Okay. So today we're going to start with three  questions. Number one, what's happening with [1:12] AI right now? Why is that not translating into  adoption? And third is what can organizations [1:20] do differently. Now a quick raise of hands if you  guys sit within the business team or a business [1:27] leader or a business representative. How many  business folks in the room? Okay. Yeah. How [1:33] many technology folks, data, AI, tech teams?  Okay. So we got a good mix of both. So let's [1:42] let's walk through a journey and answer the  first question. What is what's happening in [1:46] the market right now? Let's look at the market  reality. Remember it started with LLMs, chatbots. [1:53] I remember waking up in like 2022. I think it was  like late 2022. I was doing my masters and all of [1:59] a sudden I just got access to chat GBT. I was so  thrilled because not only was it able to code, but [2:06] it was also able to help me with research papers,  summarize informations. That was amazing. Right? [2:14] That's when organizations started experimenting  with AI. The question then was how can I use AI? [2:22] What else can AI do? This is so cool. How do I  interact with it more? Next came co-pilots. This [2:32] is where AI experimentation moved on to a little  more hands-on AI. Organizations started embedding [2:39] AI into their workflows because chatbot were able  to summarize, draft and recommend next steps. And [2:48] then finally came agents something that we are all  talking about today. Something that every vendor [2:55] has talked about. The difference between chatbots  and co-pilots was it started with the human first. [3:05] But with agents, they have a higher level of  autonomy. It starts with the AI first and then [3:12] the AI agent invokes the human whenever required.  So an AI agent is able to do everything a chatbot [3:19] and a co-pilot would, but also executes the  workflow autonomously. Let's look at an example. [3:29] Let's say you are a customer service rep and from  an insurance company you get a client call saying, [3:35] "Hey, my policy payment has been delayed." Now,  you as a rep, you'd go back. Let's say you're [3:41] using a chatbot. Your chatbot would be able to  summarize what's happening. Maybe there's like a [3:46] paperwork issue. Your paperwork is not in good  order. But again, the human here still has to [3:53] go back. They got to find which paperwork it is.  Got to send it back to the client. make sure they [3:59] receive the paperwork and then update the system  and then the payment is issued. With co-pilots, [4:06] it's going to be a step beyond. Co-pilot will  have access to the client policy information, [4:12] previous communication, and co-pilot would be  able to summarize which paperwork is missing and [4:18] probably give you an email saying, "Hey, this  is what I recommend you send to the client, [4:24] which is, hey, this paperwork is not in good  order. please fill it up and that's when the [4:29] payment would get issued. Again, human is still  in control. AI is either answering a question, [4:37] assisting or recommending. But with agents, it's  going to be a very very significant shift which is [4:46] your client will now be talking to an agent itself  and not a human. Your AI agent will summarize all [4:55] the information. Tell your client that hey this  is some paperwork not in good order. You need to [5:00] process it. Once client finishes updating that  paperwork your AI agent will go back update the [5:08] system and the payment will get issued. Remember  human is still not invoked. Pretty exciting and [5:16] pretty scary isn't it? But again let's say if  something falls out of bounds. Let's say the AI [5:22] agent doesn't understand what the client wants.  AI agent will reroute the client back to a human [5:28] but it will be invoked. It will still execute  that workflow and that is the future. Future [5:37] is AI agents and it's here because every vendor  is talking about it. I was attending a session [5:42] today and they introduced a concept of AI native  engineer a super AI agent that orchestrates all [5:51] other AI agents to wipe code and that's the new  software development. So this pressure is real and [5:59] it's real because the market is heavily investing  in AI agents. Don't believe me? Let's look at the [6:06] numbers together. We are in what I call as a  AI gold rush era. Companies are investing in [6:15] AI. Gardner predicts that by the end of 2026,  AI spending would be $2.59 trillion. That's not [6:27] all. Gartner also saw a 47% yearover-year growth  in AI spending. McKenzie also found out that by [6:38] 2025 88% of organizations in United States were  using AI in at least one of their functions and [6:48] the projected AI market value by 2030 is $4.8  trillion. So that explains the urgency. So if [6:58] you feel that in your workplace you're getting  pressurized, you're asked to use AI, believe me, [7:04] your leaders are feeling the pressure too because  vendors are selling it, competitors are talking [7:10] about it, boards discussing about it, and all of  your employees are using it. But these numbers [7:18] explain the pressure. They explain the urgency,  but they don't necessarily explain the adoption, [7:25] now do they? Because let's look at the adoption  number. Now remember that number 88% I told you [7:31] McKenzie said 88% of companies in United States  were using AI by end of 2025. As they go deeper in [7:40] their survey they also found out that only 1% of  organizations out of those 88 had what they call [7:48] as a mature development. McKenzie defines mature  development if there's a business outcome tied to [7:56] your AI use case. If there is real ROI tied to  your use case and that number is significantly [8:03] low, just 1%. That's not all. Gardner also  found out that 50% Gen AI PC's are abandoned. [8:15] The pilot looks good. The demo looks good. But  there is no building. There's no real outcome. [8:23] That's not all. We are also looking at 40 plus%  of all gen AI AI agents project cancellation by [8:31] end of 2027. Now why does this keep happening?  There's two reasons or rather the two fundamental [8:38] reasons I'm pretty sure you know all of  you have heard about in these two days. [8:43] The first is the value gap. Just because you  build something which is technically impressive, [8:49] technically flashy doesn't mean it's tied to the  business outcome. Remember McKenzie's development [8:55] definition, sorry, mature development. Now, if  it's not tied to a business outcome, there is [9:03] no ROI with it. And second is what I call as the  agent gap. Organizations are feeling the pressure [9:10] to use and adopt more AI agents. That's fair. You  saw the urgency. You saw the numbers. However, [9:17] they lack the foundation. Do you have the data  ready? Do you have the architecture? AI agent [9:24] is a very sophisticated AI tool. Do you have  the foundation to build such a sophisticated [9:31] tool? And these are the two challenges. And when  McKenzie and Gartner were trying to understand a [9:39] little bit more about why AI adoption is not  increasing, they interviewed organizations, [9:46] business leaders, tech leaders and they found  a consistent theme come up which was every [9:52] organization felt pressure and they just had a  limited amount of time to get a solutions and [9:59] they were just overwhelmed. overwhelmed with the  number of choices, overwhelmed by number of tools, [10:05] technology, vendor, and they just made a decision.  They picked the one they found was good at that [10:11] time. And think about it, we've all felt that kind  of pressure in some way. Raise your hands if you [10:18] have been to one of those selfserve shops. Yeah.  Okay. Imagine you're in the line and now you know [10:28] exactly what you want. just entering. But now, you  know, you see all the toppings, the choices, the [10:34] flavors, and as you come closer to the counter at  the dead center, you see a board, which is limited [10:41] edition flavor of the month. And all of a sudden,  you kind of want a little bit of everything. You [10:47] feel a little overwhelmed and you end up with  something that you might not want it in the first [10:53] place. That's exactly what's happening in the AI  market and that's what I call the frozen yogurt [11:00] syndrome. So think about it. Companies are feeling  that pressure to make a decision and all of a [11:08] sudden everything is being clumped together. AI,  BI, data analytics, dashboards, co-pilots, models [11:15] and all of a sudden you end up with something  that's not what solves your business problem. and [11:22] agents have become the newest topping. But here's  the thing, newest topping doesn't always mean it's [11:30] right for your organization. So that brings us to  the third part of the presentation, which is so [11:37] what can organizations do differently? I suggest  you adopt a sequence automation framework. It's [11:47] broken down into five steps. The number one  is painpoint literacy. I know we talked about [11:54] or rather throughout these two days you guys must  have heard a lot about tying it back to ROI. What [12:00] does that really mean? It means find opportunity.  Find business opportunity. And that business [12:07] opportunity lies with your business stakeholders.  Go find those pain points. Ask those questions. [12:14] The second is a business language taxonomy. Have  a place of shared definitions because multiple [12:24] business teams might have multiple different  names. Let's say one team calls it client, [12:30] the other says customer, someone else might say  policy holder. And your AI will be as good as the [12:37] data and the context you provide. And that starts  with building a business language taxonomy. But [12:43] now you might tell me, "Hey, Nemo, but here's the  thing. Business and technology don't necessarily [12:49] speak the same language together. So how do I  actually get the two parties involved or multiple [12:55] parties involved and build this business language  taxonomy?" Well, that's you have a translation [13:02] layer for that. Translation layer is an  interpreter layer. It could be a team, [13:07] it could be a person or it could be multiple  persons from both teams coming in together, [13:13] interpreting the needs, speaking both languages.  Again, for the first three, we have still just [13:19] talked about all the pre-work, just making sure we  have the right use case, we have the right people, [13:26] we bring everyone to the table. Step  four, which is the operating foundation, [13:31] is where you actually start building. This is  where you start with your foundation. Remember the [13:36] keynote yesterday which was do you have a strong  foundation and if you don't you have a migration [13:44] coming and then step five is build trustbased  adoption which is build with your stakeholders [13:52] not just for them. Okay. So we are going to go  through all of these five steps and I'm also [13:58] going to show you industry experiences where these  steps have been used by those companies who come [14:05] under those 1% mature development. Okay. So first  we have painpoint literacy which means starts with [14:15] your stakeholders. So your stakeholder could be  a seuite leader, it could be a business leader, [14:22] it could be your colleague or simply someone  you've seen work a lot with on the business [14:28] cases because a lot of times I've noticed folk  starts with hey where can we use AI agents but [14:36] that's still a technology first question. The  question should be what processes are broken? [14:41] Where is business decision getting delayed? What  is business painoint? What are some decisions [14:47] that you want to make but you cannot because you  just don't have access to that data? And finally, [14:53] what's what's taking someone 3 hours while that  task should just be done in 30 minutes. So start [15:00] with your stakeholders. And honestly, it doesn't  have to be like a formal workshop or a meeting. [15:07] Sometimes you just got to be curious. Reach out  to your stakeholders. Reach out to your colleagues [15:11] and just ask them, "Hey, what's what slows  you down. What is that one thing that's taking [15:17] you 4 hours and that's why all the other billion  things on your plate gets pushed?" And believe me, [15:23] when you ask these questions, these questions  open floodgates. People will tell you exactly [15:28] what processes are breaking, what's frustrating,  and what's keeping them from being productive. [15:34] And that's your opportunity. Now you take  these opportunities and convert them into [15:41] business opportunities. These are your problems.  These this is where you could potentially build [15:47] an AI solution. But as you start gathering  these pain points, you got to make sure that [15:54] you differentiate between a recommendation and  an actual pain point. Someone might say, "Hey, [15:59] um, we should use AI agents for customer care."  That's great, but that's still a recommendation. [16:06] If someone says, "Hey, our customer care rep  is spending 35 minutes just trying to find [16:12] policy information while the client is on the  other line." Now, that's a painoint. That's a [16:17] challenge worth exploring. And that's exactly  what happened with McKenzie. Imagine this. [16:25] McKenzie had a lot of cases where a client would  call the financial advisor and ask them questions. [16:32] Now McKenzie had sorry Morgan Stanley had all  of this information but it was just fragmented [16:39] between different data sets between different  units between CRM and financial advisor when [16:46] they received the call from the client they would  just go hey I'm sorry let me put you on brief [16:51] hold and try to find that information for you and  that's not really the client experience you want [16:58] to provide and neither did Morgan Stanley so they  built something called as an AI assistant. Now, [17:04] this AI assistant sat on top of all of their  databases, sat on top of all of their internal [17:10] files and the CRM data. So, now when a client  would call them, a financial advisor did not [17:17] have to scramble and find it in five different  place, but just go to the chatbot and say, "Hey, [17:23] this particular person is on the other line.  Where can I find this information? What's really [17:28] happening? What's the current status?" And this  led to a 98% adoption in finan between financial [17:36] advisors. With that, let's talk about step two,  building the business language taxonomy. Now, [17:47] have you ever been in situations just like raise  your hands or not if you have, but let's say [17:52] you're copied on an email chain and you have  no idea what's going on and all of a sudden, [17:57] you know, you just call the other person,  go like, "Hey, what is this about? Can you [18:02] please give me context?" And that 5minut call  provides you with so much more context than [18:08] that email chain is. Ever that ever happened to  you guys? Yeah, I see a few nods. So as humans, [18:15] if we actively look for context, we can't really  expect an AI agent to know everything by itself, [18:22] right? And that's exactly what's happening. As you  start building AI solutions, building AI agents, [18:30] you got to make sure that the people who are  building these tools understand and speak the same [18:36] language as the business as your end user. Because  remember, your end user is going to use the tool. [18:43] And if they don't get that buy in, if they don't  really adopt that tool, it's not going to last and [18:49] it's not going to get you that ROI. And that's  why you need a shared language, which is where [18:55] the business taxonomy comes in. This is where  you get together define common terms. Remember [19:02] business units may have different terminologies.  Let's say marketing one might call it client, [19:08] operations might say end customer, finance might  say policyholder, someone else might say borrower. [19:15] But all of these terms mean the same thing.  And that's what should come under this business [19:20] language taxonomy. Common terms, definitions,  ownership in workflow context. And that's [19:28] exactly what Goldman Sach did. The Goldman Sachs  like every other team had a very crucial problem [19:36] that there was one technical team working across  multiple business user. The business users would [19:42] come to the technical team and ask them questions  like where can I find customer information? Where [19:48] can I find client information? And there was  this back and forth. So they created a business [19:53] language taxonomy together. So now when a business  end user had a question about a client or a policy [20:00] holder, they would rather come to the Goldman  Sach platform as the tool right there and there [20:07] instead of going to the technical teams. And this  tool showed them the lineage, showed them where [20:14] the data lived, how it was accessed, how it was  updated, and what the other teams were calling it. [20:22] That brings us to step three because business and  technology don't often speak the same language [20:28] together. And that's why you need someone called  as an translator or an interpreter layer because [20:36] this interpreter layer is who are who who are  going to control step one and step two. They [20:42] are going to connect with your stakeholders. They  are going to connect with your business users and [20:47] identify those pain points. They are the ones  who are going to help put that business language [20:52] taxonomy together. Not only that, but they're  also going to identify what process is this. Is [20:58] this really an AI challenge? Is this really a BI  issue? Is this what another dashboard can fix? Or [21:04] is this another Python code can fix? They're going  to identify opportunity and tie it back to real [21:11] tools. And let's say if the answer is, hey, this  is a good AI agentic solution. Now they're going [21:17] to work with business and define what kind of  autonomy can we give this tool. What kind of read [21:23] write context, what kind of readrite access are we  going to give this tool? And if this agent fails, [21:30] who's going to be accountable for that? So they  keep the business and the technical teams aligned [21:37] and that's what DBS did. So DPS found this  ongoing challenge where the business users [21:45] would go ahead business units would connect  with the technology teams they would give [21:49] them the project requirements but then over time  both teams kind of drifted off. So DBS came up [21:57] with a two in a box model where every platform  that DBS built was now jointly led between a [22:05] business and a technology leader. The business  leader here spoke both languages. So they were [22:12] able to interpret the needs of the business but  also interpret the technical questions. So they [22:18] were at the intersection of what's valuable and  what's possible. They were able to understand [22:24] why are the technical teams asking us about  infrastructure roll back processes governance [22:29] and were able to translate and bring it  back and weave into business decisions. [22:34] They were also able to understand changing  business priorities. They were able to collaborate [22:40] with the technical teams with the technology  leader and made sure that the solution that [22:44] the technology team was building was relevant  and still solving the same business outcome. [22:53] And that brings us to step four. Now we're  getting into the building of your tool. Let's [22:59] say you did step one, step two, step three. you've  identified that hey this is a good opportunity to [23:04] build an AI solution. Now step four is more of  an infrastructure check because building an AI [23:14] solution is a lot like driving a car. You may have  the most luxurious sophisticated car but with cars [23:22] you also need a couple things. First of all,  you need roads. You need fuel. You need traffic [23:28] safety measures. And you need to know who has  rideway because if you don't know these, if you [23:34] don't have these things, no matter how luxurious  your car is, you're just not going to be able to [23:40] take it for a drive. And that's exactly how it is  with AI. You got to build a strong foundation. You [23:46] got to make sure your pipelines are ready, your  data is ready. Is your data all in one house or [23:52] is it siloed in like 25 different places? Is the  governance there? What about monitoring accuracy [23:59] roll back processes? There comes a significant  time to just check if you have the foundation [24:07] ready to build something as sophisticated as an  AI agent. And again, that is exactly what DBS and [24:14] HSBC did. These DPS and HSBC spent about a year  year and a half just building foundation. They [24:23] did not build any AI solution but just focused  on the foundation. Went through a couple of [24:28] migrations and the result was fascinating because  DBS saw one 1,500 plus models used across 370 plus [24:40] use cases with a strong foundation. That's not  all. HSBC wanted to use AI to detect financial [24:47] crime but unfortunately they figured out that  they could not build a system as strong and [24:54] efficient because they lacked the foundation. So  they spent and invested in building a foundation [25:00] and the result was tremendous because now their AI  financial detection financial crime detection rate [25:08] increased up to four times and that's not all but  it also reduced 60% of false positive. So you see [25:16] the strong foundation and the result it yields  to. And finally, that brings us to step five, [25:25] building trust through continuous learning.  Because remember, this is where you're building [25:31] with your stakeholder, not for your stakeholder.  Your stakeholder is the one who are actually going [25:36] to use the tool. They have the business context.  So start looping them in from step one. Don't show [25:43] them the demo, disappear for 6 months, and then  show them the system. Rather, loop them in from [25:48] day one. And it could be something of an Excel  file for first week like hey this is what we have [25:54] in the second week maybe it could be a broken UI  demo but loop them in from the start because they [26:01] have that business context which you cannot just  replicate and your tool needs to understand that [26:07] particular context. So the earlier you start  looping them in the more context you're going [26:13] to have the more buy in you're going to have  in earlier stages and the more adoption you're [26:18] going to have. And it also means after you build  a system, after you build a tool, after you launch [26:25] the tool, make sure you're still keeping in touch  with them. Make sure you monitor it. You monitor [26:30] it for accuracy, for feedback, and business  priorities change. Let's say sometimes someone [26:36] might launch new product, someone might shelf a  new product, and you could make those changes in [26:42] your tool. So build those feedback loops. Make  sure your stakeholders are able to tell you [26:48] what's working and what's not, what they're able  to trust and what they aren't. And finally, when [26:54] you get these feedbacks, iterate intentionally.  You can either start from scratch, but it's not [27:01] required every time. Sometimes a small tweak in  the UI or a small tweak in the database, a quick [27:08] update is what stakeholders need. So work with  them. Start thinking or and shifting your ideology [27:16] from a project thinking to a product thinking  from a one-time development and deployment to [27:23] building a living capability building with your  stakeholders and not for your stakeholders. And [27:30] that's exactly what Bank of America did. Are you  guys familiar with Erica on your apps if you guys [27:37] are using? Yeah, I see. Couple nods. I I found  this case study and I was so fascinated by it. [27:43] Turns out Erica was never meant for customers.  It was meant for employees. Bank of America [27:49] rolled out Erica for one of its business units  and it wasn't a very very technical impressive [27:57] discovery but this was just something helpful for  the team. The technical team were demoing it. They [28:03] were experimenting with it. So they worked with  the business team, produced this results, shared [28:08] it with the business team, got feedback from them,  actually incorporated it and turns out that this [28:15] one was something that also the tax benefit team  needed and eventually one by one they got buyin [28:22] from several business teams. They incorporated  their feedbacks and today Erica for employee is [28:29] also Erica for customers. [snorts] So you see  the power of feedback and if you go into those [28:36] uh into your profile app there's also a feature  where you can give feedback after using Erica. [28:44] That's the power of feedback and that's why people  or business users are taking that feedback really [28:50] seriously. Okay, I know we covered a lot today.  We were going to start with three questions and we [28:57] covered them all. We started with what's happening  in the AI right now. We looked at the investment [29:02] numbers. We saw the urgency. But we also saw  that urgency was not really translating into [29:09] AI adoption. Remember the 88% organizations using  AI but just 1% mature development. Then we saw why [29:19] it's not translating into adoption. Remember  the frozen yogurt syndrome. And then finally [29:26] we also saw what can organizations do differently  which was the sequence automation framework which [29:34] starts with five steps. Number one the pain point.  Start with your stakeholder. Identify who your [29:42] stakeholder is. Ask them questions. Again doesn't  have to be a formal workshop or a formal meeting. [29:48] Just be curious and ask them what slows you down.  What processes are breaking? because that's your [29:54] business opportunity. That's where your ROI lies.  Second is business language taxonomy. Work with [30:03] business and technical teams and define common  definitions, common terms. Define what does it [30:10] mean to be a client, a customer, an end user, or  do they mean the same thing? And also go a step [30:16] beyond that. Define functions. Define what does  it mean to be a retention rate. Define when does [30:22] a business actually mean when a sale will sale  is done. Is it after the policy is signed or is [30:29] it after you receive the initial premium? Make  those definitions formalized in a document. And [30:37] if you need to do those things, that's where your  translation layer comes in. This is a joint team [30:44] led by technology leader and your business leaders  together. remember the two in a box model by DBS [30:51] and that worked out for them. Use that. Make sure  your business and technology leaders are speaking [30:59] same languages because only and only if the people  who build the tool are speaking the same language [31:05] as your end stakeholder, that's when your tools  going to speak the same language. Make sure and [31:11] to leverage your translation layer so that they  can keep the projects aligned both technically [31:17] understanding the technical limitation and also  understanding and translating the business's [31:23] changing priorities. And then fourth you have  operating foundations. Remember the car analogy [31:29] the car and the roads that you need AI and AI  agents the same way. Make sure you have a really [31:36] strong foundation. Make sure you have strong  pipelines and if not those are some conversations [31:44] worth having with your leaders. And then finally,  it's the trustbased adoption where you're working [31:52] with your business users and not for your business  users where you're looping them in from the start, [31:57] getting that context from them, giving it to  your tool because again AI will function better [32:03] if you give it more context and that context  comes from your business stakeholders. Again, [32:08] doesn't have to be really perfect. Show them the  imperfections. Show them things are not perfect [32:15] and that's how you get their buy in earlier.  That's how you get your adoption rates higher. [32:20] Build feedback loops even after you're done with  the project. Make it easy for your stakeholder [32:27] to tell you what's working and what's not.  And then finally, iterate intentionally. Not [32:34] everything needs a rebuild. Sometimes it could  be an update to the database, just a tweak to [32:38] the UI. So make sure you're leveraging this in  this framework as you go back. And I know that [32:47] was a lot. So I'm open to questions. Thank you  so much again for being here and congratulations. [32:53] You survived day two again. So huge round  of applause for all of you guys. [applause]