Power BI Semantic Layer Capabilities and Limitations for AI

Power BI's semantic layer sits inside 95% of Fortune 500 companies, with more than 35 million people touching it every month. It works fine for the person clicking through a report. What I want to dig into here is whether it holds up when the one asking isn't a person at all, but an AI agent making calls on its own, mid-run.

Microsoft Fabric, the platform hosting the semantic model now, hit 31,000 customers faster than any data platform Microsoft has shipped. Power BI has held the Gartner Magic Quadrant Leader spot every year since 2008, and has been recognized by other major analyst firms for its semantic layer work as well. Winning the BI market and being ready to serve autonomous agents are two different tests, though. I think a lot of people conflate them. The semantic model's job was to encode trusted measures and relationships so every tool gives back the same number, for someone sitting behind a screen. Whether that job description still holds when the user isn't a person is the real question.

What a Power BI semantic model actually contains and how it works

Strip a semantic model down and you get definitions: measures written in DAX, hierarchies, relationships between fact and dimension tables, calculation groups, security roles. DAX does the heavy lifting. It lets someone slice a table with a billion rows without touching SQL or copy-pasting the same formula into five different reports. Define "net revenue" once, and every report pulling from that model does the same math, every time.

The model doesn't stay boxed inside Power BI Desktop, either. The XMLA endpoint exposes it over an open standard, so Excel or Tableau can query the same definitions instead of rebuilding their own version from scratch. TMDL, the Tabular Model Definition Language, reached general availability and turned the whole model, tables, columns, relationships, DAX measures, security roles, into plain readable text. That opened the door to Git version control and scripting for work that used to mean clicking through menus by hand, one at a time.

There's a real programmability layer underneath, too: Fabric REST endpoints, Python notebooks through Semantic Link,.NET through the Tabular Object Model. Code can talk to the model directly instead of going through a report canvas. Direct Lake mode lets the model read Parquet files straight off OneLake instead of importing a copy, which gets you close to real-time data without waiting on a scheduled refresh job.

This is the foundation Microsoft points to when it calls semantic models "AI-ready." Open formats, an API surface, code-level access: they add up to a real base. What matters more is what it actually lets an AI system do today, not what it could theoretically support down the road.

The specific capabilities Power BI exposes to AI consumers today

Copilot's natural language Q&A is the most visible piece here. You ask a plain question, Copilot writes a DAX query against the model's definitions. How well that translation lands depends almost entirely on documentation quality. Table descriptions, metric definitions, relationship metadata: all of it cuts down the odds that the model invents a join or makes up a metric that was never there.

Microsoft shipped an "AI-ready" label in April 2025, available starting at F2 Fabric tiers. It unlocks full Copilot access to key fields, turns on an autonomous "chat with your data" mode, and sharpens how natural language questions get parsed. None of that happens automatically; it takes deliberate modeling and annotation before the label means anything for a given dataset.

Governance shows up through certified metrics and endorsed datasets, a workflow where specific measures get flagged as the authoritative version. Copilot favors those certified definitions over ad hoc ones, which cuts down on three people getting three different answers to the same question. TD Bank is a real example of this working at scale. Paul Wellman, who runs Enterprise Data & Analytics Platforms there, has talked about Power BI Copilot paired with trusted data products as the common language of insight across the bank, tying teams, data, and decisions together on one platform.

On security, Copilot's handling of row-level and object-level security is genuinely ahead of most competitors. Power BI Copilot's handling of RLS and OLS natively, with no bolted-on custom config needed, is a genuine differentiator relative to most competitors in the space.

That capability is real, and it shouldn't get waved off. Even so, the scope is narrow: every capability here runs inside the reporting layer, on data already sitting inside the model.

Where the design boundaries sit: what the semantic layer was built to serve

Who was this model actually built for? Someone clicking through a dashboard somebody else built ahead of time, not an autonomous agent firing off ad hoc queries at 3 a.m. because a warehouse threshold tripped. That distinction shapes everything downstream.

