19 September 2026

What Makes a Power BI Model AI-Ready?

Copilot answers from your model's definitions, not from your data. If your tables are called Query1 and you have four measures that all mean revenue, AI will answer confidently and wrongly. Getting ready is mostly naming, descriptions and deciding what things mean.

A Power BI model is AI-ready when the names in it mean what they say, every measure a business person might ask for exists exactly once, and the relationships between tables reflect how the business actually works. That is most of it. It is unglamorous, and it is why so many Copilot pilots produce confident nonsense.

The thing to understand before spending anything: Copilot does not read your data and work out what it means. It reads your model, the names, the descriptions, the relationships and the measures, and uses that to decide what to calculate. If your model says a table is called Query1 and there are four measures containing the word revenue, the AI will pick one. It will not tell you it guessed.

What does AI-ready actually require?

What Copilot needs What it usually finds Why it matters
Tables named as the business speaks Query1, Sheet1$, fct_sales_v2_final AI can't match a question to a table it can't recognise
One measure per concept Revenue, Revenue2, Total Revenue, Rev (net) Four candidates means a coin toss on every answer
Descriptions on measures and columns Blank, almost universally Descriptions are how you tell the AI what a thing means
Relationships matching the business Missing joins, or ambiguous multiple paths Wrong or absent joins produce wrong totals silently
Hidden technical columns Key columns and helper fields fully exposed Clutter gives the AI more wrong things to choose from
Consistent date handling Several date tables, or none marked properly Time questions are the most common, and the most fragile
Agreed definitions "Active customer" meaning three things AI can only be as decided as your business is

None of that is exotic. It is the same discipline that makes a model good for humans, which is the genuinely useful thing to know here: there is no separate AI project. A well-built model is most of the way to AI-ready already, and a badly built one needs the work it always needed.

Why does AI make a bad model worse?

Because it removes the human sense-check that was quietly protecting you.

When a person builds a report on a messy model, they know that Revenue2 is the one finance uses. They ask someone. They notice when a total looks wrong. That accumulated knowledge sits between the messy model and the answer, and it catches most of the errors.

Ask Copilot the same question and there is no such filter. It picks a measure, calculates, and presents the result in a fluent sentence with no indication of what it chose or how confident it should be. The output looks identical whether the model was pristine or a decade of accumulated shortcuts.

That is the actual risk, and it is not really about AI being unreliable. It is that AI removes the friction that used to reveal the underlying problem. Businesses that never got round to fixing their definitions could function because their people compensated. Take the people out of the loop and the compensation goes too.

What to fix first

Names. Rename tables and columns to what the business calls them. Sales, not fct_sales. Customer Name, not cust_nm. This is tedious and it is the highest-value thing on the list, because it is how the AI maps a question to your data.

Duplicate measures. Find everything that means roughly the same thing and reduce it to one, with a name that says which one it is. If the business genuinely needs both gross and net revenue, keep both, name them unmistakably, and describe the difference. Ambiguity is the enemy, not quantity.

Descriptions. Almost nobody fills these in, and they are the most direct channel you have for telling the AI what something means. A description saying that Active Customer means one with an order in the last 12 months, excluding internal accounts, is the difference between a right answer and a plausible one.

Hiding what should not be visible. Key columns, helper fields and technical scaffolding should be hidden. Every visible field is a candidate the AI might choose, and half of them are meaningless to a business question.

Dates. Have one properly marked date table that everything relates to. Time-based questions are the most common thing anyone asks, and multiple unmarked date tables produce answers that are wrong in ways nobody notices for months.

The part that is not technical

Before any of that, somebody has to decide what things mean.

The awkward truth in most businesses is that "active customer", "revenue" and "on-time" do not have single agreed definitions. Different departments use different ones, they have never had to reconcile, and the ambiguity has been absorbed by people knowing which version to use in which meeting.

An AI cannot absorb ambiguity. It will answer, definitively, using whichever definition happens to be encoded. Making a model AI-ready therefore forces a decision the business has been avoiding, sometimes for years. That is genuinely valuable, and it is also why these projects take longer than the technical work suggests: the bottleneck is getting someone with authority to rule, not writing the description.

How do you know if you are ready?

Test it rather than assess it in the abstract. Write down thirty questions a business person would realistically ask. Not clever ones, ordinary ones: what were sales last month, which customers are down on last year, how many orders shipped late in Q2.

Ask them, and check every answer against a figure you can verify independently. Count how many are right, how many are wrong, and how many are wrong in a way you would not have caught without checking. That third number is the one that matters, because it tells you the real risk of putting this in front of people who will believe it.

That test is exactly what my AI-Ready Power BI assessment is built around: models scored, a tested set of thirty business questions run against them, and a prioritised list of what to fix. It is £2,950 fixed for up to three semantic models, £650 for each one after that, delivered in five working days. You can run the same test yourself with a spreadsheet and a morning, and I would rather you did that than buy anything on faith.

The related question of whether your tenant and your governance are ready, as opposed to your model, is covered in Copilot readiness for Power BI.

Is it worth doing if you are not buying Copilot?

Yes, and this is the argument I would make even to someone with no interest in AI at all.

Everything on the fix list makes the model better for people. Clear names help the next developer. One measure per concept stops reports disagreeing. Descriptions mean somebody in two years can work out what a field is without asking. Hidden technical columns make self-service actually usable rather than bewildering.

So the honest framing is not "get ready for AI". It is that AI has given a commercial reason to do the modelling hygiene that was always worth doing, and which never got prioritised because it did not produce a visible deliverable. If Copilot never arrives at your business, you still end up with a model people can use and trust.

Common questions

What are the requirements for Power BI Copilot?

Commercially, a licensing arrangement that includes it, which changes over time and is worth verifying against Microsoft's current documentation. Practically, a semantic model with meaningful names, unambiguous measures, filled-in descriptions, correct relationships and one properly marked date table. The licence is the easy part.

Why does Copilot give wrong answers in Power BI?

Almost always because the model is ambiguous. Several measures could plausibly answer the question, names do not indicate what things are, descriptions are blank, or relationships are missing. Copilot resolves the ambiguity by choosing, and it presents the choice as an answer rather than flagging it as a guess.

How do I make my semantic model AI-ready?

Rename everything to business language, consolidate duplicate measures to one per concept, write descriptions on measures and key columns, hide technical fields, fix relationships, and make sure there is one properly marked date table. Then test with thirty realistic questions and verify every answer.

Do I need to rebuild my model for AI?

Usually not. Most of the work is renaming, describing, hiding and consolidating on the model you already have. A rebuild is only warranted if the underlying structure is genuinely wrong, in which case it was already causing performance and trust problems before AI entered the conversation.

Is Copilot in Power BI worth it?

It depends almost entirely on the state of your model. On a well-built model with agreed definitions, it lets people ask questions without waiting for a report, which is genuinely useful. On a model with four measures called some variant of revenue, it produces confident wrong answers faster than anyone can check them, which is worse than not having it.

How long does it take to get a model AI-ready?

The technical work on a single reasonably sized model is usually days. The part that takes longer is getting the business to settle definitions it has never formally agreed, which is a calendar problem rather than a work problem and depends entirely on how quickly the right person will make a decision.

Start with twenty minutes.

Tell me what's eating your week. I'll tell you whether it's a report, an automation, some AI advice, or nothing you need me for.