Preparing Your Power BI Semantic Model for AI - A Practical Walkthrough

Most Australian organisations that switch on Copilot in Power BI have the same experience in week one. Someone senior asks a simple question like "what were sales in Queensland last quarter?", Copilot picks the wrong date column, sums a field that should have been averaged, and returns a number that's confidently wrong. The pilot stalls. A month later somebody in the steering committee says "we tried AI in Power BI and it didn't work."

It usually did work. It just worked on a model that was never built for a machine to read.

Microsoft has a tutorial on preparing a semantic model for AI that walks through the tooling. I want to go through the same ground from the consulting side, because the tooling is the easy bit. The judgement calls are what decide whether your Copilot rollout gets used or quietly abandoned.

What "prepare for AI" actually means

There are two layers here and people tend to blur them.

The first layer is plain model hygiene. Table names, column names, descriptions, hidden technical fields, proper relationships, measures instead of implicit aggregations. None of this is new. Good Power BI developers have been doing it for years because it makes reports easier to build and maintain. The difference now is that a language model is reading your model's metadata as if it were documentation, so the cost of sloppy naming has gone way up.

The second layer is the dedicated "Prep data for AI" features in Power BI Desktop and the service. There are three main pieces:

• AI data schema - you choose a subset of tables, columns and measures that Copilot is allowed to consider. Everything else is still in the model for your reports, but the AI doesn't see it.
• Verified answers - you take a visual you've built and checked, attach some trigger phrases to it, and when a user asks something similar Copilot returns that visual rather than generating a fresh one.
• AI instructions - free text guidance that gets passed to Copilot as context. Business definitions, preferred date logic, which measure to use when someone says "revenue", that sort of thing.

Once you've done the work you can mark the model as prepped for AI, which tells Copilot (and users) that someone has deliberately set this model up for natural language questions.

Start with the schema, not the instructions

The temptation is to jump straight into AI instructions because they feel like prompt engineering and that's the fun part. Don't. In the projects we've run, cutting down the AI data schema made a bigger difference to answer quality than anything we wrote in instructions.

Here's why. A typical enterprise semantic model we inherit has somewhere between 300 and 1,500 fields once you count every column across every table. Plenty of them are surrogate keys, audit columns, staging leftovers or three different versions of "Customer Name" from three source systems. A human report developer knows to ignore CustNm_Legacy. The model doesn't know that unless you tell it, and the easiest way to tell it is to remove the field from what it can see.

Our rough process:

1. Pull the list of fields actually used in the top 20 reports built on the model. The usage metrics and the lineage view help here, or you can script it against the PBIP files if you've got the model in source control.
2. Start the AI schema with only measures and the dimension attributes people genuinely filter by. For a sales model that might be 40 or 50 fields out of 600.
3. Leave out raw numeric columns where an explicit measure exists. If you've got a [Total Sales] measure that handles returns and GST correctly, don't let Copilot sum SalesAmount directly.
4. Test with real questions from real users, then add fields back only when a question fails because something is missing.

That last step matters. Teams often go the other direction, starting with everything and trying to prune. You'll never finish pruning. Start small.

Naming and descriptions still carry the most weight

Even within a tight schema, Copilot is reading names and descriptions to work out what you mean. A few things we see over and over:

Abbreviations. GM% might be obvious to your finance team. To Copilot, it's ambiguous. Call it Gross Margin % and put a one-line description on it that says how it's calculated.

Duplicate concepts. If you have Order Date, Invoice Date and Ship Date all connected to a date table (one active, two inactive relationships), Copilot will pick the active one by default. That's usually fine, but write it in the description and in the AI instructions: "When users ask about sales over time, use Invoice Date unless they mention orders or shipping."

Australian financial years. This one catches nearly every client. Copilot has a habit of assuming calendar years. If your date table has a Financial Year column with values like "FY26", describe it explicitly and add an instruction that "this year" and "last year" mean financial year, July to June. Otherwise your CFO asks for "this year's revenue" in October and gets three months of data.

Synonyms. The Q&A linguistic schema still exists and Copilot does draw on it. If your sales team says "deals" and your model says "Opportunities", add the synonym. It takes five minutes.

