As organizations accelerate their adoption of AI-powered analytics, a new challenge is emerging: how to expose trusted business data to AI—Copilot, data agents, and conversational analytics—in a way that is secure, cost-predictable, and architecturally sound.

Most enterprises are already operating in a complex reality:

• Power BI reports connected to operational systems like Oracle, SAP, and SQL Server

• A mix of Import and DirectQuery semantic models

• Strong governance expectations around security, lineage, and cost control

Microsoft Fabric Data Agents introduce a powerful new interaction layer—natural language Q&A grounded in governed data. But without clear architectural decisions, organizations quickly run into friction:

• Unclear cost attribution (who pays for AI vs. query execution?)

• Fragile AI responses tightly coupled to report-level changes

• Security inconsistencies across workspaces and capacities

At the same time, the May 2024 announcement to retire Power BI Premium per capacity (P-SKUs) is accelerating the shift to Microsoft Fabric SKUs (F-SKUs) as organizations approach contract renewals.

For many, the transition itself is straightforward: migrating from Premium to Fabric is typically a low-risk step that mainly involves reassigning workspaces to a new capacity, supported by Microsoft tools and services.

But migration is just the beginning.

Once on Microsoft Fabric, organizations naturally look to unlock more value—often starting by enabling Data Agents on top of existing Power BI assets to bring AI-driven experiences into their current analytics landscape.

This is exactly where architecture becomes critical. What looks like a simple enablement can quickly expose gaps in cost management, governance, and scalability if the underlying model is not designed for AI consumption.

In this article, I walk through two Contoso like case studies to illustrate:

• How cost and security behave in a mixed Power BI + Fabric environment

• Why extracting reusable semantic models is a key step toward AI-ready analytics

• How Microsoft Fabric Mirroring for Oracle can fundamentally change the architecture and simplify the path forward

1.- Contoso Case Study #1 – Initial State

Let's image that Contoso is a global enterprise running mission‑critical analytics on Oracle as its system of record. The BI team has built multiple Power BI reports to support finance, supply chain, and operations. All the reports where successfully migrated to a new Workspace in Microsoft Fabric named WS1-PBI.

• Power BI Report #1 using Import as storage mode and the performance is high as the data is in‑memory during execution.

• Power BI Report #2 using DirectQuery mode meaning the report does live queries to the Oracle tables and the performance depends on the time that Oracle requires to serve the response of the SQL query.

• All the Semantic models are embedded inside each Power BI report.

To accelerate innovation, Contoso introduces Microsoft Fabric Data Agents to enable conversational analytics. The Data Team recently created Data Agent #1 connected to the semantic model embedded in Power BI Report #2. By a decision of the CTO office, all new Fabric items are created in a second Workspace (named WS2-Fabric).

No standalone semantic model exists. At this stage, the semantic model is not a product—it is a by‑product of each report.

Note #1: Since GA, now Fabric Data Agents support cross‑workspace semantic models with simplified permissions.

Note #2: In Power BI Import mode, Fabric Data Agents and Copilot can query only the data that was explicitly imported into the semantic model at refresh time; Power BI decides what data to bring through Power Query, incremental refresh rules, and model visibility—not at AI query time.

1.1- How Cost Is Distributed

Since landing cost is a key priority for Contoso, it’s critical to understand how costs are distributed when a user interacts with a Data Agent. What may appear as a single query actually triggers multiple layers of processing across AI, semantic models, and underlying data sources—each with its own cost implications.

