Whenever I help a client pilot Microsoft 365 Copilot, the works council gets involved sooner or later. AI features raise new questions about visibility, transparency and the monitoring of individual employees. Works councils want technical guardrails, and they often want them written into a formal agreement. Below are the technical measures that have repeatedly helped me support a works council agreement on Copilot. This isn't legal advice, just what has held up in real projects.

Microsoft 365 usage reports can hide user names

The visibility of user names in Microsoft 365 usage reports comes up first, almost every time. In the Microsoft 365 admin center, under "Settings → Org settings → Services → Reports", you'll find a switch called "Display concealed user, group, and site names in all reports". Turning it on anonymizes most user data in the activity and usage reports, so the metrics can no longer be traced back to individual people. In most of the tenants I work with, this is a precondition before Copilot or any new reporting feature goes live.

I always record when the setting was enabled and keep a screenshot as evidence for later reviews. That way I can show the works council without much effort that individual-level reporting isn't possible. Microsoft's documentation describes the setting in more detail.

The Copilot Dashboard in Viva Insights enforces a minimum group size

The Copilot Dashboard in Viva Insights shows aggregated Copilot usage for teams and for the whole organization, but never for individuals. It only displays data for groups with 10 or more members, and you can't lower that threshold. Individual usage is therefore protected on a technical level. However curious someone gets, the dashboard simply won't show data for small groups or single users. Microsoft's documentation confirms these minimums.

In practice I write down which roles have access to the dashboard. Usually that's a handful of people from HR, IT or the works council itself. A screenshot of this goes into the Copilot rollout documentation as well.

Purview Audit roles decide who sees Copilot interactions and for how long

The question of who can view Copilot interactions in the Purview Audit log or in eDiscovery tends to be the most heated one in works council meetings. Every Copilot activity is logged in Purview Audit, but only people with the "Audit log search" role or specific eDiscovery roles can get to it. You manage these roles in the Purview portal under "Permissions" → "Roles". Keeping those role assignments tight, and documenting who holds them, is a big part of complying with the works council agreement.

How long Copilot interactions are kept depends on your Microsoft 365 licence and your Audit configuration. In E3 and E5 tenants the default is typically 90 days, though custom retention policy settings in Purview can extend that. If you need long-term retention, make sure the right audit licences and configurations are in place. I've covered Copilot interaction audit retention in detail here.

Practical tip: Before I meet with the works council, I check who is currently in the audit and eDiscovery roles in the Purview portal. Every now and then someone turns up who shouldn't be there, and it's much better to clean that up beforehand.

A dedicated Teams policy controls meeting transcription for Copilot

Copilot in Teams meetings needs access to the meeting transcript. Whether transcripts are created by default is configured in the Teams admin center under "Meeting policies" ("Allow transcription"). I recommend creating a separate Teams policy for the Copilot pilot groups and leaving the default policy more restrictive. That gives you a clear way to show the works council that Copilot access is limited and under control. I've written about Copilot and Teams meeting transcription policies here.

Group-based licensing keeps the Copilot pilot contained

Works councils also regularly ask how I make sure Copilot doesn't end up switched on for the entire company by accident. I handle this with group-based licensing in the Entra ID admin center. I create a dedicated security group, assign the Copilot licence to it and document the membership process, including who is allowed to add or remove users. This keeps the pilot auditable and transparent for the works council.

I document every common works council question the same way

In my experience, the works council's concerns about Copilot usually come down to these points:

  • Who can see individual data in reports or dashboards?
  • Who can access audit logs and eDiscovery?
  • How long are Copilot interactions retained?
  • How is the pilot group controlled?
  • What happens with Teams meeting transcripts?

For each one I record the exact setting, keep a change log and, where I can, add screenshots to the Copilot introduction plan. Solid documentation gets approvals through faster and makes people more willing to trust the setup.

A diagram shows how the technical controls fit together

To give stakeholders a picture of how these controls work together, I like to use a simple Mermaid diagram. It shows in one view how the settings and roles combine to protect users and meet the terms of the works council agreement:

flowchart TD
A["Reports: Hide names"] --> B["Works council: No individual reporting"]
C["Copilot Dashboard (Viva Insights)"] --> D["Minimum group size"]
E["Purview Audit: Control via roles"] --> F["Only authorized users"]
G["Teams Meeting Transcription"] --> H["Teams policy for Copilot groups"]
I["Copilot licence via group"] --> J["Pilot and auditability"]

Figure: The technical controls behind the Copilot works council agreement

Transparency is what builds trust

In most cases the discussion with the works council isn't really about blocking AI features. It's about reducing mistrust. With anonymized reports, narrowly assigned audit roles and documented pilot licensing, I can show convincingly that monitoring individuals is off the table and that sensitive data stays protected. What actually speeds up Copilot adoption is good technical documentation and clear processes, and they go a long way toward real trust between IT, employees and the works council.