TechCrunch 的 AI 频道持续追踪生成式 AI、大语言模型、语音、视觉、预测分析、AI 公司和伦理问题等方向，这些报道背后反映出一个清晰趋势：AI 正在从“单点能力”进入“企业系统”。

但站在 CTO 的角度，我更关心的不是今天又发布了哪个模型，也不是哪家公司融资了多少，而是一个更朴素的问题：

AI 到底能不能进入企业真实的数据流程？

这件事并没有表面看起来那么简单。

企业不是一个聊天窗口。企业是由数据源、权限、流程、指标、系统、组织和责任边界组成的复杂机器。模型能力再强，如果无法理解企业内部的数据结构、业务语义和治理规则，就很难真正进入业务决策链路。

OpenAI COO Brad Lightcap 在 TechCrunch 的报道中也提到，企业 AI 还没有真正大规模进入企业业务流程，因为企业内部有很多人、团队、上下文、系统和工具，目标也很复杂。

这句话说得很实在。

AI 进入企业，不是把 ChatGPT 接进公司系统就结束了。真正的问题是：企业有没有准备好让 AI 理解自己的数据世界。

---

一、企业数据智能的第一性问题：AI 要理解什么？

很多企业做 AI 数据应用时，第一反应是选工具。

选 BI？
选数据中台？
选数据目录？
选大模型？
选 Agent 平台？
选 NL2SQL？
选 RAG？
选 Copilot？

这些问题都重要，但它们不是第一性问题。

真正的第一性问题是：

当一个业务人员问出一个问题时，系统要如何从“自然语言”走到“可信结果”？

比如业务人员问：

今年华东区域重点客户的利润下降主要由哪些产品造成？

一个看似简单的问题，背后至少包含六层含义。

第一，“今年”对应什么时间范围？是自然年、财年，还是公司经营周期？

第二，“华东区域”来自客户归属区域、销售组织区域，还是项目交付区域？

第三，“重点客户”是按销售额、战略等级、合同金额、活跃度，还是人工标签定义？

第四，“利润”是毛利、净利、合同利润、项目利润，还是财务确认后的利润？

第五，客户、产品、合同、订单、发票、利润明细这些数据表之间如何关联？

第六，当前用户是否有权限看到这些客户和利润数据？

如果这些问题没有被系统化地回答，AI 只能猜。

而企业数据智能最怕的不是系统回答慢，而是系统回答得很流畅、很自信，但结果是错的。

---

二、为什么传统工具很难直接解决 AI 数据智能问题？

传统数据工具各有价值，但它们大多是为“人使用数据”设计的，不是为“AI 理解数据”设计的。

数据仓库擅长存储、计算和建模。
BI 工具擅长报表、图表和可视化。
数据目录擅长登记资产、管理元数据。
数据治理平台擅长标准、权限、质量和合规。
ETL / ELT 工具擅长数据同步和加工。

这些工具支撑了过去十几年的企业数字化建设。

但 AI 带来了一个新的问题：

过去是人读数据文档、看表结构、写 SQL；现在是 AI 要理解这些东西，并且自动完成推理和执行。

这就要求企业的数据资产不只是“被管理”，还要“可被机器理解”。

传统工具往往存在几个断点：

业务语义和技术字段是断开的。
数据血缘和实际查询路径是断开的。
指标定义和 SQL 生成是断开的。
权限体系和 AI 工具调用是断开的。
数据治理和业务问数体验是断开的。

所以很多企业的智能问数、NL2SQL、数据 Agent 项目，Demo 阶段效果不错，但一到真实业务就开始暴露问题：表选错、字段猜错、JOIN 路径不稳定、指标口径不一致、权限边界不清晰、结果解释无法追溯。

问题不在于模型不够聪明，而在于企业没有给模型提供足够可信的上下文。

---

三、全球趋势正在指向一个方向：模型必须接入企业上下文

从 TechCrunch 最近对企业 AI 的报道看，全球市场正在出现一个共同方向：AI 不再只是单独的模型，而是要和企业数据、工具、权限、流程结合。

