Plan responsible AI strategy

A compliance lead hands you three sentences: users must always know they are talking to a machine, the agent must not invent answers about company policy, and no payment goes out without a person signing off. None of that is buildable until each sentence becomes something you can open in Microsoft Copilot Studio and set. The first becomes a message in the Conversation Start system topic. The second becomes a knowledge source list plus the Allow ungrounded responses setting. The third becomes an approval stage inside the agent flow (an automation built in Copilot Studio and used standalone or as a tool of an agent) that moves the money. Turning stated intent into a named control on a named page is the whole job here, and it is the reason this objective is answered at build-decision depth rather than as policy writing.

Microsoft's own framing sits above those controls. Its Application Card for Copilot Studio^[1] states that Microsoft adheres to six core principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. Those six are goals. They tell you what good looks like; they do not tell you which toggle to move. The same card is blunt about why the gap matters: despite responsible AI controls, AI-generated content "might still reflect biases, stereotypes, or ungrounded information", and it advises builders to implement approval steps for high-impact actions and to limit automation to reversible tasks where possible.

This page organizes the builder's side of those principles into four families, and the sections below follow them in order. Disclosure is what the agent tells users about itself. Grounding is what the agent is allowed to answer from. Human review is what the agent may not do alone. Evidence and review is what survives a conversation and what someone does with it afterwards, which is why it takes two sections rather than one. Every fact on this page belongs to one of the four.

Two neighbouring pages own the seams this one deliberately leaves alone. Plan channels and deployment decides where the agent is published and which clients may connect to it, and evaluate security and governance decides who the user is and what data the agent may reach on their behalf. This page decides what the agent may say, what it may do without a person, and what record it leaves behind. Anything that can only be configured in the Power Platform admin center, including tenant data policies, environment provisioning and transcript retention rules, belongs to an administrator rather than to you; plan around what those settings permit.

The test for a finished plan is unglamorous. For every commitment, name the page, the setting or the node it lands on. A commitment with no such name is an intention, not a design.

Disclosure is a message you design and place, not a footnote somebody else adds later. Copilot Studio already ships a default line for it, and Microsoft calls the practice out explicitly in the FAQ for generative answers^[2]: "it's a best practice to communicate to users that the agent uses artificial intelligence, so the following default message informs users: 'Just so you are aware, I sometimes use AI to answer your questions.'" When your organization needs its own approved wording instead, the usual home is an extra message in the Conversation Start system topic, which triggers when an agent first engages with a user in conversation^[3]. Microsoft gives the same advice for a narrower case: when a tool generates its own questions to collect inputs, inform your users that AI generated some of the conversation^[4], for example by adding a message to Conversation Start.

That placement carries a channel constraint you have to plan for rather than discover. On the Microsoft Teams channel, Conversation Start runs only once, the first time a user adds the agent, even if they remove it and add it back, because Teams uses the same conversation ID for every session with the agent. So if your policy is that the notice must be seen at the start of every session, Conversation Start on Teams will not deliver it. Either the notice moves into the answers themselves, or the requirement is written against the channels where a new session really does start a new conversation.

The second half of transparency is telling users what the agent is for and where it stops. This is where a scope failure looks like a rudeness failure. When the agent cannot match a request, the default reply is "I'm sorry, I'm not sure how to help with that. Can you try rephrasing?", which tells a user asking a password-reset agent about payroll precisely nothing about why. The guidance on writing instructions^[5] is explicit that custom instructions cannot override that default message: you change it by editing the Message node in the Fallback system topic. Instructions do carry the scope statement itself, in the shape Microsoft demonstrates: "Only respond to messages that are relevant to Contoso corporation and ordering coffee. Otherwise, tell the user you can't help with their inquiry."

For a boundary you cannot afford to have interpreted, the same guidance recommends going further and authoring a topic with a manually written response, "to prevent having to rely only on instructions to avoid that topic". That distinction is the through-line of the next section: an instruction expresses an intent to the model, while a topic and a setting constrain what happens.

