How to Measure Generative AI Adoption in the Workplace

Introduction

Learning how to measure generative AI adoption in the workplace has become a board-level question because usage is climbing faster than most companies can count it. The St. Louis Fed found that 39.2% of employed adults used generative AI for work in the past week during the second quarter of 2026. That share was 28.2% in the third quarter of 2024, so weekly use rose by about eleven points in under two years. A license count or a login total says almost nothing about whether those people use the tools well, how often they return, or whether their work improves. Leaders who report adoption from seat counts alone end up defending a number that cannot survive a single follow-up question from a finance partner. This guide builds a more honest picture in layers, covering reach, frequency, depth, and outcomes, and it ends with an eight-step tutorial that includes working SQL and Python. Along the way it covers survey design, shadow AI, employee privacy, and the cohort-level diagnostics that separate healthy adoption from a shallow plateau. Readers who want background on the technology itself can start with our overview of what generative AI is before returning here.

Quick Answers on How to Measure Generative AI Adoption at Work

How do you measure generative AI adoption at work?

To learn how to measure generative AI adoption in the workplace, track four layers: reach, frequency, depth, and outcomes. Pull usage telemetry from each AI tool’s admin console, then confirm what the logs cannot show with a short survey.

Which generative AI adoption metrics matter most?

Weekly active rate among licensed users, return frequency, the share of multi-step sessions, and cost per active user matter most. License totals and one-time logins overstate adoption because they ignore repeat behavior and depth of use.

What is a normal generative AI adoption rate for employees?

Benchmarks vary by role and survey. Gallup found 15% of U.S. employees use AI daily and 30% use it a few times a week or more in May 2026, so set targets by job family.

Key Takeaways

• Adoption is a behavior change, so measure reach, frequency, depth, and outcomes together instead of counting licenses or logins.
• Combine admin telemetry with a short pulse survey; telemetry shows what people do while surveys explain why they do it.
• Report adoption by team and cohort rather than by individual, and respect minimum group sizes to protect employee trust.
• Treat shadow AI as a visibility gap to close, because unmeasured tools hide both risk and the most motivated users.

What Is Generative AI Adoption in the Workplace?

How to measure generative AI adoption in the workplace starts with defining adoption itself: the share of employees who use generative AI tools regularly, deeply, and productively in their real work, rather than merely holding a license or logging in once.

Why Seat Counts and Login Totals Mislead Leaders

Most organizations buy generative AI seats before they agree on what success looks like, which leaves the first dashboard dominated by procurement data. A seat count tells you how many licenses finance approved, and a login total tells you how many people opened a tool at least once. Neither number describes behavior change, and behavior change is what adoption actually means. A review of adoption research by IntuitionLabs cites SHRM data showing that 56% of HR professionals do not formally measure the success of their AI investments. That gap explains why so many executive updates rely on anecdotes, vendor slides, and license utilization figures that nobody has audited.

Breadth of access also hides a steep drop in depth, and the best recent evidence comes from a paper on adoption telemetry. The author reports that ActivTrak data show 82% of AI users sustain usage quarter over quarter, yet only about 2% reach consistently embedded use. Read that sentence twice, because it means a dashboard that celebrates retention can look healthy while almost nobody has changed how they work. The same paper shows a synthetic cohort in which 99.4% of users reach recurring use and the cohort still stalls, because depth never develops. A single headline percentage cannot reveal that pattern, so any honest measurement program needs at least two or three complementary views.

Login counts fail for a third reason, which is that they treat every session as equal. A person who opens a chatbot once a quarter and a person who runs a dozen multi-step research sessions every week both register as active users in a naive report. Employees also spread their usage across several tools, so a single-vendor dashboard undercounts the people who prefer a different assistant. The denominator matters just as much as the numerator, since reporting against licensed seats, total headcount, and eligible roles produces three very different percentages. Decide which denominator you will use before the first report goes out, and keep it fixed so that trends remain comparable from one quarter to the next.

A Four-Layer Model for Reading Adoption

A layered model keeps a measurement program from collapsing into a single vanity number, and it gives each stakeholder a question they can answer. The four layers used throughout this guide are reach, frequency, depth, and outcomes. Reach asks who has access and who has actually tried the tool, while frequency asks how often those people return. Depth asks how sophisticated their use is, and outcomes asks whether the work improved. Each layer builds on the one beneath it, so a weakness at a lower layer usually explains a weakness above it. When you read the layers together, a dip in outcomes can be traced back to the exact layer where people stopped progressing.

The model maps onto three questions that Worklytics uses to organize its AI adoption KPIs: is AI being used, is it used well, and is it worth it. Reach and frequency answer the first question, depth answers the second, and outcomes answer the third. Placing your metrics under those headings stops teams from arguing about whether a given number belongs on the dashboard. It also reveals where you have no data at all, which is common for depth and almost universal for outcomes. Most companies start with excellent reach data and almost nothing else.