Schema gets authored in advance here, always. A measure, a hierarchy, a relationship: someone has to build it before it exists in the model. An agent can't ask about a concept the model never defined, no matter how sharp the language model behind it is. Copilot's DAX generation lives entirely inside that fence, answering what the semantic layer already covers, with zero reach into operational systems, SaaS APIs, or outside databases that were never federated in. The boundary is documented plainly: Copilot's DAX generation helps analysts, but it's limited to Power BI's semantic model and can't automate a process spanning multiple systems.

Data currency runs into a similar wall. Direct Lake helps, but it's still bound to when files actually land in OneLake. A snapshot that's fine for Monday's weekly sales dashboard might already be stale by the time an agent needs it for a live operational call.

The "AI-ready" label carries a cost most people skip past when reading the marketing copy. It needs a Premium or Fabric-licensed workspace, plus real modeling work, not a toggle flip. One practitioner analysis put it plainly: enterprise, AI-ready BI takes more effort and more attention to best-practice design than the surface-level pitch implies. The design center of all this is also the Microsoft ecosystem: OneLake, Fabric, Azure. Cross-cloud, multi-warehouse setups need federation work this layer just doesn't do on its own.

Security enforcement and where governance reaches its limits for agentic workloads

Row-level and object-level security get enforced at the model layer, and Copilot respects both without extra setup. That's earned, not a marketing line. OneLake security, in preview through 2025 and into 2026, pushes it further: row- and column-level controls get set once and apply automatically across Spark notebooks, SQL endpoints, Excel Online, and Direct Lake models alike. That's a real move toward one enforcement point instead of five scattered ones.

Microsoft Purview layers compliance on top, now generally available for Fabric users: auditing Copilot prompts and responses, eDiscovery, retention policies, flagging sensitive-data risk before it spreads. That matters more than it sounds on paper. Roughly 99% of organizations have already run into some form of sensitive data exposure through AI tools, according to Microsoft's own September 2025 Purview blog post.

Still, there's a gap underneath all that tooling.

RLS and OLS get enforced at the model level. But an agent usually runs through a service account, and that account can carry broader permissions than the actual person it's acting on behalf of. Permission doesn't automatically scope down to the real requesting identity at query time; nothing forces that narrowing. At the volume agents operate at, an audit log showing what query ran and what came back doesn't tell you why the agent asked, what decision the answer fed into, or who signed off on whatever action followed. That's a thinner form of lineage than it looks like on paper. Sensitivity checks at the field level also miss the case where two individually harmless fields, joined together, produce something that never should have surfaced. The model doesn't evaluate that combination at all.

Fabric governance analysis splits this into three layers: platform security, data governance, and semantic governance. Microsoft has mostly nailed the first one. Organizations handle the second on their own, unevenly. The third, who owns a given definition, which version counts as authoritative, when a measure was last reviewed, is almost always the piece nobody's covering.

Fabric IQ and Microsoft's roadmap response to agentic AI demands

Microsoft's own answer to this gap showed up at Ignite in November 2025: Fabric IQ, launched in preview, pitched explicitly as the semantic foundation for enterprise AI agents. It sits a layer above the existing semantic model rather than replacing it.

The core idea inside Fabric IQ is what Microsoft calls an Ontology: a unified model of business entities, relationships, rules, policies, and constraints. Microsoft's own framing gets at the shift directly: agents reason and act on business entities, not tables and schemas. Alongside the Ontology sit a handful of other pieces, Plan, Fabric Graph, Data Agent, Operations Agent, all built to extend the semantic model toward agents rather than replace it outright.

Existing Power BI semantic models can generate an Ontology directly, so none of the prior modeling work gets thrown away. There's support for MCP too, the Model Context Protocol, an open standard letting outside agents and tools plug into the ontology and ground themselves in governed business entities instead of raw schema. That's a direct answer to the cross-system access problem. Microsoft places Fabric IQ next to two sibling efforts, Work IQ for productivity signals and Foundry IQ for institutional knowledge, as three sources of context for enterprise agents.

Read plainly, the roadmap tells you what you need to know. Microsoft built Fabric IQ because the existing semantic layer wasn't enough on its own for agentic use cases. As of mid-2026, it's still in preview.

Why the data layer is where most enterprise AI projects actually break down

