Microsoft's Responsible AI Principles for Azure AI Fundamentals (AI-901)

Microsoft's six principles of responsible AI are fairness, reliability and safety, privacy and security, inclusiveness, transparency and accountability. They are the considerations every team should work through when it designs, builds, deploys and runs an AI solution, and AI-901 asks you to describe what each one means in practice.

Each principle answers a different question about the system. Learning that question is the quickest way to place any scenario under the right principle:

The principles overlap in real projects, and one measure can support more than one of them. When you classify a measure, ask what problem it mainly solves: unequal outcomes, unsafe behavior, exposed data, people being shut out, people misunderstanding the system, or nobody being answerable.

Fairness means an AI system should treat people equitably: people in similar circumstances should get similar outcomes, whatever their gender, age, ethnicity, neighborhood or other characteristics that should not matter. Microsoft's guidance gives the classic example of a loan-approval model that should make the same recommendation for applicants with similar financial circumstances.

Where unfairness comes from

Most unfairness comes from the training data. A model learns patterns from past examples, so if those examples reflect historical bias, the model reproduces it. A model trained on years of past admissions, hiring or lending decisions will learn whatever preferences shaped those decisions, and a group that is under-represented in the data tends to get less accurate predictions.

Simply deleting a sensitive column (such as gender) does not remove the bias. Other features often correlate with it, so they act as proxy features: a postcode can stand in for ethnicity or income, and the wording, hobbies or career gaps on a CV can stand in for gender. The model can rebuild the same pattern from the proxies, and without the sensitive column it becomes harder to measure whether it has done so.

How teams address fairness

• Make the data representative. Collect more data for under-represented groups, or rebalance or reweight the training data so every group is adequately represented.
• Measure outcomes per group. Compare selection or approval rates and error rates across groups of people with similar relevant characteristics, on held-out test data. This produces the evidence that similar people get similar decisions. The fairness assessment in the Azure Machine Learning Responsible AI dashboard is built for exactly this kind of comparison across sensitive groups.
• Check quality of service, not just decisions. Microsoft's Responsible AI Standard treats a system that works noticeably worse for some groups (for example, a document-scanning model that misreads handwriting from some regions far more often) as a fairness harm, even when nobody is refused anything.
• Keep checking after release. Data and populations change, so fairness metrics are monitored, not measured once.

A useful test: a measure supports fairness only if it changes, or produces evidence about, how outcomes and error rates compare between groups of people. Good practices that do something else, however valuable, sit under another principle.

Reliability and safety means an AI system should perform consistently as designed, respond safely to conditions it was not designed for, and resist being manipulated into harmful behavior. The starting point is that AI is probabilistic: a model produces the most likely output for an input, which is usually but not always correct, and it can be wrong while sounding or scoring confident.

Why a good demo is not enough

A demo exercises a handful of typical inputs. Real users send unusual, ambiguous and adversarial ones, and models are least reliable on inputs unlike their training data (for example, rare situations that barely appear in it). Reliability therefore requires testing with a wide range of normal, edge-case and unexpected inputs before release, and planning for what happens when the model is wrong.

Designing for the model's weak spots

• Confidence thresholds. Many models return a confidence score with each prediction. A system can act automatically above a threshold and stop, ask for help or hand over to a person below it, as a medical-triage model might when it flags a case it cannot classify with enough confidence for a clinician to assess.
• Targeted human review. Where errors are serious, send the risky cases (low confidence, or categories known to be weak) to a human reviewer, and keep automation for routine cases where the model performs well. This reduces the risk while keeping the benefit of automation. Error analysis, which breaks a model's errors down by type of input, is how teams find out which categories those are.
• Safe failure. When the system cannot answer well, it should fail gracefully, for example by declining or escalating rather than guessing.

Reliability and safety for generative AI

Generative models add a specific risk: they can produce harmful content such as hateful, violent, sexual or self-harm material, or be steered towards it by crafted prompts. The main mitigations are:

• Content filters (guardrails). In Microsoft Foundry, model deployments such as Azure OpenAI models apply content filtering by default, powered by Azure AI Content Safety, that detects and blocks harmful categories of content in both prompts and responses. Each category's severity threshold can be configured.
• Adversarial testing. Teams evaluate the app with realistic and deliberately hostile prompts (often called red teaming) before launch to find where it misbehaves.
• Monitoring. Once live, the app's outputs and any filter hits are monitored so new failure patterns are caught and fixed.

