Describe principles of responsible AI

Two teams ship the same résumé-screening assistant. One team can say, for each of six named questions, what they checked and what they found. The other can only say that the model is 94% accurate. Only the first team has done responsible AI work, because Microsoft's Responsible AI Standard^[1] frames that work as six principles a system has to satisfy together: fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. The six are not ranked, and none of them covers the others: a system can be accurate and unfair, or dependable and completely opaque.

The other two pages in this domain answer different questions. Identify AI model components and configurations covers what a generative model is and how you configure a deployment, and Identify AI workloads covers which kind of AI a given scenario calls for. This page covers neither piece of machinery. It covers the six questions you ask about any AI solution, whichever model or workload it happens to use, and it follows the six considerations the official AI-901 study guide^[2] lists under this topic. The six apply to any AI solution, from a chat assistant over a deployed model to a classifier scoring loan applications, so the only background they assume is that a model produces output that people act on. Naming which of the six a scenario illustrates, and one consideration that addresses it, is what the sections below drill.

One line per principle

Each principle gets its own section below, in this order, so treat these as the short definitions and read on for the considerations that go with each.

• Fairness: do people in similar circumstances get similar treatment?
• Reliability and safety: does the system behave as designed, including under conditions nobody planned for?
• Privacy and security: is the data protected, and do people know and control how it is used?
• Inclusiveness: can people of all abilities and backgrounds use the system at all?
• Transparency: do people know they are dealing with AI, and can they understand what it did?
• Accountability: who is answerable for the system, and who keeps meaningful control?

One quirk of the documentation is worth knowing before you read further. The Azure Machine Learning article on responsible AI discusses fairness and inclusiveness under a single heading^[1], because both concern who the system serves well, while the Standard and this exam's objectives count them separately. Treat them as six principles, and keep the two apart the way the last section of this page describes.

The figure below shows the six principles under the Standard, each with one representative consideration of the kind an exam scenario tends to describe.

Fairness asks whether people in similar circumstances get similar treatment. It does not ask whether everyone gets the same answer, and that distinction is where most wrong answers come from. Microsoft's guidance states the requirement in terms of similarity: when AI systems provide guidance on medical treatment, loan applications, or employment, they should make the same recommendations to people with similar symptoms, financial circumstances, or qualifications^[1]. A lending model that offers different terms to two applicants with the same income, debt, and history has a fairness problem. A lending model that offers different terms to applicants with genuinely different finances does not.

Aggregate accuracy is not a fairness measurement

The measurement that exposes a fairness problem works at the level of groups, not at the level of the whole test set. Compare outcomes and error rates for the groups the scenario cares about, such as gender, ethnicity, and age, which are the examples Microsoft's own fairness assessment^[1] tooling is built around. Those three are examples rather than a fixed list: the relevant groups depend on who the system affects, and a scenario about regional dialects or age brackets is still a fairness scenario.

The reason group-level comparison is the right instrument is arithmetic. A model can score well overall while performing badly for a cohort that makes up a small share of the data, because the majority's results dominate the average. So an answer option that reports a single accuracy number, however high, never demonstrates fairness. It reports something real, but not the thing fairness is about.

One caution about the relationship between accuracy and fairness, since the docs address it directly: accuracy and responsible AI metrics are often interconnected, and improving a model's accuracy can reduce fairness-related harms, but accuracy alone doesn't include all safety considerations^[3]. Better accuracy can help. It is not evidence on its own.

The takeaway to carry into a question: fairness is a comparison, so the correct answer usually describes comparing something across groups, and the distractor usually describes a single overall number or an identical result for everybody.

The rule in one line: a system meets this principle when it functions as designed and responds safely to conditions it was not built for, not only to the inputs it was tested on. Microsoft's framing is that AI systems must operate reliably, safely, and consistently, function as designed, and respond safely to unexpected conditions^[1], and that a system's ability to handle varied conditions reflects the range of situations its developers anticipated during design and testing. That last clause is the useful one for a builder: reliability and safety is bought at design time, by widening the set of situations you deliberately consider. Concretely that means naming the conditions the system will meet, expected and unexpected, testing what it does when they go wrong, and defining a safe fallback behavior for the cases it cannot handle.

