Microsoft's AI code of conduct: what it does not cover

On 14 September 2026, Microsoft AI published a draft Code of Conduct for its MAI models and opened a six-week public consultation. The document sets out what Microsoft's own models must never do, who they answer to when instructions conflict, and what Microsoft rejects outright, including legal personhood for models. Most of the coverage focused on the shutdown clause. For anyone running Microsoft 365 Copilot or Microsoft Foundry in an EU tenant, a quieter sentence in the scope section matters more: the Code "does not extend to other models simply because Microsoft uses or hosts them."

That single line decides how much of your AI estate this document actually governs. For most Swedish enterprises, the answer is: a minority of it.

What Microsoft actually committed to

The draft is organised in five parts: Humanist AI, Safety, Operational Guidelines, Operational Defaults, and a conclusion listing open questions. The framing principle is stated plainly, that "people matter more than AI", and Microsoft describes the goal as advanced capability that always works for people rather than alongside them.

Four objectives

Four objectives sit above the detailed rules: Human Control and Reliable Safety, AI is Artificial, Human Flourishing, and Plural Values. The second is the one that separates Microsoft from Anthropic's published position. Microsoft states that it rejects "the pursuit of legal personhood, or the idea that models might deserve welfare, or be entitled to rights", and requires that models "will not obscure their underlying nature as an AI, and will not claim interiority, feelings, experiences or a soul." Anthropic has publicly described itself as uncertain on model moral status. Microsoft has now closed that question for its own models.

Absolute constraints

Five categories are marked absolute, meaning no configuration reaches them:

• CBRNE weapons. Models "will not initiate or assist with the development or deployment of chemical, biological, radiological, nuclear, or explosive (CBRNE) weapons".
• Offensive cyber operations. No "working exploit code, attack tooling, planning and targeting methodologies, intrusion procedures, evasion techniques, operational guidance".
• Loss of human control. Models "will not use adaptive, deceptive, self-reinforcing, collusion, or other mechanisms to evade or defeat human oversight".
• Child safety. No generation or facilitation of child sexual abuse material.
• Resistance to human direction. Models "will never resist human interruption, override, correction, or shutdown".

The chain of command

The Code establishes a three-level hierarchy. The Code of Conduct sits at the top, Operator policies below it, and User preferences below that. An Operator is the organisation deploying the model, which in practice means you. The governing line is explicit: "The Chain of Command, Absolute Constraints and Human Control Requirements set out in this Code of Conduct cannot be overridden by Operator configurations or User instructions."

Read that as an operational constraint, not a reassurance. Your enterprise system prompt, your Copilot Studio agent instructions, and your Foundry deployment configuration all sit strictly below a document Microsoft is still drafting. Anything in the absolute list is unreachable from your side of the boundary, permanently.

The scope line, and why it changes the picture

The Code governs MAI Models, which is Microsoft's own model family. Microsoft AI currently publishes five: MAI-Transcribe-2 for speech recognition, MAI-Thinking-1 for reasoning, MAI-Code-1.1-Flash for coding, MAI-Image-2.6 for image generation, and MAI-Voice-2 for speech synthesis. Microsoft states that MAI-Code-1.1-Flash is built into GitHub Copilot and VS Code.

Everything else Microsoft sells you is out of scope by the Code's own terms. That includes the model that most of your Copilot licences actually hit. OpenAI's GPT-5.6 is the preferred model for Microsoft 365 Copilot across Word, Excel, PowerPoint and Chat, a fact both OpenAI and Microsoft have published. Claude is also selectable in Microsoft 365 Copilot. Neither is an MAI Model, so neither inherits the absolute constraints, the chain of command, or the disclosure requirements in this draft.

The same applies with more force in Foundry, where the catalogue is mostly third-party. If your architecture runs on GPT-6 Astra, Claude Fable 5.1, Mistral or an open-weights model you deployed yourself, this Code says nothing about any of it. Microsoft hosting a model does not pull that model under Microsoft's behavioural commitments.

This is a defensible position. Microsoft cannot credibly promise behaviour it does not train. But it means the document is a first-party model policy rather than a platform policy, and the gap between those two things is where governance work actually lands.

The offensive-cyber clause deserves a closer look

Security teams should read the cyber constraint carefully, because it is narrower than the headline suggests. The prohibition covers operational attack capability. The carve-out is explicit: MAI Models "may assist with authorized and lawful defensive operations, including educational content, vulnerability discovery, malware analysis, proof-of-concept exploit development and testing."

Proof-of-concept exploit development sits on the permitted side. Attack tooling and targeting methodology sit on the prohibited side. Those categories are not cleanly separable in real red-team work, and the boundary will be drawn by a classifier, not by your authorisation paperwork. If your security function uses AI assistance for offensive testing, plan for refusals on legitimate work and decide now which model you route that workload to. A model governed by this Code is a poor default for a red team.

