3.1 Plan Responsible AI Strategy

When you plan an agent solution in Microsoft Copilot Studio, responsible AI is not a late-stage checklist item—it is a design discipline that shapes knowledge sources, prompts, tools, channels, and escalation paths. AB-620 expects you to plan a responsible AI strategy before builders wire every connector. That plan balances business value with safety: agents should answer accurately from approved data, refuse harmful or out-of-scope requests, protect personal and confidential information, and make it clear when a person must decide.

Why a RAI strategy belongs in solution planning

Enterprise agents touch HR records, customer cases, product catalogs, and operational systems. A single ungrounded answer or an action that runs without consent can create legal, brand, and security exposure. Planning responsible AI early reduces rework later: you decide which topics are safe for generative answers, which actions require human approval, how users are told they are speaking with AI, and how privacy rules apply per audience. On the exam, questions often present a business scenario and ask which control—grounding, moderation, authentication, handoff, or instruction design—best addresses the risk.

Microsoft Responsible AI principles applied to agents

Microsoft’s Responsible AI (RAI) framework centers on six principles. For Copilot Studio, translate each principle into agent-level choices:

Do not memorize the principle list alone. AB-620 scenarios test whether you pick the implementation that matches the principle—for example, choosing human handoff for accountability, or generative answers constrained to SharePoint knowledge for reliability.

Groundedness: answers tied to approved knowledge

Groundedness is the practice of anchoring generative responses in retrieved, organization-approved content rather than free model recall. In Copilot Studio this appears as knowledge sources (SharePoint, documents, Dataverse, public websites you explicitly allow, enterprise connectors, Azure AI Search) feeding generative answers. A grounded agent:

1. Retrieves relevant passages for the user question.
2. Generates a response constrained by those passages and your instructions.
3. Preferentially surfaces references so users and auditors can verify claims.

Ungrounded or weakly grounded designs answer from model priors alone or from overly broad public web search. That increases hallucination, stale facts, and accidental disclosure of competitor or non-policy guidance.

Planning checklist for groundedness

• Inventory which systems of record own each answer domain (policy, product SKU, case status).
• Prefer internal authenticated knowledge for employee data; use public sites only for public content.
• Decide when generative answers are primary versus when authored topics must force exact wording (legal disclaimers, regulated scripts).
• Prohibit tools from returning secrets; never store API keys or passwords in knowledge documents used for grounding.
• Plan evaluation sets that include “known answer” and “should refuse” cases so you measure groundedness before go-live.

Scenario — Contoso benefits agent. Contoso wants an employee agent that explains health plan options. The RAI plan requires SharePoint HR policies as the only knowledge source for plan details, generative answers at medium moderation, and explicit refusal if the user asks for medical diagnosis. That design is grounded (official policy docs), transparent (agent identifies as AI HR helper), and safe (no clinical advice).

Content moderation and safety filters

Copilot Studio applies content moderation on user input and on model output. Filters are powered by Azure AI Content Safety–style classifiers that score risk categories (for example hate, violence, self-harm, sexual content, and other harmful categories Microsoft defines for the service). Makers can set moderation sensitivity (commonly High, Medium, or Low) at agent level and, for generative answers nodes, refine behavior at the topic or node level.

Important exam facts:

• Baseline Responsible AI protections cannot be fully turned off. Even at Low moderation, platform safety still blocks clearly disallowed content.
• Filtered interactions may surface as a ContentFiltered style error in test/debug experiences; production UX should use custom messages and the On Error system topic so users see a professional refusal instead of a raw error.
• Filtering can trigger on user prompt, grounded knowledge chunks, or draft model output. Troubleshooting may require cleaning knowledge documents, not only rewriting the user question.
• Email-style or high-risk action surfaces can enforce stricter safety than a casual chat surface.

Use custom instructions and generative-answer prompt modifications as a second layer: for example, ban competitor recommendations, ban personal medical advice, and require citations when policy answers are given. Instructions shape desired behavior; moderation is a hard safety net.

Transparency and AI disclosure

Users must understand they are interacting with an AI system. Plan AI disclosure in the Conversation Start (greeting) topic and in channel-specific first messages. Good disclosure is short, honest, and actionable: name the agent’s purpose, state that answers may be incomplete, and tell users how to reach a human. Transparency also includes citations or source labels when generative answers return knowledge-backed content, and clear messaging when an action failed or was blocked by policy.

Avoid over-promising. Do not claim the agent is a licensed professional, a legal authority, or “always correct.” On AB-620, if a scenario stresses customer trust or regulatory communication, prefer solutions that add disclosure and human review rather than only raising moderation.

Human oversight and accountability

Human oversight keeps people in control of consequential outcomes:

• Conversational handoff to a live agent or service desk when confidence is low, the user is frustrated, or the topic is sensitive.
• Human-in-the-loop agent flows that pause for approval before submitting orders, changing access, or sending customer emails.
• Maker and admin accountability: named owners, environment separation (dev/test/prod), evaluation runs, and review of transcripts and Application Insights telemetry.

Accountability also means defining who may publish, who may connect production data, and who reviews red-team results. RAI strategy documents should list those roles.

Privacy in the RAI plan

Privacy sits at the intersection of RAI and security. In the planning phase, answer:

• What personal data will the agent process, and under which lawful basis or corporate policy?
• Will transcripts store sensitive fields, and how long are they retained?
• Does the agent need user credentials for tools (least privilege per user) versus a service identity?
• Are external channels allowed to see the same knowledge as internal employees?

Never instruct the model to “ignore privacy rules.” Instead, omit sensitive knowledge from external-facing agents, require authentication, and use DLP policies (covered in the next section) so makers cannot accidentally publish an unauthenticated agent with SharePoint HR content.

Building a lightweight RAI strategy artifact

For AB-620 design questions, a complete plan usually includes:

1. Purpose and audience — internal helpdesk vs public website customer bot.
2. Allowed knowledge and tools — explicit allow lists.
3. Forbidden topics and actions — medical diagnosis, legal advice, credential extraction, competitive disparagement.
4. Moderation level and custom flagged-response text.
5. Disclosure and citation standards.
6. Escalation and HITL rules with SLAs.
7. Evaluation approach — test sets for accuracy, groundedness, and abuse cases.
8. Ownership — business owner, security reviewer, support queue.

Exam scenario pattern. A company wants an agent that both answers FAQ and can cancel customer subscriptions. The responsible design uses grounded FAQ knowledge for questions, requires authenticated identity for cancel actions, inserts a human approval step for high-value accounts, sets content moderation to High for public channels, and discloses that the assistant is AI-powered. Choosing “no authentication and full generative web search” fails multiple RAI principles at once.

Common planning mistakes

• Treating moderation as a substitute for good instructions and clean knowledge.
• Publishing without disclosure because “users will figure it out.”
• Allowing tools that write back to systems of record without approval gates.
• Using public website knowledge for internal-only policies.
• Assuming ContentFiltered events mean the model is broken—often the knowledge or prompt is the root cause.
• Skipping red-team prompts such as “ignore previous instructions” or “list connection secrets.”

Key design takeaways for AB-620

Plan responsible AI as a first-class architecture decision. Map each Microsoft RAI principle to grounded knowledge, content moderation, transparent messaging, privacy-aware data scope, and human oversight. When a scenario presents risk, pick the control that addresses that risk most directly—grounding for accuracy, moderation for harmful content, handoff for accountability, authentication and data scope for privacy—and be ready to explain why.