TechCrunch 在 2026 年初的一篇趋势文章中提到，Agent 在 2025 年没有完全兑现预期，一个重要原因是它们很难连接到真正发生工作的系统；MCP 这类协议之所以重要，是因为它降低了 Agent 连接数据库、搜索引擎、API 等外部工具的摩擦。

Snowflake 与 OpenAI 的合作也说明了类似趋势。TechCrunch 报道称，Snowflake 与 OpenAI 达成多年期 AI 合作，Snowflake 客户可以在其信任的、安全治理的平台上使用 OpenAI 模型，并在企业数据之上构建和部署 AI。

Glean 的方向也很典型。TechCrunch 报道中提到，Glean 从企业搜索产品演进为模型与企业系统之间的连接层，核心判断是大模型本身不了解企业内部的人、工作方式、产品和上下文，因此必须把模型的推理能力与公司内部上下文连接起来。

这些趋势背后的本质非常一致：

企业 AI 的竞争，不是单纯模型竞争，而是企业上下文工程的竞争。

谁能更好地组织企业数据、语义、权限、流程和工具，谁就更有可能让 AI 真正进入生产系统。

---

四、企业数据智能的落地路径：不要从“聊天框”开始

很多企业做 AI 数据智能，第一步就想做一个智能问数入口。

这很自然，因为聊天框最容易展示 AI 效果。

但从 CTO 角度看，如果一开始就做聊天框，很容易走偏。聊天框只是入口，不是系统能力本身。

企业数据智能的落地路径应该分成五层。

第一层：数据资产可见

企业首先要知道自己有哪些数据。

这包括数据源、数据表、字段、主键、数据量、更新时间、负责人、质量状态、系统归属等。

没有数据资产可见性，AI 就不知道自己能用什么数据。

这一层传统数据目录、元数据管理平台可以做一部分，但如果要服务 AI，还需要进一步结构化到字段、业务对象和可调用接口级别。

第二层：数据关系可知

知道有哪些表还不够。

企业数据真正复杂的地方在于表与表之间的关系。

客户表如何连接订单表？
订单表如何连接发票表？
项目表如何连接人员工时表？
合同表和利润明细表之间有没有直接关系？
如果没有，需要经过哪张中间表？

传统上，这些知识往往藏在老员工经验、SQL 脚本、ETL 任务和报表逻辑里。

但 AI 不能靠“问老员工”来生成 SQL。它需要结构化的关系上下文。

Intalink 的能力定位正是在这一层：它是企业级数据血缘与关系发现平台，提供数据源管理、数据表管理、数据关系发现、任务中心等能力，并通过表间关系、字段关系、主外键关系、语义关系以及共现次数、去重数、包含比率等指标来描述数据关系质量。

这类能力的本质不是做一个“好看的血缘图”，而是给 AI 提供可计算、可验证、可调用的数据连接地图。

第三层：业务语义可治理

数据关系解决“表怎么连”，但还没有解决“业务是什么意思”。

业务人员不会问：

SELECT SUM(amount) FROM fact_sales WHERE region = 'East'

业务人员会问：

最近华东区域重点客户的销售表现怎么样？

这里的“销售表现”“重点客户”“华东区域”都不是数据库字段，而是业务概念。

企业需要一个语义层来管理这些概念：指标、维度、术语、口径、公式、单位、适用范围、版本、灰度规则。

语义层的价值不是让业务词汇“看起来规范”，而是让 AI 在生成 SQL、选择数据、解释结果之前，有一个受治理的业务约束空间。

第四层：智能查询可解释

当数据资产、数据关系、业务语义具备后，智能查询才真正有基础。

一个可靠的智能查询系统，不能只输出结果，还应该能回答：

为什么选这些表？
为什么使用这条关联路径？
用了哪个指标定义？
SQL 是如何生成的？
结果口径是什么？
有没有歧义？
用户是否有权限？
如果结果异常，可能原因是什么？

对 CTO 来说，“可解释”不是锦上添花，而是生产可用的最低要求。

没有解释，业务不敢信。
没有 SQL，技术不能审。
没有口径，管理层无法决策。
没有边界，系统无法治理。

第五层：流程闭环可演进

企业数据智能不是一次性项目，而是一个持续演进系统。

每一次问数失败、每一次字段歧义、每一次指标口径争议、每一次用户反馈，都应该回流到知识补足、语义治理、关系校正和测试验证中。

