2026年4月29日，全球第二大资产管理公司Vanguard在AWS官方博客发布了一篇技术文章，但读起来更像一份诚实的失败报告——以及从失败中提炼出的8条生死原则。

这篇文章没有用”AI彻底改变了我们的公司”这类套话开场。它用的是一个令人不舒服的场景：当Vanguard的金融分析师需要查询任何复杂数据集时，哪怕是一个看似简单的问题——”上季度哪类基金的客户流失率最高？”——都需要先找到懂SQL的工程师、等待数据团队排期、收到查询结果，这个周期通常以”天”为单位计算。

在一个金融市场每秒都在变化的行业里，这意味着什么，不言而喻。

Vanguard拥有超过8万亿美元的资产管理规模（数据来源：Vanguard官网，2026年），是全球最大的共同基金公司之一。其创始人John Bogle于1976年创立了全球第一支面向散户的指数共同基金（Vanguard 500 Index Fund），将学术界的指数投资理念第一次商业化地带给了普通投资者。这样一家在金融行业具有标志性地位的机构，在2026年公开分享一个”我们踩了哪些坑、怎么解决的”故事，本身就是一个信号——企业AI落地，已经进入了去除幻觉、回归工程现实的阶段。

AI项目的第一个谎言：这是一个模型问题

Vanguard的Virtual Analyst项目团队最初的假设，和绝大多数正在推进企业AI的公司一样：找到足够强大的基础模型，训练它理解金融查询语言，问题就解决了。

这个假设在工程实践中被迅速证伪。

“随着Virtual Analyst项目推进，团队发现构建有效的对话式AI不是机器学习挑战——而是数据架构挑战，”Vanguard工程师Ravi Narang、Rithvik Bobbili、Jiwon Yeom和Matt Lanza在AWS博客中写道。”即使是最先进的基础模型，也需要适当的数据基础才能可靠地工作。”

这句话的信息量极大。它意味着：企业AI项目失败的根本原因，通常不是模型不够好，而是数据不够”AI-ready”。

这个认知转变不是Vanguard独有的。麦肯锡全球研究院2024年发布的《The state of AI in 2024》报告指出，在已部署AI的企业中，数据集成和数据质量问题是最常被提及的扩展障碍——这与Vanguard团队的工程发现高度吻合。这里存在一个关键的语义混淆：数据的存在与数据的可用，是两个完全不同的概念。

金融服务行业的数据复杂性尤为突出。以”客户终身价值”（Customer Lifetime Value）这个指标为例：在一家典型的资管公司内部，零售银行部门、机构业务部门和财富管理部门对这个指标可能有三种不同的计算方式，基于三套不同的基础假设。当一个AI系统被要求”分析客户终身价值”时，它面对的是一个语义上模糊的问题——而语义上的模糊，会直接导致技术上正确但业务上错误的输出。

Vanguard的独特之处在于，他们没有在”模型不够好”这个错误诊断上停下来，而是系统化地拆解了”AI-ready数据”究竟意味着什么，并将其提炼成可操作的8项原则。

8项原则：金融AI落地的真实配方

Vanguard提炼的8项原则，不是随机排列的清单——它们有内在的架构逻辑：前4条解决”数据知道什么”（语义和治理层），后4条解决”数据有多可靠”（质量和组织层）。两个层次共同构成了一个可以被AI系统有效使用的数据基础。

原则一：明确数据产品与运营模型

在Vanguard的框架中，每一个关键数据资产必须有明确的双重所有权：业务负责人（对业务目标和业务语义负责）和技术负责人（对数据质量和技术实现负责）。

这不是一个模糊的”谁都负责等于谁都不负责”的安排——而是书面化的责任分工，包含数据新鲜度的SLA（服务级别协议）、协调容差标准，以及对下游使用者的支持模型。关键数据资产的业务和技术负责人，需要在文件中明确写出各自的职责边界。

这一原则的背后逻辑：AI系统需要”知道”某个字段的业务含义，而这个含义只有真正使用它的业务团队才能定义清楚。没有双重所有权，数据资产就像一个没有说明书的精密仪器——功能存在，但无法被正确使用，也无法在使用出错时找到负责任的人。

→ 所有权确立之后，接下来的问题是：谁有权访问什么，如何保证安全？

原则二：提前建立治理与安全措施

Vanguard在Virtual Analyst项目启动之初，就让合规和安全团队参与其中，而不是在原型做完之后才去补充安全要求。这个顺序至关重要，它带来了完全不同的项目结果。

