AI Act, GDPR, NIS2 and ISO: which controls for Microsoft 365 agents count more than once

📝 As of October 2026
This post is not legal advice. It maps obligations from laws and standards to technical evidence in Microsoft 365. Whether your organization is in scope is a question for your legal team, data protection officer or counsel. English terms for German law are my own translations.

HR builds an agent in Copilot Studio that reads incoming applications, compares them with the job profile and suggests a ranking. Technically, that is an afternoon’s work. From a regulatory point of view, it has little in common with the travel expense helper from part 2.

The AI Act explicitly lists AI systems that analyze and filter job applications or evaluate candidates as high-risk (Annex III, point 4(a)). The exemptions in Article 6(3) for narrow or purely preparatory tasks do not apply once a system performs profiling (Regulation (EU) 2024/1689). Ranking people by their documents is likely to be exactly that. At the same time, the agent processes personal data, runs in a tenant that in regulated industries is often in scope for NIS2, and has to fit into the existing ISO 27001 certification. This fourth and final part of the series is about turning that into one set of shared controls rather than five separate projects.

Laws, standards and evidence

Gökhan Adamhanoglu describes AI regulation in the EU as a system with two layers: laws define what an organization owes, standards describe how it operates and proves it. For organizations that build and run agents in Microsoft 365, I add a third layer. Auditors and regulators ultimately ask for evidence: who approved the agent, what did it do and when, who reviewed its output? That evidence comes from the tenant: the agent registry, the audit log, Entra and Defender.

An example: the AI Act requires deployers to keep the logs of a high-risk system for at least six months. A management system standard requires the organization to define such rules and monitor them. Purview Audit provides the actual records. Once the three layers are connected, the same evidence serves several frameworks.

Which frameworks matter for M365 agents

The AI Act distinguishes providers, who develop an AI system, from deployers, who use it under their authority. All deployers have to address AI literacy (Article 4), and the transparency obligations in Article 50 have applied since 2 August 2026. The deployer obligations in Article 26 only cover high-risk systems, and the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved them to 2 December 2027 for Annex III.

The GDPR requires a data protection impact assessment (DPIA) where processing is likely to result in a high risk. Article 35(3)(a) explicitly names systematic and extensive evaluation of personal aspects, including profiling, on which decisions are based (GDPR). As I read it, an agent that pre-sorts candidates falls under that.

In Germany, NIS2 has applied since 6 December 2025 through the revised BSI Act (BSIG) (BSI). AI is not mentioned, but Section 30 BSIG requires risk management for the IT systems an entity uses for its services, Section 32 sets out reporting obligations and Section 38 makes management accountable. I treat an agent with access to the HR system like any other IT system that reads from it (my professional view).

ISO/IEC 27001 and ISO/IEC 42001 are management system standards. ISO builds them on a common harmonized structure with the same core clauses so they can be integrated (ISO). If you run an ISMS under 27001, an AI management system under 42001 can extend it. 42001 adds AI-specific requirements, such as assessing an AI system’s impact on the people affected.

The Data Act, the Cyber Resilience Act and the Machinery Regulation don’t matter for most readers. The Cyber Resilience Act covers products made available on the market in the course of a commercial activity, which an internal agent is not. The Data Act is mostly about data from connected products and switching between cloud services, the Machinery Regulation about physical machines. If you sell agents or build them into products, look again.

Deployer or provider?

Under Article 3(3) of the AI Act, a provider is anyone who develops an AI system and places it on the market or puts it into service under its own name. Putting into service explicitly includes own use (Article 3(11)). Under Article 25, a deployer also becomes a provider by putting its name on a high-risk system, modifying it substantially, or changing the intended purpose of a system, including a general-purpose AI system, so that it becomes high-risk.

My reading of the wording: using Microsoft 365 Copilot to summarize email makes you the deployer of a system Microsoft provides. Building your own candidate screening agent in Copilot Studio means developing an AI system with an Annex III purpose and putting it into service under your own name. There is a good case that the organization is then both provider and deployer of a high-risk system. The Commission’s guidelines on classification are only available as a draft. Until they are final, I would document the role for every agent with an Annex III purpose and have legal review it.