Reach deserves a precise definition because every later metric inherits its denominator. Activation rate is the share of licensed or eligible employees who have run at least one qualifying session in the last twenty-eight days. Time to first use measures the days between license assignment and that first session, and long delays point to an access or awareness problem. Reach is a precondition for everything else, but it is also the layer where leaders most often declare victory too early. Frequency then measures return behavior through weekly active rate, the ratio of weekly to monthly users, and early return within a fortnight.

Depth and outcomes round out the picture and are harder to instrument, which is exactly why they are worth the effort. Depth captures how many distinct tasks someone brings to the tool, how long and multi-step their sessions run, and whether they use advanced features such as agents or file analysis. Outcomes translate that usage into cycle time, quality, error rates, and cost, usually by comparing teams or periods. For guidance on scaling programs once the measurements are in place, see these four strategies for scaling generative AI across an organization. Each layer needs its own owner, its own data source, and its own review cadence, otherwise the dashboard turns into decoration.

What the Latest Workforce Surveys Show About Usage

Building on that four-layer model, it helps to anchor your internal numbers against what national surveys report, because executives will ask how you compare. The St. Louis Fed tracker puts weekly use among employed adults at 39.2% in the second quarter of 2026, with generative AI assisting 6.3% of all work hours. The same tracker estimates that AI saved about 2.2% of work hours, up from 1.6% in the third quarter of 2024. Those time savings are self-reported, so the Fed treats them as approximate, and you should apply the same caution to any internal survey. The trend still matters because it shows usage rising faster than measured time savings.

Frequency tells a more sober story than the weekly headline suggests. Gallup’s workplace indicator shows that 15% of U.S. employees used AI daily as of May 2026, while 30% used it a few times a week or more. Only 52% reported using it at least a few times a year, which means roughly half of workers remain occasional or non-users even now. The gap between weekly use and daily use is the single most useful benchmark for judging whether your own program is shallow or deep. If your company reports 70% weekly use but 5% daily use, you probably have a reach story and not yet a habit story.

Variation inside similar jobs is the other lesson, and it should shape how you segment your own data. A summary of an NBER working paper by the Information Technology and Innovation Foundation reports that more than 20% of workers use generative AI in four of five detailed occupations. Yet only one in six occupations exceeds a 70% adoption rate, so the typical job sits well below saturation. The paper also finds that workers doing very similar tasks differ substantially in how much they use the tools. For measurement, that means averages by department hide the people who matter most, namely the heavy users who can coach peers and the non-users who need access or training. Segment by role and task, not just by org chart.

Building on Telemetry: The Data Sources Worth Connecting

Building on those survey benchmarks, the practical question becomes where your own usage data lives and how trustworthy each source is. Most enterprise AI products ship an admin console with aggregate usage reports, and the better ones also expose an API or export. Microsoft 365 Copilot offers usage reports over rolling windows of 7, 28, 90, and 180 days. Its Graph report endpoint returns per-user detail but is still in beta. The Viva Insights Copilot Dashboard adds adoption trends by organization and hides any group smaller than five people. Our guide to using Microsoft Copilot explains the product surface if you are new to it.

Developer tools expose richer telemetry, and they make a useful model for what good instrumentation looks like. GitHub documents its Copilot usage metrics as IDE active users, daily and weekly active users, requests per chat mode, and agent adoption. The dashboard refreshes daily with data up to three days behind, and the API can be filtered by day or by user login to find newly activated users. Whatever your toolset, insist on a user-level export so that you can compute your own metrics instead of trusting a vendor’s definition of active. Supplement vendor consoles with identity provider logs, network proxy data, and expense reports, because those sources reveal tools your official dashboards never see.

Reach and Frequency Metrics That Hold Up

Shifting from sources to calculations, start with the handful of reach and frequency metrics that are cheap to compute and hard to game. Activation rate counts licensed users with at least one qualifying session in the last twenty-eight days, divided by all licensed users. Weekly active rate counts distinct users active in a seven-day window, divided by the same denominator. Stickiness divides weekly active users by monthly active users, so a value near one means the same people return constantly and a low value means casual, sporadic use. Retention tracks the share of a first-week cohort that is still active four and eight weeks later.

Benchmarks for these metrics exist, but most of them are weaker than they look. A vendor guide from Larridin proposes that weekly active usage above 70% is strong and below 40% needs intervention, yet it offers no source or method for those thresholds. Treat such numbers as hypotheses to test against your own history rather than as targets to chase. A trend that rises steadily for eight weeks is more persuasive evidence than a snapshot that happens to clear someone else’s threshold. Record your own baseline in the first month, then judge every later reading against it.

Company context changes what a good number looks like, so avoid copying a rate from a firm of a different size or sector. Adoption patterns differ sharply between small firms and large enterprises, a gap explored in our analysis of the small business versus enterprise adoption gap. Role mix matters too, because analysts and writers use assistants more naturally than field technicians. Always publish the denominator beside the percentage, for example 61% of licensed knowledge workers rather than a bare 61% adoption. That one habit prevents most of the arguments that erupt when a number travels from a dashboard into a slide.

