Getting a semantic model ready for AI

Why this is worth doing

AI does not read your data. It reads your model: the table names, column names, measures, descriptions and relationships you left in it. Whatever is ambiguous stays ambiguous, and whatever is hidden is gone.

Christian Wade puts it plainly in the Fabric Insider interview: a semantic model exists to abstract the complexity for people who cannot write joins and SQL, and that job does not change when the consumer is an AI. He argues the model matters more in the age of AI, because an AI is non-deterministic and the model is what keeps the answers repeatable.

That is the benefit: the same question gets the same answer next week, from a person or from Copilot, because there is only one definition to find. It also pays for itself in documentation you needed anyway — a description on a measure is read by the report author who hovers over it, by the person opening the file in six months, and by the AI.

The failure it prevents has a shape. In one of his Copilot tests, Avi Singh asked for total sales and got sales plus tax, because the model had a column and a measure that both looked like the answer he meant. The AI did not do anything strange. It picked a plausible field in a model that let it.

The worked example

Start with the problem, not the fix. A sales model with three things called sales:

Object	Name in the model	What it is
Table	Sales	the fact table
Column	Sales[Sales Amount]	amount before tax
Column	Sales[Tax]	tax
Measure	Total Sales	SUMX ( Sales, Sales[Sales Amount] + Sales[Tax] )

A person reading the report sees “Total Sales” and may know it includes tax. Copilot has to pick between a table, two columns and a measure that all answer to the word “sales”. If the measure includes tax and the column does not, “total sales last month” has more than one honest answer.

The before and after are not about clever DAX. They are about removing the choice:

Before	After
Sales[Sales Amount], Sales[Tax] visible	amount columns hidden from report view; one measure exposed
Total Sales with no description	Net Sales and Gross Sales, each with a description saying what is included
fact table named Sales, also a column Sales	columns named for what they hold; the word “sales” means one thing

Net Sales =
SUM ( Sales[Sales Amount] )

Gross Sales =
SUMX ( Sales, Sales[Sales Amount] + Sales[Tax] )

Both measures need a description, because the difference between them is the whole point. If a reader has to guess, so does the AI.

What to do, in order

1. Fix the model before you touch the AI

Copilot and Q&A inherit the model’s problems. A flat table with one wide fact and no dimensions gives the AI fewer relationships to use but a lot more ambiguity: dozens of columns whose names repeat the same business word. A star schema gives it one path from a dimension to a fact, and one place to find each concept.

The test is the one you would apply to a new analyst: could they answer “sales by product by month” without asking which column? If not, no prompt will fix it.

2. Name things the way people ask

Q&A in Power BI matches the words in a question to names in the model — exactly as written, with no understanding of context. Marc Lelijveld explains the consequence in his talk on interacting with data in the AI era: a question full of context is still reduced to matching “sales” and “year” to whatever is named that way. He also points out that hiding fields is part of the job: key columns and the table a field parameter creates are exactly the kind of objects you do not want the AI to reach for.

So:

• name tables and columns for the business concept, not the source system;
• hide keys, IDs and technical columns from report view;
• hide helper tables (field parameters, disconnected lookup tables) unless the reader is meant to use them;
• give one concept one name, in one place.

3. Write the descriptions

Measure descriptions are read by the AI and by people. Copilot can draft them for you: in Guy in a Cube’s walkthrough with Carly, Copilot wrote a description for a “Product Sales Top 3” measure that the author recognised as accurate. Microsoft shipped the same ability in the February 2024 update, framing it as documentation rather than an AI feature.

4. Say what is included and what is not

The descriptions do the work that a definition does in a business glossary: net or gross, which date, which customers, what happens to blanks. This is where a model stops being ambiguous even when the names are short.

5. Check the relationships

Every Copilot answer is a query, and a query pays for every relationship it has to cross. In SQLBI’s test, the same query took about ten times longer over a limited relationship than over a regular one-to-many relationship: around 148 seconds against 15. Every query that crosses it pays. AI does not make that cheaper; it makes it more frequent.

If the model has a direct many-to-many because two dimensions could not be related, fix the model (a bridge table, or a redesign of the grain) rather than teaching the AI to live with it.

6. Test with the questions people actually ask

Write down ten real questions from the business, including the awkward ones, and ask them of the AI. Then ask again tomorrow. Guy in a Cube’s 2026 experiment found the same prompt on the same model returning a different result at different times, even with a model that was a clean star schema with hidden columns and well-named measures. A model cannot make an AI deterministic. It can remove the ambiguity the AI is guessing at, which is the part you control.

7. Keep a person on the answer

Avi Singh’s sales-plus-tax case is the normal failure, not the exotic one. The answer looked right, the author caught it because they knew the business. The model should make that catch less necessary; it cannot make it unnecessary.

What goes wrong

• The AI picks a field, not a definition. Two columns and a measure called sales gives it three answers.
• Keys and helper tables leak into answers. Hiding them is a model setting, not a prompt.
• A many-to-many relationship gets asked more often. It took about ten times as long as a regular relationship in SQLBI’s test, so a model that felt fast enough for report authors can feel slow for AI.
• The answers change without the model changing. That is the AI, and it is why the model has to be the stable part.
• The model is a mess and nobody agrees what a semantic model is. Enterprise DNA’s counterpoint is worth keeping: ask ten data people what a semantic model layer means and you may get twelve answers, and many real models are not the clean layer the theory describes. Adding AI to a bad model exposes it faster.

Where it can be used

• Copilot and Q&A in Power BI, which match a question to the names and descriptions in the model.
• Any agent that reaches the model directly. Enterprise DNA point out you can already query a model from Claude Code over an MCP connection; that agent reads the same names and descriptions Copilot does.
• People. Microsoft’s February 2024 update shows the description appearing when an author hovers over the measure in report view. The work for the AI is documentation for the next person.

Where the teachers disagree

Christian Wade’s position is that the semantic model is the source of trust and becomes more important with AI. Enterprise DNA’s position is close to the opposite: agents can already work over data through tools such as MCP, and a model in a real organisation is often too messy to be the constraint people claim.

They are describing different models. Wade is talking about a model designed as the context layer; Enterprise DNA is talking about what many organisations actually have.

The practical difference is the test: if your model can answer the top ten business questions consistently, it is the asset Wade describes. If it cannot, calling it the source of truth does not make it one — and an AI will find the gaps quickly.

Where it can take you

All of this is about answering questions. When an agent has to take an action — decide, recommend, trigger something — RADACAD shows the next layer: an ontology on top of the semantic model, with definitions closer to business terms, used as a knowledge base for an operational agent. That is optional and a step beyond Copilot. Get the model and its descriptions right first; an ontology built on an ambiguous model inherits the ambiguity.

More guides

• Why a star schema: the shape the AI reads, and the hard parts a star has to get right.
• Working with Power BI project files and AI: save the model as text so an agent can change it and you can review the diff.