OpenAI has launched a Data agent in ChatGPT Work that connects to approved company data, investigates changes in business metrics, builds interactive dashboards and can carry findings into connected tools. The release turns ChatGPT Work into a front end for data warehouses, BI systems, documents and operational context rather than a separate analytics island.
The important architectural detail is not simply the list of connectors. OpenAI says queries inherit the permissions of the connected account, including table, row and column restrictions, while the agent also consumes business definitions and semantic context from systems such as dbt, Databricks Genie Ontology, Snowflake Horizon and existing BI dashboards. That gives enterprises a familiar access-control boundary, but it does not answer a different question: whether the agent interpreted the right metric, joined the right data or reached a reliable conclusion.
The product sits above the existing data stack
OpenAI lists Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB and Snowflake among approved data sources. Google Drive and SharePoint can supply files and documents, while dashboards can be built or used through tools including Power BI, Tableau, ThoughtSpot, Sigma, Oracle BI and Omni.
The design is deliberately federated. Instead of requiring a company to move all data into a new repository, the agent combines context from existing systems and lets a user refine an investigation conversationally. OpenAI says administrators choose which connections and roles are available, and the connected account's existing data restrictions continue to apply.
That is a meaningful change for self-service analytics. A salesperson, operations lead or product manager can ask a question without first translating it into SQL or waiting for a dedicated report. The agent can then produce a dashboard, refresh it and continue the investigation with follow-up questions.
Permission inheritance solves only one layer of governance
Access controls answer who may see a row or column. They do not establish what a metric means, which source is authoritative, whether a transformation is current or whether two teams use the same definition of revenue, churn or an active customer.
OpenAI's own description implicitly recognizes this problem. The Data agent can use an organization's metric definitions, calculations and relationships from semantic layers and trusted sources. In other words, the agent is more useful when the organization has already done the hard work of making its data interpretable.
Aipolix's analysis is that this moves part of AI governance into the semantic layer. If the same user can legitimately access two conflicting definitions of a metric, permission checks can pass while the analysis is still wrong for the decision being made. Enterprises therefore need to govern not only which tables the agent can query, but which definitions should be preferred for specific business questions and how disagreements are surfaced.
A robust deployment should make the provenance of important findings visible: which sources were used, which business definition was applied, what filters and time windows were chosen, and where the agent had to infer rather than retrieve an explicit rule.
There is no published external accuracy benchmark
OpenAI includes customer examples and says the capabilities are widely used inside the company, but those are adoption and experience claims, not a public measure of analytical correctness. VentureBeat reports that OpenAI has not published a retrieval-accuracy or correctness benchmark for the external Data agent. According to the report, OpenAI compares internal results with its own data tools, but did not provide a public benchmark figure.
That absence does not mean the product is inaccurate. It means buyers cannot use a published accuracy number to compare it with competing approaches or to estimate error rates on their own data.
For an enterprise rollout, this changes what proof should look like. Teams should create their own evaluation set from questions with known answers, including difficult joins, ambiguous metric names, incomplete data, permission boundaries and queries where the correct response is to ask for clarification. The evaluation should test not just whether a dashboard renders, but whether its claims are supported by the underlying data.
This is especially important because polished dashboards can make uncertain analysis look authoritative. A visual result needs the same evidentiary discipline as a query result: traceable sources, reproducible calculations and a clear indication when the agent is making an inference.
Analysis and action need separate authority
OpenAI says the Data agent can move beyond answering questions and carry out approved actions through connected tools. That makes the boundary between analysis and execution operationally important.
Being allowed to read sales data should not automatically authorize an agent to change an account, message a customer, alter a campaign or update another system. Those are different permissions with different consequences.
A practical control model should separate at least three capabilities: access to source data, authority to construct or share an analytical artifact, and authority to cause an external side effect. High-impact actions can then require stronger confirmation or policy checks even when the analysis itself is fully self-service.
The same separation helps with auditability. An organization should be able to reconstruct which data supported a recommendation, what the user approved and which action the agent ultimately executed. Without that chain, a conversational interface can collapse several distinct control decisions into one apparently simple request.
The real deployment work shifts upstream
The Data agent reduces the amount of specialist syntax a business user needs to know. It does not remove the need for data engineering, semantic governance or evaluation. In some organizations it may increase the importance of those disciplines because many more people can now ask consequential questions directly.
The useful deployment question is therefore not simply whether the agent can connect to Snowflake, BigQuery or Power BI. It is whether the organization has reliable metric definitions, permission boundaries, provenance, evaluation cases and action controls that make broad self-service safe enough to trust.
OpenAI's release makes enterprise analytics easier to reach from a general-purpose AI workspace. The architectural consequence is that the quality of the underlying data contracts becomes part of the agent's behavior. Permissions determine what the agent may see; semantic definitions shape what it thinks the data means; evaluation shows whether the answer is dependable; and separate execution controls determine what it may do next.