NIS2 on DR.365

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

Thu, 29 Oct 2026 07:00:00 +0100

📝 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

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.

References

Microsoft's AI Strategy Roadmap from an operator's view: what holds up and what regulated organizations must add

Tue, 20 Oct 2026 07:00:00 +0200

In July 2026 Microsoft published a 66-page e-book called The AI Strategy Roadmap, subtitled How organizations are achieving Frontier Transformation. As service owner for Digital Workplace & AI at an IT service provider whose customers mostly work in regulated sectors (KRITIS, NIS2), I read it with one question: what holds up in operations, what is marketing, and what’s missing?

“Frontier Transformation” is Microsoft’s term for moving from isolated AI use cases to AI that is built into core business processes.

What the e-book is based on

The recommendations draw on 70 interviews of 30 to 45 minutes with IT and business decision-makers, conducted by Emerald Research Group on Microsoft’s behalf between 23 February and 13 March 2026. Microsoft’s own internal rollout, where it acts as “customer zero”, is the second source.

The opening table lists seven typical hurdles: too many ideas and no clear starting point, ROI that stays abstract, fragmented data, compliance reviews that slow expansion, scaling without clear responsibility, users who don’t trust the agent, and missing skills. The answers attributed to “Frontier Firms” mostly say the same: start narrow, measure early, expand one use case at a time.

The e-book then defines five overall readiness stages (Exploring, Planning, Implementing, Scaling, Realizing) and gives each of its five value drivers its own five-level maturity model.

Five drivers across five stages: my condensed reading of the e-book’s maturity models, in my own words.

The five drivers as a self-check

Each driver in short, with one question for your own organization. The questions target stage 3, where most of the work between pilot and production happens.

1. Business strategy. AI work is tied to business goals, funded deliberately and managed as a portfolio. The e-book wants one narrow, measurable use case first, prioritized with a consistent framework. It names the Microsoft AI Decision Framework, also known as the BXT framework (business, experience, technology). Stage 3 check: Do AI KPIs show up in your regular business planning, or only in the project status report?

2. Technology and data. Data readiness is a prerequisite, and a shared, managed platform replaces a new build for every pilot. Cost management is part of the design from the start. Stage 3 check: Can you name the data sources a production agent may use, and who owns each one?

3. AI strategy and experience. Pilots are instrumented from day one, and what works becomes templates and patterns for the next team. GenAIOps practices such as versioned prompts and continuous testing turn experiments into operations. Stage 3 check: When the prompt or model of a production agent changes, is there a test run before it goes live?

4. Organization and culture. A Frontier Center of Excellence (CoE) sets standards and guardrails without owning every solution, backed by champions and role-based training (the e-book points to AI Skills Navigator, which now surfaces in the Learning agent in Copilot as a preview). According to Microsoft’s 2026 Work Trend Index, cited in the e-book, organizational factors drive 67% of the realized value from AI. Stage 3 check: Does your CoE have a mandate, a budget and a named lead, or is it a recurring meeting?

5. Governance and security. Governance is built into the agent lifecycle: identities, least privilege, monitoring, an inventory of all AI systems and a review before every deployment. Stage 3 check: Can you list every agent in production today, with owner and permissions, without asking around?

Microsoft Learn has a related agentic AI adoption maturity model with almost the same five pillars and levels 100 to 500. For an assessment workshop I’d use that one: each pillar has its own detailed page.

What holds up in operations

Data hygiene is the critical path. Microsoft’s own lesson as customer zero: when data is poorly classified, duplicated or overshared, agents amplify the problem. The line I’d show any steering committee: “For agents, data quality becomes action quality.” With Copilot we see the same: oversharing that existed for years becomes visible the day an agent can search it. My pre-rollout playbook on oversharing covers the concrete steps.

The safe path has to be the easy path. When IT makes approved routes slow, people move to public tools and take company data with them. The e-book recommends building guardrails into the tools that make experimenting easy and moving IT from owning every solution to governing platform and data. In my experience that’s the only thing that works against shadow AI over time. Bans age quickly.

Agents need identities and a lifecycle register. The e-book wants permissions, lifecycle controls and monitoring per agent, plus a register that tracks each one from approval to retirement. In Microsoft 365 that maps to Microsoft Entra Agent ID and the agent registry in Agent 365. I’ve written about the lifecycle side and about delegated permissions at runtime.

Every agent should get a safety evaluation before deployment. Security teams test before production, and continuous monitoring looks for prompt injection and unsafe tool calls afterwards. That’s the Measure stage from Microsoft’s four-stage model for responsible generative AI, and it belongs in the release gate.

Reuse works best when guardrails come with it. Templates and pattern libraries should contain the governance, data handling and evaluation requirements, so a new team inherits the controls. Microsoft describes its own agents as “graduating” from personal to enterprise-wide use, with validation, security review and integration hardening before they scale. Whether you build with Agent Builder, Copilot Studio or Foundry decides how much of that you can enforce centrally.

