# OpenAI Put a Dashboard Builder Inside ChatGPT Work

> OpenAI's Data agent lets business users build dashboards in ChatGPT Work. The harder job moves to metric definitions, benchmarks, permissions, and review.

- Published: 2026-09-11
- Author: Gene Dai
- Canonical: [https://digidai.github.io/2026/09/11/chatgpt-work-data-agent-dashboard-labor/](https://digidai.github.io/2026/09/11/chatgpt-work-data-agent-dashboard-labor/)
- Topics: Artificial Intelligence, Data Analytics, Future of Work, Employee Experience, Organizational Design

---

On September 10, OpenAI put a sample request beneath a new product announcement: "Diagnose why weekly active users
changed last week." A worker could address @Data inside ChatGPT Work, ask that question in ordinary language, and
receive an investigation with comparisons, likely drivers, suggested checks, and an interactive dashboard.

The request used to arrive in somebody else's queue.

A product manager might open a ticket for the data team. An analyst would ask which users counted as active, which time
zone closed the week, whether employees and test accounts belonged in the population, and whether a tracking change had
broken the comparison. The analyst would locate tables, inspect joins, write or reuse a query, reconcile the answer with
a certified report, choose a chart, and explain the limits. The manager might receive the dashboard hours or days later.

OpenAI's new [Data agent in ChatGPT Work](https://openai.com/index/put-data-to-work/) is designed to compress that
chain. It connects to approved company data, interprets business definitions, investigates a question, builds a
dashboard, and can recommend an action. It reaches data systems such as Amazon Redshift, Google BigQuery, Databricks,
MongoDB, and Snowflake. It can also work with established business intelligence products including Power BI, Tableau,
Sigma, and ThoughtSpot.

Inside OpenAI, the product already has a broad stated footprint. The company says nearly all of its product team and
more than two-thirds of its go-to-market organization use the underlying data-agent capabilities to analyze company data
themselves. It names 11 alpha customers and describes teams using the agent to study sales, spending, onboarding,
campaigns, supplier opportunities, and staffing.

The percentages document internal reach. They do not measure answer accuracy.

OpenAI does not publish the number of people behind either internal-use percentage. Nor does it provide the frequency or
difficulty of their questions, a benchmark pass rate, the cost per accepted analysis, or the business results of the
decisions that followed.

Most customer examples on the page are statements supplied by customers and presented by the vendor. One customer says
it rebuilt a performance dashboard in half an hour and found errors in the original. Another says a dashboard associated
use of its AI product with roughly three times the campaign-launch rate of nonusers. Neither example establishes how
often the agent produces the right answer across unfamiliar questions.

More revealing are the prerequisites. OpenAI says its data team created shared business definitions, set access rules,
and added safeguards before broad internal use. Microsoft tells Power BI customers to prepare semantic models and
validate generated analysis. Databricks provides benchmark sets, generated-SQL review, manual corrections, and a
monitoring queue for its Genie agents. Google warns that its conversational analytics system can return plausible but
factually wrong output and recommends validating every result.

Natural language changes who can ask. It does not decide what a metric means.

Routine dashboard requests may no longer consume the same analyst hours. Business users may explore their own questions
before a formal review. Yet somebody still has to define revenue, retention, active use, cost, and headcount. Table
relationships need maintenance. Teams need to test common questions, investigate failures, and decide whether each
result is safe to publish or use.

Part of the dashboard queue is moving upstream, into the definitions and tests that make self-service possible. Review
also moves downstream, to managers who must judge an answer they did not construct.

## September 10 opened @Data to business users

Installation starts in the plugin directory. A ChatGPT Work administrator can configure Data and its source plugins,
then decide which roles may use them. A worker starts a conversation with @Data and asks a business question.

The product runs within configured connections and identities. OpenAI says queries retain the permissions of the
connected account, including table, row, and column restrictions. Administrators choose the available connections. The
agent can draw on semantic layers, metric definitions, custom calculations, table relationships, existing dashboards,
files from Google Drive, and documents from SharePoint.

OpenAI names several jobs the agent can attempt. It can diagnose a metric change, design a KPI framework, prepare a
leadership readout, examine adoption and retention, analyze product growth, and explore financial or operational
performance. It can publish or interact with dashboards in familiar BI products. After the analysis, it can suggest next
steps, identify people who should be involved, share findings through Slack or email, and carry out actions that a
person approves through connected tools.

Generating a query answers a bounded retrieval problem. The product promises a wider workflow. Diagnosing a change
requires selecting comparison periods, finding candidate drivers, checking data quality, deciding which correlations
deserve attention, and explaining what the evidence cannot establish. Designing a KPI framework adds choices about
company goals, leading indicators, guardrails, ownership, and targets. Recommending an action introduces a consequence
outside the dashboard.

OpenAI places a human approval step before connected action. The page is less explicit about the approval required
before a generated dashboard becomes a shared management record. A worker can edit, share, and refresh the output. Each
verb creates a different state. An editable draft may support exploration. A shared chart may be treated as an official
number. A refreshed dashboard may continue informing decisions after its source schema or company definition changes.

The release does not disclose separate pricing for Data, a general accuracy score, latency, warehouse-query cost, or
service-level commitments. It does not say how many alpha questions failed, how many required analyst intervention, or
how often a generated explanation was removed before sharing. These omissions do not show that the product performs
poorly. They define what the public evidence cannot answer.

Yuji Shono, head of NTT DATA Group's Global AI Office, says licensing cost, effort, and technical expertise had limited
dashboard use across the organization. In the alpha program, non-engineers in sales and corporate functions built and
updated dashboards in plain language. At Doeren Mayhew, teams in marketing and finance reportedly began building
office-specific dashboards within two days. Piston's leaders used the agent across sales-funnel, support-ticket, and
card-spend analysis.

These teams did not need to wait for a specialist to translate every first question into a report. The shorter path can
reduce time to an initial view and let workers refine a question while the business context is still fresh.

It can also increase demand. When asking becomes cheaper, people ask more. A manager who once accepted a monthly report
may explore five cuts of the data, build a local scorecard, and request a deeper explanation. The data team may receive
fewer simple chart tickets while inheriting more disputed definitions, unusual joins, access questions, and requests to
certify analyses that began elsewhere.

Self-service analytics has always carried this tension. The new product changes its reach and speed. A conversational
agent can assemble data, documents, narrative, charts, and approved actions inside one session. An error can therefore
travel farther before somebody notices it.

## Plain language kept the semantic layer

Consider the launch prompt about weekly active users. It appears simple because the hardest choices have been hidden.

What event makes a user active? Does a login count, or must the person complete a product action? Is the week a rolling
seven-day window or a calendar week? Which time zone closes Sunday? Are employees, contractors, bots, free accounts, and
deleted accounts included? Does a user with activity in two workspaces count once or twice? Did the instrumentation
change between the two periods?

SQL can encode each answer. The prompt does not supply them.

A semantic layer stores the organization's approved interpretation of business terms and the relationships needed to
calculate them. OpenAI names Databricks Genie Ontology, dbt, Snowflake Horizon, GitHub, BI dashboards, and other trusted
sources as context for Data. That architecture lets a worker ask about "weekly active users" without naming a table or
remembering a join. The model receives more than raw column names.

One preprint offers a bounded measure of that context. Michael Rumiantsau and Ivan Fokeev tested three frontier models
on [100 natural-language questions over a synthetic retail dataset](https://arxiv.org/abs/2604.25149). Each model first
received the warehouse schema alone, then the same schema plus a four-kilobyte document defining measures, conventions,
and ambiguous terms. The added semantics improved accuracy by 17 to 23 percentage points.

Accuracy with the semantic document ranged from 67.7% to 68.7% in the authors' single-shot protocol. Roughly one answer
in three still failed the benchmark. The paper is an arXiv preprint rather than peer-reviewed research, uses a synthetic
dataset, and does not test OpenAI's Data agent. It supports a narrower claim: explicit business definitions can
materially improve natural-language analytics, but definitions alone did not make the tested systems reliably correct.

Microsoft's current
[Power BI guidance for Copilot and semantic models](https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-semantic-models)
describes the same problem from a deployed product. Microsoft tells developers to prepare the model for Copilot
consumption and tells users to inspect the fields and filters behind an answer. Its documentation includes an example in
which a profit-percentage request returns a profit value, and another in which a year question selects a customer's
birthday column instead of the intended date table.

Microsoft also states that the experience is nondeterministic. A model can return an inaccurate answer even when the
prompt and semantic model appear sound, and the same prompt against the same data need not return the same answer.
Generated DAX can parse correctly yet behave incorrectly under a different filter context. Less experienced analysts are
told to validate and understand the code before putting a generated measure into a model.

A malformed query often fails loudly. A valid query against the wrong date, grain, or join can produce a polished
number. Natural-language explanation can make that number easier to trust because the prose removes the visible friction
of the calculation.

The semantic layer reduces ambiguity only when people maintain it. A revenue definition changes when a company changes
refund policy, introduces a marketplace, acquires a business, or moves from annual contracts to usage. A retention
metric changes when the eligible population changes. A regional hierarchy changes when sales territories move. Each
revision has to reach the agent's context, benchmark answers, certified dashboards, and documentation.

Workers typing @Data will see little of that maintenance. Analytics engineers, data modelers, finance partners,
operations leaders, privacy teams, and domain experts supply the accumulated judgment that the agent consumes at query
time.

Plain language therefore changes the interface to data work more quickly than it changes the data work itself. The
requester no longer needs to express the question in SQL. The organization still needs an executable definition.

## Eleven alpha customers described the queue they skipped

OpenAI's launch page offers 11 customer examples. They span accounting, food delivery, industrial science, software,
financial services, drones, consulting, and data work. The variety shows that dashboard demand is not confined to an
analytics department.

ServiceTitan says a generated dashboard found that users of Atlas, its AI sidekick, launched campaigns at roughly three
times the rate of nonusers. The ratio can support an onboarding investigation. It does not establish that Atlas caused
the higher launch rate. Early adopters may differ in company size, digital maturity, campaign intent, account tenure, or
support exposure. A decision about onboarding needs the cohort definitions and a plan to test those alternatives.

micro1 says its operations team rebuilt performance-tracking dashboards in half an hour and caught errors in the
original. That is a vivid cycle-time example. The public statement does not say how many dashboards were rebuilt, what
the original errors were, who verified the replacement, or whether the half-hour includes source preparation and final
review. The agent may have corrected an old manual mistake. It may also have benefited from substantial evaluation work
that micro1 had already performed as an OpenAI partner.

CookUnity says its growth team checked an agent-built conversion dashboard against internal reports before using it to
plan seasonal acquisition spending. That validation step may be the most instructive part of the account. The team did
not treat rapid generation as sufficient evidence. It reconciled the result with an existing reference before money
moved.

At Turing, a business-operations team explored operational metrics while Usama Nadeem, a senior data scientist, is the
named source on the launch page. That pairing complicates a simple replacement story. Business users gained a direct
interface while a data specialist remained close enough to describe the result. NTT DATA similarly frames the gain as
enabling non-engineers rather than eliminating the data function.

The cases suggest at least five stages in the old dashboard queue:

1. A business user submits a question.
2. An analyst clarifies the metric and population.
3. The data team finds sources and writes or reuses logic.
4. Somebody validates the result and presentation.
5. A manager decides what to do.

A conversational agent can compress the first and third stages for many questions. It can ask follow-ups, select
sources, generate queries, and build charts while the requester stays in one conversation. With good semantic context,
it may also reduce clarification at the second stage.

Validation and decision ownership remain. They may become more demanding because the volume of draft analysis rises. The
old queue limited how many dashboards a company could produce. That limit was frustrating, but it also forced a request
to compete for analyst attention. When generation becomes abundant, review capacity becomes the new constraint.

There is a second distributional issue. Senior operators often know which number looks implausible because they have
seen years of budgets, product changes, and reporting disputes. A new employee may accept a smooth explanation without
that history. Giving both workers the same interface does not give them the same ability to detect a wrong cohort or a
broken comparison.

The product could narrow an access gap by letting more employees investigate data. It could widen a judgment gap if
companies remove the analyst conversation that once taught people how a metric was constructed. The outcome depends on
whether self-service includes a visible route to definitions, source logic, review, and correction.

The alpha examples do not settle that outcome. They show where organizations found useful work and what early users
valued. They do not provide a common denominator for accuracy, adoption, time saved, review time, or decisions improved.
A buyer can learn from them without turning them into an average ROI estimate.

The strongest case for the product is not that analysts make every old dashboard perfectly. They do not. Requests wait,
requirements get lost in handoffs, spreadsheets retain stale formulas, and a person can choose the wrong join as easily
as software can. micro1's statement that the agent caught errors in an existing dashboard is evidence of one such
failure, even though the public account does not reveal its severity or replication.

A business user also holds context that a central data team may lack. A growth manager knows that a campaign paused
midweek. A supply manager knows that a vendor changed lead times. Keeping that person in a live conversation can surface
the relevant follow-up sooner than a ticket exchange. Generated SQL, cited sources, and benchmark comparison can make
some reasoning easier to inspect than a spreadsheet assembled through undocumented manual steps.

The fair comparison is therefore agent-assisted self-service against the real queue, not against an imaginary analyst
who answers instantly and never errs. Review should preserve the product's speed advantage. If every exploratory chart
requires the old intake process, the organization has bought a new interface without changing the work.

## Analysts inherit benchmarks and corrections

Databricks describes a data agent as a long-running collaboration between data teams and business users. Its
[Genie monitoring documentation](https://docs.databricks.com/gcp/en/genie-agents/monitor) makes that collaboration
concrete.

An agent author can inspect generated SQL, correct it, and save the corrected query as an instruction. Managers can
review questions flagged by users. A monitoring view tracks conversations, ratings, and recurring issues. Each Genie
agent can hold as many as 500 benchmark questions. Databricks recommends testing two to four phrasings of common
questions against the same expected query because ordinary users will express one intent in different ways.

Launch opens a new testing queue.

The data team must choose representative questions, approve the reference answer, and examine differences between
expected and generated results. When fiscal quarters, product categories, or account ownership change, the benchmark and
context need revision. User feedback needs triage. A correction that solves one question can damage another, so a
release needs regression testing.

The agent may write more SQL while the analyst spends more time on the test system around it.

More agent-written SQL changes the role mix; it does not supply an automatic job count. The U.S. Bureau of Labor
Statistics currently projects
[data-scientist employment to grow 35% from 2025 to 2035](https://www.bls.gov/ooh/math/data-scientists.htm), from
275,600 workers to 371,000. It projects about 24,800 openings a year and reports a May 2025 median annual wage of
$120,230. BLS explicitly expects AI adoption to increase demand for workers who help organizations use data and improve
business processes.

The category is imperfect for this product. "Data scientist" does not cover every BI analyst, analytics engineer, data
modeler, or finance analyst who supports a dashboard. A ten-year occupational projection cannot predict how one
September product launch will affect hiring. The figures do prevent an equally weak claim that conversational dashboards
make analytical labor obsolete.

The mix of work can still shift sharply.

Routine requests with stable definitions are the clearest candidates for self-service. "Show weekly orders by region
using the certified sales model" gives the agent a bounded metric, dimension, source, and output. An analyst may no
longer need to build that chart by hand.

Ambiguous and consequential questions move in the other direction. "Why did margin fall?" can cross pricing, discounts,
product mix, logistics, accounting, returns, currency, and data quality. A generated set of likely drivers can
accelerate exploration. It can also lead a manager toward the first available explanation. The review needs someone who
understands both the model and the business.

Several responsibilities become more visible:

- Metric owners decide which definition is official and when it changes.
- Analytics engineers maintain joins, grains, dimensions, and reusable logic.
- Agent curators supply instructions, trusted queries, and examples.
- Reviewers investigate failed benchmarks and high-consequence outputs.
- Platform owners manage access, query cost, retention, and integrations.
- Business leaders own the action taken from the result.

These are responsibilities, not evidence of six new job titles. One worker may hold several, and existing data teams
already perform much of the work. The product changes the volume and location of the tasks. It can replace chart
assembly while increasing the return on careful semantic modeling and evaluation.

Junior development needs attention. Simple tickets teach new analysts where data lives, how leaders misuse metrics, and
which exceptions matter. If an agent absorbs all routine work, the entry path loses a practice surface. A team can
preserve it by assigning junior analysts to benchmark design, failure review, paired validation, and supervised metric
changes. Sending them directly to certify executive dashboards without that apprenticeship would save time at the wrong
level.

Business users need training too. Prompt technique is the smaller issue. They need to know when a question is
exploratory, when a result is certified, which evidence supports a causal claim, and when a chart requires specialist
review. A polished dashboard should not erase those states.

## Competitors expose the same hidden labor

By OpenAI's launch day, business users already had competing routes into conversational analytics. Google, Microsoft,
Databricks, Salesforce's Tableau, Snowflake, ThoughtSpot, and others place natural-language analysis beside enterprise
data. Their product pages compete on access, context, explanation, and action. Their operating documentation converges
on a less glamorous requirement: somebody has to prepare and test the data experience.

Google made Conversational Analytics in BigQuery generally available in June 2026. Its
[current product documentation](https://docs.cloud.google.com/bigquery/docs/conversational-analytics) recommends
verified queries, glossaries, instructions, table descriptions, clean data, and prebuilt views for joins. It warns that
Gemini for Google Cloud can produce plausible but factually incorrect output and tells customers to validate all output
before use.

Product lead Vasiya Krishnan and senior engineering manager Jiaxun Wu described the June release around visible
generated SQL, context citations, clarification requests, and stored business meaning. Those features place evidence in
front of the user instead of asking for blind trust. They still require someone to author or approve the verified query
and glossary entry that appears behind the answer.

The same documentation advises teams to narrow scope. If an agent needs more than 20 data sources, crosses teams with
different metric definitions, or prioritizes different result types, Google suggests creating additional agents. It also
tells administrators to set project, user, and query spending limits. Natural language lowers the user's technical
barrier. It does not eliminate warehouse compute or the cost of repeated exploration.

Google's design makes query logic inspectable and supports verified deterministic SQL for matching questions. That
tradeoff is revealing. The most reliable answer may come from a reusable query that a person has already checked, with
the agent extracting parameters such as product, region, and date. In such cases, the model improves access to trusted
analysis more than it invents the analysis anew.

Microsoft takes a similar approach in Power BI. Semantic models can be marked ready for Copilot consumption. Users can
inspect the visual, fields, and filters selected by the agent. Developers can validate generated DAX. Microsoft also
notes that traditional report visuals, data explorations, or Excel may be more convenient than chat for many users.
Conversation is one interface, not the inevitable destination of every analysis.

Databricks makes benchmark and feedback work explicit. Tableau markets an AI-infused semantic layer and conversational
agent.
[Snowflake describes](https://www.snowflake.com/en/blog/engineering/snowflake-coco-cowork-token-spend-efficiency/)
agentic data analysis as a sequence that can require hundreds of model calls, making cost per trusted outcome more
useful than cost per attempt. The vendors use different architecture and commercial language, but each depends on
business definitions that do not originate in a foundation model.

Some BI creation can move from specialist labor to software consumption. The company may spend less analyst time on
routine charts while paying for ChatGPT Work, warehouse queries, connectors, partner products, and longer agent
sessions.

Investment in the data platform then matters more. Clean models, documented measures, access policies, and trusted
queries can support several interfaces at once. A weak semantic foundation creates repeated errors across them.

Evaluation becomes recurring operating work because models, schemas, products, and company definitions all change. A
benchmark passed in September does not certify an October release or a reorganized sales territory.

Procurement cannot settle the comparison with a feature checklist. The relevant unit is a reviewed analysis used for a
decision, with the cost of data preparation, model access, queries, validation, rework, and any downstream error
included. A cheap first answer can be expensive if it sends finance toward the wrong forecast. A costly semantic layer
can pay for itself across thousands of reliable questions.

The public evidence does not yet provide that cross-vendor cost. Buyers will have to produce it inside their own
workflows.

## A review file for agent-built dashboards

An agent-built dashboard needs a state between "generated" and "official." A review file can supply it without forcing
every exploratory question through a full audit.

The file should travel with the analysis rather than live in a separate policy document:

| Review field         | Record to keep                                                                       | Primary owner               | Failure it catches                                     |
| -------------------- | ------------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------------------ |
| Business question    | Exact prompt, intended decision, population, and period                              | Requester                   | A precise chart answering the wrong question           |
| Decision consequence | Exploration, team action, customer action, finance commitment, or regulated decision | Business owner              | Review effort that is too light for the stakes         |
| Semantic source      | Certified model, glossary, metric layer, or local instruction used                   | Metric owner                | The same term carrying two definitions                 |
| Metric definition    | Numerator, denominator, exclusions, time zone, grain, and version                    | Analyst or finance owner    | Silent changes to revenue, retention, or active use    |
| Data boundary        | Tables, documents, refresh time, missing sources, and known quality issues           | Data owner                  | Current-looking output built on stale or partial data  |
| Access boundary      | Connected identity plus table, row, and column restrictions                          | Platform administrator      | A correct answer disclosed to the wrong person         |
| Trusted answer       | Approved query, certified dashboard, or hand-checked sample                          | Analyst                     | Fluent output with no reference result                 |
| Benchmark variants   | Common question plus two to four alternate phrasings                                 | Agent curator               | Accuracy that depends on one carefully worded prompt   |
| Result parity        | Values, filters, cohorts, joins, and totals compared with the trusted answer         | Reviewer                    | Valid code selecting the wrong business logic          |
| Narrative boundary   | Supported drivers, correlations, unknowns, and causal claims removed                 | Domain reviewer             | A correct chart paired with an invented explanation    |
| Query cost           | Warehouse scan, model use, connector cost, retries, and review time                  | Platform and finance owners | Self-service volume hiding a rising operating bill     |
| Publication state    | Draft, reviewed, certified, shared with limits, revised, rejected, or retired        | Business owner              | Exploratory analysis circulating as an official record |
| Refresh owner        | Trigger for source, schema, definition, model, or policy change                      | Metric owner                | A once-correct dashboard decaying unnoticed            |
| Follow-up evidence   | Action taken, observation window, outcome, error, reversal, or no decision           | Decision owner              | Dashboard production mistaken for business value       |

Take the weekly-active-user prompt. The requester first records whether the dashboard is exploratory or will change a
product plan. The metric owner identifies the certified definition and version. The data owner records the latest
complete event date and any instrumentation change. A trusted query supplies the expected total for a small set of
periods and segments.

The benchmark set should include ordinary variation: "weekly active users," "people active last week," "seven-day active
accounts," and a deliberately ambiguous request. The agent should clarify the last question rather than choose a
definition silently. The reviewer compares totals, filters, join behavior, and exclusions. The domain owner then checks
the explanation of likely drivers. A correlation between a release and activity belongs in the analysis; a claim that
the release caused the change requires more evidence.

Review depth should follow consequence. A private exploratory chart may need a visible source and a warning. A metric
used in a weekly team meeting needs benchmark parity and an owner. A forecast that changes hiring, pricing, inventory,
customer treatment, or financial guidance needs deeper review and a record of assumptions. The same interface can
support all three, but the product should not make their evidence states look identical.

Each perspective changes the review question. A CFO needs total cost and reconciliation with booked financial measures.
The platform administrator needs proof that the connected identity and sharing destination preserve the intended access
boundary. An analyst needs enough trace to reproduce the result. The manager owns the decision that follows.

An employee or customer affected by that decision sees something else. If a generated chart changes a sales target,
staffing plan, service priority, or account treatment, the person may need to know which period and population were
used. A review file cannot resolve every disagreement, but it can stop an editable exploration from acquiring the
authority of a certified record without a named owner.

Sampling can keep the workload bounded. A data team does not need to approve every question before a user sees a draft.
It can certify common metrics, benchmark frequent prompts, review a sample of ordinary questions, and require escalation
for high-consequence outputs or anomalies. Failed questions should enter a correction queue with enough context to
reproduce them.

The file also separates four kinds of value.

Time to first view measures how quickly a worker gets an initial analysis. Accepted-analysis rate measures how often the
result passes the required review without material correction. Decision cycle time measures whether the responsible team
acted sooner. Outcome measures track what happened after the action. These can move in different directions.

An agent might cut time to first view from two days to ten minutes while half of the drafts require changes. That can
still be useful for exploration, but it is not a 99% reduction in analysis cost. Another workflow may produce fewer
dashboards while improving a high-value inventory decision. Counting dashboards alone would favor the busier system.

Review labor belongs in the denominator:

`cost per accepted analysis = software + warehouse + connector + preparation + review + rework / accepted analyses`

The equation is a management frame, not an accounting standard. It forces the software invoice and human work into the
same view. The organization can then compare the old ticket process with the agent-assisted process on questions of
similar difficulty and consequence.

Workforce changes should be recorded separately. Analyst hours released from routine chart production may move to data
quality, experimentation, forecasting, or fewer open roles. Business users may spend more time exploring data or less
time waiting. Managers may inherit review. None of those destinations can be inferred from the number of @Data
conversations.

Each party can make a narrower promise. The product team can promise faster access to a draft. The data team can certify
a defined set of metrics and questions, while finance measures total cost and a business leader owns the decision.
Employees can see whether a dashboard is exploratory or approved before it affects their target, budget, or performance
discussion.

## Next month's KPI meeting tests the result

In October, a product leader will open a dashboard that began as an @Data prompt. The chart may show weekly active users
falling after a release. The colors will be finished. The explanation will name likely drivers. A link may offer to send
the findings to Slack.

Before that click, the leader can inspect which definition of active use was applied, how the week closed, which
accounts were excluded, and whether the total matches a trusted query. An analyst can review the unusual segment instead
of rebuilding every chart. If the explanation reaches beyond the evidence, the team can cut it while keeping the
verified result. If the question exposes a missing definition, that correction can improve the next request.

Business users gain the first move. Data specialists maintain the shared logic and concentrate on hard exceptions.
Managers carry a clearer duty to distinguish a generated view from a certified decision record.

OpenAI has reduced the first move to a short sequence: install a plugin, connect approved sources, type @Data, and ask.
At the KPI meeting, the screen still needs to reveal the metric definition, reference query, connected identity, and
name beside the final approval.

## Continue reading

- [One Employer Reached 141 AI Solutions. Another Kept Three.](https://digidai.github.io/2026/09/10/ai-sandbox-141-solutions-hidden-work/): See why shared review, protected time, and technical support separate durable AI tools from abandoned experiments.
- [Software Seats Meet Salesforce's Agentic Work Units](https://digidai.github.io/2026/08/27/salesforce-agentic-work-units-software-seats/): Connect agent activity and software cost to accepted business outcomes and human review.
- [Botsitting Takes Back the AI Workweek](https://digidai.github.io/2026/07/06/botsitting-ai-workweek-operating-cost/): Measure the context, checking, and correction work that ordinary adoption dashboards leave out.
- [Microsoft Closed FY26 With 30 Million Paid Copilot Seats and a Smaller Workforce](https://digidai.github.io/2026/07/30/microsoft-copilot-scale-smaller-workforce/): Keep paid access, active use, accepted work, and workforce change in separate denominators.