ChatGPT Usage Data Shows Where People Work, Not Whether AI Pays Off

OpenAI’s Signals data covers ChatGPT use for work across 165 activities in nearly 100 countries and describes how usage changes over time ¹. For a CTO building a board case on enterprise AI adoption, that scope can help identify questions to investigate. It does not report whether the work got faster, better, cheaper, or more valuable ¹.

That gap matters when AI spending reaches the board agenda. Usage patterns can help motivate a pilot. They cannot, by themselves, justify a claim about return on investment.

What the ChatGPT at work data actually covers

OpenAI published Signals on October 26, 2026, describing how people use ChatGPT for work across 165 activities and nearly 100 countries, and how usage changes over time ¹.

That scope offers a broad external lens for generating questions. But the supplied description does not specify the population sampled, the method, the observation window, or how OpenAI defines a “work activity” or an instance of “use” ¹.

Those gaps limit what can safely be inferred from the description. It indicates that people use ChatGPT for work across many activities ¹. The description does not establish that the data is a census of enterprise AI adoption or a ranking of which teams perform best.

A defensible approach is to treat it as a prompt for internal questions, not a verdict. If an activity appears in the external data, ask whether an equivalent workflow exists in-house, whether staff have the right access, and whether the task can be measured. Those questions do not, on their own, establish that the task should be automated or funded.

Patterns suggest hypotheses, not explanations

The data’s coverage and tracking of changes over time can help leaders form hypotheses about where ChatGPT is used for work and how usage shifts ¹. It does not explain why those shifts occur.

A rise in use could mean more people got access, existing users returned more often, a workflow changed, or people began classifying their work differently. The supplied description does not distinguish among these explanations or name specific activities that are rising or falling ¹.

For a deployment decision, the question is not simply whether a task appears in usage data. It is whether the task fits AI assistance given your error tolerance, review capacity, and desired outcome.

Use external patterns as a shortlist generator for AI use cases at work, not as an investment ranking. Weigh any candidate against internal data on volume, cost, risk, and how easily you can evaluate output. A popular use case may be hard to control; a less visible one might be a better pilot.

What usage cannot prove about AI value

Usage patterns alone do not establish productivity gains, quality improvement, cost reduction, satisfaction, or business value. Those require separate measurement and a defined comparison. The supplied description reports coverage and changes in usage, not outcomes ¹.

It does not provide evidence about whether a task got done faster, whether output was more accurate, whether rework dropped, or whether time saved moved to something higher-value ¹. Nor does it report whether AI-assisted results needed more review.

Usage alone also does not establish cause. A team might use ChatGPT more because access expanded, because the underlying process got harder, or because policy changed. The supplied description does not say which, if any, explains a change ¹.

The same gap between activity and outcome shows up elsewhere; for a related case, see More AI-Generated Code, No Matching Increase in Completed Work.

That is the line between adoption and impact:

• Adoption: who can use the tool, where, and how often.
• Impact: whether time, quality, cost, risk, or customer outcomes changed.

Keep these separate in board reporting. “Staff use ChatGPT for this kind of work” is a behavioral claim. “ChatGPT improves this work” is an outcome claim, and it needs company-specific evidence, not borrowed usage data.

Cross-activity and cross-country comparisons need caution

The reported scope of 165 activities and nearly 100 countries is broad ¹. The supplied description does not explain how activities are defined, how use is measured, or how populations and time windows are selected ¹.

Two teams can share an activity label and still have different workflows, complexity, volume, review load, and consequences for errors. A country-level pattern might reflect differences in access rather than differences in adoption. The source description does not establish that raw usage should be treated as a performance score ¹.

Before comparing internal groups, define the basis of comparison: task volume, user population, access policy, workflow maturity, and the outcome under test. These are measurement choices a company has to make itself.

Read external patterns directionally. They can point toward a workflow worth checking. They do not show that one department, country, or team is better at adopting AI.

A layered model for measuring generative AI adoption

Separate measurement into layers so that an adoption number is not mistaken for proof of value.

Layer	What to track	What it answers
Exposure	Who has access, under what conditions	Who could use the tool?
Behavior	Where and how often it is used, and for what task	Where is use happening?
Outcome	Time, quality, review effort, cost, risk, customer results	Did the business result change?

Signals data primarily concerns behavior: activity coverage and changes in usage over time ¹. Exposure and outcome measurement still have to come from inside the company. An enterprise AI gateway with usage analytics, audit logs, and role-based access can help record exposure and behavior across teams, but outcomes still need their own measurement.

For each workflow you target, set a baseline before deployment. Name the outcome that matters to the decision, and run a comparison group or period where you can. Track review effort and quality alongside speed or cost; a task that looks faster on paper can still cost more once you count corrections.

Pair the numbers with qualitative review. Usage data alone does not establish whether outputs are good enough, whether staff rely on them appropriately, or whether the workflow introduces new risk. That judgment has to happen inside your own process and controls.

Using external usage data without overstating it

Treat the global scope and activity coverage as inputs to your adoption roadmap, not proof that a use case deserves funding ¹. The supplied description does not claim every company or activity is represented equally, so it cannot substitute for your own workflow inventory ¹.

For each candidate workflow, ask:

• Is the task defined clearly enough to measure?
• What is the baseline for time, quality, cost, or risk?
• Who reviews output quality and exceptions?
• What evidence would justify expanding, changing, or ending the deployment?

Report adoption and outcomes in separate sections of the dashboard. Adoption shows where people use a tool; outcomes show whether a result changed. Combining the two risks presenting activity as evidence of productivity.

What to do next

Use the 165-activity scope as a trigger to inventory your own workflows, not as proof that those activities carry equal weight in the data ¹. Pick workflows where you can define task boundaries, output quality, review effort, and business value.

For each one, log access, use, role, and task type separately from time saved, quality, error rate, and financial result. Set a review date, and keep definitions and populations stable when you check for change over time.