Copilot in Power BI Embedded means Microsoft’s generative AI features showing up inside reports served through Power BI’s embedding framework. The term covers everything from a narrative visual that writes a short summary to a full conversational pane where users type questions directly into a report. What Copilot actually does in any single embed depends heavily on which embedding model and authentication approach the company building the portal has chosen.
Power BI Embedded itself covers several different embedding models, so stating that Copilot works in embedded Power BI can be misleading without naming the specific deployment.
Power BI also draws a separate line between user-owns-data experiences, where each viewer signs in with their own identity, and app-owns-data customer embedding, where the application authenticates on everyone’s behalf. Copilot support does not move uniformly across those models, and the gap between them is the reason this article exists.
Internal Power BI
External embedded analytics
The diagram above captures the difference in one line: internal Power BI puts an employee directly in front of Copilot, while external embedded analytics routes the same request through an application and an identity and security layer first. That extra hop is not a formality; it is where authentication gets resolved and row-level security gets applied before any AI response reaches the customer. That extra delivery layer is the article’s central theme.
The table below breaks down how each embedding model handles Copilot today, based on Microsoft’s current documentation and community guidance rather than marketing language. Treat the “Copilot Position Today” column as a snapshot, since Microsoft has been revising embedded AI support release by release throughout 2026.
| Scenario | Typical Audience | Authentication | Copilot Position Today | Best Fit |
|---|---|---|---|---|
| Power BI Service | Internal users | Power BI / Entra identity | Native Copilot, generally available on paid capacity | Internal analytics |
| Secure Embed | Internal or authenticated external users who sign in | User signs in with their own identity | Narrative visual and Copilot pane documented as supported for authenticated, signed-in viewers | Portals with known, authenticated users |
| Embed for Your Organization | Employees and internal users (user-owns-data) | Microsoft Entra user identity | Copilot narrative visual documented as supported in this scenario | Internal applications |
| Embed for Your Customers | External customers and tenants (app-owns-data) | Application authenticates via a service principal, not individual users | Native Copilot is not currently documented as supported for unauthenticated app-owns-data embedding; capability here is still evolving | SaaS and customer-facing analytics |
A Copilot-powered visual inside an embedded report is not necessarily the same thing as giving every customer a full conversational Copilot experience. A single narrative visual documented as supported for one embedding model says nothing about whether a customer can open a chat pane and ask follow-up questions. Most of the confusion around Copilot in Power BI Embedded comes from collapsing these different levels of support into one yes-or-no answer.
Even where Copilot is documented as supported, getting it to actually appear for embedded users takes more than flipping one setting. The five requirements below tend to be the ones teams miss first.
Copilot requires a paid Fabric capacity at F2 or higher, or a Premium capacity; trial and shared capacities do not qualify. The capacity has to be created and running, since pausing it to save cost disables Copilot immediately for everyone connected to it. Sizing this capacity for external delivery means accounting for customer traffic patterns, not just internal report usage.
Copilot must be switched on at the tenant level through the setting that governs Azure OpenAI-powered features, and capacity-level delegation alone is not sufficient. Administrators can scope the rollout to a specific security group first, which is useful for testing embedded scenarios before opening access more broadly. Tenant settings also control whether cross-region data processing is permitted, which matters for organizations with customers outside their home geography.
The workspace holding the semantic model and reports has to sit on the qualifying capacity, or Copilot will not activate no matter what else is configured. Workspace-level permissions also determine who can edit a report to add a narrative visual in the first place. Misconfigured workspace assignment is one of the more common reasons a Copilot button appears in the interface but does nothing when clicked.
Power BI Embedded already lets vendors deliver reports to customers without requiring each viewer to hold a Power BI Pro license. Copilot features layered on top do not automatically carry the same exemption in every scenario, so licensing needs to be checked against the specific embedding model in use. This is one of the details that changes most often as Microsoft adjusts embedded AI licensing, so it is worth revisiting before launch rather than assuming last year’s rules still apply.
Every Copilot interaction, from a narrative summary to a follow-up question, consumes capacity resources alongside normal report rendering. External-facing embeds with unpredictable customer traffic can hit capacity limits faster than an internal team expects, which shows up as slow or failed AI responses. Monitoring capacity consumption separately for AI features helps teams catch this before customers notice degraded performance.
Where Copilot is supported in an embedded report, the experience is narrower than the standalone Power BI service but still useful for customers. The capabilities below cover what is realistically available today.
The narrative visual reads the data behind a report page and writes a short summary in plain language, highlighting notable figures and changes. Customers viewing an authenticated embed can see this summary alongside the visuals rather than having to interpret a chart on their own. The summary updates when a viewer refreshes it against whatever filters and slicers they currently have applied.
Copilot can surface directional language around a metric, noting whether a number moved up or down against a prior period. This helps less analytical users get a read on a dashboard without scanning every visual individually. It does not replace deeper analysis, but it shortens the time to a first impression of what the data is showing.
In scenarios where a customer signs in with their own identity, the Copilot pane can appear inside the embedded report itself. That lets a signed-in customer ask a follow-up question about the report they are already looking at, rather than leaving the portal. This experience currently depends on the embed being authenticated, which rules it out for anonymous or app-owns-data customer scenarios.
Copilot can respond to a plain-language question about the data with a written answer instead of requiring the customer to build a filter or visual themselves. For customers unfamiliar with Power BI’s interface, this lowers the skill needed to get a useful answer out of a report. The quality of these answers depends heavily on how well the underlying semantic model’s tables and columns are described and named.
Adding a conversational AI layer to an embedded report does not remove the security requirements that already applied to external delivery. It adds a few new ones, since an AI response can expose information a static visual would not have surfaced on its own.
A static report either shows a number or it does not, which makes permission testing relatively binary. A conversational AI layer can paraphrase, infer, or combine information in ways that are harder to predict from a fixed set of test cases. Reviewing Copilot output for an embedded customer scenario means testing what the AI says, not just what the underlying visuals display. That is a different kind of quality assurance than most embedding teams have had to build before.
Native Copilot capabilities are expanding into embedded scenarios, and Microsoft has closed some of the gaps that existed even a year ago. External intelligence delivery still has requirements beyond generating an AI response, and those requirements are where most of the remaining work sits.
A narrative summary generated for one customer is not automatically appropriate to send to another, even if the underlying report template is identical. Governance in this context means having a policy for what Copilot is allowed to say, not just what data it is allowed to see. Few organizations have written that policy down, because internal Copilot use rarely raised the question in the first place.
The moment a customer reads an AI-generated summary, it functions as a communication from the vendor, regardless of how it was produced. That shifts the standard for accuracy and tone closer to a support ticket response than to an internal analyst’s working notes. Teams that would never let an unreviewed automated email go out to customers are, in effect, doing something similar when they expose Copilot output directly.
Some regulated industries and cautious customers will expect a review step between an AI-generated insight and what actually reaches an end user. Power BI Embedded on its own does not provide a workflow for holding, reviewing, or approving AI output before delivery. That gap has to be filled by the application layer surrounding the embed, if it needs to be filled at all.
A narrative summary generated today can read differently than the same summary generated next week, since the underlying model and data have both changed. Without a record of what was shown to a customer and when, it becomes difficult to answer a question about a decision made from an old summary. Internal Power BI use rarely needs this kind of history, but customer-facing delivery often does.
Standard Power BI audit logs capture who accessed a report and when, but they do not always capture what a Copilot response actually said. For customer-facing products, being able to reconstruct a specific AI answer after the fact matters for support and dispute resolution. This is typically something the surrounding application has to log itself, rather than something Power BI Embedded handles automatically.
Customers using a vendor’s product generally expect the interface, including any AI features, to look like part of that product rather than a Microsoft tool. Branding an embedded report is a solved problem, but branding a conversational AI pane consistently across a customer base is less mature. How much of the underlying Copilot experience is visible, and how it is styled, is still something vendors have to manage deliberately.
Reporting Hub does not compete with Copilot, and positioning it as a replacement would misrepresent what it does. The product sits in the layer that Microsoft’s own embedding documentation gestures toward but does not fully solve: turning a technically supported AI feature into something ready for customer delivery. That layer covers governance, branding, and workflow rather than the underlying AI generation itself.
Reporting Hub positions BI Genius as a conversational intelligence layer grounded in a customer’s existing Power BI semantic models. Reporting Hub itself then handles the external governance and delivery work: review workflows, branded presentation, and the audit trail an AI-powered customer portal needs. The architecture keeps each layer doing what it is built for, with Power BI as the analytics foundation underneath both.
None of this requires abandoning Power BI or Copilot; it adds the delivery layer that external, customer-facing use tends to need.
Yes, but only in specific embedding models rather than across every embedded scenario. Support currently centers on secure embed and embed for your organization, where the viewer authenticates with their own identity.
External users can access Copilot features when they sign in through an authenticated embed, such as secure embed or a user-owns-data experience. Anonymous or app-owns-data customer scenarios currently have much more limited native support.
App-owns-data embedding authenticates through a single service principal rather than individual users, which conflicts with how Copilot applies security and permissions. Native Copilot support in this scenario remains limited compared with authenticated embedding models.
Yes, Microsoft documents Copilot narrative visual and pane support for reports embedded in secure, authenticated scenarios. Enabling it still requires the correct Fabric or Premium capacity and tenant-level settings.
Power BI Embedded already allows vendors to deliver reports to external users without a Power BI Pro license for each viewer. Copilot features do not automatically carry that same exemption in every configuration, so licensing needs a separate check.
Row-Level Security is designed to govern what a Copilot response can see, since the AI operates within the same permission boundaries as the underlying report. A properly configured model should not let Copilot surface data a viewer’s RLS role would otherwise hide.
Power BI Embedded supports branding the surrounding report experience, but a fully white-labeled conversational Copilot pane across an entire customer base is still an evolving capability. Vendors currently manage how much of the native AI interface is visible through their own application layer.