Content filters target categories of harmful content. Other risks, such as unequal outcomes or exposed personal data, are addressed by the fairness and privacy measures described in their own sections.

Privacy and security means an AI system must protect the personal and organizational data it uses, and must not become a way to reveal that data. AI depends on large amounts of data, often personal, so the principle covers two things: the data that goes into the system, and what the system can be made to give out.

Protecting the data the system uses

• Minimize and limit retention. Collect only what the system needs and keep it no longer than necessary.
• De-identify. Mask, remove or replace names, addresses, card numbers and other identifiers before data is used for training, fine-tuning or analysis.
• Restrict and encrypt. Limit who can access datasets and recordings, and encrypt data at rest and in transit.
• Consent and control. Privacy laws, and Microsoft's principle, expect people to have appropriate control over how their data is collected and used: ask permission before using their data (for example, to improve a model), explain the use, and let them withdraw that permission.

Protecting what the model can reveal

A trained model can memorize details from its training data, and an assistant grounded on internal documents can quote from them. Microsoft's guidance is that the system itself must not be usable to reveal private personal or organizational details. A document-search assistant that can be prompted into quoting confidential contract terms or a customer's home address fails privacy and security, even though nothing it says is offensive or violent. Mitigations include keeping sensitive data out of training sets or grounding sources unless it is needed, applying the user's own access permissions to the documents an assistant can retrieve, and testing whether prompts can extract private information.

Inclusiveness means an AI solution should empower and engage everyone and must not exclude people from using it or benefiting from it, whatever their physical ability, gender, age, language, location, connectivity or other circumstances. Where fairness asks whether the model's outcomes are equal, inclusiveness asks whether everyone can use the system in the first place.

• Accessibility. Offer more than one way to interact: captions or on-screen text for people who cannot hear a voice interface, typed input for people who cannot speak, screen-reader support and adjustable speech speed for people with visual or other impairments, plain language for people with limited reading skills.
• Design for real conditions. Consider slow connections, older devices and different languages, so the benefit is not limited to users with ideal circumstances.
• Involve diverse people from the start. The most effective practice is to include people with a range of abilities, ages and backgrounds in design and user testing, so barriers are found and removed before release rather than discovered afterwards.

Transparency means people should understand that an AI system is involved, how it works and what its limitations are, so they can judge how much to trust it, especially when it informs decisions about them. Transparency calibrates trust: users who do not know they are dealing with AI, or who do not know where it can go wrong, tend to over-trust it.

Disclosure

• Disclose AI use. Tell people when they are interacting with an AI system (for example, that a chat assistant is AI and not a human agent) or when AI contributes to a decision about them.
• Describe the data. Explain the kinds of data the system was trained on and its intended uses, without revealing confidential details.
• State limitations. Say where the system is known to perform poorly and that its outputs can contain mistakes. Microsoft publishes transparency notes for its AI services for this purpose, and teams can write the same kind of document for their own systems.

Interpretability

Microsoft treats interpretability, giving human-understandable explanations of a model's behavior, as a crucial part of transparency. There are two kinds of explanation:

The Azure Machine Learning Responsible AI dashboard includes model interpretability with both global and local feature importance. Note that explaining an individual decision is transparency; comparing outcomes across groups is fairness, even though both use model analysis tools.

Accountability means the people and organizations that design, build and deploy an AI system are answerable for how it operates. AI should not be the final authority on decisions that affect people's lives, and humans should keep meaningful control over highly autonomous systems.

• Governance framework. Organizations set internal policies and standards, often with a review board or committee that must approve AI systems before release, guided by industry and legal requirements.
• Named owners. Each system in production has a person or team who answers for its behavior, signs off releases and acts on problems.
• Humans as the final authority. For consequential decisions, people review the model's output (for example, case officers reviewing a model's recommendation before a benefits application is turned down) and affected people can appeal to a person rather than to the model.

Records such as audit trails support accountability by making it possible to trace an outcome back to the system and the people responsible for it.

Near-twin principles are told apart by asking what problem a measure mainly solves. Four pairs cause most confusion:

One scenario can raise two principles at once. A face-verification check that fails more often for people with darker skin tones has a fairness problem (unequal quality of service); if the same self-service kiosk also has no screen at wheelchair height, it has an inclusiveness problem too (some people cannot use it at all). Likewise, a public chat assistant may need a disclosure that it is AI (transparency) as well as content filters (reliability and safety).

In short, transparency is aimed at the people who use or are affected by the system and is measured by whether they understand it; accountability is aimed at the organization and is measured by whether someone is answerable for it.