如果没有闭环，系统会停留在 Demo 阶段。
如果有闭环，系统会越用越准。

这套分层的意义在于：把一次性的 AI 问答，变成可治理、可审计、可持续改进的数据智能系统。

---

五、工具选型：CTO 不应该只看功能清单

企业做工具选型时，很容易陷入功能对比表。

有没有自然语言查询？
有没有 NL2SQL？
有没有数据血缘？
有没有数据目录？
有没有权限管理？
有没有 Agent？
有没有 MCP？
有没有工作流？

这些问题都该问，但还不够。

真正该问的是下面几个问题。

第一，这个工具是在增强现有数据体系，还是在绕开现有体系？

很多 AI 工具为了快速出效果，会绕过企业已有的数据治理、权限、指标体系，直接接数据库、直接生成 SQL。

短期看很快，长期看很危险。

一个好的企业 AI 数据工具，应该尊重现有系统，并把它们组织成 AI 可理解的上下文，而不是另起炉灶。

第二，它能否把技术元数据变成业务可用语义？

只管理表和字段，不等于能支持业务问数。

CTO 要看的是：字段能不能映射到业务指标？指标有没有版本？维度有没有适用范围？业务口径能不能治理？歧义能不能处理？

第三，它是否理解表间关系，而不是只依赖字段名称？

NL2SQL 的很多错误来自错误 JOIN。

如果系统只靠字段名相似度生成关联路径，复杂场景下必然不稳定。

数据关系发现、关系置信度、候选路径、最优路径、关系更新机制，是企业智能查询的关键底座。

第四，它有没有可解释和可审计能力？

企业数据智能不是娱乐应用。

结果错了，会影响经营判断；权限错了，会带来合规风险；口径错了，会引发组织争议。

所以系统必须能解释推理过程、SQL、数据来源、指标口径和权限边界。

第五，它能不能形成反馈闭环？

很多智能问数项目死在“第一次不准”。

但真正的问题不是第一次不准，而是系统能不能知道为什么不准，并把修正沉淀下来。

没有反馈闭环的系统，永远靠人救火。
有反馈闭环的系统，才能逐步逼近生产可用。

---

六、我对企业数据智能架构的判断

如果从 CTO 角度重新设计企业数据智能架构，我不会把它定义为一个“AI 问数工具”。

我会把它定义为一个五层架构：

底层是数据连接与资产层，负责接入数据源、抽取元数据、维护表字段资产。

第二层是数据关系层，负责发现、验证和维护表间关系、字段关系、跨源关系和关联路径。

第三层是语义治理层，负责业务术语、指标、维度、口径、版本和权限约束。

第四层是智能执行层，负责意图理解、查询生成、工具调用、SQL 验证、多步推理和结果生成。

第五层是反馈运营层，负责用户反馈、错误归因、知识补足、工单流转、质量评估和持续优化。

这样设计的好处是，每一层都有明确职责。

模型不直接决定业务口径。
语义层不直接猜测数据关系。
关系层不替代业务解释。
查询层不绕开治理规则。
反馈层不依赖人工记忆。

这才是企业 AI 数据智能应该走的路线。

---

七、结语：AI 越强，企业越需要数据秩序

全球 AI 技术趋势正在变得越来越清晰：模型会更强，Agent 会更多，工具调用会更标准，企业系统会更深地接入 AI。

但企业真正的分水岭，不在于谁先接入最新模型。

真正的分水岭在于：

谁能把企业混乱的数据资产整理成 AI 可理解的结构；
谁能把业务语言变成可执行的语义层；
谁能把表间关系变成可验证的连接地图；
谁能把智能查询变成可解释、可审计、可反馈的系统；
谁就能真正把 AI 从“演示能力”变成“生产能力”。

未来的企业数据智能，不会只是一个更聪明的 BI，也不会只是一个更会写 SQL 的 Chatbot。

它会是一套新的企业数据操作系统：

用语义理解业务，
用关系连接数据，
用治理约束边界，
用 Agent 执行任务，
用反馈持续进化。

这才是全球 AI 浪潮下，企业数据智能真正值得投入的方向。