Depth, Breadth, and the Shallow Plateau

Beyond reach and frequency lies depth, the layer that separates enthusiasm from real workflow change. The adoption telemetry paper proposes five stages: notice, attempt, navigate, transform, and embed. A user navigates when activity appears in at least three distinct weeks. A user transforms when sustained multi-step work spans six or more active weeks, and embeds when activity continues in at least 90% of weeks since first use. The paper evaluates cohorts rather than individuals, and that design choice is worth borrowing because it avoids scoring any single employee. Stage counts give you a funnel, and the funnel shows exactly where your people stall.

The most common failure pattern is the shallow plateau, in which retention looks healthy but depth never grows. In the paper’s synthetic data, a shallow-plateau cohort places 99.4% of users at the navigate stage and carries a composite score of 49.9. A healthy cohort scores 60.5 with 25.1% of users at the transform or embed stages. Breadth alone cannot tell those two cohorts apart, since their weekly active rates look similar. Only a depth measure, such as the share of sessions that run twelve or more turns, exposes the difference. The prescribed response also differs, because a shallow plateau calls for workflow redesign and not for more licenses or more generic training.

Other failure signatures deserve a place on your diagnostic checklist. Champion dependency appears when activity concentrates in a few users, which the paper flags when the Gini coefficient of usage exceeds 0.5. Usage regression appears when late-window activity falls below 40% of early-window activity, a sign that novelty faded without reinforcement. Low task success appears when users attempt complex work and fail at it, which usually indicates an ability gap rather than an awareness gap. Worklytics adds manager-facing views of breadth, meaning distinct use cases per team, and of time to proficiency, meaning days from first use to steady use.

Treat these depth metrics as diagnostics, not targets, because every score can be gamed once people know it is watched. The paper itself warns about Goodhart risk, noting that converting scores into targets may degrade their meaning. A team told to hit twelve-turn sessions will happily pad its conversations with filler. Pair each depth metric with an outcome check, such as task success or reviewer ratings, so that inflated activity cannot pass for progress. The research on why pilots stall in large organizations, summarized in our piece on why AI pilots fail to scale, points to the same lesson.

Measuring Outcomes Without Fooling Yourself

Moving on to results, the outcomes layer is where most measurement programs either earn executive trust or lose it permanently. The core problem is attribution, because a team that adopts generative AI rarely changes only one variable. Headcount, seasonality, product launches, and tooling upgrades all move the same cycle-time metrics that you hope to credit to the assistant. Without a baseline and a comparison group, any improvement you report is a story, not a measurement. Capture at least eight weeks of pre-rollout data for each metric, and where possible stagger the rollout so that late adopters serve as a natural control group. The guide to measuring ROI on AI investments on this site walks through the financial framing in more detail.

Choose a small set of outcome measures that match how each function already defines good work. Support teams might track resolution time and reopen rate, engineering teams might track pull request cycle time and defect escapes, and sales teams might track proposal turnaround and win rate. Pair every speed metric with a quality metric, because faster output that needs heavy rework is not a gain. Cost matters as well, and cost per active user, which divides total AI spend by people who actually used the tools, should fall as adoption deepens. For a broader view of translating usage into business results, read about delivering real value with generative AI across functions.

Surveys and Interviews as a Check on Telemetry

Stepping back from the logs, remember that telemetry shows what people do but never why they do it. A pulse survey of five to seven questions, sent every quarter, fills that gap at very low cost. Useful items ask how often people use AI, which tasks they use it for, how confident they feel, what blocks them, and how much time it saves. Keep the wording behavioral, such as “In the last week, how many days did you use AI for work?” because attitudes drift away from habits. Anonymous responses tend to be more candid, but you should still tag the department and tenure band so that you can segment results.

Self-reported numbers need careful handling because people misremember and because some wish to please the sponsor. The St. Louis Fed notes that its time-savings estimates are self-reported and therefore approximate, which is the right attitude for any internal survey as well. Use surveys to rank problems and generate hypotheses, then verify the important ones against telemetry or work product. Perceived usage often runs ahead of logged usage in teams that test several tools, and behind it in teams using embedded features unknowingly. Large gaps between the two views are themselves a finding worth investigating.

Short interviews add the texture that dashboards lack, and five conversations often reveal more than five hundred survey responses. Ask the most active users to demonstrate a real task from start to finish, and ask non-users what would have to change for them to try it. Listen for process obstacles, such as unclear data rules, awkward approvals, or missing integrations, because those rarely appear in a log. The same exercise exposes inequity, since access, language, and confidence are not evenly distributed across a workforce, a theme explored in our look at the growing AI workplace divide. Feed what you learn back into training and tooling decisions quickly, because people stop answering surveys that change nothing.

Shadow AI Risks and the Blind Spots in Your Data