Grounding is the accuracy control, and in Copilot Studio it has a switch. The Allow ungrounded responses setting, in the Knowledge section of the agent's Generative AI settings page, decides whether the agent may answer from the model's general knowledge. Turned on, the agent can respond using the model's general knowledge, even when it doesn't use any knowledge sources or tools^[6]. Turned off, the agent blocks any response generated in a turn where it did not use a knowledge source or a tool, and the Fallback topic triggers instead. The setting requires generative orchestration, the mode in which the agent selects the appropriate tool or topic and searches across knowledge itself, so it is not available to an agent left in classic mode, where the agent can only use topics to respond.

Two consequences of that design surprise builders, and both are worth designing around rather than debugging later. First, turning the setting off does not guarantee the agent never uses general knowledge: Microsoft states that the underlying model might still incorporate general knowledge when it combines that knowledge with information it retrieves. The gate is about whether a source or tool was called in the turn, not about the provenance of every clause in the answer. Second, with the setting off, the agent returns a knowledge-source answer only when the answer includes an in-text citation to that source, and because models do not always include citations, a correct answer can be withheld and the agent responds as though it found nothing. Microsoft's own mitigations are to ask the model in the agent instructions to always cite its sources, and to avoid instructions that force a rigid output format, which can suppress the citation markers the feature depends on. The figure below traces a single turn with the setting off, including both places the answer can stop.

Content moderation is the second control in this family and it is separate from grounding: it filters harm, not inaccuracy. Moderation levels range from Lowest to Highest, where the lowest level generates the most answers but they might contain harmful content, and the default level is High. You can set it in three places, at agent level on the Generative AI settings page, at topic level on a generative answers node, and at prompt level in the prompt tool, and at runtime the topic-level setting takes precedence over the agent-level one. Copilot Studio applies moderation on both sides of the exchange: all content is checked twice, first during user input and again when the agent is about to respond.

The planning rule that falls out of this is narrow and worth stating plainly. Restricting an agent to approved sources is a two-part act: attach only the sources you accept, and turn off ungrounded responses so that everything else lands in a fallback path you have written. Doing only the first leaves the model free to answer anyway; doing only the second blocks every turn that reaches no knowledge source or tool, so users meet the fallback message instead of an answer.

Review that arrives after the record is deleted is a report, not a control. The design question is therefore never whether a human is involved, but whether the human decides before the external side effect happens. Copilot Studio offers three mechanisms for that, and they are chosen by where the action runs rather than by how important it feels.

The first is tool confirmation, which happens in the conversation. Each tool carries an Ask the end user before running option in its Details section, described as asking the agent for confirmation before running the tool^[4], and it is set to No by default. Two details make it work in practice: the same section holds an optional description that the agent shows the user when it wants to run the tool, and the Authentication setting decides whether the tool runs with the end user's credentials or with maker-provided credentials. A confirmation prompt in front of a tool running on maker credentials asks a user to authorize an action that will run under the maker's identity rather than their own, which should be a deliberate choice rather than an accident to stumble into.

The second is an approval inside an agent flow, which is where actions that no user is watching tend to live. An approval action starts an approval, sends it to the required assignees, and waits for the approval requests to be completed before the rest of the flow continues. Copilot Studio also offers multistage approvals^[7], currently in preview and available exclusively in agent flows, which combine manual stages assigned to human stakeholders with AI stages that produce an Approve or Reject decision with a rationale from instructions you write. The point of mixing them is stated in the docs: routine requests are processed automatically while human oversight is kept for complex decisions, and the Next step based on decision routing "ensures that humans remain in control by letting them make final decisions even after AI stages make decisions". Microsoft advises exercising care with AI approvals for highly sensitive cases such as financial transactions, legal decisions, personnel actions and compliance-critical processes, and ensuring human approval stages are reached in those flows. Whichever shape you use, position matters more than presence: the figure below shows the approval sitting between the flow gathering its details and the action that commits, with the notification afterwards as a courtesy rather than a gate.

The third mechanism, handing the whole conversation to a person, is the subject of the next section. It is not a smaller version of the other two: tool confirmation and approval keep the agent working on the task, while a handoff ends the agent's part in it.

One planning heuristic covers all three. Ask what the world looks like if the agent gets this wrong and nobody notices for a week. If the answer is a wrong sentence, grounding is your control. If the answer is a changed record, one of these three is.

