原始标题: How Open Context Layers Help Enterprises Build, Govern, & Scale Agentic AI - with Prukalpa Sankar of Atlan

发布日期: 2026-01-08 | 来源频道: @ai-in-business

📝 深度摘要

1. 核心信息与行业纵深

受访嘉宾：Prukalpa Sankar | Atlan 联合创始人

Atlan 是一家专注于数据治理与 AI 上下文层的 enterprise SaaS 公司。Sankar 作为联合创始人，拥有深厚的数据目录（Data Catalog）与元数据管理背景，深刻理解企业在 AI 落地过程中面临的结构性困境。

核心议题：企业如何通过构建「开放上下文层」（Open Context Layer）解决 AI 在生产环境中失败率高达 75%-95% 的核心难题，实现 Agentic AI 的规模化落地与可持续治理。

行业坐标：企业级 AI 数据基础设施、数据治理与元数据管理、人工智能应用层、Enterprise SaaS

2. 现状挑战与痛点

深层结构性痛点

企业在推进 AI 项目时面临三个维度的上下文缺失（Context Gaps），这些缺失直接导致 AI pilot 在生产环境中大规模失败：

数据发现困境（Data Discovery Gap）：根据 Atlan 的调研显示，首席信息官（CIO）们普遍不知道企业数据究竟存储在何处。数据分散在数百个系统中，缺乏统一的元数据层，导致 AI 无法可靠地定位和调用所需数据资产。这不仅是技术问题，更是组织治理层面的系统性失灵。

业务语义断裂（Business Meaning Gap）：大型语言模型（LLM）缺乏对企业特定业务术语的理解能力。例如，「TAM」在企业语境中代表「Total Addressable Market」（可寻址市场总量），但互联网通用定义完全不同。这种语义鸿沟导致 AI 输出的分析结果与业务实际需求南辕北辙。模型无法理解「客户」「收入」「转化」等核心业务概念在特定企业中的精确含义和计算逻辑。

治理失控风险（Governance Gap）：企业缺乏对 AI 应用访问敏感数据的有效控制机制。薪酬、绩效、人员等高度敏感数据面临未经授权访问的风险。在缺乏治理框架的情况下，企业不敢将核心业务数据开放给 AI 系统，形成了「想用却不敢用」的困局。

这三个缺失相互叠加，形成了一个根本性的恶性循环：没有上下文，AI 无法可靠推理；无法可靠推理，企业不敢将 AI 投入生产；不投入生产，就无法积累实际应用中的上下文数据。

3. AI 破局与工作流重塑

AI 解决方案架构

解决方案的核心是构建一个「开放上下文层」（Context Layer），这与传统意义上的语义层（Semantic Layer）存在本质区别：

动态性设计（Dynamics）：传统语义层是静态的，一次性定义后长期使用。而企业是每天都在变化的——组织架构调整、业务流程优化、新产品上线——上下文层必须具备实时同步能力，持续反映企业的最新状态。这不是建立一个静态数据字典，而是构建一个「活」的上下文引擎。

反馈循环机制（Feedback Loops）：每一个「人机交互」都应成为上下文沉淀的机会。当业务人员纠正 AI 的理解偏差、补充缺失的定义、标注新的数据关系时，这些「人类智慧」应被自动编码回系统，成为下一代 AI 推理的上下文基础。上下文层不是一个一次性工程，而是持续演化的知识系统。

业务参与范式（Business as Context Engineers）：与传统 IT 项目不同，AI 项目的成功不再仅仅依赖业务方的资金支持和项目赞助，而是需要业务人员深度参与，成为「上下文工程师」（Context Engineers）。因为领域专业知识（Domain Expertise）存在于业务一线，而非 IT 部门。

工作流地图

环节 传统模式 AI 赋能模式
数据定位 人工搜索数据资产，耗时数天 AI 基于上下文自动推荐相关数据源
语义理解 业务人员手动解读 AI 输出 AI 理解企业特定业务定义，自动映射
知识沉淀 散落在个人笔记或 Wiki 中 每次交互自动编码回上下文层
权限治理 IT 部门静态配置，响应滞后 基于上下文的动态访问控制

执行步骤/SOP

第一步：识别高频 AI 用例。从业务部门最高频的数据分析场景入手，例如销售预测、客户画像、运营指标生成等。这些场景具有「容错率相对可控」的特性，适合作为试点。

第二步：围绕用例构建上下文。为每个核心业务概念建立精确的企业级定义，包括：计算公式、数据来源、业务规则、关联指标。以「收入」为例，需明确定义什么是收入（签约即确认vs.到账确认）、哪些订单计入、哪些折扣排除、货币换算规则等。

第三步：嵌入现有工具链。上下文层不是另建一个孤岛系统，而是与现有 BI 工具、CRM、Data Warehouse 无缝集成。让业务人员在熟悉的工具中直接调用上下文感知的 AI 能力。

第四步：建立反馈循环机制。每次业务人员使用 AI 时，开放「修正反馈」入口，将人类的业务判断自动沉淀为新的上下文知识。

第五步：横向复制与复用。当一个用例的上下文体系成熟后，将其抽象为可复用的「上下文模板」，快速扩展到其他相似场景。

4. 落地建议与高管指南

首选战场