Providers need, among other things, a quality management system, technical documentation, a conformity assessment and registration (Article 16). For Annex III point 4, conformity assessment is internal control without a notified body (Article 43(2)). Since 14 October 2026 there is a harmonized standard for the quality management system: EN 18286:2026 is cited in the Official Journal through Implementing Decision (EU) 2026/2274 and gives a presumption of conformity. Often the cheaper control is to scope the agent so it stays out of Annex III. An agent that answers candidates’ questions about the hiring process evaluates no one and, in my view, is outside Annex III point 4.

The fundamental rights impact assessment under Article 27 only applies to public bodies, private entities providing public services and deployers of certain Annex III point 5 systems (creditworthiness, life and health insurance). For a typical company’s HR agent, the DPIA remains the key document. Where Article 27 applies, the Omnibus allows cross-references to the DPIA (new Article 27(4)).

Where the frameworks overlap

Control matrix: eight shared controls, their relevance for the AI Act, GDPR, NIS2, ISO 27001 and ISO 42001, and the matching evidence in Microsoft 365, with a timeline of deadlines below

The matrix is my own mapping: a filled dot for an explicit requirement, a ring for an indirect one.

Inventory and ownership. The GDPR requires a record of processing activities, Section 30(2) no. 9 BSIG asks for concepts for managing ICT systems, ISO 27001 for an inventory of assets. The AI Act assumes one: you can only meet deployer obligations for systems you know about. One entry per agent with owner, purpose, zone, Annex III classification and role as deployer or provider covers all four.

Risk assessment. The DPIA, the risk analysis under Section 30(2) no. 1 BSIG and both ISO risk assessments ask largely the same questions. Article 26(9) of the AI Act requires deployers to use the provider’s information for the DPIA. I keep one document per agent with a shared core and short sections per framework.

Logging. At least six months under Article 26(6), plus the data you need for a report under Section 32 BSIG. Purview Audit (Standard) keeps records for 180 days, which is right at the minimum. Audit (Premium) supports retention policies of up to one year, and up to ten years with an add-on license (Microsoft Learn).

Human oversight. Article 26(2) requires natural persons with the necessary competence, training and authority, and Article 22 GDPR restricts decisions based solely on automated processing. The approval belongs in the flow that performs the action, as described in part 3. Add a named role that reviews the ranking and may reject it.

Data protection and access. Access control appears in Section 30 BSIG, Article 32 GDPR and ISO 27001. The AI Act requires deployers to ensure that input data under their control is relevant and representative (Article 26(4)). In M365 that means end-user credentials, sensitivity labels and DLP.

Incident reporting. Three paths: Section 32 BSIG with an early warning within 24 hours, Article 33 GDPR with 72 hours, and Article 26(5) of the AI Act, which requires informing provider and authority without undue delay after a serious incident. A shared incident process therefore asks early whether an agent was involved.

Informing affected people. Workers’ representatives and affected employees must be informed before a high-risk system is used at the workplace (Article 26(7)), and so must people the system helps make decisions about (Article 26(11)). Add the GDPR information duties and Article 50(1): the provider of an agent that talks to people has to make that recognizable.

Training and AI literacy. Under the revised Article 4, providers and deployers have to take measures to support the AI literacy of their staff, without any specific level being required. Section 30(2) no. 7 BSIG requires training, Section 38(3) regular training for management, and both ISO standards require evidence of competence. One training for agent makers and owners serves all three.

Which M365 tool provides which evidence

Part 3 covers registry, identity and runtime protection in more detail. For evidence, what counts is this: the agent registry in the Microsoft 365 admin center holds the inventory, with the owner rules from part 2 (Microsoft Learn). Entra Agent ID with a sponsor shows who is accountable (Microsoft Learn).

Purview provides most of the evidence. Prompts and responses from Copilot Studio agents land in the unified audit log, DSPM shows data risks in AI interactions, and DLP and sensitivity labels apply to agents (Microsoft Learn). Compliance Manager has premium templates for the EU AI Act, ISO/IEC 42001, ISO/IEC 23894 and the NIST AI RMF, plus a template for ISO/IEC 27001:2022 (Microsoft Learn). For the DPIA there is Priva Privacy Assessments, currently in preview (Microsoft Learn).