他们实施的具体措施包括：企业级身份管理、基于角色的数据访问控制（RBAC）、查询级别授权、数据保留策略，以及所有授权事件的日志记录（以满足金融行业的监管要求）。在技术实现层面，行级（Row-Level）和列级（Column-Level）安全控制根据数据敏感度动态实施，将现有的数据访问策略映射到新的AI系统中。

对于金融行业而言，”移动快打破东西”（Move Fast and Break Things）从来不是选项。监管合规是金融AI项目中最刚性的约束。Vanguard选择将合规团队从第一天起就纳入项目，而不是在原型阶段结束后才去”做合规审查”——后者往往意味着大规模返工，甚至整个项目的搁置。

→ 安全边界划定之后，下一个问题是：AI如何理解数据的含义？

原则三：构建统一技术与业务语境的元数据目录

Vanguard将这一原则描述为整个AI架构的”控制平面”（Control Plane）。这是一个将两种截然不同的元数据类型统一整合的系统：

技术元数据（由数据工程师和数据管理员定义）：

  • 表结构和列描述，包含数据类型
  • 跨转换的数据血缘（Data Lineage）
  • 同义词和分类指标
  • 数据集之间的关联关系映射

业务元数据（由业务用户和领域专家通过协作治理流程贡献）：

  • 特定属性的业务定义和规则
  • 领域特定术语和本体论
  • 业务所有权信息
  • 使用场景和上下文

为什么同时需要这两种元数据？因为AI系统在生成SQL查询时，需要同时理解两件事：这个字段在技术上是什么类型（技术元数据），以及这个字段在业务上意味着什么（业务元数据）。大多数企业的技术元数据是相对完整的，但业务元数据几乎是空白的——这就导致AI生成的查询”技术上正确但业务上错误”。

Vanguard的建议：从使用最频繁的数据集开始，系统化地补充技术元数据，然后逐步扩展到其他数据源；对元数据进行版本控制，并持续度量映射精度以维护可发现性。

→ 目录记录了业务定义，但如何让AI系统将这些定义转化为可执行的查询逻辑？

原则四：实现语义层以落实业务元数据

语义层是将原则三中定义的业务元数据”操作化”的执行层。它将复杂数据结构转换为用户友好的格式，把业务定义、规则和本体论（Ontologies）翻译成可执行的逻辑，标准化组织定义关键指标及不同数据元素之间关系的方式。

以Vanguard的具体实现为例：他们的语义层在不同部门和系统之间维护”客户终身价值”（Customer Lifetime Value）的统一定义——通过落实业务用户所定义的业务规则来实现。有了这个语义层，无论哪个团队的分析师提问，系统计算”客户终身价值”时使用的是相同的公式和相同的假设。

这消除了一个在大型金融机构中极为普遍、又极为昂贵的问题：同一个指标，在不同部门的报告中呈现不同的数字——而每个部门都坚持自己的数字是”正确的”。这种数字不一致性不仅浪费大量时间在内部争议上，在面临监管审查时还可能带来合规风险。

语义层的实现方式：与业务利益相关者协作，记录组织最常用的20个核心指标，包含其精确定义和计算方法，然后将这些定义转化为可执行的语义层逻辑。

→ 前4条原则解决了”语义”问题。现在转向”质量”问题：AI如何知道它的输出是正确的？

原则五：开发Ground Truth示例库

这是Vanguard分享的最具操作性的原则之一。他们构建了一个包含超过50个问题-SQL对（Question-to-SQL Pairs）的示例库，用于服务三个不同的技术目的：

  1. Few-shot提示：作为AI模型的上下文示例，帮助模型理解”这个领域的用户实际上如何表达问题”
  2. 评估基准：测量AI系统的查询准确度，量化性能改进
  3. 对抗性测试集：测试边界情况和错误查询，发现系统弱点

如何构建有效的示例库？Vanguard的建议是：收集最终用户实际提出的问题（而非工程师假设的问题），将其转换为经过验证的SQL查询，然后使用这些真实问题-答案对来训练和评估系统。

这个”真实用户问题”与”工程师假设问题”之间的差距，在金融行业尤为显著。分析师的实际查询语言高度依赖领域术语、行业缩写和内部约定——这些都是工程师在设计系统时往往意识不到的隐含假设。

→ 示例库解决了”准确性基准”。下一步：如何系统性地保障数据本身的质量？

原则六：建立数据质量框架

一致的质量度量是AI系统可靠性的基础。Vanguard实施了7个核心数据质量维度：完整性（Completeness）、及时性（Timeliness）、准确性（Accuracy）、有效性（Validity）、一致性（Consistency）、唯一性（Uniqueness）和完整性（Integrity）。