A name collision to clear up at first touch. "Reliability" also names an Azure Well-Architected Framework pillar, where it means the workload stays available and recovers from failure. The responsible AI principle covers safe, as-designed behavior, resilience, and availability. A scenario about an outage or regional failover can therefore involve both responsible AI and architecture; a scenario about what the model does when it receives an input nobody anticipated also falls under this principle.

The work does not stop at release

Predeployment testing sees the conditions you thought of. Production sees the rest, so this principle carries an obligation that runs after go-live: changing data and changing usage surface behavior that no test set contained, a shift the docs call system drift. Foundry's observability guidance describes the matching practices as continuous evaluation of production traffic at a sampled rate, scheduled evaluation against test datasets to detect system drift, and alerts when outputs fail quality thresholds or produce harmful content^[4]. An answer that stops evaluating once the system passed its initial test set is describing the failure this principle exists to prevent.

One phrase deserves care. The wording "resist harmful manipulation" appears in Microsoft's responsible AI material attached to reliability and safety on the Azure Machine Learning responsible AI page^[1], while other responsible AI guidance treats preventing manipulation as a security concern, describing unacceptable behaviors such as manipulation^[3] among the things security measures must prevent. The placement is not settled across official pages, so do not decide a question on that phrase alone. Decide instead on what is being protected: the system's behavior points to reliability and safety, while the data and who may reach it points to privacy and security.

The takeaway is that this principle is judged on behavior at the edges of what you planned for, and it is judged twice: once before release and continuously afterwards.

The figure below traces the loop this principle implies, from naming the conditions through to what happens when production shows you something new.

This principle has two halves, and a solution has to satisfy both. The security half is technical and familiar: protect the data the system consumes and produces. The privacy half is about the person the data describes: they are told what happens to their data and get a say in it. Microsoft ties the two together through the legal obligations AI systems inherit, noting that privacy laws require transparency about the collection, use, and storage of data and mandate that consumers have appropriate controls to choose how their data is used^[1].

The controls that count as considerations

On the security side, the platform-level measures Microsoft names for AI workloads are the ones to recognize in an answer option: restrict access to resources and operations by user account or group, restrict incoming and outgoing network communications, encrypt data in transit and at rest, scan for vulnerabilities, and apply and audit configuration policies^[1]. In Azure terms, the access-restriction control is Microsoft Entra ID (the identity service, formerly Azure Active Directory) with role-based access control (RBAC), the model in which permissions are granted through role assignments rather than to individuals ad hoc. Well-Architected guidance for AI workloads asks for role-based access control for both the control plane and the data plane^[3], so it covers user access and system-to-system calls alike.

On the privacy side, three practices carry most of the weight. Collect only the data the scenario needs and obtain consent for it. Keep personal data out of prompts and logs where you can, or remove it before storage, which is what the same guidance means by anonymizing data as it moves through the pipeline. And be able to honor a deletion request, which the docs discuss as the right to be forgotten.

The trap is treating the technical half as the whole principle. An encrypted, access-controlled system that never tells users their conversations are retained for analysis fails this principle, because the disclosure and control obligations are part of it, not an optional extra. Conversely, a scenario about telling users what an AI system can and cannot do is not this principle at all: disclosure about the system is transparency, while disclosure about the data belongs here.

Captioning a live session, reading a page aloud, and driving an app by voice are all the same principle at work. Inclusiveness is the requirement that an AI system engage and empower people across the full range of ability, language, and background, rather than working well only for the majority in the training data. Microsoft states it as a hard requirement of the Standard: everyone can access AI systems regardless of any disability, and responsible AI solutions must enable full global inclusion by offering alternative modes of interaction such as voice control, captions, and screen readers^[5].

That gives you a short, concrete list of what counts as an inclusiveness consideration in a scenario: assistive technology support such as screen readers, more than one way to interact with the system such as voice or text, captions and transcription, and additional languages, including regional dialects rather than only the major ones. Those are examples of the requirement, not the complete set; anything that removes a barrier to using the system belongs here.

Who tests it matters as much as what you build

A development team is a poor judge of whether its own interface is usable by people unlike them, because they already know where everything is and how it expects to be spoken to. The guidance is to have people of diverse backgrounds and abilities test the system to determine whether it can be used as intended by the broadest possible audience^[5], and to check it against common accessibility standards. So "ask the developers to review accessibility" is a wrong answer even though it sounds diligent: it is the group least able to see the barriers.