Turning to the tools you cannot see, every adoption dashboard has a blind spot called shadow AI, meaning AI tools that employees use without approval. A 2025 survey by ManageEngine and Censuswide found that 93% of employees admit entering information into AI tools without approval. The same study reports that 85% of IT decision makers say employees adopt tools faster than IT can assess them. Although 91% of those decision makers have some AI policy, only 54% have clear, enforced policies with active monitoring for unauthorized use. Shadow AI is best understood as a measurement gap first and a policy problem second, because you cannot govern activity you cannot see.

You can shrink the blind spot with methods that do not require reading anyone’s prompts. Review secure web gateway or DNS logs for domains in known AI categories, audit single sign-on grants and OAuth consents for AI applications, and scan expense reports for subscriptions. Then compute a shadow AI share, defined as activity on unsanctioned AI domains divided by all AI activity, and track it by team over time. A falling share suggests that approved tools are meeting needs, while a rising share suggests the opposite. Our overview of the 2025 shadow AI threat covers the security side of the same problem.

Privacy, Trust, and the Ethics of Usage Monitoring

Given the sensitivity of usage data, the ethics of measurement deserve as much design effort as the metrics themselves. Employees reasonably worry that adoption data will become a performance ranking, a layoff list, or a tool for monitoring what they type. If they believe that, they will route around official tools, and your numbers will quietly degrade. Trust is therefore a precondition for accurate measurement and not a nice extra. State the purpose of the program in plain language before collecting a single data point, and write down what you will never do with the data.

Concrete safeguards make that promise credible to skeptical employees and works councils. Worklytics’ guide to Microsoft Copilot reporting notes that admin center reports hide usernames and group names by default and that the Copilot Dashboard suppresses groups smaller than five people. Adopt the same rules for your own analytics: report on cohorts, apply a minimum group size, and prefer anonymized identifiers in exports. Never store verbatim prompts for adoption analytics when prompt length and word counts answer the same question. Check local labor rules and works council agreements before you reveal identities, since some jurisdictions require consultation or consent.

Fairness is the second ethical thread, because adoption is shaped by access and confidence as much as by motivation. Low usage in one group may reflect a missing language model, an inaccessible interface, or a manager who discourages experimentation. Measuring those groups as laggards, and rewarding or penalizing them accordingly, would deepen the very divide you hope to close. A better approach is to treat low adoption as a signal to investigate barriers and offer support. Pair every dashboard with an explicit statement that adoption data is never an input to individual performance reviews.

Governance ties these commitments together and keeps them from eroding as leaders change. Publish a short measurement charter that names the data collected, the retention period, who can see it, and how employees can ask questions. Review it whenever you add a tool or a data source, since each addition changes the privacy surface. Our guide to building an AI usage policy for employees shows how to write the acceptable-use rules that sit alongside the charter. Policies that employees helped shape are far more likely to be followed than policies handed down without explanation.

Putting Adoption Data to Work in Reviews and Budgets

On top of the dashboards, adoption data only creates value when it changes decisions, so build a regular operating rhythm around it. A monthly team review should look at reach, frequency, and depth for each cohort and name one action per cohort. A quarterly executive review should show trends, the biggest stall point, and the outcome evidence collected so far. Treat the whole practice of how to measure generative AI adoption in the workplace as an operating process with owners and deadlines, not as a one-off research project. Without that cadence, the best dashboard in the company becomes a bookmark nobody opens.

Let the diagnosed stall point decide the intervention, because the wrong fix wastes budget. The telemetry paper maps each stall to a different response. A stall at notice calls for visibility and access instead of training, while a shallow plateau calls for workflow redesign instead of more licenses. Its stage model treats each stall as a diagnosis, so the right fix always depends on where the cohort actually stalled. Use cost per active user and license utilization to reclaim idle seats and redirect that money toward the cohorts that are ready to go deeper. The broader cost levers are covered in our guide to enterprise AI cost optimization strategies.

The Future of Adoption Measurement: Agents and Task-Level Data

Looking ahead, the unit of measurement is shifting from the chat session to the task, and from the human prompt to the agent run. The NBER paper behind the ITIF summary builds the first task-level generative AI adoption indexes from a representative survey. It finds that adoption is wide but shallow, with fewer than half of workers adopting in most occupations and tasks. It also shows that indexes built from chat logs differ conceptually from survey measures and tend to over-classify conversations into generic activities. Expect vendors to add task-type fields, outcome flags, and acceptance signals to their telemetry in response. Until then, supplement raw usage with a short task inventory for each role.

Agents change the arithmetic of adoption because one person can now trigger many automated actions without typing a single prompt. Metrics such as the ratio of agentic to interactive usage, spend velocity, and task completion rate will join weekly active rate on the dashboard. When software acts on behalf of employees, the relevant question shifts from whether people use AI to whether the work it does is correct, safe, and worth its cost. Teams are already building scorecards for that question, and our walkthrough on how to measure AI agent performance is a good starting point. Disposition signals, such as how often a human accepts, edits, or overrides an agent output, are likely to become the most informative depth metric of all.