IT acts as curator instead of gatekeeper. At Microsoft, IT exposes certified data sources and runs agent memory and integrations (APIs, MCP, connectors). The CoE started in 2023 as an advisory group and moved to coordination, reviewing ideas against four pillars: strategy, architecture, roadmap and culture. A “fast train” gives a trusted group early, broad access under clear guardrails. I’d copy that model and keep the trusted group small.

Where it’s too smooth

The ROI message contradicts itself. The hurdles table says it’s hard to convince leaders that hard ROI evidence isn’t the goal. A few pages later, readers are told to pick use cases that show ROI early. In a mature program both can be true. A steering committee that hears both will pick the one it prefers.

Agents are enablers, or they replace capacity. Change management should make clear that agents are enablers and not job threats. Yet the target state for driver 1 says growth is no longer constrained by headcount, and the benefits list promises scaling without proportionally more staff. Employees and works councils read both statements. If you use the e-book internally, decide which message you mean and stick to it.

The evidence is thin. Seventy vendor-commissioned interviews plus the vendor’s own rollout describe patterns but prove no effects. The 67% figure comes from Microsoft’s own Work Trend Index. That’s fine for orientation and weak as a business case.

Cost management stays vague. The e-book wants cost efficiency designed in early and names cost modeling as a scaling gap, without saying how: no chargeback model, no unit cost per agent, no guidance on consumption-based billing. For a service provider, this is where pilots stall.

What’s missing for Europe

The regulatory map in driver 5 shows the EU AI Act, the NIST AI RMF, ISO 42001, ISO 23894 and frameworks from several other countries. The GDPR gets one mention, next to HIPAA. Three things that shape every AI project in a regulated German organization don’t appear. What follows is my professional view, not legal advice.

Co-determination. Under Section 87(1) no. 6 of the German Works Constitution Act (BetrVG), the works council has a say in technical systems designed to monitor employees’ behavior or performance, and courts read “designed” broadly: being objectively suitable is enough. Copilot and agents that log usage will usually meet that test. Since 2021, Section 90 explicitly includes AI among the planned work processes the works council must be informed about. That belongs in driver 4: involve the works council when you plan the first use case and treat a works agreement as part of the roadmap.
NIS2. For entities in scope, an agent is an IT system like any other. Risk management, incident reporting and management accountability apply. In driver 5, the agent inventory and the incident process have to cover agents.
DORA. Financial entities have been subject to DORA since 17 January 2025, including ICT risk management and a register of contractual arrangements with ICT third-party providers. Every AI platform and external model is a candidate for that register, which touches driver 2 (platform choice) and driver 5 (evidence).

How AI Act, GDPR, NIS2 and ISO controls overlap for agents is the topic of my compliance map for Microsoft 365 agents.

What I’d take from it

For an organization at Planning or Implementing:

Start with one measurable use case and a human in the loop. Define the KPI before building and keep the approval step in the workflow until the numbers justify removing it.
Set up the agent inventory before the second agent: owner, purpose, data sources, permissions, next review date. Retrofitting it at agent 30 is a project of its own.
Turn the CoE into a “Center of Acceleration”, a term the e-book uses itself. Measure it by how fast a team gets a safe template and a decision, not by how many requests it turns down.
Bring data protection, the works council and information security to the table when the first use case is chosen. At go-live, all they can do is say no.

Where do organizations in KRITIS and NIS2 environments tend to get stuck? I’d place most of them between Planning and Implementing: the first use case is defined, but not yet in production. The brake is usually drivers 4 and 5 together. Nobody decides with authority what an agent may access, and the works council and information security join late, so every approval starts from zero. That’s why steps 2 and 4 come before the second agent.

Conclusion

The five drivers give you a shared vocabulary for a maturity check; the Microsoft Learn model adds the detail.
The strongest content is operational: data hygiene, an agent inventory, predeployment evaluation and guardrails built into templates.
Read the ROI and headcount statements critically, and the evidence as vendor research.
In Europe, add co-determination, NIS2 and DORA to drivers 4 and 5 yourself.

References

Microsoft: The AI Strategy Roadmap: How organizations are achieving Frontier Transformation (e-book, PDF, July 2026)
Microsoft Learn: Agentic AI adoption maturity model
Microsoft Learn: Build an agentic Center of Excellence
Microsoft Learn: Evaluate and prioritize an AI use case with business envisioning (BXT)
Microsoft Learn: Agent registry in the Microsoft 365 admin center
Microsoft Learn: What are agent identities? (Microsoft Entra Agent ID)
Microsoft Learn: Manage AI Skills Navigator
Works Constitution Act: Section 87, Section 90 (gesetze-im-internet.de, German)
EUR-Lex: NIS2 Directive (EU) 2022/2555, DORA Regulation (EU) 2022/2554