Keep inclusiveness and fairness apart with one question. If the scenario is about whether someone can use the system at all, it is inclusiveness. If it is about whether the system's results treat comparable people comparably, it is fairness. Both are about who the system serves, which is why the Azure Machine Learning article discusses them under one heading, and why exam options routinely offer one as a distractor for the other.

Transparency covers two obligations that a scenario may test separately. The first is disclosure: people should know they are interacting with an AI system rather than a person, and organizations are advised to ensure every AI agent clearly identifies itself as artificial intelligence to users^[6]. The second is comprehension: when a system informs a decision that affects someone, they should be able to understand how that decision was reached.

Microsoft calls the second half interpretability and describes it as providing useful explanations of AI system behavior, so stakeholders can identify performance issues, fairness concerns, exclusionary practices, or unintended outcomes^[1]. Read that list again: the payoff of an explanation is that somebody can catch a problem with one of the other principles. Transparency is the principle that makes the rest auditable, which is why a bank deciding creditworthiness or a company screening candidates is the canonical example.

Setting expectations is part of it

Disclosure alone is thin. The system's stated capabilities and limitations matter too, and Microsoft publishes Transparency Notes for exactly this reason: they exist to help you understand how the technology works, what its capabilities and limitations are, and how to achieve the best performance^[7]. The application-level equivalents recommended for generative apps are to disclose the AI's role in the interaction, highlight potential inaccuracies in generated output, and cite the information sources a response was built from^[8] so a reader can see where the content came from.

A scenario that says users were surprised to learn they had been talking to a bot, or that a rejected applicant could not get any account of why, is a transparency scenario. A scenario about encrypting those same conversations is not, and neither is a scenario about who signs off on the system: explaining the system is transparency, owning its outcomes is accountability.

Accountability is the principle that keeps a human name attached to the system. Microsoft's statement of it is that people who design and deploy AI systems must be accountable for how those systems operate^[1], and that organizations should use industry standards to develop accountability norms. Two consequences follow from that sentence, and both show up in questions.

The first is organizational. Accountability is made real by naming owners and putting the system through a governance process: an AI center of excellence or ethics committee that sets standards, responsible AI checkpoints at design review, testing, and prelaunch, and formal sign-offs from the governance team for high-risk AI that interacts directly with customers or makes consequential decisions^[6]. Auditing continues after deployment, because compliance is a claim that has to keep being true.

The second is the one to memorize. Accountability norms exist to ensure that AI systems are not the final authority on decisions that affect people's lives and that humans maintain meaningful control over highly autonomous systems^[1]. "Meaningful control" has a practical test attached: users need a route to challenge an outcome. Well-Architected guidance is explicit that a feedback mechanism should allow users to contest AI decisions^[3], giving the example of a financial institution whose credit rejections must be contestable, with clear procedures for the team to review them.

Two wrong answers follow predictably. Removing human review once a model clears an accuracy threshold is exactly what this principle forbids for consequential decisions, because accuracy is not the reason the human is there. And building on a model somebody else trained does not transfer accountability to the model provider: the team that designed, deployed, and operates the solution answers for it. Foundry's own guidance pushes the same idea down to end users, recommending that applications remind people they are accountable for the final content when reviewing AI-generated output^[8].

You have a working prototype in a Foundry project and someone asks what you did about responsible AI. The answer that satisfies the question is a process rather than a feature list, and Microsoft publishes one. Grounded in the Responsible AI Standard, the recommended stages for a generative AI system are to identify potential harms through red-teaming and analysis, measure their frequency and severity with clear metrics and test sets, mitigate them with tools and strategies, then operate the system under a deployment and operational readiness plan^[8]. You will meet the same shape under different labels: the Microsoft Learn module on responsible generative AI walks plan, map, measure, mitigate, and manage, and the Foundry responsible AI overview for agents^[9] groups the work as discover, protect, and govern. The labels differ; the order does not. Red teaming, which the first stage leans on, means testers deliberately probing the system to find its limitations and vulnerabilities.

Where a mitigation sits

