SecurityMicrosoft 3659 min read

The EU AI Act and your Microsoft 365 tenant: a compliance checklist

You switched on Copilot, somebody built a few agents, and now legal is asking about the AI Act. Here is the honest news: most of what the law asks of a deployer is measurable tenant hygiene, and you can start checking it today.

Published by 1Security TeamSeptember 15, 2026
EU AI Act compliance checklist for Microsoft 365 tenants

Somewhere in your tenant there's an AI system nobody has written down. Copilot went live for a pilot group and quietly spread. Someone in operations built a few Copilot Studio agents that answer procurement questions. A sales tool with an AI feature got OAuth consent from one enthusiastic user eight months ago and has been reading mailboxes ever since.

Then legal forwards you an article about the EU AI Act and asks where the company stands.

The reflex answer is to treat this as a paperwork project: hire a consultant, open a spreadsheet, map controls to articles for a quarter. Before you do that, here's a number worth knowing. We built a compliance crosswalk across eleven frameworks, the EU AI Act among them, alongside NIS2, GDPR, DORA, ISO/IEC 27001, ISO/IEC 42001, SOC 2, NIST CSF 2.0, HIPAA and the two Polish acts. All eleven collapsed into 15 shared requirements. And of those 15, 11 are measurable directly from tenant data. Only four are genuinely documents that a human has to write and attest.

That ratio is the useful insight. Most of what the AI Act asks of an organization deploying AI inside Microsoft 365 already lives in your tenant as facts you can check, not prose you have to produce. The paperwork is real but it's the minority. The rest is hygiene, and hygiene can be measured.

What the AI Act actually asks of you

First, the shape of the law, because the headlines mostly describe obligations that belong to someone else.

The Act sorts AI by risk. Prohibited practices (social scoring, some biometric surveillance) are banned outright. High-risk systems, listed in Annex III, carry the heavy obligations. Limited-risk systems get transparency duties: people should know they're talking to a machine. Everything else, which covers most business AI, carries little beyond a general AI literacy duty for staff.

The second sorting matters more for you. The Act splits obligations between providers, who build AI systems, and deployers, who use them under their own authority. Microsoft is the provider of Copilot. Your organization is the deployer. Provider duties, like conformity assessments and CE marking, aren't yours. Deployer duties are, and they're narrower: use the system as instructed, ensure human oversight, keep logs, monitor operation, and make sure the people operating it are competent.

Timeline, briefly. The Act entered into force in August 2024. Prohibitions and the AI literacy duty have applied since February 2025, obligations for general-purpose AI models since August 2025, and the bulk of the high-risk regime since August 2026, with obligations for AI embedded in regulated products following in 2027. In other words: this is no longer a law you're preparing for. Parts of it already apply to you.

Penalties scale with the violation: up to 35 million euro or 7% of worldwide turnover for prohibited practices, up to 15 million or 3% for breaching most other obligations.

One honest caveat before the checklist. Copilot in itself is almost never a high-risk system. Risk class follows usage, not branding. Drafting emails and summarizing meetings sits outside Annex III entirely. Feed the same assistant into hiring decisions, worker evaluation or credit scoring and you've deployed a high-risk system, with the full Article 26 duty set attached. So the question isn't "is Copilot high-risk", it's "which of our uses are", and you can't answer that without the first item below.

The checklist

Each item names the obligation, then what it concretely means inside a Microsoft 365 tenant.

#ObligationWhere it lives in Microsoft 365
1Inventory every AI system in useCopilot, Copilot Studio agents, OAuth-consented AI apps
2An accountable person per AI systemOwner on every agent, no orphans
3Know what each agent is instructed to doCaptured agent instructions
4Control what data AI can reachPermissions, labels, restricted data types
5Logs that reconstruct AI activityAudit log ingestion and retention
6The four documentsImpact assessment, usage policy, incident procedure, risk management

1. Inventory every AI system in use. You can't classify what you haven't listed, and the list is longer than anyone expects. It includes Copilot itself, every agent built in Copilot Studio or Azure AI Foundry, and the category most inventories miss: third-party applications that reached your data through a single user's OAuth consent. Nobody approved them, nobody registered them, and several of them are AI products. An AI inventory that only counts the AI you bought is a provider list, and the Act regulates what you deploy.

2. Every AI system has an accountable person. Article 26 requires deployers to assign human oversight to people with the competence and authority to exercise it. In practice this collapses to one checkable fact: does every agent in the tenant have a named owner? Agents outlive their creators. The person who built that procurement bot left in March, the bot still answers questions, and right now the honest owner of record is nobody. Orphaned agents are where AI governance fails first, because an obligation assigned to no one is met by no one.

3. Know what your agents are told to do. An agent is its instructions. If you can't produce the system prompt and the knowledge sources behind an agent your organization runs, you can't demonstrate you're using it in accordance with anything, and you can't monitor operation in any meaningful sense. Captured instructions are also the artifact an auditor can actually read, unlike a model.

