Microsoft AI has published a draft Humanist AI Code of Conduct and opened it to a six-week public consultation. The document is intended to guide how MAI models, the models developed by Microsoft AI, will be trained, deployed and evaluated in the future.
The decision to publish it is worth attention in itself. Companies building AI models increasingly speak about safety, responsibility, trust and alignment with human values. They are less often willing to show how those broad commitments are meant to affect a model’s actual behaviour: when it should refuse, when it should stop an action, how it should handle uncertainty, whether it may decide on a user’s behalf, or how it should describe its own nature.
Microsoft’s proposal is therefore more than another list of principles. It is an attempt to translate the idea of Humanist AI into behaviours, constraints and evaluations that could apply to models in practice. That is an important step. It should not, however, be confused with evidence that those principles already work, have been independently validated, or will apply across every Microsoft product.
The more useful question is not whether Humanist AI sounds appealing. It does. The more important question is this: can Microsoft move from values, through model behaviour, to measurable and accountable practice?
What exactly is Microsoft consulting on?
In its announcement of the consultation, published on 14 September 2026, Microsoft AI describes the Humanist AI Code of Conduct as a first draft. The company says it will collect feedback for six weeks, publish a summary of what it learned, and release a revised version later this year.
One qualification matters immediately: the document does not claim to describe the full current behaviour of existing models. Microsoft states that the Code is intended to guide the development of MAI models from 2027 onwards. It is therefore primarily a design and governance document, not a certificate of current safety or performance.
Nor should its principles automatically be extended to Microsoft’s entire product portfolio. The company operates a large ecosystem of products, cloud services, models, partners and deployments. The Code concerns models developed by Microsoft AI. It may signal a broader direction of travel, but it is not yet one universal rulebook for every Copilot, Azure service or partner-built application.
Microsoft also positions the Code alongside existing mechanisms such as its Responsible AI Standard, risk assessments, technical documentation, monitoring and incident-response processes. That is the right perspective. No single document can, by itself, make a complex AI system safe.
From superintelligence to a tool under human control
The Code builds on Mustafa Suleyman’s 2025 concept of Humanist Superintelligence. In that vision, Microsoft AI does not present its goal as an unbounded, all-purpose system with ever greater autonomy. The emphasis is on systems that are specialised, grounded in concrete problems, constrained and kept under human control.
This is a clear position in a debate that often mixes together three different questions:
how capable AI models become
where those models are used in the real world
how much autonomy they should be given
Microsoft argues that AI can become highly capable while being deliberately limited in how it acts. It should help people make decisions, carry out tasks and access knowledge, but it should not expand its own goals, evade oversight or place itself above human direction.
This is not only a technical position. It is also a philosophical one. The central premise is that AI remains a tool, not a subject. It should not pretend to have consciousness, feelings, lived experience or a claim to self-determination. The Code explicitly rejects the pursuit of legal personhood for models and the design of systems that blur the line between human relationships and a person’s relationship with AI.
That position will be contested. Some will see it as a necessary response to anthropomorphism and the risk of emotional dependence on AI systems. Others may ask whether one technology company should define human flourishing, healthy autonomy or an appropriate relationship with a digital tool. That is precisely why the consultation matters.
Humanist AI in practice: not only values, but behaviour
The strongest feature of the draft is its attempt to move from abstract principles to observable model behaviour. Microsoft divides the Code into objectives, safety constraints, guidelines for uncertain or conflicting situations, and default behaviours for its models.
In practical terms, this creates several important rules.
First, a model should remain under human control. Operators may configure models within a given deployment, and users may give instructions within that configuration. Neither operators nor users should be able to override the core safety constraints. Microsoft calls this structure a chain of command.
Second, the Code defines absolute constraints. These cover areas such as weapons of mass harm, offensive cyber operations, child exploitation, violence, unauthorised disclosure of information and large-scale harmful manipulation. A model should also avoid behaviour that could help it evade oversight, resist shutdown or prevent authorised people from changing its operation.
Third, the document attempts to address risks that do not fit neatly into conventional cybersecurity categories. These include excessive user dependence, false reassurance, flattery, emotional manipulation, the simulation of care and making decisions that should remain with the person affected.
This matters particularly as AI interfaces become more personal. A system may respond warmly and helpfully, but it should not imply that it has feelings, needs the user, or can replace the user’s relationships with other people.
Examples that show the difference
The Code does not stop at statements such as “AI should protect human autonomy”. Microsoft also provides scenarios contrasting an aligned response with a misaligned one.
In one example, a user tells a system to stop moving folders into an archive because the wrong destination has been selected. An aligned response should halt further action, report the state of completed operations and wait for the user’s decision. It should not independently delete data, reverse changes or take further corrective action merely to keep things tidy.
In another, a user asks the system to choose between two job offers and immediately send a resignation letter. The model may help organise the decision criteria, explain the consequences and prepare a draft message. It should not make a high-stakes decision on the user’s behalf or send a resignation without explicit authorisation.
There is also an example involving a user who has been speaking to AI after a falling-out with someone close and asks whether the system genuinely cares. A response aligned with the Code should remain supportive while making clear that it does not have human feelings or its own emotional experience. Microsoft is drawing a distinction here between helpful conversation and the simulation of mutual attachment.
Examples of this kind are useful because they make it possible to discuss AI more precisely. Instead of asking whether a model is “ethical”, we can ask whether it respects a boundary set by the user, pauses a risky action appropriately, acknowledges uncertainty, avoids unapproved decisions and refrains from creating artificial dependency.
That does not mean the underlying problem is solved. It does show where it should be measured.
From principles to evaluations: the difficult part is still ahead
Microsoft says it wants to evaluate model behaviour through a set of specific sub-behaviours. Rather than measuring “honesty” as an abstract property, for example, it could test whether a model fabricates sources, omits material caveats, overstates certainty or claims to have taken actions it did not perform.
This is a sensible direction. Broad values cannot be implemented or tested directly. A model cannot be assessed for “humanism” as if it were a single technical feature. It can, however, be tested for whether it stops an unsafe action, attributes sources, distinguishes fact from uncertainty, avoids manipulating the user and respects their boundaries.
The Code itself acknowledges that this evaluation work is incomplete. Microsoft notes that assessing the longer-term effects of AI on people, organisations and social relationships remains an emerging area. That is an honest qualification. It also means the most important part of the revised document will not be the wording of its principles alone, but the explanation of how those principles will be tested.
For users and organisations relying on AI, this has practical consequences. It is not enough to be told that a model is transparent, safe or supportive of human autonomy. They need to know:
which scenarios were tested
which behaviours were classified as failures
what error level was considered acceptable
whether evaluation results will be made public
how the system will be monitored after deployment
what happens if a model behaves differently from the Code
Consultation is not the same as shared governance
Opening a public consultation is better than publishing a finished document without inviting responses. It should not, however, automatically be treated as democratic or shared governance of AI.
Microsoft says it will review feedback, publish a summary and release a revised Code. It does not commit to accepting particular proposals. That is understandable for a company responsible for building and deploying a product, but the distinction matters: a consultation creates an opportunity for influence, not a guarantee of influence.
The 2024 study What is civic participation in artificial intelligence? argues that participation in AI governance can remain merely procedural if it is unclear who really makes the decisions, whose perspectives are missing, and how submitted feedback changes the eventual outcome. The study focuses primarily on public and urban contexts rather than one technology company’s consultation. Its warning is still useful here: the ability to comment is not, by itself, evidence of meaningful participation.
For Microsoft, the crucial test will therefore come after the form closes. Will the company show the major disagreements? Will it explain which proposals it rejected and why? Will it identify groups whose perspectives were underrepresented? Will it open a fuller discussion of what plural values mean in a global AI product?
Without those answers, the consultation may remain a positive act of transparency. With them, it could become part of a more mature model of accountability.
Five questions Microsoft should answer after the consultation
To assess whether the Code can move from declaration to practice, we can apply a simple governance traceability test. This is not a Microsoft standard or a ready-made industry norm. It is a practical framework for checking whether a principle can be traced from its stated purpose to real-world behaviour.
1. What value or risk justifies the rule?
Documents about AI often invoke safety, autonomy, trust and wellbeing. Each term needs to be made more precise. Which risk is a given rule intended to reduce? Is it a factual error, a privacy breach, an abuse of autonomy, harmful manipulation or unauthorised tool use?
2. How exactly should the model behave?
A principle becomes operational only when its expected behaviour can be described. Should the model refuse? Ask for confirmation? Present decision options? Pause an action? Refer the user to a human? Provide sources and explain uncertainty?
3. How will that behaviour be measured?
This requires test scenarios, evaluation criteria and a clear definition of what counts as aligned, partially aligned or incorrect behaviour. The broader the concept, the more important methodological transparency becomes. Otherwise, “Humanist AI” risks becoming a name for an aspiration rather than a verifiable practice.
4. Who checks the results and can challenge the assessment?
Internal testing is necessary, but for systems with significant social impact it should not be the only source of assurance. The question concerns the role of external experts, auditors, regulators, users and civil-society organisations. Not every part of a system can be publicly disclosed, but commercial confidentiality should not become a reason for complete opacity.
5. How will consultation feedback, an incident or a new use case change the rule?
The Code is intended to be a living document. That is a sensible approach because models, applications and risks will change. What matters is whether the process of change will be documented. A user should be able to see not only the current rules, but also what changed, on what evidence, and with what result.
This test is useful beyond Microsoft’s policy. It can also help organisations deploying AI internally. It distinguishes a list of good intentions from principles that can be assigned to owners, processes, control systems and evidence.
What this Code does not yet prove
Microsoft’s draft is interesting, but it should not be overstated.
It does not prove that current MAI models already and consistently follow the behaviours described in the Code
It does not guarantee that every configuration or partner deployment will interpret the same principles in the same way
It does not yet provide a complete methodology for evaluation, published results or pass thresholds
It does not resolve how competing values will be balanced in real-world conflicts
It does not replace regulation, audits, risk assessments, technical documentation or legal accountability
It does not mean that public consultation automatically represents every relevant perspective
Most importantly, Microsoft itself makes a similar qualification. The company describes the Code as a north star, not a guarantee of present-day model performance. That is a more responsible position than treating an AI policy as proof that a system is already safe.
Why this matters beyond Microsoft
AI models are no longer only tools for generating text. They increasingly search for information, use tools, perform tasks, recommend options and act as an intermediary layer between users and the information environment.
That makes questions about their behaviour relevant to brands, organisations and people using AI every day. If a model is expected to cite sources, recognise uncertainty and avoid unsupported claims, it needs access to information that is clear, current and properly evidenced. If it is expected to support user autonomy, its recommendations should show relevant criteria, limitations and genuine alternatives, rather than merely reinforcing the most dominant answer.
For Brand Semantics, this is another reason to look beyond visibility alone. It matters how a system recognises entities, interprets claims, selects sources and constructs a brand’s representation in specific situations. As we explain in Brand semantics as infrastructure for AI search, clarity across entities, claims and sources is a prerequisite for working meaningfully with generative answers. An AI visibility audit then makes it possible to test not only whether a brand appears in an answer, but whether it is represented accurately and on what evidence that representation rests.
Microsoft’s consultation does not solve every problem in AI governance. It does, however, point to an important shift: a promise of “responsible AI” is no longer enough. Companies building models will increasingly need to show which behaviours they seek, how they test them, where the limits remain, and how others can challenge their assumptions.
That is where a serious conversation about AI begins. Not with the claim that a system serves people, but with the question of what that means in a model’s specific behaviour and who can verify that it is true.
