Preparing Power BI Data for AI - The Questions Clients Actually Ask

Every time we help an Australian organisation get Power BI ready for Copilot, the same handful of questions comes up. Not the technical ones you would expect. The practical ones: do we really have to do this, how long will it take, whose job is it, and will it actually make the AI better or is this just busywork. Microsoft has an FAQ on preparing data for AI that covers the official line. This is the version I would give a client over coffee, based on doing it rather than documenting it.

So here are the questions we get asked, and honest answers to each.

"Do we actually need to prepare our data, or can we just turn Copilot on?"

You can turn it on without preparing anything. It will work in the sense that it produces answers. Whether those answers are any good is the question, and the honest answer is usually no, not without preparation.

Copilot reads your semantic model and answers based on what the model tells it. If your model is clear, well named and well described, Copilot has what it needs. If your model is a pile of cryptic column names and duplicate measures that only make sense to the person who built them, Copilot guesses, and its guesses come out sounding confident regardless of whether they are right. Preparing your data is what moves Copilot from "impressive demo, useless in practice" to "actually trustworthy". So technically no, you do not need to. Practically, if you want people to rely on it, yes you do.

"What does preparing the data actually involve?"

Less exotic than it sounds. It is mostly making your model legible to something that reads it literally and brings no context of its own.

The core of it: give your tables, columns and measures clear names a person would recognise, add descriptions that explain what a field holds, and add synonyms so that when your people say "clients" and your table says "Accounts", Copilot knows they are the same thing. Beyond that, it is trimming the noise - hiding internal helper fields and half-finished measures that would only confuse an answer - and making sure the measures that do exist are correct and there is one obvious way to calculate the numbers that matter.

None of this is glamorous. All of it matters. The gap between how your business talks and how your model is labelled is exactly where Copilot gets lost, and closing that gap is most of the job. This is ordinary good Power BI hygiene that happens to also be what makes the AI work.

"How long does it take?"

Depends entirely on the state of your model, and this is where I have to be honest rather than reassuring. A clean, well-built model that just needs descriptions and synonyms is a manageable piece of work. A sprawling model with years of accumulated mess, undocumented measures, and tables nobody remembers the purpose of is a bigger job, because you are not just labelling it, you are untangling it first.

The mistake is assuming it is a quick pass because the marketing makes Copilot sound instant. Preparing data for AI done properly takes real time from someone who understands both the data and the business. It is not a five-minute toggle. My advice is to scope it honestly rather than discovering halfway through that the model needs fixing before it can be described. If you want a straight assessment of where your environment sits, that is exactly the sort of thing we look at in a business intelligence engagement.

"Whose job is this - IT, the data team, or the business?"

All three, honestly, and that surprises people who expect it to be purely technical.

The data team owns the model itself: the relationships, the measures, the structure. That part is theirs. But the descriptions and synonyms, the part that makes the model speak your business's language, needs input from people who actually know that language. A developer who does not work in sales will not know that "top accounts" means something specific to the sales team, or that "active" has a particular definition in your context. The business knowledge has to come from the business.

The best results we see come from the two working together. The technical people get the model clean, and the people who use the data every day tell them what things should be called and what the terms mean. It is a collaboration, not a handoff. Treat it as purely an IT task and you get a technically clean model that still does not speak the language its users think in.

"Will this actually make Copilot better, or is it busywork?"

It genuinely makes it better, and the difference is not subtle. We have put a prepared model and an unprepared model side by side, both technically functional, and watched them produce wildly different quality of answers to the same questions. The prepared one understands what is being asked. The unprepared one guesses. That is the whole difference, and it is entirely down to the preparation.

So no, it is not busywork. It is the work. The AI is the easy part; Microsoft built that. The part you own is making your data ready for it, and that is where a good Copilot experience is actually won or lost. This is a theme across pretty much all AI adoption, not just Power BI: the model is rarely the bottleneck, the data and the context around it usually are. It is a big reason we talk to clients about AI strategy before we talk about any specific feature.

"What could go wrong if we get this wrong?"

A few things, and they are worth naming plainly.

The worst one: Copilot faithfully amplifies whatever is in your model, mistakes included. If a measure is subtly wrong, Copilot will surface that wrong number in fluent, confident language, and the polish makes people believe it. That is arguably more dangerous than a spreadsheet error, because it looks authoritative. Get your numbers right before you make them easy to ask for.

The other big one is governance. Making your data more legible to Copilot means being deliberate about what Copilot can reach and describe. A field that is fine for an analyst who understands its caveats can mislead badly when it turns up in a plain-language answer with no context. And for Australian organisations with obligations around how information is handled, "the AI can see everything" is not a neutral default. Decide what should be exposed and what should not, on purpose.

"Is this a one-time job?"

No, and this is the part people least want to hear. Preparing data for AI is a loop, not a switch. You prepare, you test with real questions from real users, you find the places where Copilot still misunderstands, and you go back and refine. The messy, ambiguous questions people actually ask are where you learn what still needs work, and those only show up once real people start using it.

On top of that, the feature itself keeps evolving. Copilot in Power BI has improved quickly, which is good, but it means what you optimised a year ago may not be optimal now. Revisit it, retest periodically, keep an eye on what has changed. A Copilot-ready model is something you maintain.

Who should care about this

If you are an Australian organisation planning to put Copilot in front of your people in Power BI, these questions are worth answering honestly before you start, not after the first disappointing demo. Preparing the data is where most of the success is decided, and going in with realistic expectations about the effort involved is half the battle.

Most of the organisations we work with want the same outcome: people across the business asking questions of their data in plain English and getting answers they can trust. That is achievable, and the path runs through the unglamorous, valuable work of preparing the model. If you want a partner who will give you a straight read and do the work properly, that is what we do. Have a look at how we work with Power BI, or get in touch and we will tell you honestly where you stand.

For the official answers and the current state of the feature, Microsoft's prepare data for AI FAQ is the reference to keep handy.