Measurement itself will also face regulatory and market pressure as disclosure expectations grow. Boards, auditors, and customers increasingly ask how AI is governed and what evidence supports claims of productivity gains. Organizations with clean cohort-level telemetry, documented definitions, and privacy safeguards will answer those questions in days, while others will scramble for months. Build the foundation for how to measure generative AI adoption in the workplace now, with simple, well-defined metrics that you can explain on one slide. The eight-step method that follows is designed to produce exactly that foundation, and it works with any combination of tools.

How to Measure Generative AI Adoption in the Workplace in Eight Steps

Next, the eight steps below turn the four-layer model into a working measurement pipeline that a small analytics team can build in about a month. The pipeline assumes you can export usage data from your AI tools as CSV files, and it uses SQLite and Python so that no special platform is required. You can swap in your warehouse of choice later without changing the logic. Each step produces an artifact that the next step consumes, which keeps the project auditable and easy to hand over. The code examples are deliberately small, so adapt the column names to whatever your vendors actually export.

Step 1 - Define adoption outcomes and the denominator

Start with a one-page definition that names the outcome you want, the people who count, and the period you will measure. An outcome might be that at least 50% of licensed knowledge workers use an approved AI tool weekly, and that 25% of them run multi-step sessions. Write down whether your denominator is licensed users, eligible roles, or total headcount, and never change it mid-year. Agree on a qualifying session, such as any chat or agent run of at least one turn, so that opening the application does not count. Name an executive owner and a data owner, and consider using the process in our guide to setting up an AI governance board to ratify the definition.

Next, translate the outcome into the four layers so that every metric has a home. List reach metrics such as activation rate, frequency metrics such as weekly active rate, depth metrics such as the stage distribution, and outcome metrics such as cycle time. For each metric record the formula, the data source, the owner, the refresh cadence, and the minimum group size for reporting. This table becomes the measurement charter that you will publish to employees in the final step. A short, explicit charter prevents the most common failure, which is two teams reporting the same metric name with different math.

Step 2 - Inventory every AI tool and data source

List every generative AI tool that employees can reach, including approved assistants, embedded features in existing software, and developer tools. For each one, note whether it has an admin console, a usage report, an API, and a user-level export. Microsoft 365 Copilot, for example, offers admin center reports over fixed windows and a Graph endpoint, as described in this Worklytics tutorial on measuring Copilot usage. Add identity provider logs, proxy logs, and expense data as secondary sources for tools you do not officially manage. Mark each source as authoritative, partial, or inferred, because that label tells readers how much to trust any metric built on it.

Step 3 - Export raw usage data and pseudonymize users

Pull user-level exports from each console on a fixed schedule, ideally every 7 days, and store the raw files in a restricted folder. GitHub, for example, lets administrators download user-level data from the Copilot usage dashboard as NDJSON for analysis in other tools. Then run a small normalizer that maps each vendor's columns to one shared schema and replaces every identity with a salted hash. The hash lets you count distinct people and follow their behavior over time without exposing names to analysts. Pro tip: keep the salt in a secrets manager, rotate it each quarter, and never commit it to a repository.

import hashlib
import os

import pandas as pd

SALT = os.environ["ADOPTION_SALT"]


def pseudonymize(identity: str) -> str:
    digest = hashlib.sha256((SALT + identity.strip().lower()).encode("utf-8"))
    return digest.hexdigest()[:16]


raw = pd.read_csv("vendor_export.csv", parse_dates=["activity_date"])
events = pd.DataFrame({
    "user_id": raw["user_email"].map(pseudonymize),
    "tool": "copilot",
    "event_date": raw["activity_date"].dt.strftime("%Y-%m-%d"),
    "session_id": raw["session_id"],
    "turns": raw["turn_count"],
})
events.to_csv("events.csv", index=False)

Step 4 - Load a clean roster and event table

Create 2 core tables in your analysis database: a roster of everyone who should be measured and an events table of sessions. The roster comes from your HR system and carries the department, role, license flag, and license date for each pseudonymized person. The roster is what makes non-adopters countable, which is the single feature that separates real adoption analytics from a list of active users. Load both tables and check that every event maps to a roster row. Investigate any orphan events, because they usually signal unmanaged accounts or contractors missing from the HR feed.

Data hygiene determines whether your numbers will survive scrutiny from finance and audit teams. Deduplicate sessions by identifier, convert timestamps to a single time zone, and drop internal test accounts before any metric is computed. Record row counts at each stage so that you can explain any change from last week's report. Many teams skip this discipline and then spend meetings debating whether a dip is real or an artifact of a failed export. Store the load script in version control so that reviewers can see exactly how the data was shaped.

CREATE TABLE roster (
  user_id TEXT PRIMARY KEY,
  department TEXT NOT NULL,
  role TEXT,
  licensed INTEGER NOT NULL DEFAULT 1,
  first_license_date TEXT
);

CREATE TABLE events (
  user_id TEXT NOT NULL,
  tool TEXT NOT NULL,
  event_date TEXT NOT NULL,
  session_id TEXT NOT NULL,
  turns INTEGER NOT NULL DEFAULT 1
);