Verified answers are underrated

I'll be honest, when verified answers first appeared I thought they were a bit of a crutch. If the model is good, why do you need canned responses?

I've changed my mind. In practice, about a dozen questions make up most of what executives ask. "How are we tracking against budget?" "What's our pipeline for next quarter?" "Which region is down?" For those, you don't want Copilot improvising a chart. You want the exact visual the finance team has signed off, with the right filters and formatting.

Verified answers give you that. The user asks in their own words, Copilot matches it to the trigger phrases, and they get the trusted visual. Everything else falls through to generated answers.

A couple of tips from setting these up:

• Write trigger phrases the way people actually talk, not the way the report is titled. "Are we on budget" and "budget vs actual" and "how far off target are we" should all land in the same place.
• Use the filter options so one verified answer can serve multiple regions or business units instead of building eight near-identical ones.
• Review them quarterly. A verified answer that points at last year's budget structure is worse than no verified answer, because people trust it more.

AI instructions - useful, but keep them short

AI instructions are where you put the business context that doesn't fit anywhere else. Things like:

• "Revenue means the Total Revenue measure, excluding GST."
• "Active customer means a customer with at least one invoice in the last 12 months."
• "Region refers to the Sales Region column, not the State column."
• "The financial year runs July to June."

What doesn't work well is turning the instructions into a 3,000-word essay about your business. We've seen teams paste in their entire data dictionary. Answer quality got worse, not better, because the important rules were buried. Aim for a short list of rules that resolve genuine ambiguity. If you find yourself writing an instruction to explain a confusing field, that's usually a sign the field should be renamed or removed from the AI schema instead.

Also worth knowing: instructions are guidance, not hard constraints. Copilot will mostly follow them. Mostly. Don't rely on an instruction to stop it doing something that would be genuinely harmful, like exposing data a user shouldn't see. That's what row-level security is for, and RLS still applies to Copilot queries.

Testing is the part everyone skips

Here's the step that separates a model that works from one that demos well. Build a test set.

Sit with three or four actual users from different teams and collect 30 to 50 questions they'd genuinely ask. Write down what the correct answer is (a number, or at least which measure and filter). Then run them through Copilot and score each one: right, wrong, or right but presented badly.

Do this before you make changes so you have a baseline, and again after each round of schema, naming and instruction changes. In one recent engagement with a distribution business, the first pass scored around 45% correct. After trimming the schema, renaming about 60 fields and adding eight verified answers, we got to the high 80s. The remaining failures were mostly questions the model genuinely couldn't answer because the data wasn't there.

It's tedious work. It's also the only way you'll know whether to roll Copilot out wider or hold off.

What's still rough

A few honest caveats.

The prep features have improved a lot in the last year, but the authoring experience in Desktop can still feel clunky on large models. Ticking boxes across hundreds of fields in a tree view isn't anyone's idea of a good afternoon. If you're working in PBIP format with TMDL, some teams find it faster to manage things in the files directly, though you need to be careful about what's supported.

Copilot's behaviour also shifts as Microsoft updates the underlying models. A question that worked perfectly in June might behave a bit differently in September. Your test set is your early warning system here, so keep it and rerun it periodically.

And licensing still trips people up. Copilot in Power BI needs the right Fabric or Premium capacity behind it, and the tenant admin settings have to allow it. Check that before you spend two weeks prepping a model nobody can query.

Where to put your effort

If you only have a few days, here's the order I'd go in:

1. Fix names and add descriptions on the measures people use most.
2. Build a tight AI data schema.
3. Set up verified answers for the top ten executive questions.
4. Write a short set of AI instructions for date logic and key business definitions.
5. Test with real questions and iterate.

None of this is glamorous. But the organisations getting real value from Copilot in Power BI are the ones that treated the semantic model as a product with an AI audience, not a by-product of report development.

If you want help getting a model into shape, our Power BI consultants do this work regularly, and it often fits into a broader AI for business intelligence program. For organisations already moving onto Fabric, the same principles apply to the wider platform, and our Microsoft Fabric consultants can help plan that out.