但更重要的是他们的操作方式：针对关键指标构建自动化数据质量检查；将质量评分与数据产品的业务负责人关联（而非与技术团队关联）；将质量指标纳入数据产品的SLA中，作为可度量的承诺。

这将数据质量从一个”技术问题”转变为一个”业务问题”——由真正关心数据质量后果的人来负责，而不是由”维护数据管道的工程师”来负责。这个责任归属的转变，通常比任何技术手段都更有效地提升数据质量。

→ 质量框架解决了”数据的可信度”。下一步：选择什么样的技术平台来承载这一切？

原则七：设计AI-Ready的技术架构

Vanguard的AWS技术栈选择反映了金融服务行业的特殊要求。核心服务包括：

  • Amazon Bedrock：为自然语言理解提供基础模型访问
  • Amazon Bedrock Guardrails：保护Vanguard敏感金融数据的AI输入/输出安全过滤
  • Amazon Redshift：集中式数据仓储，作为金融分析的主要数据源
  • AWS Glue：数据目录构建和ETL（提取-转换-加载）作业，整合来自多个源系统的数据
  • Amazon ECS：可扩展的容器计算基础设施
  • Amazon DynamoDB：对话持久化存储（低延迟、水平可扩展架构）
  • Amazon S3：对象存储
  • Amazon SageMaker：模型实验和评估平台

这个技术栈的选择有其明确的内在逻辑：金融服务行业对安全合规的要求极为严苛。AWS的安全和合规特性（包括SOC 2、ISO 27001、PCI DSS等认证，以及针对金融服务的专项合规框架）符合Vanguard作为受监管金融机构的要求，这是选择AWS作为AI基础设施的核心理由之一。

值得注意的是，架构图在文章中被明确标注为”特定实现，应被视为说明性而非规范性”——这是一种难得的技术诚实：Vanguard的架构是Vanguard自身需求的产物，而不是放之四海皆准的最佳实践。

→ 技术平台选定之后，最大的挑战往往不是技术——而是人。

原则八：打破数据孤岛的组织变革

这是Vanguard在博客中特别强调的”协作命令”（Collaborative Imperative），也是8项原则中最难以复制的一条。

构建Virtual Analyst要求一些大型组织难以实现的东西：让传统上相互隔离的团队真正协同工作。Vanguard将5类截然不同的职能团队整合到一个跨职能运营模型中：

  • 数据工程师：理解技术基础设施的能力边界
  • 业务分析师：了解金融指标的语义含义和使用场景
  • 合规官员：确保监管合规要求被正确实施
  • 安全团队：建立数据访问和保护机制
  • 业务利益相关者：提供真实使用场景和需求反馈

没有这种跨职能合作，就没有清晰的所有权模型、语义定义和质量标准——而这些恰恰是AI系统可靠工作的前提。

Vanguard的团队还发现了一个意外的收获：Virtual Analyst项目不只是交付了一个AI应用，它还成为了建立新流程和新框架的催化剂——这些流程和框架带来的组织价值，远远超过了最初的AI用例本身。当你被迫明确”谁拥有什么数据、这个数据意味着什么、它的质量如何保障”时，你实际上是在修复一个大型企业长期以来存在的系统性隐患。

结果：数天变成数分钟

所有这些原则的最终呈现，是一个可量化的业务成果：金融分析师的数据查询响应时间从数天缩短至数分钟。

这不是模糊的”效率提升”，而是一个量级的跃升。在原来的工作流程中，一个复杂查询需要：找到具备SQL能力的技术人员→提交查询请求→等待数据团队排期（可能队列中有数十个请求）→等待查询执行和结果验证→接收最终结果。整个过程以天为单位，而且高度依赖技术人员的可用性和时间安排。

现在，业务分析师可以用自然语言直接提问，系统在分钟级别内返回准确的业务洞察。不需要SQL能力，不需要等待技术团队，不需要在一个问题等待回答的同时失去分析的时机。

更关键的是，这种效率提升不是在牺牲准确性的前提下实现的。Vanguard通过语义层、元数据目录和Ground Truth示例库的组合，确保了AI生成的查询在业务语义上是准确的——这在没有这些基础设施时，往往是无法保证的。

值得关注的是，Vanguard在AWS博客中还特别强调了一个通常被忽视的效益类别：基础设施的外溢价值。Virtual Analyst项目为了使AI正确工作而建立的元数据目录、语义层、质量框架和跨职能协作模型，其价值已经远远超出了这个AI应用本身。这些基础设施现在可以服务于公司内部任何未来的AI应用，也可以改善现有的BI报告、数据分析和决策支持流程。