CREATE INDEX idx_events_user ON events (user_id, event_date);

Step 5 - Compute reach and frequency metrics

With clean tables in place, the reach and frequency layers reduce to a few queries. The query below computes weekly active rate by department against licensed users, and it suppresses any department with fewer than 5 licensed people. Run it weekly and store the output so that you can chart trends without recomputing history. Add a second query for activation rate, using the first session date per person, and a third for stickiness, dividing weekly active users by monthly active users. Compare each result to your own baseline from the first month rather than to an external benchmark.

WITH weekly AS (
  SELECT strftime('%Y-%W', e.event_date) AS week,
         r.department,
         COUNT(DISTINCT e.user_id) AS active_users
  FROM events e
  JOIN roster r ON r.user_id = e.user_id
  WHERE r.licensed = 1
  GROUP BY week, r.department
),
base AS (
  SELECT department, COUNT(*) AS licensed_users
  FROM roster
  WHERE licensed = 1
  GROUP BY department
)
SELECT w.week,
       w.department,
       w.active_users,
       b.licensed_users,
       ROUND(100.0 * w.active_users / b.licensed_users, 1) AS weekly_active_rate_pct
FROM weekly w
JOIN base b USING (department)
WHERE b.licensed_users >= 5
ORDER BY w.week, w.department;

Step 6 - Measure depth and classify cohorts by stage

Depth is where your analysis starts to differ from a vendor dashboard, so give it the most care. The script below assigns each licensed person to a simplified version of the 5 stages from the adoption telemetry paper: notice, attempt, navigate, transform, and embed. It omits the task-success condition because most exports do not carry outcome flags, so treat the result as a first approximation. Aggregate the stages by department, apply the minimum group size, and never print individual identifiers in the output. Look first for cohorts where most people sit at navigate, because that pattern is the shallow plateau.

Interpret the stage table as a diagnosis and not as a score. A department with many people at notice has a visibility or access problem, one with many at attempt has an onboarding problem, and one stuck at navigate needs workflow redesign. Re-run the script monthly and compare the stage distribution with the previous month, because movement between stages is the clearest evidence that interventions work. Share the output with team leads in a group view only. Resist the temptation to build a leaderboard, since a leaderboard invites gaming and erodes the trust you need for honest data.

import sqlite3

import pandas as pd

con = sqlite3.connect("adoption.db")
events = pd.read_sql_query(
    "SELECT user_id, event_date, session_id, turns FROM events",
    con, parse_dates=["event_date"])
roster = pd.read_sql_query(
    "SELECT user_id, department FROM roster WHERE licensed = 1", con)

events["week"] = events["event_date"].dt.to_period("W")
sessions = events.drop_duplicates("session_id")
per_user = sessions.groupby("user_id").agg(
    active_weeks=("week", "nunique"),
    first_week=("week", "min"),
    multi_step_share=("turns", lambda s: (s >= 12).mean()),
)
last_week = events["week"].max()
per_user["weeks_since_first"] = per_user["first_week"].map(
    lambda w: (last_week - w).n + 1)
per_user["active_ratio"] = per_user["active_weeks"] / per_user["weeks_since_first"]


def assign_stage(row):
    if row["active_weeks"] >= 6 and row["multi_step_share"] >= 0.6:
        return "embed" if row["active_ratio"] >= 0.9 else "transform"
    if row["active_weeks"] >= 3:
        return "navigate"
    return "attempt"


per_user["stage"] = per_user.apply(assign_stage, axis=1)
table = roster.merge(per_user["stage"], left_on="user_id",
                     right_index=True, how="left")
table["stage"] = table["stage"].fillna("notice")

sizes = table.groupby("department")["user_id"].count()
summary = (table.groupby("department")["stage"]
           .value_counts(normalize=True).unstack(fill_value=0))
print((summary[sizes >= 5] * 100).round(1))

Step 7 - Add a pulse survey and a shadow AI check

Telemetry cannot see intent or unofficial tools, so add two lightweight instruments. Send a quarterly pulse survey of 5 to 7 behavioral questions about frequency, tasks, confidence, barriers, and perceived time saved. Then measure shadow AI by classifying proxy or DNS traffic into sanctioned and unsanctioned AI domains and computing the unsanctioned share by department. Compare the survey's reported usage with logged usage for each group, since large gaps point to unseen tools or to embedded features that people do not recognize as AI. Pair the findings with an amnesty message that invites people to disclose tools they rely on, and point them to the acceptable-use rules in your responsible AI policy template.

SELECT department,
       ROUND(100.0 * SUM(CASE WHEN sanctioned = 0 THEN requests ELSE 0 END)
             / SUM(requests), 1) AS shadow_share_pct
FROM proxy_ai_traffic
GROUP BY department
HAVING COUNT(DISTINCT user_id) >= 5;

Step 8 - Publish the charter, report by cohort, and iterate

