Turning On Copilot for Everyone: What It Does to Your EU AI Act Exposure

Most organizations treat “enable Copilot Studio for all employees” as a licensing and change-management decision. IT flips a switch, the digital workplace team sends an adoption email, and the story becomes one about chasing productivity gains. However, under EU AI Act is also a compliance decision, arguably one of the biggest ones a company can make, and almost nobody frames it that way. The moment you give every employee the ability to build agents, you extend your own regulatory footprint into however many agents get built. And many times it builds an inventory you only watch growing.
‍
The Digital Omnibus on AI (Regulation (EU) 2026/1744), in force since 27 July 2026, pushed the high-risk obligations under Annex III, including the employment category, back from August 2026 to 2 December 2027. The extra eighteen months changes when enforcement bites, not what counts as high-risk, and inside most organizations, Copilot adoption is moving on a completely different clock than compliance is. Every rollout expands the number of people who can build something that quietly crosses into Annex III territory, long before anyone in legal has heard about it.

‍

A quick refresher on where Annex III bites

Annex III, point 4 classifies two categories of employment-related AI as high-risk:
‍

• 4(a) — recruitment and selection: systems used to place targeted job ads, filter applications, or evaluate
  candidates.
  ‍
  4(b) — employment relationship decisions: systems used to make or influence decisions on promotion,
  termination, task allocation, or to monitor and evaluate worker performance and behaviour.

‍
The Commission's draft guidance on this point is the detail that matters most: classification doesn't hinge on whether the AI decides anything. It hinges on whether the AI's output materially influences a human decision-maker. A manager who reads an AI-generated summary before deciding who gets a new assignment, a warning, or a promotion is still relying on a high-risk system, even though the manager signs off.
‍

That's the trap. Agents built inside Copilot Studio are built to solve a narrow, practical problem: “save me an hour writing status updates”, many times with zero awareness that the output will have an influence and is about to become an input into someone's career.

‍

Enabling the platform doesn't outsource the compliance

Here's the distinction that gets lost in the rollout announcement: Microsoft is the provider of the underlying Copilot system. Your organization, the moment it lets staff build and use agents on top of that system, is the deployer, and deployer obligations under Article 26 are non-delegable. Human oversight, usage logging, incident reporting: those sit with you regardless of whose model is doing the reasoning underneath.

It gets sharper than that. Under Article 25, a deployer that repurposes a system beyond what it was originally intended for, in a way that pushes it into high-risk territory, can be treated as the provider of that new system, and inherit the full obligation stack: conformity assessment, technical documentation, EU database registration. This is precisely the mechanism at play when an employee takes a general-purpose Copilot summarization or drafting capability and points it at candidate screening or performance evaluation. That's a new intended purpose the base platform was never assessed for. Microsoft's compliance work on the underlying model doesn't cover it. Yours has to.

‍

What this means in practice

The fix isn't reversing the Copilot rollout, the productivity case is still being tested, and it isn't going away. Hence, treating enablement itself as the compliance event can help to set proper boundries that will help your organization to spot higher risk agents immediately:
‍

• Gate the rollout, not just the agents. Turning on Copilot Studio org-wide should trigger a classificationframework on day one, meaning before the first employee builds anything.
  ‍
• Treat HR-related connectors as the trigger point. Any agent that connects to an HR system,performance data, or employee communications should be labeled and require a classification check beforepublishing.
  ‍
• Build the guardrail into the platform, not the policy document. A written policy or communicationlaunched itself is not sufficient, however a built-in classification prompt is a way to control and keepimproving how agents are being used.
  ‍

None of the fixes above require walking away from Copilot rollout, they rather require visibility that moves as fast as adoption does. That's what we can help you with by enabling Microsoft Purview.

Purview's agent governance capabilities, the agent registry, sensitivity labels, Insider Risk Management, compliance check with externally published regulators give you a live inventory of every agent running across your Microsoft 365 and Power Platform estate. More importantly, they show you what data each agent is actually touching: performance records, HR files, employee communications, calendar and activity metadata.

That's the lever for highliting the Annex III blind spot. Instead of discovering a risky agent after it's already shaped a manager's decision, we configure Purview to flag any agent the moment it starts accessing HR-adjacent or employee-behaviour data.

We help clients set this up end-to-end: agent inventory and data-access mapping in Purview, classification workflows that decide what's genuinely narrow-task and what isn't, and the documentation trail Annex III actually requires. If you've already enabled Copilot for your staff and don't know what they've built with it, let us help you govern it and stay compliant.

‍