Defender keeps its own agent inventory and groups agent alerts into incidents, which feeds a Section 32 report (Microsoft Learn). For human oversight, the approvals in agent flows from part 3 remain the tool.

Microsoft holds an ISO/IEC 42001 certification for Copilot, Copilot Chat, Copilot Studio and Foundry. Customers may use it in their own assessment, but their own implementation needs its own audit (Microsoft Learn). In supplier management the certificate is useful evidence, but it says nothing about your own HR agent.

Who delivers the evidence

The three models from part 1 also decide who has to produce which evidence.

In the intrinsic model (Agent Builder), Microsoft provides the evidence for the platform, such as the ISO 42001 certificate. Your organization documents what happens in the tenant: inventory and owners in the registry, the sharing settings and the permissions on knowledge sources.

In the configurable model (Copilot Studio), whoever configures the platform documents the configuration: environments, data policies, publishing approvals and pipeline history. If that is the service provider, this evidence is part of its service, for example as a regular report the customer can review without admin access of its own.

In the explicit model (Foundry), the organization provides almost everything itself, from model choice and evaluations to technical documentation. Compliance Manager can pull evaluation results from Foundry into an assessment automatically (Microsoft Learn). If the agent falls under Annex III, the provider obligations from the section above apply on top.

The service provider itself shows up in several frameworks. Section 30(2) no. 4 BSIG requires measures for supply chain security, explicitly including relationships with service providers. For managed service providers that are themselves in scope for NIS2, Section 30(3) BSIG refers to the technical requirements in the Commission’s implementing act. A provider that processes personal data on the customer’s behalf must, under Article 28(3)(h) GDPR, make available all information needed to demonstrate compliance and allow audits. And under Article 3(3) of the AI Act, a provider is also whoever has an AI system developed and puts it into service under its own name. If a service provider builds the candidate-ranking agent on behalf of a customer, my reading is that the provider role stays with the customer as long as the agent runs under the customer’s name. The contract should then define which documents the service provider supplies for the technical documentation.

Deadlines deployers should know

AI literacy has been an obligation since 2 February 2025, in its revised form since the Omnibus took effect on 27 July 2026. NIS2 has applied in Germany since 6 December 2025 without a general transition period, Article 50 since 2 August 2026. 2 December 2026 matters little for deployers: two new Article 5 prohibitions apply, plus a transition deadline for providers of generative systems on machine-readable marking.

For the HR agent, 2 December 2027 counts. From then on the Annex III high-risk obligations apply, including Article 26. AI in regulated products under Annex I follows on 2 August 2028. Under Article 111(2), high-risk systems put into service before that date are only covered after significant changes to their design. For agents whose instructions and knowledge sources change all the time, I would not rely on that.

What Microsoft doesn’t take off your plate

Microsoft provides tools and evidence. Responsibility for operating an agent lawfully stays with you. The Compliance Manager templates describe measures someone still has to implement and prove, and they consume premium licenses. Automated agent assessments in Compliance Manager are built on Microsoft Foundry, and Microsoft doesn’t describe a comparable integration for Copilot Studio agents.

Several building blocks are still in preview, including threat detection for agents in Defender and Priva Privacy Assessments. Agents built with Agent Builder don’t get an Entra Agent ID. Some things happen in no portal at all: deciding whether an agent falls under Annex III, informing workers’ representatives, management accountability under Section 38 BSIG, and the question of who in the organization can carry provider obligations.

Five things you can check tomorrow

Go through the agent registry and flag every agent that evaluates, ranks or helps make decisions about people.
For those agents, document whether your organization is the deployer or the provider, and have legal review it.
Check in Purview how long audit records for Copilot and agent interactions are kept, and whether 180 days is enough for you.
See which Compliance Manager templates you are licensed for, and extend your existing ISO 27001 assessment with the template for the AI Act or ISO 42001.
Add two things to your incident process: the question whether an agent was involved, and the GDPR and AI Act reporting paths next to Section 32 BSIG.