Close the loop by publishing the measurement charter, scheduling the reviews, and committing to a small number of actions per quarter. The charter lists each metric, its definition, its data source, its minimum group size, and the commitment that adoption data never feeds individual performance reviews. Report to executives on trends, the largest stall point, and the evidence for outcomes, and report to team leads on their own cohort only. Revisit definitions every quarter as tools and usage patterns change. Agents that act without prompts are a growing reason to do so, as our roundup of agentic AI adoption statistics for 2026 shows. Keep the pipeline simple enough that a new analyst can rerun it in an afternoon.

metrics:
  - name: weekly_active_rate
    layer: frequency
    denominator: licensed_users
    window_days: 7
    source: events
    min_group_size: 5
    owner: analytics
  - name: stage_distribution
    layer: depth
    denominator: licensed_users
    source: events
    min_group_size: 5
    owner: analytics
privacy:
  individual_scoring: false
  store_verbatim_prompts: false
  retention_days: 400

Key Insights

• Weekly generative AI use among employed U.S. adults reached 39.2% in the second quarter of 2026, so internal adoption rates should be judged against a rising external baseline.
• Only 15% of U.S. employees used AI daily as of May 2026, according to Gallup, which shows that daily habit lags behind weekly reach and needs its own metric.
• Just one in six occupations exceeds 70% generative AI adoption, so most roles still sit well below saturation and need role-specific goals instead of one company-wide number.
• ActivTrak data cited in an adoption telemetry paper show that 82% of AI users sustain usage while only about 2% reach embedded use, so retention alone overstates change.
• A 2025 survey found that 93% of employees admit entering information into AI tools without approval, making shadow AI a measurement gap to close before totals can be trusted.
• A study of 5,179 support agents found that AI assistance raised productivity by 14% on average and by 34% for novices, so outcome gains concentrate among less experienced workers.
• Research summarized by IntuitionLabs reports that 56% of HR professionals do not formally measure AI investment success, which means disciplined measurement is itself a competitive advantage today.
• Microsoft's Copilot dashboard hides groups smaller than five people, according to a Worklytics guide, a privacy default that your own cohort reporting should copy.

The evidence points in one direction: adoption is broad but uneven, and the headline numbers hide most of what leaders need to know. Weekly reach keeps climbing, yet daily use, depth of use, and embedded workflow change remain far smaller than license counts imply. Measurement therefore has to separate the layers, report them by cohort, and pair usage data with outcome evidence from comparison groups. Shadow AI and privacy concerns add two more constraints, because unseen tools distort the numbers and heavy-handed monitoring erodes the trust that honest data depends on. Organizations that define their denominators, publish a charter, and diagnose stall points will make better decisions than those that chase a single adoption percentage. The comparison below shows how the main metric families differ in effort, risk, and usefulness.

Dimension	Seat and login counts	Weekly active rate	Stage distribution	Outcome study
Question answered	Who has access or has tried the tool	Who returns every week	How deeply each cohort uses the tool	Whether work results actually improved
Primary data source	License system and sign-in logs	Admin console or event export	Session-level events plus a roster	Business system data plus a comparison group
Effort to build	Very low, a few hours	Low, a few days	Moderate, a few weeks	High, a quarter or more
Main blind spot	Ignores repeat use and depth	Ignores quality of sessions	Needs event-level data and clear definitions	Attribution fails without a baseline
Gaming risk	Low, but easily misleading	Moderate, since nudges inflate logins	High if the stages become targets	Moderate, since metric choice can bias results
Privacy exposure	Low	Moderate	Moderate to high without cohort rules	Low to moderate
Best use	Procurement and license reclaiming	Executive trend line	Diagnosing stalls and choosing interventions	Budget and renewal decisions
Refresh cadence	Monthly	Weekly	Monthly	Quarterly

Adoption Measurement in Practice at Three Organizations

The St. Louis Fed Generative AI Adoption Tracker

In practice, the clearest public example of ongoing adoption measurement is the Generative AI Adoption Tracker built by economists Alexander Bick, Adam Blandin, and David Deming. The team ran the Real-Time Population Survey each quarter with a nationally representative sample of adults aged 18 to 64. Employed respondents report how often and how intensively they use generative AI. Between late 2024 and mid 2026, weekly use among employed adults rose from 28.2% to 39.2%, and AI-assisted work hours climbed from 4.1% to 6.3%. Estimated hours saved increased from 1.6% to 2.2%, a gain of roughly 37% relative to the starting level. The design separates reach, intensity, and time savings into distinct series instead of blending them into a single score. Its main limit is that respondents self-report their time savings, so the Fed calls the measurements approximate and companies should pair survey answers with logged usage before reporting savings.

Cohort Stage Classification in the NANTE Telemetry Model

A second example comes from the reference implementation of the NANTE adoption telemetry model, which classifies cohorts into five stages using usage logs alone. The author built a deterministic classifier and ran it on six synthetic profiles covering 167 users over 149 days. In the shallow-plateau profile, 99.4% of users reached the navigate stage yet the composite score was only 49.9, compared with 60.5 for the healthy cohort. The classifier also flagged champion dependency, with a Gini coefficient of 0.65, in a cohort where a few users generated most of the activity. These results show how stage counts expose depth problems that a weekly active rate completely hides. The main limitation is that the data are synthetic and the thresholds are proposed rather than validated, so real cohorts may show several pathologies at once. Teams should treat the stages as a diagnostic starting point and calibrate the cutoffs against their own history.