换句话说，Vanguard为Virtual Analyst投入的不只是一个AI项目的成本——而是在构建一个使整个企业数据基础设施对AI友好的能力平台。这个平台一旦建立，每一个后续的AI应用都可以以更低的成本、更高的速度和更好的可靠性来落地。这才是Vanguard选择在2026年公开分享这段历程的深层原因：不是炫耀一个AI应用的成功，而是提供一个企业级AI能力建设的框架。

谁能复制这条路径？

在评估Vanguard经验的可复制性之前，有必要建立一个坐标系：Vanguard是一家拥有超过5000名技术员工、管理全球8万亿美元资产的顶级资管机构。它的数据基础设施积累了数十年，它的组织文化以数据驱动决策著称，它的所有权结构（非外部股东所有）使长期投资变得更容易——这些条件的组合，在金融行业是极为罕见的。

大型银行（摩根大通、高盛等）：具备类似的技术实力和数据资源，但面临更强的监管约束和更复杂的业务线（零售、投行、资管并存），跨业务线的元数据统一是更大的挑战。数据孤岛的形成往往有监管隔离的合理理由，而非单纯的组织政治问题。

中型资管机构（管理规模100-1000亿美元）：具备意愿，但通常缺乏专门的数据工程团队。8项原则中的前4条（语义层相关）需要大量的一次性投入；Ground Truth示例库的构建需要持续的业务用户参与，这对于人员精简的中型机构是真实的挑战。

亚洲金融机构：面临额外的数字化分层问题——许多机构在核心数据基础设施上仍在运行20-30年历史的遗留系统，在这些系统上构建AI-ready的元数据层需要先解决更基础的数据现代化问题。

因此，Vanguard的经验对不同规模机构的参考价值是不同的：大型机构可以参考完整路径，中小型机构可以从最关键的单点开始（通常是原则三：元数据目录），而不必一次性完成所有8项原则。

第三层洞察：大多数AI项目在错误的位置寻找原因

理解Vanguard的案例，需要翻越一个最普遍的认知误区。

企业在AI项目失败后，最常见的第一反应是：”也许我们需要一个更好的模型”，或者”也许我们需要更多算力”，或者”也许我们需要用更新的技术”。这三种反应都指向了技术层面的解决方案。

但Vanguard的经验——以及越来越多企业AI落地实践的共识——指向了一个不同的方向：AI项目的最大瓶颈，通常在模型之前，在技术选型之前，在算力配置之前。

具体来说，它在于数据的”AI可用性”（AI-Readiness）：

  • 这些数据是否有清晰的业务语义，还是只有技术元数据？
  • 是否有统一的术语定义，还是每个部门用自己的语言讲自己的故事？
  • 是否有足够的示例让模型理解”业务用户实际上如何表达问题”？
  • 数据质量是否被系统化地度量和保障，还是靠工程师的经验判断？
  • 数据的所有权是否清晰，还是处于”大家都负责等于没人负责”的模糊地带？

当这些条件不满足时，再强大的前沿模型——无论是OpenAI的GPT系列、Anthropic的Claude系列还是Google的Gemini系列——都无法产生可靠的业务价值。它们会生成”技术上无懈可击但业务上完全错误”的输出——而这种错误往往比没有AI更危险，因为它以专业的外表呈现了错误的结论。

这个洞察的战略价值在于：它将”AI转型”的成功路径从”选择正确的模型”重新定向为”建设正确的数据基础”。这两件事的投资回报率、时间线和失败模式都完全不同。前者可以在几周内完成（购买API访问权限），后者需要数个月到数年的系统性工程投入。但前者在后者没有完成时产生的价值，往往接近于零。

两种对立的视角：这个案例值得信任吗？

任何理性的读者都应该带着批判性眼光阅读Vanguard的这篇文章。

乐观视角认为：Vanguard的案例证明了企业AI不是泡沫。当数据基础设施准备充分时，AI应用可以产生真实可量化的效率提升（数天→数分钟），并且这种提升可以通过系统化的原则在其他企业复制。这是一个来自全球顶级金融机构的可信实证。

批判视角必须指出：Vanguard和AWS之间存在明显的商业利益关系——这篇文章发布在AWS官方博客上，作者包括Vanguard工程师和AWS工程师的联合署名，是一篇典型的由云服务商主导的客户案例研究。其中的核心量化成果（”从数天缩短至数分钟”）来自自我报告，而非独立第三方审计。

更深层的问题是：Vanguard的案例高度特化。全球第二大资管公司拥有数十年积累的金融数据基础设施、Vanguard特有的以数据为核心的企业文化，以及其独特的公司所有权结构——Vanguard由基金持有人拥有，而非外部股东，这使得长期投资和跨部门协作比在典型的上市公司中更容易实现（没有季度业绩压力驱动的短期主义）。