Mitigation is layered rather than single-shot, because no one control catches everything. Microsoft recommends a plan spanning four layers, which the figure below stacks in the documented order: the model itself, the safety system around it, the application you build, and how you position the system to the people who use it. The Microsoft Learn training module teaches the same four-layer stack, describing the third and fourth layers as the system message and grounding, and the user experience^[10], which is a useful gloss on what actually goes in them: the system message is the instruction set you give the model to steer its behavior, and grounding data is the source material you supply with the prompt so that answers come from it.

The safety system layer is where guardrails live, the platform-level safety filters the documentation also calls content filters. They run prompts and responses through classifiers that detect harmful content, and they are powered by Azure AI Content Safety^[11], which detects harmful material in user-generated and AI-generated content alike. Do not memorize a category count for these filters: Microsoft's pages enumerate the filter categories differently depending on which page you read, some listing the core harm categories only and others adding optional detections such as protected material, prompt attacks, and agent task adherence. Learn what the filters do and where they run, and treat any specific count as page-dependent.

Which capability serves which principle

These are the Foundry-side features most often paired with a principle in a scenario. The mapping is illustrative rather than exclusive, since one feature can support several principles.

Principle	Capability that supports it
Reliability and safety	Evaluators for quality and safety, the AI red teaming agent, continuous and scheduled evaluation
Privacy and security	Microsoft Entra ID with RBAC, encryption, Defender for Cloud alerts surfaced in the portal
Transparency	Transparency Notes, disclosing the AI's role, citing sources in responses
Accountability	Tracing and monitoring, governance sign-off, human review of consequential actions

Evaluators are the concrete instrument behind the first row: Foundry provides built-in evaluators covering general-purpose quality metrics, retrieval metrics such as groundedness, safety and security metrics, and agent-specific metrics^[4], and an AI red teaming agent that simulates adversarial attacks before deployment. Choosing thresholds and wiring these into a specific deployment is implementation work covered on this guide's Foundry pages. What belongs here is the link: each capability exists because a principle demanded it.

Almost every question on this objective is the same shape: a two-line scenario, and six plausible principles. The scenarios are written so that the surface topic points at one principle while the actual subject is another, so the reliable method is to ask what the described action protects, not what it sounds like.

The four pairs that get swapped

• Fairness and inclusiveness. Both concern who the system serves. Ask the question the inclusiveness section closed on, whether the scenario is about results or access: a hiring model approving one group less often for equal qualifications is fairness; an interface a screen-reader user cannot operate is inclusiveness. Adding multilingual output and screen-reader support is an inclusiveness answer, and it is a favorite distractor on a privacy question.
• Transparency and accountability. Both concern how an organization answers for a system, and the transparency section drew the line: explaining what the system did is transparency; being answerable for it and keeping a human able to overrule it is accountability. Publishing a detailed explanation of how the model reached each prediction is transparency, offered as a distractor whenever inclusiveness is the real answer.
• Privacy and security versus transparency. Both involve telling people things. Disclosure about the data (what is collected, how it is used and stored, and the controls the person has) is privacy and security; disclosure about the system (that it is AI, and what it can and cannot do) is transparency. Encrypting customer records and restricting access by role is a privacy and security answer, and it appears as a distractor on transparency questions.
• Reliability and safety, including availability. Both use the word reliability. Safe and as-designed behavior is part of the principle; resilience and availability are part of it too.

Traps worth recognizing on sight

These distractors are wrong for a stated reason rather than because they sound weak, which is what makes them effective.

• Reporting high overall accuracy as evidence of fairness. It hides cohort-level disparity by construction.
• Returning an identical result to every person regardless of circumstances. Fairness compares similar cases; it does not flatten different ones.
• Stopping evaluation once the system passes its initial test set. Deployed behavior changes, which is why monitoring belongs to reliability and safety.
• Removing human review after the model beats an accuracy target, for decisions that significantly affect people. Meaningful human control is not an accuracy-gated feature.
• Naming the model provider as the accountable party once the application is live. The team that designs, deploys, and operates the solution answers for it.
• Treating encryption as satisfying privacy when users were never told how their data is used. The principle has a disclosure half.

One closing habit that resolves most remaining ambiguity: name the party the scenario is protecting. A group of people compared against another group points to fairness. A person who cannot get in the door points to inclusiveness. A person whose data is at stake points to privacy and security. A person who does not understand what happened points to transparency. A person who needs someone to answer for the outcome, or to overturn it, points to accountability. And the system itself, behaving safely under conditions nobody planned, points to reliability and safety.