Every agent already has an escape hatch, and left untouched it is close to useless. The Escalate system topic exists in every agent, informs customers if they need to speak with a human, and triggers when "talk to agent" is matched or the Escalate system event is called, including from a Question node configured to escalate when it does not receive a valid answer from the customer. The Microsoft docs call the person on the other end a live agent, which collides with this exam's other use of the word: in Copilot Studio an agent is the thing you built, and a live agent is a human being. This section uses "a person" for the human and reserves "agent" for the software.

What the topic does when it triggers depends on a node most builders have never added. When you create an agent from Dynamics 365 Customer Service, the Escalate topic already includes a Transfer conversation node, but agents created in Copilot Studio are not configured with this node by default^[8]. Without it, escalation is whatever message the topic contains, and Microsoft's suggestion for that case is to edit the topic to include a URL to a support website or ticketing system, or instructions for emailing or contacting support. With it, and with an engagement hub connected (the product the people who take over the conversation work in, such as Omnichannel for Customer Service), the agent sends the conversation to the hub, which finds an available person who can pick it up with the history in front of them.

Context is what makes that handoff worth designing rather than accepting. Alongside the conversation history, Copilot Studio passes context variables that the hub can route on, including va_LastTopic for the last topic the user triggered, va_LastPhrases and va_Phrases for what they actually said, va_ConversationId to identify the conversation, and all user-defined topic variables; the agent gathers these across topics and merges them before sending. A Transfer conversation node placed in one of your own topics also carries a private message to the person, stored in the va_AgentMessage context variable, which is how several topics that all escalate can arrive distinguishable. The figure below shows both routes from trigger to person.

One consequence lands in reporting rather than in the conversation. Sessions that reach a transfer are marked as Escalated in analytics, and the escalation reason is broken down as System intended when a business rule you wrote escalated deliberately, System unintended when the user got stuck and thresholds fired, and User requested when the person asked. Those three read very differently in a review: the first is your design working, and the second is a defect wearing an escalation costume. Deciding which of your escalation paths should count as intended is part of planning the handoff, not an afterthought of reading the chart.

Being able to explain, months later, why an agent said what it said is a design decision with preconditions, and the preconditions are easier to satisfy before release than after. The Activity page is the primary builder-side record. An activity map is generated for every activity, where an activity begins when an agent starts a conversation or an external event triggers an agent, and each activity is represented by a node; the transcript records the user input, trigger payloads, and agent responses^[9]. Selecting a knowledge node shows the query the agent actually used, which can differ from what the user typed, the response built from the sources, the sources it referenced, and the other sources it searched but did not use. For a fairness or accuracy complaint, that last item is often the answer: it distinguishes a source that was never consulted from one that was consulted and found irrelevant.

Three preconditions govern whether that record exists for you. Activity tracking is available only for agents with generative orchestration enabled. You see only your own interactions, and only where the agent used your credentials, unless a system administrator enables sharing of activity transcripts with other users, which means a compliance reviewer cannot simply be told to open the page. Historical activity is available for interactions in the Copilot Studio test chat, agents published to the Microsoft Teams and Microsoft 365 Copilot channels, agents published to the SharePoint channel, and activities started by an autonomous trigger, and viewing it requires a Microsoft Exchange license and an inbox because the data is stored using Microsoft 365 services. A channel outside that list is a channel whose conversations you plan to reconstruct some other way.

Rationale deserves a caution rather than a recommendation. It explains how the agent decided to call a particular tool, and it is generated by AI on demand from agent metadata and activity, so Microsoft's own advice is that it might not be accurate and to use your best judgment when reviewing it. Rationale is a debugging aid. It is not an audit record, and quoting it as one in an incident review would be citing a generated explanation as evidence of a generated decision.

Citations are the reader-facing half of traceability, and they are fragile in one specific way covered earlier: with ungrounded responses turned off, the citation is what makes the answer returnable at all. Two channel-level facts follow from that. Microsoft Teams applies stricter citation limits than other channels, so citations past its cap are dropped and long titles and snippets are shortened. More importantly, if you customize the generative answer response, for example by clearing the Message node and rendering the answer yourself through a variable or an Adaptive Card, citations are not added automatically and you have to render them yourself. A page that ships a prettier answer and quietly drops its sources has traded the evidence for the layout.