企业应从「高频、低复杂度、业务容错率可控」的场景切入 AI 上下文层建设。具体建议：

数据分析助手：这是大多数企业最高频的 AI 应用场景。业务人员每天都需要从数据中提取洞察，但传统方式需要依赖数据团队排期，效率极低。上下文层可以让 AI 准确理解「本月收入」「客户留存」等业务术语的真实含义，大幅提升分析效率。

数据发现与治理：帮助数据团队和数据消费者快速找到「数据在哪里」「数据意味着什么」，这是所有 AI 应用的基础设施。

局限性与避坑指南

不要先建完美的 Data Lake 再做 AI：这是传统数据项目的思路，但在 AI 场景下是致命的陷阱。上下文层应该是「用例驱动」的，边用边建，而非自上而下的全局规划。

不要一开始就追求端到端全自动化：AI 在生产环境中的可靠性取决于上下文的完整性。一开始应聚焦在「人机协同」模式，允许人类审核和纠正 AI 输出，逐步积累上下文后再考虑自动化程度提升。

避免纯技术驱动的治理方案：上下文层的治理必须由业务部门主导，IT 部门执行。纯技术视角的治理方案往往无法覆盖业务语义的复杂性。

战略对标清单

自查建议一：评估当前 AI 项目是否「死于」上下文缺失。检查 AI 输出的结果是否与业务实际需求存在系统性偏差，这些偏差是否源于「数据定义不一致」「业务规则未被理解」等上下文问题。

自查建议二：确认业务部门是否真正参与 AI 项目。如果业务方仅停留在「赞助角色」而未深度参与定义业务语义和验证输出质量，AI 项目大概率会失败。

自查建议三：检查数据治理的「动态性」。现有数据治理体系是否能跟上业务变化的速度？如果治理规则是静态的，那么它无法支撑动态演进的 AI 应用。

5. 核心价值与全维 ROI

硬核指标/证据

根据 Atlan 客户案例的量化数据显示：

Workday：通过上下文层技术，AI 准确率提升超过 5 倍。这一数字极具说服力——不是 10%、20% 的改进，而是 5 倍以上的质变。这意味着 AI 从「辅助参考」升级为「可信赖的业务决策依据」。

Virgin Media O2：成功上线并运行包含 6,000 名员工的平台，累计平台访问量超过 100 万人次。这一规模验证了上下文层技术的可扩展性——从中小企业到大型组织的全员部署均可支撑。

通用指标：根据 MIT 研究，企业 AI pilot 在生产环境中的失败率高达 75%-95%。上下文层的核心价值在于将这一失败率大幅降低，使 AI 从「实验性项目」变为「可规模化的生产系统」。

ROI 的非传统定义

除了直接的效率提升和成本节省，上下文层带来的战略价值还包括：

决策速度提升：业务人员不再需要等待数据团队排期获取数据定义，AI 可以实时提供基于统一业务语义的分析结果。这直接压缩了「从问题到洞察」的时间周期。

跨部门协作效率：统一的上下文层消除了不同部门对同一业务指标的不同理解，减少了「数据口径不一致」导致的内部扯皮和重复沟通。

AI 采用率与信心：当 AI 输出变得可解释、可信赖，业务人员更愿意在日常工作中使用 AI 工具，形成正向飞轮——使用越多，上下文越丰富，AI 越智能。

6. 核心金句与反共识洞察

反直觉/非共识结论

传统的企业 AI 项目治理思路是「先建标准，再推应用」——先制定完善的数据治理规范，再将 AI 投入生产。但这种思路在 AI 时代是致命的：企业业务变化速度远快于治理标准的更新速度，静态的治理框架无法支撑动态的 AI 需求。

正确的路径应该是「用例驱动，边建边用」：从具体业务场景出发，围绕用例构建上下文，让业务人员在实际使用中不断丰富和校验上下文质量，再将成熟的上下文体系横向复制到其他场景。这不是「多year governance program」，而是持续演进的「living system」。

另一个反直觉洞察是：AI 项目不再只需要「业务赞助」（Business Sponsorship），而是需要「业务深度参与」（Business as Context Engineers）。传统 IT 项目中，只要业务领导点头支持，项目就能推进。但在 AI 领域，业务人员必须亲自参与定义业务语义、验证输出质量，因为领域专业知识存在于业务一线，而非 IT 部门。

原汁原味金句

「75% 到 95% 的企业 AI pilot 在生产环境中失败。问题不在于数据本身，而在于缺失上下文——连接数据与业务逻辑的机器可读语义。没有上下文，即使是最先进的 AI 系统也无法可靠地推理。」—— 针对 AI 项目高失败率的根本原因

「上下文层必须是动态的，因为企业每天都在变化。它应该嵌入反馈循环，让每一次人机交互都将上下文编码回系统中。」—— 区别传统语义层的核心特征

「与过去 IT 项目仅需业务赞助就能上线不同，AI 需要业务人员作为『上下文工程师』深度参与，因为领域专业知识存在于业务部门，而非 IT 部门。」—— AI 项目治理范式的根本转变

「从具体用例开始，围绕用例构建上下文，并使其可复用到未来用例——而不是一个多年期的治理项目。」—— 落地方法论的核心原则

📺 播客地址

播客时长: 25分钟