MIT's Project NANDA found that roughly 95% of generative AI pilots show no measurable effect on the bottom line. Only about 5% produce material revenue gains. That gap is enormous, and it should change how most organizations think about where their AI money is actually going wrong.

Analysis of enterprise AI engagements points to a consistent root cause, and it's rarely the model itself. The data layer underneath is usually the culprit: inconsistent metric definitions, no certified source of truth for key entities, pipelines built for dashboards that were never designed to carry inference workloads on top of them.

Semantic drift is the clearest way to watch this failure happen in real time. A business user asks a dashboard for last quarter's revenue and gets one number. They ask an AI assistant the same question and get a different one back. Trust doesn't survive that gap, and the cause is straightforward: "revenue" was never defined the same way on both sides. Power BI's certified metrics and endorsed datasets solve exactly this problem inside the model's boundary. The trouble is, the problem gets worse the moment agents start querying across systems that don't share a common semantic layer at all.

Industry analysts warn that a large share of agentic AI projects risk being abandoned in the coming years, largely from unclear outcomes and poor integration. Integration failure, in most of those cases, is a data-layer failure wearing a different name. It's the structural reason a semantic layer built for human report consumption needs something more once agents need live, governed access across systems it was never built to reach.

What organizations need beyond Power BI's semantic layer when agents are the consumers

Runtime identity is the first gap. Permissions need checking against the actual end user asking the question, at the moment they ask it, not assumed from whatever service account the agent happens to run under that day.

Cross-system federation comes next. Agents often need a warehouse, a CRM, and an operational database answered in a single query, and a semantic layer scoped only to what's already loaded into OneLake can't get there.

Freshness is its own problem, separate from the other two. For an agent making an operational call, what matters is whether the data reflects the business right now, not the state as of the last scheduled pipeline run three hours back. Semantic context, table descriptions, metric definitions, relationship metadata, needs to travel with the data itself, so any agent querying it has that context in hand instead of guessing from bare schema.

Sensitivity checks need to move from the field to the join. Governance that only checks individual columns misses the case where combining two fields creates something that shouldn't be exposed, and that check has to happen the moment the data actually gets combined, not before it. Audit logs need identity, intent, and lineage captured together, at agent scale, instead of query-level records that lose the thread across a multi-step reasoning chain. Write access deserves its own governance category, separate from read. An agent that can act, not just look, needs permissions tight enough to work at the workload level without breaking every downstream report riding on read access underneath it.

How teams can evaluate whether Power BI's semantic layer covers their AI use case or needs a complementary data layer

Power BI's semantic layer is the right call when the AI use case stays report-centric: Copilot answering questions about metrics already defined in the model. It's the right call when the data already lives in Fabric or is already federated into OneLake, when the people asking questions are human analysts and business users, and when an agent's job stops at being an assistant inside the BI interface rather than an autonomous system running across five platforms at once. If RLS, OLS, and Purview audit cover the governance need, and that need stays field-level within a single platform, the case is closed.

Things change once agents need to query live operational data across systems that were never brought into OneLake in the first place. They change once permissions have to enforce against a real end user's identity instead of a shared service account, or once semantic context, definitions, relationships, lineage, has to reach agents working outside Power BI entirely. They change once sensitivity only shows up at the join and not the individual field, and once audit requirements call for identity, intent, and lineage together at agent query volume, not query by query after the fact.

Peaka sits in that gap. It's an AI-ready data layer built on top of infrastructure that's already there, warehouses, SaaS tools, operational databases, with no migration or rip-and-replace needed to get started. It exposes one semantic interface with table descriptions, metric definitions, and relationships built in, enforces permissions at query time under the real user's identity, and logs full lineage per query rather than per session. This is a cross-system, runtime-governed setup built for agents from day one, covering ground Power BI's semantic layer was never meant to reach, while Power BI keeps doing what it does well: serving human report readers.

Power BI's semantic layer is a real foundation, proven at a scale few products in this industry can touch, and it does its job about as well as anything out there. What every team has to answer honestly is whether their AI use case stays inside that design or pushes past it. Getting that boundary right keeps organizations from underinvesting in what they already have, or building the same thing twice for no good reason.