打破数据孤岛、建立跨职能所有权模型、维护持续更新的语义层……这些在技术上是可行的，但在组织政治上面临的阻力，对于大多数中小型金融机构而言可能是压倒性的。Vanguard能做到，部分原因在于其体量足以支撑这种系统性投入，部分原因在于其组织文化，部分原因在于其不受外部股东短期回报压力影响的治理结构。这些条件的组合，在金融行业中是相当罕见的。

三大潜在风险：Vanguard没有说完的故事

除了上述批判视角，还有三个在原文中未被充分讨论的系统性风险，对于计划跟随这条路径的企业而言是不可忽视的：

风险1：AWS供应商锁定

Vanguard选择了高度集成的AWS全栈技术方案（Bedrock + Redshift + Glue + ECS + DynamoDB + SageMaker）。这个选择在当前状态下性能卓越、安全合规，但也意味着显著的供应商锁定风险。如果未来AWS调整定价、服务条款或区域政策，Vanguard迁移到其他云平台的成本将是可观的——金融行业的监管合规性进一步增加了迁移的复杂度。跟随这条路径的企业，需要在架构设计阶段就考虑抽象层（API层）的设置，以保留未来多云可能性。

风险2：AI幻觉在金融场景的特殊危险

文章描述的系统允许业务分析师用自然语言提问，并由AI直接生成SQL查询进行金融数据分析。在金融决策场景下，AI幻觉（即模型生成看起来合理但实际错误的输出）的危险性被显著放大——一个错误的投资组合分析可能导致数亿美元的损失决策。Vanguard提到了Bedrock Guardrails和Ground Truth示例库作为保障，但对于AI输出的人工审核机制和错误检测流程，文章着墨不多。这是金融AI部署中不能被技术工具完全替代的人工监督层。

风险3：监管合规的动态性

2026年，全球金融监管环境正在快速变化。欧盟AI法案（EU AI Act）将AI在金融领域的高风险应用纳入严格监管，美国SEC和FINRA也在加强对AI辅助投资决策的监管要求。Vanguard为Virtual Analyst建立的合规框架，是基于2026年4月的监管现状设计的——而监管要求的持续变化，意味着企业需要将”监管合规的可维护性”（而非只是”初始合规性”）内置到AI系统的架构设计中。今天合规的架构，三年后可能需要显著调整。

为什么这个案例在2026年的意义不同于以往

在AI应用的早期阶段（2023-2024年），大多数企业AI项目是”原型驱动”的：先做一个让高管印象深刻的演示，然后再考虑如何扩展到生产环境。原型可以用”精挑细选的好数据”运行，可以在受控条件下展示完美的结果。

2026年，这个阶段已经结束。企业领导层普遍经历过”原型成功→生产失败”的循环，投资者、董事会和业务领导者现在都在问一个不同的问题：我们在AI上的数百万美元投入，什么时候能产生可量化的ROI？

Vanguard的案例之所以在这个时间点具有特殊意义，是因为它提供了一个从”演示成功→生产可靠”这条路径的清晰工程蓝图——而不是另一个”AI很厉害”的宣传叙事。它承认了实施的复杂性（数据架构挑战、组织变革挑战），并提供了具体可操作的原则，而不是”全面拥抱AI、加速数字化转型”这类对实践没有指导意义的方向性建议。

全球拥有超过8万亿美元资产管理规模的Vanguard，选择在2026年4月公开分享这个历程，本身就是一个信号：企业AI落地的竞争，已经从”谁先用AI”进入”谁用AI用得对”的新阶段。

而”用得对”的真正门槛，很可能不是更好的模型——而是更好的数据。

参考资料

  1. Ravi Narang, Rithvik Bobbili, Jiwon Yeom, Matt Lanza - “Building AI-ready data: Vanguard’s Virtual Analyst journey” - AWS Machine Learning Blog, 2026年4月29日
    https://aws.amazon.com/blogs/machine-learning/building-ai-ready-data-vanguards-virtual-analyst-journey/

  2. Vanguard官方网站 - 关于Vanguard公司及资产管理规模信息
    https://investor.vanguard.com/

  3. McKinsey & Company - “The state of AI in 2024” - McKinsey Global Survey
    https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

  4. Amazon Bedrock - AWS基础模型服务产品页
    https://aws.amazon.com/bedrock/

  5. Amazon Bedrock Guardrails - AI安全过滤服务
    https://aws.amazon.com/bedrock/guardrails/

  6. EU AI Act - 欧盟人工智能法案（高风险AI分类包括金融服务领域）
    https://artificialintelligenceact.eu/