Go-live is where responsible AI work changes shape, not where it ends. This is the second half of the evidence and review family: the previous section decided what record exists, and this one decides what gets read. The pre-release half of the discipline belongs to two sibling pages, build agent test sets and select agent evaluation methods, and Microsoft's agent evaluation guidance^[10] frames the point of it well: evaluation turns "the agent isn't working well" into a specific, measurable, fixable statement. What this page owns is the part that only exists after real users arrive.

The Analytics page carries most of it. The Effectiveness section shows user feedback gathered from reactions, agent responses, survey results, and sentiment^[11] for a session, and it splits that into five subsections. Four of them carry the responsible-AI signals, and the fifth, Agents, reports call volume, success rate and status for child and connected agents. Conversation outcomes classify each engaged session as Resolved, Escalated or Abandoned, with the escalation reasons described in the previous section. Reactions count thumbs up and thumbs down on individual responses and collect free-text comments. Customer satisfaction reports a score out of 5 from end-of-session surveys, where 1 and 2 map to Dissatisfied, 3 to Neutral, and 4 and 5 to Satisfied. Sentiment, in preview at the time of writing, estimates the percentage of sessions with negative user sentiment. The Use section covers the other half: answer rate, an AI-assessed answer quality split into Good and Poor over a sample with a reason assigned to each Poor answer, tool use, and knowledge source use.

Two access facts turn those charts from a dashboard into an investigation. Reactions are on by default and can be turned off under Settings in the User feedback section, where you can also add or edit a disclaimer telling users how their feedback is used, which is a disclosure decision as much as a telemetry one. Viewing the comments themselves, and drilling from a chart segment down to individual sessions, requires the Bot Transcript Viewer security role. A responsible AI plan that names an owner for ongoing quality review has to name both grants that person needs: for a reviewer who does not own the agent, the Analytics Viewer sharing role opens the Analytics page and Bot Transcript Viewer opens the sessions behind it. An owner given neither will see aggregates they cannot act on. Note also that agents published to the Microsoft 365 Copilot channel do not support reactions, so a feedback-based control does not cover that surface.

Bias and harm reviews use both halves together. The aggregate view tells you a category of answers is going wrong; the drill-down to sessions and transcripts tells you what actually happened in one of them. Analytics covers events from a bounded recent window, documented as the last 360 days, so evidence a review will need beyond that has to be captured deliberately rather than assumed. The rest is cadence: review on a schedule, and when the evidence shows a problem, change the thing that caused it, whether that is a knowledge source, an instruction, a moderation level, or the point at which the agent hands over to a person.

The failures below are the ones this exam keeps testing, and each is a mismatch between a stated intention and the control that would have implemented it.

Treating the disclaimer as the mitigation. A notice that the agent uses AI is required and cheap, and it constrains nothing. If the plan says answers must come from approved policy documents, the disclosure sentence is not the control; the knowledge source list plus Allow ungrounded responses is.

Reading "ungrounded responses off" as a guarantee. It blocks turns in which no knowledge source or tool was used. It does not promise that no general knowledge ever appears in an answer, and it will occasionally withhold a correct, sourced answer whose citation the model failed to emit.

Lowering content moderation to raise the answer rate. The setting does exactly what it says: the lowest level generates the most answers, and they might contain harmful content. Answer-rate pressure is a real product problem, but the fix is better sources and clearer instructions, not a lower filter.

Approving after the fact. A flow that deletes the record and then emails a report has a notification, not an approval. Move the approval stage ahead of the action that commits, and check the ordering in the flow rather than in the description of the flow.

Letting instructions carry a security requirement. Instructions cannot modify search retrieval logic, cannot change how retrieved documents are shared, and cannot override the fallback message. Data boundaries belong to the knowledge source and its authentication, covered on evaluate security and governance.

Assuming the disclosure was seen. On the Microsoft Teams channel, Conversation Start runs once per user, not once per session.

Planning an owner without planning their access. Reading comments and session transcripts needs the Bot Transcript Viewer role, and seeing other users' activity needs an administrator to enable transcript sharing. An accountable owner without either has responsibility and no visibility.

Stopping at the pre-release review. A test set that passed before launch says nothing about the knowledge source that was edited last week, or about the question no one thought to ask until a real user asked it.