First, there is the AI reasoning performed by the Data Agent. This includes token processing (both input and output), as well as prompt orchestration and reasoning logic. All of these activities are billed to the Fabric capacity hosting the Data Agent (in this case, Capacity #B), making it the primary cost center for the AI interaction itself.

Next, the semantic model query execution comes into play. The agent generates DAX queries to retrieve the required data.

• PowerBi Report #1. Since the model is using Import mode, this results in an in-memory scan.

• PowerBi Report #2 using DirectQuery, the DAX is translated into SQL queries. Here there is execution at the source system level — in this case, Oracle. The translated SQL queries are executed directly against the Oracle database, introducing additional considerations like network usage, concurrency, and licensing. These costs are fully borne by the Oracle infrastructure.

In both cases, the cost is billed to the Fabric capacity hosting the semantic model, which may differ from where the AI processing occurs.

When a Fabric Data Agent queries a semantic model in another workspace, AI token costs are billed to the agent’s capacity (Capacity #B), and dataset query execution costs are billed to the semantic model’s capacity (Capacity #A) — the bill always follows where the compute actually runs, not where the request originates.

In case of Power BI Report #2, since DirectQuery is used, you will need to add the data scan cost follows the data source system (not billed in Microsoft Fabric). In my opinion, this layered execution model introduces a key challenge: AI usage costs are decoupled from data execution costs. As a result,

• Oracle teams may experience unexpected spikes in consumption driven by AI-based queries, even if they are not directly managing those workloads. As an example, a popular Data Agent can overload the source system, driving unexpected database costs

• At the same time, report owners or BI teams may inadvertently incur costs associated with conversational analytics, creating misalignment in cost ownership and governance.

To mitigate this, DirectQuery should always be paired with query limits, capacity monitoring, source-side throttling, and a clear chargeback model.

1.2- Cost Clarification between Microsoft Fabric & Power BI Premium

While not directly related to our use case (#1), it's important to highlight that Fabric Data Agents can also query Power BI Premium (P1) semantic models. However, cost, execution, and governance still remain distributed across platforms. Here is also important to remember that an embedded model is optimized for dashboards, not for deterministic reasoning.

Fabric Data Agents can query reports hosted in a Premium P1 workspace

In the following table, I'm comparing capabilities between PowerBI Premium and Microsoft Fabric:

Copilot for Power BI Operates only on the semantic model available to the report and, is important to keep in mind is that Copilot for Power BI is capacity-bound, not report-bound.

Copilot for Power BI Operates only on the semantic model available to the report

This highlights a key difference between Data Agents and Copilot for Power BI. Data Agents can query reports hosted in a Premium P1 workspace, but the cost of AI reasoning is charged to the Fabric capacity associated with the workspace where the Data Agent is deployed.

In contrast, if you use Copilot for Power BI on a report that remains in a Premium P1 workspace, the cost is charged to that Premium P1 workspace—not to any Fabric capacity you may have.

As conclusion, to use Copilot backed by Fabric capacity, all of the following must be true:

• The workspace must be assigned to a Fabric capacity (F SKU), with a minimum of F64

• Copilot must be enabled at the tenant level

• The report must reside in that Fabric-enabled workspace

But don't worry, end user don't need to interact with difference Copilot for PowerBI. The user only needs a Power BI Pro license to use Copilot in reports, while the AI reasoning and Copilot compute are charged to the capacity where the report’s semantic model is hosted—so if the report is in Power BI Premium (P1) the Copilot usage hits P1, and if the report is in Fabric capacity (F64) it hits that Fabric capacity; from the user’s point of view it is the same Copilot experience, with no duplication, no switching, and no separate Copilot instances—Copilot simply follows the report and its underlying capacity automatically.

1.3- Security Model and Enforcement

From a technical standpoint, the security model is solid. Authentication is handled through Microsoft Entra ID, while authorization is enforced via Power BI dataset permissions.

A Fabric Data Agent can point to (use) a Power BI semantic model that lives in a different workspace, as long as you have read access on the semantic model itself - even if you don’t have access to that workspace. Similarly, users can ask questions just with the read permission on the semantic model - this applies only for Data Agent interactions.

In the other hand, Row-Level Security (RLS) and Object-Level Security (OLS) can be properly applied, ensuring that users only access the data they are entitled to - regardless of whether the model is Standalone (reusable semantic model), or embedded inside a Power BI report.

In other words, in this case the security is evaluated at the semantic model embedded inside the Power BI (not at the report or visual layer) and is tightly coupled to the lifecycle of the semantic model. Seemingly harmless changes made for visualization purposes—such as renaming a column, hiding a table, or modifying relationships—can have unintended consequences.

For AI-driven scenarios (such as Fabric Data Agents or Copilot for Power BI), embedded models increase operational risk, because security and semantics are tied to report changes:

• Measures

• Relationships

• Hidden columns

• Visual-driven refactors can silently alter AI responses

Since AI agents in Microsoft Fabric don't interpret visuals; these changes may alter how AI interprets the data, potentially impacting the accuracy of responses or even unintentionally expanding or restricting access to certain information.

The core challenge lies in the lack of clear separation between visual design, business semantics, and AI consumption. Because all three are intertwined, as said, changes in one area can ripple into others in unpredictable ways. As a result, while security enforcement itself remains correct, it becomes inherently fragile in practice, requiring careful governance and coordination to avoid unintended side effects.

For production AI use cases, Microsoft strongly recommends extracting and governing a reusable semantic model.

2.- Contoso Case Study #2 – Re‑Architecting for AI Readiness

Over time, to better support enterprise AI scenarios, Contoso evolves its architecture by introducing a dedicated semantic product (SM#4), creating a cleaner separation of concerns between data, semantics, and AI consumption.

Report #1 remains unchanged, while Contoso refactors Report #2 to leverage the standalone, reusable semantic model (SM#4). In addition, a new Power BI report (#3) is introduced, also built on SM#4, but tailored to different roles and business needs.

Since Contoso is running Oracle v10+ with LogMiner, the IT team opts to use Microsoft Fabric’s Oracle Mirroring. This allows near real-time replication into OneLake without complex ETL and without impacting resources reserved for operational systems. Contoso’s data architects can implement this either through Fabric’s native mirroring or via Oracle GoldenGate 23ai with Open Mirroring. In this setup, Fabric becomes AI‑native, while Oracle remains a system of record rather than a query engine.

In addition, Power BI report #3 requires data that resides on‑premises in a Microsoft SQL Server database. To address this, Contoso’s Data Team adopted a similar pattern by enabling SQL Server Mirroring, now generally available.

With this approach, Fabric creates a mirrored database in OneLake to handle replication, along with a SQL analytics endpoint for querying and analysis.

2.1- How Cost Is Distributed

In Use Case #2, cost responsibilities are now clearly separated across layers. AI reasoning by the Data Agent is billed to the Fabric capacity, as is semantic model DAX execution. This clear separation brings multiple benefits: it enables precise FinOps chargeback, facilitates capacity monitoring via Fabric Capacity Metrics, and ensures more predictable scaling across both AI and data layers.

With both Oracle Mirroring and SQL Server Mirroring, the compute required to replicate data into OneLake is free, and storage is included as part of the Fabric capacity. Costs are incurred only when the data is queried—via SQL, Power BI, or Spark—and are billed based on the Fabric capacity while it is running.

This mirroring approach in Microsoft Fabric makes the required data available to Fabric Data Agents in near real time, without additional ingestion charges or replication compute costs. In this scenario, since WS2‑Fabric is backed by an F64 Fabric capacity, Contoso benefits from up to 64 TB of included storage for mirrored databases.

2.2- Security Model and Enforcement

In this use case, security becomes centralized, intentional, and fully auditable.

RLS and OLS are defined once in Semantic Model #4 and/or in OneLake, ensuring that all data accessed by Power BI reports and Data Agents follow consistent rules. As a result, all consumers—whether Power BI reports, Data Agents, or future Copilot experiences—inherit the same security policies. Report modifications no longer impact AI security or behavior, providing a stable and predictable security model.

You can also monitor, audit, and attribute SQL and DAX activity in a centralized, auditable way without compromising security guarantees. By design, however, RLS and OLS cannot be bypassed, and users cannot access raw data they are not authorized to see.ee.

Visibility and governance can be safely achieved through several mechanisms:

1. Fabric Capacity Metrics App: Monitor query execution from Power BI reports and Data Agents at the capacity level, including DAX, DirectQuery SQL, CU usage, and top consumers—enabling chargeback, anomaly detection, and cost visibility without exposing data.

2. Power BI / Fabric Audit Logs: Track who accessed which semantic model or report/Data Agent, including timestamps, workspace, and user identity, meeting SOX, GDPR, HIPAA, and audit requirements.

3. Log Analytics (optional): Stream engine logs to Azure Log Analytics for metadata-level insight into queries, CPU/memory usage, and executing users—supporting performance tuning, AI-driven analysis, and security reviews while enforcing RLS/OLS.

4. Source-System Monitoring (DirectQuery): Monitor SQL execution at the source, including locks and execution plans, combined with Fabric orchestration and CU usage, providing end-to-end lineage and accountability.

Why the use case #2 is fundamentally better for AI‑based agents

Use Case #2 improves AI-based agents like Fabric Data Agent #1 by elevating the semantic model from a report artifact to a governed, reusable data product.

This provides AI with stable meaning, enforceable security, predictable costs, and auditable behavior at enterprise scale.

• AI agents reason over semantics, not visuals AI agents translate natural language into executable queries—DAX, SQL, or KQL—against authorized data sources and semantic models. With semantics in a reusable model, AI queries become far more reliable, and answers are explainable and repeatable instead of fragile or unpredictable.

• Centralized semantics enforce security automatically Data Agents and Copilot respect Row-Level Security (RLS), Object-Level Security (OLS), and workspace/model permissions. A standalone semantic model (SM #4) ensures RLS/OLS are defined once and consistently inherited across reports, agents, and future Copilot experiences—eliminating the need to re-engineer security per report or prompt.

• Semantic models turn AI into a production system Treating semantic models as first-class data products ensures consistent definitions, measures, and relationships. Lineage is explicit, ownership is clear, and the risk of hallucinations or conflicting KPIs is minimized. AI agents become trusted analytical teammates, not experimental tools.

• Costs become predictable and auditable Centralized semantic models separate AI reasoning costs (billed to Fabric Data Agent capacity), query execution costs (billed to the semantic model or storage engine), and source-system exposure (DirectQuery), making consumption visible and controlled. In contrast, report-embedded models blur costs, making AI-driven spikes harder to track and manage.

• Report changes no longer break AI behavior Decoupling reports (presentation), semantic models (logic), and agents (interaction) ensures AI behavior remains stable even as reports evolve. Renaming columns, hiding tables, or refactoring visuals no longer silently change or block AI answers.

Now that Contoso has introduced AI-based agents—such as Fabric Data Agents, Power BI Copilot, and future Copilots—these agents do more than just read data; they reason over it. By combining AI instructions in a reusable semantic model (SM#4) with agent-level instructions in Data Agent #1, AI evolves from a simple “chat over data” feature into a governed, predictable, and auditable analytics capability.

AI Instructions are important because they give Copilot and Fabric Data Agents explicit business context, reducing ambiguity and ensuring that AI reasoning aligns with how your organization actually defines, measures, and talks about its data. Through AI Instructions, you can formally encode business definitions, preferred metrics, time logic such as fiscal calendars, and organizational vocabulary directly into the semantic model. These instructions are stored as part of the semantic model metadata and are consistently consumed by both Copilot and Fabric Data Agents, acting as durable guardrails that improve accuracy, consistency, and trust in AI-generated answers across all reports and experiences.

You can learn more about how to prepare for AI our standalone sematic models and by reading the edition #2 of my newsletter: The Real Magic Behind AI Accuracy Isn’t AI — It’s Your Data on LinkedIn.

This architecture ensures stable AI behavior even as reports change, enforces security centrally through RLS and OLS, reduces query inefficiencies and cost volatility, and provides a scalable foundation for both current Data Agents and future Copilot experiences.

Strategic Takeaway

AI does not fail because of models—it fails because of architecture.

Organizations that treat semantic models as governed data products, not report artifacts, gain:

• Predictable AI costs

• Stable, explainable AI answers

• Strong security guarantees

• A scalable foundation for Copilot, Data Agents, and future AI workloads

Microsoft Fabric enables this transition with:

• Reusable semantic models

• Unified capacity management

• Native AI integration

• A clear path from legacy systems like Oracle to AI‑ready analytics