AI行业有一个公开的秘密：大部分AI项目赚不回投入的钱。
Gartner的预测很残酷：2026年将有60%的AI项目被放弃。不是因为模型不够好——恰恰相反，模型能力已经远超大多数企业的使用能力——而是因为数据没有准备好被AI消费。
这是一个被严重低估的问题。所有人都在讨论模型、讨论Agent、讨论应用场景，但很少有人讨论：你的数据，Agent读得懂吗？
消费者变了：从人到Agent
过去三十年，数据平台的服务对象是人。数据分析师写SQL、BI分析师做报表、业务人员看仪表盘——人有常识、有上下文、有容错能力。你给我一张报表，某个字段口径变了，我能看出来；两个表JOIN错了，我能发现；数据延迟了半天，我能理解。
Agent不一样。
Agent没有常识，没有上下文，也不会"觉得哪里不对"。你告诉它"查一下上个月的销售额"，它会严格按照它理解的口径去查——如果"销售额"在不同表里有不同的定义，如果用户表和订单表的关联字段有歧义，如果某些订单的状态码含义变了但文档没更新，Agent会一本正经地给你一个错误的答案，而且自信满满。
这就是为什么75%的企业已经试点了AI Agent，但只有15%在考虑部署自主Agent。试点的时候，Agent说错了有人兜着；真让它自主决策，谁来为错误的结论买单？
"AI项目的ROI瓶颈不在模型层，在数据层。模型是发动机，数据是燃油——你加了劣质燃油，发动机再好也跑不起来。"
—— 腾讯云AI产业应用大会核心观点
NL2SQL的三个致命陷阱
最典型的例子是NL2SQL（自然语言转SQL），这是目前企业AI应用最火热的场景之一，但也是翻车最多的场景。
第一个陷阱是指标歧义。你问"上个月的收入是多少"，Agent怎么知道"收入"指的是GMV、实际营收、还是税后利润？不同部门、不同报表里"收入"的定义可能完全不同。人会追问"你指的哪个收入"，Agent直接选一个它最"喜欢"的定义去查。
第二个陷阱是JOIN错乱。企业数据库动辄几百张表，表之间的关联关系错综复杂。一个字段名可能在多张表里出现，但含义不同；一个外键关系可能因为历史原因存在数据不一致。人类分析师踩过几次坑后会记住，但Agent每次都是"第一次"。
第三个陷阱是查询条件随意匹配。"最近30天"是自然日还是工作日？"高价值客户"的阈值是什么？"华北区"包不包括内蒙古？这些在企业里往往是"潜规则"——老员工知道，文档里没写，Agent当然也不知道。
统一语义层：AI时代的新护城河
腾讯云在最近的AI产业应用大会上发布了面向Agent升级的全栈数据平台，核心思路是三层架构：DataBuddy（Agent数据助手）+ WeData（数据治理）+ AI原生大数据底座。其中最关键的概念是"统一语义层"。
什么意思？就是把企业里所有指标的定义、口径、计算逻辑、关联关系全部统一管理起来，形成一个Agent可以直接消费的"数据字典"。Agent不需要自己去猜"收入"是什么意思，统一语义层会告诉它确切的定义、依赖的表、过滤条件、计算方式。
这看起来不性感，但这才是AI真正落地企业的护城河。模型可以换（今天GPT明天Claude后天DeepSeek），但企业的数据治理和语义层建设是需要时间、需要业务理解、需要踩坑积累的。谁先把这层建好了，谁的Agent才能真正跑出ROI。
腾讯云披露的数据：DataBuddy让数据工程重复开发降低了80%，研发效率提升5-10倍。这不是因为模型变聪明了，而是因为数据变"干净"了。
给决策者的建议
如果你正在或计划在企业里推AI项目，先别急着调模型API。先问自己三个问题：
第一，你的核心指标有统一的定义吗？还是每个部门各算各的？
第二，你的数据文档是写给人看的还是写给机器看的？Agent能理解你的表结构和字段含义吗？
第三，如果Agent给了一个错误的数据结论，你有机制发现吗？
这三个问题回答不好，再强的模型也救不了你的AI项目ROI。
明天见。
The AI industry has an open secret: most AI projects don't earn back their investment.
Gartner's prediction is brutal: 60% of AI projects will be abandoned in 2026. Not because models aren't good enough -- quite the opposite, model capability already far exceeds most enterprises' ability to use them -- but because data isn't ready to be consumed by AI.
This is a severely underappreciated problem. Everyone discusses models, Agents, application scenarios, but few discuss: can your Agents actually understand your data?
The Consumer Changed: From Humans to Agents
For the past thirty years, data platforms served humans. Data analysts write SQL; BI analysts build reports; business users look at dashboards -- humans have common sense, context, and fault tolerance. Give me a report where a field's definition changed; I can tell. Two tables JOINed incorrectly; I can spot it. Data delayed half a day; I can understand.
Agents are different.
Agents have no common sense, no context, and don't "feel like something's off." Tell it to "look up last month's sales," and it will strictly query according to its understanding of "sales" -- if "sales" means different things in different tables, if the join key between user and order tables is ambiguous, if status code meanings for certain orders changed but docs weren't updated, the Agent will earnestly give you a wrong answer -- with full confidence.
That's why 75% of enterprises have piloted AI Agents, but only 15% are considering deploying autonomous Agents. In pilots, wrong Agent answers have human backup; when it makes autonomous decisions for real, who pays for wrong conclusions?
"The ROI bottleneck for AI projects isn't at the model layer; it's at the data layer. Models are engines; data is fuel -- put in bad fuel and even the best engine won't run."
-- Core viewpoint from Tencent Cloud AI Industry Application Conference
Three Fatal Traps in NL2SQL
The most typical example is NL2SQL (Natural Language to SQL), currently one of the hottest enterprise AI application scenarios -- and also the one with the most faceplants.
The first trap is metric ambiguity. You ask "how much was last month's revenue"; how does the Agent know if "revenue" means GMV, actual revenue, or after-tax profit? Different departments and reports may define "revenue" entirely differently. Humans would ask "which revenue do you mean"; Agents just pick the definition they "like" best and query.
The second trap is JOIN chaos. Enterprise databases have hundreds of tables; inter-table relationships are tangled. A field name may appear in multiple tables with different meanings; a foreign key relationship may have data inconsistencies due to historical reasons. Human analysts learn after stepping in a few pits; Agents experience it as "the first time" every time.
The third trap is arbitrary query condition matching. Is "last 30 days" calendar days or business days? What's the threshold for "high-value customers"? Does "North China region" include Inner Mongolia? These are often "unwritten rules" in enterprises -- veteran employees know them; they aren't in docs; Agents certainly don't know them either.
Unified Semantic Layer: The New Moat for the AI Era
At the recent AI Industry Application Conference, Tencent Cloud released a full-stack data platform upgraded for Agents, with a three-layer architecture at its core: DataBuddy (Agent data assistant) + WeData (data governance) + AI-native big data foundation. The most critical concept is the "unified semantic layer."
What does that mean? It means centrally managing the definitions, calibers, calculation logic, and relationships of all metrics across the enterprise, forming a "data dictionary" Agents can directly consume. Agents don't need to guess what "revenue" means; the unified semantic layer tells them the exact definition, dependent tables, filter conditions, and calculation methods.
This doesn't look sexy, but it's the real moat for AI landing in enterprises. Models can be swapped (GPT today, Claude tomorrow, DeepSeek the day after), but enterprise data governance and semantic layer construction take time, business understanding, and pitfall accumulation. Whoever builds this layer first gets real ROI from their Agents.
Tencent Cloud disclosed data: DataBuddy reduced duplicate data engineering work by 80% and improved R&D efficiency 5-10x. That's not because models got smarter; it's because data got "cleaner."
Advice for Decision-Makers
If you're pushing or planning AI projects in an enterprise, don't rush to call model APIs. First ask yourself three questions:
First, do your core metrics have unified definitions? Or does each department calculate its own?
Second, are your data docs written for humans or for machines? Can Agents understand your table structures and field meanings?
Third, if an Agent gives a wrong data conclusion, do you have mechanisms to detect it?
If these three questions can't be answered well, even the strongest model can't save your AI project ROI.
See you tomorrow.
