Back to Blog

Power BI Copilot AI Settings - Preparing Your Data So the AI Answers Well

September 22, 20268 min readMichael Ridland

Almost everyone who turns on Copilot in Power BI expects it to be magic, and almost everyone is a little let down the first time. They ask a plausible business question, they get an answer that is confidently wrong or vaguely unhelpful, and they quietly conclude the AI is not ready. Nine times out of ten the AI is fine. The data underneath it is the problem, and nobody prepared it for a machine that reads field names literally and has no idea what your business actually means by "revenue".

That preparation is what the Copilot AI settings in Power BI are for. They are the controls that let you tell Copilot how to understand your model: what your fields mean, which ones matter, how to describe your data in plain language, and what to leave alone. Getting them right is the single biggest thing you can do to move Copilot answers from "impressive demo, useless in practice" to "actually trustworthy". Microsoft's AI settings documentation covers the mechanics. Here is the consultant's read on why it matters and how to approach it.

The uncomfortable truth about Copilot in Power BI

Copilot does not understand your business. It understands your model, and only as well as your model describes itself. When a user asks "how are sales tracking this quarter", Copilot has to map that plain-English question onto actual tables, columns and measures. If your columns are named Amt2, Fld_Cust, and DimDate[Attr7], it has almost nothing to work with, and it will either guess or give you a shrug dressed up as an answer.

This is the bit people skip. They think of Copilot as something you switch on. It is much closer to something you teach. The AI settings are the teaching interface: the place where you tell Copilot what your data means so it can answer questions about it sensibly. A model that has been prepared for AI and one that has not can sit side by side, both technically working, and produce wildly different quality of answers. The difference is entirely in the preparation.

We have seen this play out on real projects more times than I can count. A client is disappointed with Copilot, we look under the hood, and the semantic model is a mess of cryptic names and undocumented measures that a human analyst only gets through because they have three years of tribal knowledge in their head. Copilot has no tribal knowledge. It has what you wrote down. So write it down.

What the AI settings actually let you do

The settings give you a set of levers over how Copilot interprets and uses your model.

The most valuable is describing your data in language a person would use. Field descriptions, clear names, and synonyms so that when a user says "clients" and your table says "Accounts", Copilot knows they are the same thing. Your business has its own vocabulary, and the gap between that vocabulary and your column names is exactly where Copilot gets lost. Closing that gap is the highest-return work you can do.

There is also control over what Copilot should and should not use. Not every field in a model is meant for general consumption. Some are internal helper columns, some are half-finished, some are sensitive, some are just noise that would confuse an answer. Being able to steer Copilot toward the fields that matter and away from the ones that do not is a big part of getting clean answers rather than answers built on the wrong column. An AI that only ever reaches for the right measures is an AI people can trust.

And there is the ability to give Copilot the context it needs to describe your data well, so that when it generates a summary or a narrative it uses the right terms and frames things the way your business actually thinks about them. The goal throughout is the same: reduce the number of ways Copilot can misunderstand you.

Where this fits in a real build

Here is how we approach it when preparing a client's Power BI environment for Copilot.

The first move is honest, and slightly deflating: audit the model before touching the AI settings at all. If the underlying model is a tangle, no amount of AI configuration rescues it. Clear relationships, well-defined measures, sensible names. This is just good Power BI practice, and it happens to also be exactly what makes Copilot work. There is no shortcut around a clean model, and the AI settings are not one.

Once the model is sound, the AI settings are where you make it legible to Copilot. Descriptions on the things that matter. Synonyms that match how your people actually talk. Steering away from fields that would mislead. This is not a five-minute job if you do it properly, and doing it properly is the difference. It rewards someone who understands both the data and the way the business asks questions of it.

Then, and this part is non-negotiable, you test with real questions. Not the demo questions that you already know work. The messy, ambiguous, real questions your users will actually ask. This is where you find that "top customers" means something different to Copilot than it does to your sales team, and you go back and fix the model's understanding until the answers hold up. Preparing data for AI is a loop, not a one-time switch, and the testing loop is where the quality actually comes from.

The honest bits, what to watch out for

Now the parts worth saying plainly.

First, this is real work, and it is work you cannot skip. The marketing makes Copilot sound like a toggle. The reality is that a good Copilot experience sits on top of a well-prepared model, and preparing that model takes time from someone who knows what they are doing. Budget for it. The teams that treat Copilot as free and instant are the ones who end up disappointed, because they never did the part that makes it good.

Second, governance and sensitivity. Making your data more legible to Copilot means being deliberate about what Copilot can reach. A field that is fine for an analyst who understands its caveats can be dangerous when surfaced in a plain-language answer with no context. Think about what should be exposed to AI-generated answers and what should not, and use the settings to enforce it. This is a data governance decision, not just a Power BI setting, and it belongs in a broader conversation about how you use AI across the business rather than being decided ad hoc by whoever built the report.

Third, do not expect it to cover for bad measures. If your measures are subtly wrong, or defined differently from how the business thinks, Copilot will faithfully surface those wrong numbers in fluent, confident language. That is arguably worse than a spreadsheet error, because the polished delivery makes it more believable. Copilot amplifies whatever is in your model, the good and the bad. Prepare accordingly, and make sure the numbers are right before you make them easy to ask for.

Fourth, the feature set is still developing. Copilot in Power BI has been improving quickly, which is good, but it means the settings and their behaviour shift. Do not treat what you configured six months ago as settled. Revisit it, retest with real questions periodically, and keep an eye on what has changed. A Copilot setup is something you maintain, not something you finish.

Who should care about this

If you are an Australian organisation rolling out Copilot in Power BI and you want people to actually rely on the answers, the AI settings are where a good chunk of your success is decided. Prepared data is the foundation. Skip it and you get an expensive feature that people try twice and abandon.

If your Power BI environment itself is still shaky, that is the place to start, not the AI settings. Get the models clean and the measures correct first, because the AI can only ever be as good as what it sits on. Once that foundation is solid, preparing it for Copilot is genuinely worthwhile and pays off in daily use.

Most of the organisations we work with want the same thing: people across the business able to ask questions of their data in plain English and get answers they can trust. That is a real and achievable goal, and the path to it runs straight through the boring, valuable work of preparing the model. If you want a partner who will do that work properly rather than just flip the switch and hope, that is what we do. Have a look at how we work with Power BI and business intelligence, or get in touch and we will give you a straight read on where you stand.

For the mechanics and the current state of the feature, Microsoft's AI settings documentation is the reference to keep handy.