很多业务问题并不缺数据：销售为什么变慢、支出在哪些地方上升、哪些客户可能续约失败。真正的阻力是，回答这些问题往往要等报表、排 SQL，或请数据团队临时跑一次分析。
OpenAI 发布的 Data agent，目标是把这条链路压缩成一段对话：连接企业批准的数据源，用自然语言追问变化原因，生成可交互的 dashboard，再根据用户批准的下一步把结论带到 Slack、邮件或其他业务工具里。
#先接入数据，再理解企业自己的语言
Data agent 可以连接 Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB、Snowflake 等数据源，也可以把 Google Drive 和 SharePoint 中的文件与文档带入分析。
但连接器只是底层。更关键的是，系统会使用企业已有的业务术语、指标定义、自定义计算和数据关系来解释结果。这些上下文来自语义层和可信系统，例如 Databricks Genie Ontology、dbt、GitHub、Snowflake Horizon 以及现有 BI dashboard。
这意味着“活跃用户”不再只是模型对一个词的猜测，而应该指向组织已经认可的定义。企业管理员还可以控制哪些数据连接可用、哪些角色能够使用，查询继续遵守原账户已有的表、行和列级权限。
#从问题到看板，再到行动
Data agent 的工作不止是生成一段解释。用户可以继续追问，查看每个结论背后的证据，然后把分析转换成带可视化组件的交互式 dashboard。团队可以编辑、分享和刷新看板，也可以提供品牌规范，让输出适合组织内部使用。
它还可以在 Omni、Oracle BI、Power BI、Sigma、Tableau 和 ThoughtSpot 中创建或操作 dashboard。业务人员用的是自然语言，结果仍然落在团队已经使用的分析工具里。
更进一步，Agent 可以建议下一步、指出需要参与的人，并通过连接的工具发送结果或执行用户明确批准的动作。分析不再是流程终点，而是决策流程中的一个可继续推进的节点。
#OpenAI 先把它用在自己身上
OpenAI 表示，几乎所有产品团队成员和超过三分之二的 GTM 团队都在 ChatGPT Work 中使用 data agents 分析公司数据。要让这种使用方式成立，数据团队先做了三类基础工作：统一业务定义、配置访问规则、为敏感数据建立保护措施。
这组信息透露出一个常被忽略的事实：数据 Agent 的部署顺序不能反过来。先把模型接上所有表，再希望它自己悟出业务含义，结果只会更快地产生看似合理的错误。可信的语义层和权限系统，才是自然语言分析能够进入企业的前提。
公告还列出了一批 Alpha 阶段客户的使用案例：NTT DATA 让销售和职能部门的非工程人员用自然语言创建和更新 dashboard；Thermo Fisher Scientific 用既有环境的数据分析供应链机会；ServiceTitan 通过 dashboard 发现使用 Atlas AI sidekick 的用户发起活动的频率约为非用户的三倍；Zipline、Empower 和 Piston 分别用它做公司数据探索、AI 使用趋势分析以及销售漏斗、工单和支出分析。
Doeren Mayhew 在两天内为不同办公室建立了定制看板，CookUnity 用它改进旺季转化 dashboard，Turing 用它排查运营指标变化，micro1 在半小时内重建绩效跟踪 dashboard 并发现旧报表中的错误，Unit8 则用它把需求趋势与交付能力放在一起评估。
这些案例是产品公告中的客户自述，更适合用来说明采用方向，而不是当成独立的效果评测。它们共同指向的价值是：把过去集中在数据专家手里的探索和可视化，分发给更多直接做业务决策的人。
#真正的产品边界在治理
Data agent 的产品形态很容易让人想到“用聊天替代 BI”。但 BI 工具的复杂性并没有消失，只是从界面配置转移到了上下文和治理：指标怎么定义，数据能看到哪一层，哪些异常需要人工复核，什么动作必须重新授权。
如果这些边界清楚，Agent 可以成为企业数据的自然语言操作层；如果边界模糊，它只会把权限误配和口径不一致包装成一张漂亮的图。让人人都能问数据，前提是组织先决定哪些答案值得被信任、哪些行动必须由人批准。
目前 Data agent 以 ChatGPT Work 中的 Data 插件形式提供。管理员可以在 Workspace 设置里开放它，并配置 Databricks、Snowflake 等数据源插件；用户完成账户连接后，就可以直接用自然语言提出业务问题。