4. Control what data AI can reach. Copilot and agents answer with whatever the calling user can technically access, which makes years of quiet oversharing suddenly conversational. If your organization has decided some categories must never surface through AI, health data, say, or payroll, that decision is only real if it's checkable: are files of those types reachable by users, apps and agents, and do they carry a sensitivity label that encrypts? A policy PDF that says "confidential data must not be used with AI" while thousands of unlabeled files sit one prompt away is the gap between attested and measured, and it's exactly where audits go wrong.

5. Keep logs that can reconstruct AI activity. For high-risk systems, Article 26 obliges deployers to keep the logs under their control for at least six months. Treat that floor as the sensible default for all of it. When someone asks what an agent did on a specific Tuesday, the audit log is your only witness, and retention you configured after the incident helps nobody. Check two things: that AI-relevant activity is actually being ingested, and that the history is deep enough to matter. Microsoft 365 audit retention on standard licensing is shorter than you'd like, which is an argument for getting the logs out and kept elsewhere.

6. Write the four documents. Some of it really is paperwork: an AI impact assessment (Article 27 makes a fundamental rights impact assessment mandatory for some deployers, public bodies and parts of banking and insurance among them), an AI usage policy plus the register behind it, an incident response procedure that covers AI incidents, and risk management documentation. Four documents, written once, each satisfying articles across several frameworks at the same time. This is the part a consultant can genuinely help with. It's also, by count, less than a third of the job.

The overlap nobody prices in

Here's what the crosswalk taught us. The requirement "every AI agent has an accountable person" isn't just an EU AI Act fact. Articles in ISO/IEC 42001 cite it, and so does the Polish AI act. Log retention feeds NIS2, DORA, GDPR, SOC 2 and HIPAA at once. The third-party inventory from item 1 is simultaneously your supply-chain answer for NIS2 Article 21(2)(d) and DORA Article 28.

Compliance projects usually price each regulation as its own mountain. Measured as requirements, the mountains share a base. Fix agent ownership once and every framework citing it moves the same day. Organizations that discover this ordering fix the highest-overlap requirements first and watch several readiness percentages climb from a single change. Organizations that don't, prove the same control fourteen different ways and pay for each.

What "done" honestly means

One design decision matters more than any feature: what counts as a pass. A verdict that will be shown to a regulator must under-promise. That means "not evaluated" is never counted as met. No agents discovered yet doesn't mean your agent-ownership requirement passes, it means there's no data, and the two must render differently. It also means a requirement can be measured as "at risk" while your policy document says everything is fine, and when those disagree, the measurement wins, because the measurement is what the incident will eventually agree with.

If you take one habit from this post, take that one. Grade yourself conservatively now, in private, so the generous grading happens to someone else.

How 1Security does it

1Security ships this checklist as a live screen. It discovers every agent and AI-capable app in the tenant, including the OAuth-consented ones nobody registered, keeps an owner on each and flags the orphans, captures agent instructions where they're exposed, checks whether restricted data types are reachable and whether their files carry an encrypting label, and watches that audit ingestion stays fresh against the six-month floor.

The eleven-framework crosswalk runs continuously: 15 requirements, 11 measured from tenant data, 4 recorded as attestations with an owner and a review date. Every article in the EU AI Act view names the requirements that satisfy it, one deduplicated worklist ranks open gaps by how many articles they unlock, and a dated snapshot is captured weekly, so "what was our status in September" has an answer you can hand over. Nothing has to be configured first, which means the first honest readiness picture exists before the remediation project starts, not after.

Frequently asked questions

We only use Copilot for documents and meetings. Does the Act apply to us at all? Yes, but lightly. The AI literacy duty applies to everyone, and an inventory plus usage policy is how you demonstrate your uses sit outside the high-risk list. The point of the checklist is that being out of scope is a claim you should be able to evidence.

Is Microsoft responsible for Copilot's compliance, or are we? Both, for different things. Microsoft carries the provider obligations for the system itself. How your organization deploys it, who oversees it, what data it can reach and whether the use case is high-risk are deployer questions, and no vendor can answer them for you.

Do we need to block AI until the paperwork is finished? The Act doesn't ask for that, and practically it backfires: blocked official AI produces unofficial AI, which you'll find in the OAuth consent list. Inventory first, assign owners, restrict what's reachable, then write the documents against reality instead of intention.

Where should we start if we can only do one thing this quarter? The inventory. Every other item depends on it, it's the single requirement cited by the most articles across frameworks, and it's the one an auditor asks for first.


SecurityMicrosoft 365

Latest Blog Posts

Discover more insights about Microsoft 365 security, governance, and compliance.

View all posts

Take control of Microsoft 365 access today

Stop guessing who has access to your sensitive data. With 1Security, you gain the visibility, automations, and confidence needed to protect your Microsoft 365 environment.