What Your Report Isn’t Telling AI: Preparing Your Semantic Model in Power BI

Most Power BI semantic models are built to serve reports that people read. The model holds the measures and relationships, and everything else is left to the report and the person using it.

That has worked well, because people fill in the gaps themselves. But Copilot, MCP (Model Context Protocol), Fabric Apps and other agents don’t look at the report. They query the model directly, and everything that used to live in the report layout and in the analyst’s head is missing.

If an analyst has to explain the report, your model isn’t ready for AI

A well-built Power BI report carries a lot of information that isn’t in the model at all. The page title says the figures exclude intercompany sales. A page-level filter removes test customers. A note under a visual explains that the current month will be updated after the books close. The layout nudges you to look at total sales first and units second.

All of this is business logic. It ended up in the reporting layer simply because the report was the only place anyone consumed the data.

Then there’s the logic that has always lived in people’s heads. The analyst knows that the “Sales v2” measure is retired, that credit notes are posted to a different month than the original invoice, and that one business unit’s numbers arrive a week late. None of this is written down anywhere, because until now nobody needed it to be.

Reporting layer, semantic layer and semantic model: what’s the difference?

The reporting layer is the part of your data architecture that users see: the reports, dashboards and visualizations built from your data.

The semantic layer sits between the data and the reports and holds the business logic. It defines what the data means, how measures are calculated and how datasets relate to each other, so everyone works from the same definitions.

The semantic model is how the semantic layer is actually implemented. It brings together tables, relationships, measures, calculations and hierarchies, and reports are built on top of it. In Power BI, the semantic model is what used to be called a dataset.

What AI can see, and what it can’t

An AI agent sees the tables, columns, measures and relationships in your model, along with their names. If you’ve filled in descriptions, it sees those too. That’s everything.

It can’t see page filters, titles, text boxes or layout. It doesn’t know which of your five sales measures is the right one. It doesn’t know that a “Status_cd” value of 3 means a cancelled order.

What happens next is predictable. The agent picks a measure based on its name, calculates the number correctly, and delivers a confident answer that is wrong for the business. A person would have caught it, because the figure would have looked off. The agent has no sense of what looks off.

This is the real shift. A report was designed for someone who knows how to read it. For an agent, the model is the only source of truth, so the model has to spell everything out.

Seven changes that make your Power BI semantic model AI-ready

1. Describe every table, column and measure

   Power BI has had a description field for years, but in most models it’s empty. For an agent, descriptions are the most valuable information you can give it. A good one says what the measure calculates, what it leaves out and when to use it. For example: “Net sales excluding intercompany sales and credit notes. Use this when someone asks about sales without specifying further.”

   → In practice: save the model in .pbip format, use a Tabular Editor script to list every measure without a description, and have AI draft descriptions into the TMDL files for an expert to review before publishing.

2. Move report logic into the model

   Any page-level or visual-level filter that carries business meaning belongs in a measure or in the model itself. If test customers should always be excluded, build that rule into the model instead of repeating it on every report page.

   → In practice: go through the report definitions in your .pbip project, find the page-level and visual-level filters, and move the permanent exclusions into the semantic layer.

3. Keep one canonical measure per concept

   If your model contains Sales, Sales v2, Sales (new) and Sales_FIN, the agent is left guessing. Remove the duplicates, hide helper measures and make sure each business concept has exactly one clear measure.

   → In practice: find unused and overlapping measures with Measure Killer or Tabular Editor’s Best Practice Analyzer, and move them to a hidden “Deprecated” folder before deleting them for good.

4. Name things the way the business does

   “Fact_SalesLines” and “Status_cd” are system language. An agent does better with “Sales lines” and “Order status”, and code values should be spelled out in plain words. Hide technical key columns that users don’t need to see.

   → In practice: rename columns in business language within the semantic layer, and translate code values using a maintained mapping table so the same terminology shows up in every model.

5. Write down the unwritten rules

   Tacit knowledge needs to be put on paper: the month-end close schedule, the rhythm of the financial year, delays in data sources, exceptions to the rules. Power BI offers AI preparation features for this, such as instructions for the agent and verified answers, but they’re just containers. First you need to agree on the rules with the business.

   → In practice: put the rules in the AI instructions in Power BI’s “Prep data for AI” view, and keep the same text under version control next to the model so changes get reviewed like code. You can also document tacit knowledge in AI instructions or context files.

6. Build focused models with a single purpose

   One giant model with 400 measures covering the whole company is hard for an agent to work with. A smaller model focused on one subject area gives more accurate answers. Treat each model as a product with a clear audience and purpose.

   → In practice: build a separate semantic model for each subject area, such as sales or finance, and use the data schema in the “Prep data for AI” view to expose only the tables and measures that area’s questions need.

7. Don’t skip test questions and security

   Write 20 typical business questions along with the correct answers, and run them through the agent after every change to the model. You’ll see right away if something breaks. While you’re at it, check that row-level and object-level security are in order. In a report, users only saw what had been placed on the page. An agent can ask the model anything.

   → In practice: validate data quality with tests, save your test questions and correct answers as verified answers, and check row-level security using “View as” in Power BI Desktop.

Technically easy, organizationally hard

Writing descriptions and cleaning up measures is technically straightforward. The hard part is deciding what the right definition is.

When a BI developer writes “net sales excluding credit notes” in a description, they’re making a business decision. If finance and sales calculate margin differently, the description won’t settle the disagreement. It will just expose it.

That’s why every key measure should have a business owner who signs off on the definition. The BI team is responsible for implementation and quality, but the definition belongs to whoever runs that part of the business.

In that sense, agents are a test for the organization. They force you to write down what you’ve been settling in hallway conversations for years.

Where to start

You don’t have to fix your whole model library at once. Four steps are enough to get going:

• Pick one model that’s widely used and whose numbers matter to leadership.
• Document the logic in its main reports: page filters, titles and text boxes.
• Spend an hour interviewing the analyst: what exceptions do they keep in mind when using the model?
• Write 20 test questions, run them through the agent and see where it trips up.

The results will quickly show how far your model is from being AI-ready. They’ll often also show how much your data-driven decision-making has depended on what individual people remember.

So the question isn’t whether your analytics platform supports Copilot, MCP or Fabric Apps. It’s whether your semantic model can tell an agent what your analyst already knows.