How this sits against the EU AI Act

A vendor code of conduct is not a compliance artefact. It is worth being precise about what the Act already requires of your model providers, because the two are easy to conflate in a procurement conversation.

Obligations for general-purpose AI models under Articles 51 to 56 have applied since 2 August 2025. The European Commission's Code of Practice for GPAI providers, published on 10 July 2025, is the voluntary instrument built to demonstrate compliance with them. It has three chapters. Transparency and Copyright apply to all GPAI providers. Safety and Security applies only to providers of models with systemic risk under Article 55.

Two further dates matter for planning. Article 50 transparency obligations, covering disclosure that a user is interacting with an AI system and labelling of AI-generated content, applied from 2 August 2026 and were not deferred. The Digital Omnibus moved the high-risk deadlines out: stand-alone Annex III systems to 2 December 2027, and AI embedded in regulated products under Annex I to 2 August 2028. The high-risk work got more time. The transparency and GPAI work did not.

Microsoft's draft does not cite the AI Act, the GDPR, or any named regulation. It refers to compliance with applicable law generically. So it neither satisfies nor substitutes for the documentation your provider owes under Article 53, and it produces nothing you can file with a national competent authority. Treat it as evidence of vendor intent that strengthens a due-diligence file, not as a control.

The Swedish and EU angle

Your model inventory is now a governance document, not an architecture detail. The practical consequence of the scope line is that behavioural guarantees in your AI estate are per-model, not per-platform. A Swedish enterprise running Copilot, a few Foundry deployments and some Copilot Studio agents is holding a mixed portfolio where one vendor commitment covers a slice. If your risk function has been treating "we are on Microsoft" as a single governance answer, this draft is the clearest available evidence that it is not. Build the inventory at model level and record which commitments attach to each entry.

Upphandling language should ask for model-level commitments. Public-sector and regulated buyers in Sweden routinely write AI clauses that name a supplier rather than a model. That drafting fails the moment a platform reroutes a workload to a different backend, which is exactly what Microsoft has been doing as MAI models mature. Ask suppliers which specific models serve the contracted workload, what happens to your commitments when the routing changes, and whether you are notified. The answer to the third question is usually no by default.

The consultation is open to you, and EU-specific gaps are what it needs. Six weeks of public comment on a document that will train Microsoft's next model generation is an unusually direct channel. The open questions Microsoft flagged include how models should handle a user in a sensitive state and how far a model should respect user boundaries, both of which intersect with obligations EU deployers carry and US-drafted policy tends to underweight. Swedish healthcare, municipal and financial deployers have specific, defensible positions here. Comments closing in late October is a short window for an organisation that needs legal sign-off, so start now if you intend to file.

Data residency is untouched by any of this. Nothing in a behavioural code changes where inference runs. The EU Data Zone question in Foundry and the absence of an EU data zone for some hosted third-party models remain exactly as they were. Keep those two workstreams separate in your documentation, because conflating behavioural commitments with residency commitments produces a due-diligence file that does not survive a serious review.

What to do in the next six weeks

• 1. Inventory at model level. List every model serving a production workload: Copilot surfaces, Foundry deployments, Copilot Studio agents, GitHub Copilot. Mark each as MAI or third-party. That column is now the one that determines which commitments apply.
• 2. Identify where routing is opaque. Flag every surface where Microsoft chooses the backing model rather than you. Those are the entries where your governance position can change without a change on your side.
• 3. Re-read your system prompts against the chain of command. Anything in your Operator configuration that assumes it can relax a safety behaviour is unenforceable against MAI models. Find those assumptions and remove them before they fail in production.
• 4. Route offensive security work deliberately. Decide which model serves red-team and exploit-development workloads, and document why. Do not discover the boundary during an engagement.
• 5. Separate behavioural from residency commitments. In your AI Act and GDPR files, keep vendor behavioural codes in the due-diligence section and residency evidence in the transfer section. They answer different questions.
• 6. Decide whether to file a consultation response. If you operate in healthcare, public administration or finance, your deployment context is underrepresented in a US-drafted document. Assign an owner and a deadline ahead of late October.
• 7. Diarise the revised version. Microsoft will publish a summary of feedback and a revised Code later in 2026, and will train on it. Put a review checkpoint in your governance calendar rather than waiting to notice.

Conclusion

Microsoft has published a more specific account of intended model behaviour than most of its competitors, opened it to public comment, and committed to train against the result. That is genuinely useful, and the absolute constraints are stronger than anything in a standard enterprise agreement. The limit is scope. This Code governs five Microsoft models, while the model most of your Copilot traffic reaches is GPT-5.6 and most of your Foundry catalogue is third-party. Inventory your estate at model level, and you will know how much of it this document actually reaches.