OpenAI’s new Data agent can query connected company data using the connected account’s existing permissions. That does not settle who should receive the resulting dashboard. OpenAI’s setup guide says publishing an analysis through ChatGPT Sites copies the analysis data into the site. For German enterprise buyers, there is a second immediate constraint: Sites is not available in the EEA at launch, according to its current help documentation.
The practical decision is therefore narrower than “enable conversational business intelligence.” Approve the source identity, metric definition and output destination separately. A permitted query is not permission to distribute its result to a wider audience, and availability of the Data plugin does not establish availability of every recommended publishing capability.
What changed: a packaged data-analysis workflow
On 10 September 2026, OpenAI introduced the Data agent in ChatGPT Work. It connects to approved company sources, investigates business questions and builds interactive dashboards. The announcement lists sources including Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB and Snowflake, with Google Drive and SharePoint documents available as additional context.
The agent can use business definitions and relationships from semantic layers and trusted sources, including dbt, Databricks Genie Ontology and Snowflake Horizon. OpenAI also describes integration with existing BI tools such as Power BI, Tableau, Sigma and ThoughtSpot. These are vendor-documented capabilities, not an independent measurement of analytical correctness or a guarantee that every action is supported by every connector.
The launch is not the invention of natural-language analysis or a replacement for a governed warehouse. Its useful change is packaging source access, business context, investigation and output creation into one workflow. Compared with a conventional BI report, that can reduce the steps between a question and a proposed analysis. It also makes the selection of definitions, joins and output recipients part of the review process rather than assumptions hidden behind a polished chart.
This article evaluates the announcement and documentation retrieved on 13 September. It does not claim a hands-on deployment or measured productivity improvement.
Who can use Data—and which capability is unavailable in Germany
The Data plugin guide says the plugin must be available in the user’s ChatGPT Work or Codex account or workspace. Administrators configure it under Workspace settings > Plugins and can assign availability or installation by eligible role or group. The relevant data-source plugin and included app must also be enabled and connected. Some integrations require an administrator to configure an app template first.
Installation is not authorization. The general plugin documentation distinguishes the package of skills and apps from the permissions of each underlying app. A visible listing or installed plugin does not prove that a user can access Snowflake, invoke a write action or publish a dashboard. Plan, role, workspace settings, region and supported product surface can each affect access.
OpenAI recommends a warehouse connection, an authoritative semantic layer and Sites for dashboard publishing; an existing BI tool is optional. However, the Sites documentation says Sites is in public beta and is not available in the EEA, Switzerland or the United Kingdom at launch. It also says Sites does not support data residency or inference residency at launch, including deployed sites, code, storage, artifacts and logs.
For a German rollout, do not plan around Sites until actual regional availability changes and your organisation approves that service. This does not establish that the entire Data agent is unavailable in Germany. It means the recommended workflow contains a component whose regional limitation must be checked independently. Investigate an already-approved BI destination only where the actual connector supports the required actions; do not assume feature parity or the same sharing semantics.
Source permissions and published copies are different controls
OpenAI says queries use the connected account’s permissions, including applicable table, row and column restrictions. First establish whose account that is and what it can read. A broad warehouse role remains broad when reached through an agent. The control principle is the same as in our guide to enforcing access before retrieval: the model is not the authority that decides entitlement.
The Data guide then makes a separate disclosure: the data used in an analysis is copied into a published Site. The site has its own audience settings. Sites documentation describes owner-and-admin access, selected users or groups where supported, workspace access and public access where enabled. Enterprise public publishing is off by default, but an internal audience can still be too broad for a departmental dataset.
The engineering implication is not that OpenAI has demonstrated an access-control vulnerability. It is that query authorization and artifact sharing must be tested as separate decisions. Do not assume that revoking warehouse access also removes data already embedded in a published artifact. The reviewed documentation does not establish automatic propagation of that source revocation to every copied result.
For example, a finance analyst may legitimately query regional margin data, while a company-wide dashboard containing customer-level margins would have an inappropriate audience. Removing a visible detail chart is not enough if the generated site still contains those rows in its data payload. Review the exported fields and embedded data, not just the screen. This is a proposed acceptance test, not a reported incident in the Data agent.
Treat each shared output as a derived data asset: owner, source, classification, extraction time, permitted audience and removal procedure. Our RAG data-governance guide provides the lifecycle foundation; this launch adds the specific question of what crosses from a permissioned query into a separately hosted analysis copy.
Correct permissions do not make a metric correct
The agent can access exactly the right rows and still answer the wrong question. “Revenue” can mean booked orders, invoices or recognised revenue. “This quarter” can refer to a fiscal calendar or a calendar quarter. Joining account-level outcomes to line items can multiply amounts even when every individual record is authorised.
OpenAI recommends authoritative business definitions and asks users to check sources, periods, filters and metric definitions before relying on a result. Apply that guidance as an acceptance requirement: bind the analysis to a named definition, grain, timezone, currency treatment and baseline query. Have the data owner reconcile a bounded result against the established report before evaluating how quickly the agent produced it.
When a definition is missing, ask for clarification rather than letting a model’s plausible interpretation become an executive KPI. When an analysis identifies likely drivers, distinguish descriptive associations from causal evidence. A dashboard showing two movements together does not show that one caused the other.
Pricing and operational limits: verify the complete path
The announcement and Data setup guide reviewed here do not provide a standalone Data-agent tariff or a complete per-analysis price. Do not describe it as free or apply unrelated API token prices to the whole workflow. Verify the purchased plan, included capabilities and connector terms for the intended workspace.
Sites documentation says beta usage is included up to plan-specific limits, which can change. That is not an unlimited hosting commitment and does not remove the regional restriction. Warehouse queries, external BI services, scheduled refreshes and human review can add cost or capacity constraints outside the Data plugin itself.
For a pilot, measure accepted analyses, warehouse resource consumption, elapsed time and reviewer corrections. Put a limit on expensive exploratory queries before enabling recurring refresh. A cheaper initial answer is not a saving if its definition or recipient list has to be reconstructed manually every time.
Decision checklist: five gates before expanding access
1. Verify the exact account, region and destination
Record the workspace, eligible role, Data plugin, source app, connection identity and intended output destination. Confirm availability in the actual account rather than from the plugin directory alone. For a German team, keep Sites out of the rollout plan while its documented EEA exclusion applies. Pass only when the selected end-to-end path is both available and approved.
2. Prove the query boundary with synthetic records
Create an allowed and a denied dataset slice in a test environment. Verify expected table, row and column restrictions through the connected identity, including an explicit denied-access request. Retain redacted query evidence and the source-side authorization outcome. Stop if a connector requires wider permissions than the use case justifies; do not solve a failed test by granting a broader warehouse role.
3. Freeze one metric contract before comparing results
Choose one existing business question and its approved definition. Record the source version or extraction time, join grain, period, timezone, filters and expected reconciliation result. Require the agent to show its assumptions and evidence. Pass when a reviewer can reproduce the result; pause when the answer relies on an unresolved definition or unexplained difference from the baseline.
4. Review the copied data and test the recipient
Where a publishing route is available and approved, inspect the artifact’s included data and intended audience before release. Test with a separate permitted recipient and a separate denied recipient using synthetic content. Exercise source revocation and artifact-access removal independently, recording what each actually does. Block sharing until sensitive fields, audience scope and removal ownership are resolved. Do not test a public link using real confidential records.
5. Bound refresh and downstream actions
Assign a refresh owner, source identity, spending limit and failure notification route. Recheck whether a later refresh can add fields or change the audience’s exposure. Keep Slack sharing, email distribution and business-system writes disabled until their destination and approval controls have been reviewed. Apply human approval gates to consequential actions rather than treating a generated recommendation as an instruction to execute.
Start with the output boundary, not a company-wide enablement
The Data agent offers a potentially useful interface to established data infrastructure. Its benefit depends on maintaining the definitions and permission boundaries that made that infrastructure trustworthy in the first place. The documented copy into Sites, together with its launch availability limits, makes output governance a purchasing prerequisite—not a cleanup task after dashboards circulate.
Begin with one non-sensitive business question, one source identity and one approved destination. Expand only after query restrictions, result reconciliation, recipient access and removal tests pass. These controls add review work and may slow the initial rollout; they also make it possible to distinguish a useful analysis workflow from a convenient new export path.
For a scoped AI automation and implementation engagement, the first deliverable should be a data-flow and acceptance review: what is queried, what is copied, who receives it and how the copy is withdrawn. This is engineering guidance, not legal advice. Have counsel and your data-protection team assess the actual processing arrangements and applicable obligations.