A Staggered Rollout for Customer Support Agents

A third example shows how usage data can anchor a rigorous outcome study. Researchers studied 5,179 customer support agents at a company that implemented a generative AI conversational assistant in stages, which let them compare agents with and without access over time. Productivity measured as issues resolved per hour rose by about 14% on average, and by about 34% among novice and low-skilled workers. Experienced and highly skilled agents saw minimal impact, so the average hid very different results by skill level. The design worked because the rollout was staggered and the outcome metric was fixed before the analysis began. Its limit is scope, since the findings cover one occupation and may not transfer to open-ended knowledge work. Readers should still borrow the discipline of a comparison group, which is the cheapest defense against crediting AI with gains that other changes produced.

Lessons From Three Case Studies in Enterprise AI Adoption

Case Study: Sanofi's Concierge AI Companion

Turning to large enterprise deployments, Sanofi faced a classic scaling challenge with its internal AI companion called Concierge. The company needed to extend the assistant across its global workforce while keeping the flexibility to evolve and meeting strict data sensitivity requirements. Its solution was to build Concierge in-house on Amazon Bedrock and keep it model-agnostic to avoid provider lock-in. Engineers deployed it across multiple regions to reduce latency and began building an agent hub for data retrieval and workflow automation. According to AWS, Concierge reached 50,000 weekly users and 72,000 monthly users as of the first quarter of 2026, with 11 million conversations. That weekly-to-monthly ratio of about 0.69 is a respectable stickiness signal for an enterprise assistant. Among surveyed employees, 90.5% reported saving time on routine tasks.

The limits matter just as much as the headline adoption numbers do. The time savings are self-reported survey results, and the 90% positive-feedback rating is a satisfaction measure rather than a productivity measure. AWS published the case study and the same vendor supplies the platform, which is a mild concern about independence. The data also describe reach and frequency far better than they describe outcomes, since no task-level time or quality measurements are reported. Readers should treat the numbers as strong evidence of adoption and as suggestive evidence only for productivity. Anyone borrowing the approach should add a baseline and a comparison group before claiming savings.

Case Study: Novo Nordisk's Self-Service Generative AI Platform

Novo Nordisk wanted employees to innovate with generative AI in nonregulated processes while staying secure, compliant, and cost-effective. The problem was that many employees had solutions in mind but could not build the applications or maintain the supporting infrastructure. The company also found it hard to predict which use cases would succeed. Its solution was a self-service platform on AWS, built around chatbots and agents that use foundation models in Amazon Bedrock. Employees can build and customize chatbots and share them with their teams, while serverless services keep base costs low. More than 25,000 employees have used the platform to create over 2,500 chatbots, at roughly $10 per month per use case. That ratio implies about one chatbot for every ten employees who used the platform.

These figures measure breadth of adoption unusually well, since distinct use cases per team is exactly the breadth metric described earlier. They are still activity and cost measures, and they do not show how much each chatbot is worth or how many sit idle after a pilot. The cost figure covers running expenses per use case, so it excludes development effort and staffing, a limit worth stating in any executive summary. Tracking the month-over-month increase in active use cases would turn this snapshot into a trend. The platform also lacks a reported business outcome, which is a fair criticism of activity-based success stories. The lesson is to pair breadth counts with an activity threshold that separates working tools from abandoned experiments.

Case Study: Pfizer's PACT Generative AI Search

Pfizer teams were stretched thin, so the Pfizer-Amazon Collaboration Team, known as PACT, was created to address the bandwidth needed for prototyping. Scientists faced a data discovery problem because developing one drug can generate approximately 20,000 documents that they had searched manually. PACT paired Pfizer teams with AWS prototyping specialists and solutions architects, and it developed a generative AI search tool that scientists reach through an internal platform called Vox. The team also built an anomaly detection prototype for manufacturing, and it pursued 14 projects in total. AWS reports that scientists could save up to 16,000 hours of search time annually and that infrastructure costs fell by 55%. Data discovery time dropped by up to 80% for 1,500 scientists. A PACT prototype took no more than six weeks, compared with at least three months for an internal effort.

Narrow, well-defined use cases like these make outcome measurement far easier than broad assistant rollouts. Five of the 14 projects had moved into production, which is a reminder that pilot success and sustained adoption are different things. The main criticism is that an up-to figure describes a ceiling and not an average, and that the numbers come from a vendor case study without independent auditing. The results also say little about how many scientists use the search tool each week or how deeply they use it. A complete measurement program would add reach, frequency, and depth data beside these savings estimates. The takeaway is that attributable outcome metrics are valuable but should sit beside adoption data and not replace it.

Common Questions About Measuring Generative AI Adoption in the Workplace