Measure AI adoption by starting with a specific program decision and collecting the least sensitive evidence that can answer it. Agree who may see the underlying records, what reports may reveal, how long information stays and which uses are excluded. An aggregate dashboard is only one part of that arrangement.
For an adoption lead working with privacy, HR and IT owners, the practical question is what to authorize before collecting or combining employee data. The adoption metric dictionary explains how to define useful measures. This guide addresses the collection and reporting boundaries behind them.
Name the decision before collecting activity
“Understand AI use” is too broad to determine whether you need a weekly count, a named access record or the contents of a conversation. Write the decision in terms that someone can act on, then identify what evidence is missing.
Suppose Jamie Lee leads adoption at an industrial-equipment distributor. Service-desk advisers are trying an approved assistant to draft service-appointment confirmations from booking records and current service terms. Advisers still check dates and commitments before sending. Jamie wants to know where access problems or a need for practice are holding the trial back.
That purpose does not require a ranking of advisers by prompt volume. A named access problem may belong with the person who can resolve it; a broader support report may only need the affected workflow and a sufficiently protected group-level view. Keep those destinations separate.
The UK's Information Commissioner's Office monitoring guidance emphasizes a defined purpose and the least intrusive means of achieving it. Checked on October 19, 2026, the site marks this guidance as under review following the Data (Use and Access) Act. It is UK guidance, not permission to monitor employees everywhere.
Have the responsible privacy and legal owners establish the applicable requirements before collection, including any assessment and employee-participation process. A supplier's privacy label or an employee's acknowledgement does not settle that assessment. The representative-discussion guide explains how to prepare a proposal people can question.
Build a smaller record that still answers the question
For Jamie's trial, distinguish the evidence needed to fix an individual problem from information needed to review the program. Start with the records already available through approved processes. Do not create a second collection merely because a reporting tool accepts more fields.
| Proposed information | Possible use in this trial | Boundary to resolve |
|---|---|---|
Approved access and task population | Establish who could participate and identify provisioning gaps | Keep names with the access owner where needed; define what reaches the program report |
A defined activity and reporting period | Investigate whether the supported workflow is being tried | Check whether the event needs a person-level identifier before collection or export |
A support category | Distinguish access, source-information and practice problems | Avoid carrying personal circumstances or customer details into a broad report |
Selected work for quality review | Check whether appointment drafts preserve the booking facts and terms | Use an approved sample and restricted review route, with unrelated information removed |
A full prompt history would bring a different collection into the proposal. It could contain customer information and employee questions that a count does not need. Ask why that content is necessary, who would process it and whether a smaller approved sample could answer the question instead.
Removing content does not make the remaining record harmless. A timestamp, task category and branch can still say something about a person. Likewise, combining two approved extracts creates a new view to examine; the fact that each source exists does not explain why the joined report is needed.
Keep missing evidence visible. If a report suppresses a small group or cannot observe a tool, label that limitation. Do not restore identifying detail merely to fill a blank, or interpret a suppressed value as zero adoption. The metric guide's reporting checks help keep the resulting account honest.
Test whether someone can still recognize a person
A report can conceal names while leaving a person recognizable. The ICO's anonymisation assessment guidance asks readers to consider the information, its recipients and other available knowledge. Its treatment of singling out and linking records is more useful than treating a group-size setting as a universal privacy guarantee.
An employee account makes the concern tangible. In a July 2026 Reddit discussion about company-provided AI tools, a new joiner asked whether managers could see prompts or only usage totals. Replies offered conflicting answers. One commenter described recognizing their own record because they were the only person at their seniority level on the team. The account and employer configuration were not independently verified; it illustrates what to test, rather than establishing a product capability.
Jamie can examine the proposed report with someone who knows the service desk:
- Distinctive groups. Could a branch, shift or specialist role point to one adviser?
- Combined filters. Does a harmless-looking department view become identifying when narrowed by job level or location?
- Overlapping reports. Could comparing two views reveal what a hidden person contributed?
- Exported detail. Does a downloaded file expose rows or attributes that the dashboard conceals?
Change the proposed view when it reveals more than the purpose needs. That may mean fewer attributes, broader reporting groups, fewer filters or withholding a comparison. Assess the actual result rather than choosing a minimum headcount and assuming the problem is finished.
Coded identifiers need care too. Pseudonymisation separates identifying information from a coded record; it does not automatically make the processing anonymous. Check who can reconnect the records and what other attributes remain.
Control the records behind the report
Review access at each surface. Who can collect the information, inspect raw rows, change filters, download files and receive a copied presentation? A restrained dashboard does not tell you what an analyst or administrator can retrieve elsewhere.
Microsoft's technical privacy guide for Viva Insights provides a product-specific illustration. It distinguishes aggregated organization insights from advanced analysis, where some analysts can access row-level data. It also warns that descriptive attributes can enable identification. That is a reason to inspect the actual configuration and permissions, not a claim that every analytics tool behaves the same way.
| Surface | Question to answer | Responsibility to name |
|---|---|---|
Source and analysis records | Which fields and people are available before aggregation? | Who grants access, checks its purpose and removes it when no longer needed |
Program report | Which groups, filters and comparisons can its audience see? | Who approves the view and reviews changes to it |
Exports and copied reports | What leaves the controlled system, and where does it go? | Who receives it, protects it and applies its retention arrangement |
Set retention around the purpose and applicable obligations, including copies. Name the owner who can explain why each record is kept and verify what deletion actually covers. A vendor's maximum storage period is not a reason to retain every extract for that long. The ICO's monitoring checklist includes retention, access and clear worker information among the matters to resolve.
Keep an investigation route distinct from ordinary adoption reporting. If security needs information about a suspected incident, use the authorized process and its access rules. Do not quietly give every reader of the program report the same visibility. Conversely, do not promise employees that nobody can ever access content if a separate authorized route can do so.
Review what employees will actually be told
Jamie can bring a synthetic reporting example to advisers and the responsible privacy owner before collection begins. Include the fields, the intended audience and an example of something the report deliberately will not show. Keep real customer and employee records out of this rehearsal.
Use the discussion to test the arrangement:
- Explain the decision. Say which support question the report answers and which personnel decisions it does not authorize.
- Walk through the information. Show collection, analysis, reporting and exports, including any route with more detailed access.
- Invite a challenge. Ask what could identify someone, what is unclear and how an employee can question inaccurate information or its use.
- Resolve the gaps. Change the proposal or assign the unresolved decision before collecting the affected information. Update the explanation to match the approved arrangement.
Put the resulting information somewhere employees can find again. It should identify what is collected, why, who can access which version, the retention arrangement and a contact for questions or applicable rights. Connect it to the employee AI policy, rather than asking people to reconcile inconsistent promises.
Revisit the proposal when the purpose, data source, audience or reporting capability changes. Adding named drill-down, linking another workforce dataset or passing adoption records into a performance process changes the question employees were originally asked to understand. Use the performance-system guide for the separate judgment about work, learning and support.
Return to the tools and workflows guide when the change also affects tool permissions or operational responsibilities. A useful reporting boundary must match the service people actually use.
Questions about privacy and AI adoption measurement
Do we need employees' full prompt histories to measure adoption?
Not for every adoption question. An access or activity question may be answerable through a limited record without prompt content. Start with the specific decision, identify the minimum evidence and check what the selected collection actually includes. If content is proposed for quality research or support, assess that purpose, sample, access and handling separately. The collection table shows how to separate those needs.
Is a team-level AI report anonymous?
A team-level label alone does not establish anonymity. A small specialist group, a distinctive attribute or comparisons with other reports may reveal an individual. Review the data and what its audience already knows, including available filters and exports. Broaden or restrict the view where necessary and have the responsible privacy owner assess it. Use the recognition checks before making an anonymity promise.
Does a dashboard privacy setting protect every underlying record?
Do not assume it does. A display setting may limit what one audience sees while analysts, administrators or export recipients have different access. Ask the technical owner to demonstrate the source, analysis and report permissions using approved test data. Record the access needed for each purpose, then remove unnecessary access. The review of records, reports and exports covers the views that need separate attention.
How long should we keep employee AI usage records?
Choose a justified retention period for the stated purpose and applicable obligations, with the responsible privacy and records owners. There is no useful universal duration for every adoption dataset. Distinguish source records, analysis extracts, aggregate reports and downloaded copies; establish who deletes each and how that is checked. Review the arrangement when the purpose ends or changes, instead of retaining information because it might be useful later.
Can adoption data later be used in performance reviews?
Do not treat access to adoption records as authorization for a new performance use. Have the responsible HR, privacy and legal owners assess the proposed purpose, applicable requirements and what employees were told before changing the arrangement. Usage alone does not establish useful work or sound judgment. The performance-review guide explains how to examine actual results, checking and learning under agreed expectations.
