Power BI AI Data Schemas - Telling Copilot Which Fields to Ignore

The first time most organisations switch Copilot on against a real Power BI semantic model, the reaction goes something like this. Someone asks "what were sales in Queensland last quarter?" and gets a sensible answer. Then someone asks "how many active customers do we have?" and Copilot picks a column called CustomerStatus_Legacy that nobody has used since 2021, and returns a number that's wrong by about 40 per cent. Trust evaporates in a single meeting.

The model wasn't broken. Your reports never used that legacy column, so it never caused problems. But Copilot doesn't know which fields your report authors avoid. It sees everything in the model and has to guess.

AI data schemas are Microsoft's answer to that. They let you tell Copilot which tables, columns and measures it should consider, and which it should ignore. It's one of the least glamorous Copilot features and one of the most useful. Microsoft's documentation on it is here: Prepare your data for AI - AI data schemas.

What an AI data schema actually is

An AI data schema is a subset of your semantic model that you mark as relevant for AI. You set it up in Power BI Desktop under the Prep data for AI option on the Home ribbon, by choosing Simplify the data schema and ticking the tables, columns and measures you want Copilot to use.

Anything you leave unticked is still in the model. Your reports still work, your DAX still works, and your users can still see those fields when they're building visuals. The schema only affects what Copilot and related AI experiences pay attention to when answering questions about that model.

It's saved with the semantic model, so when you publish, the schema goes with it. Anyone using Copilot against that model, whether in a report, in the standalone Copilot experience or through a Fabric data agent pointing at the model, gets answers based on the narrower set of fields.

Prep data for AI has a few other parts, including AI instructions and verified answers. We covered those more broadly in our post on preparing a semantic model for AI. This post is just about the schema, because in my experience it's the step people skip, and it's the one that fixes the most embarrassing wrong answers.

Why trimming the model helps so much

Language models answering questions over your data are doing something like this: read the question, look at the available tables and fields, decide which ones are relevant, then generate a query. Every extra field is another option to pick from, and another chance to pick wrong.

Typical enterprise semantic models are full of things that are useful to the model but confusing to an AI:

• Key columns and IDs like CustomerKey, DateKey, SourceSystemID. They exist to build relationships, not to be reported on.
• Helper columns for sorting, like MonthNumber sitting next to MonthName.
• Duplicate or near-duplicate measures, such as Revenue, Revenue (excl GST), Revenue Old Calc and Revenue v2 DO NOT USE.
• Staging or technical tables that support calculation logic but don't mean anything to a business user.
• Legacy fields kept around so an old report doesn't break.

Hiding fields in the model helps a bit, and you should be doing that anyway. But the schema is a more deliberate signal. It says "these are the business concepts this model is for."

On one financial services project, the model had about 600 columns and 180 measures. After a workshop with the finance team, the AI schema ended up with roughly 90 columns and 35 measures. Copilot's answer quality on our test questions went from "please don't show this to the CFO" to good enough to pilot with a group of analysts. We didn't change a single line of DAX.

How we decide what goes in

The tick boxes are easy. Deciding what to tick is the actual work. Here's the approach we use.

Start from questions, not fields. Get the people who'll use Copilot to write down 20 to 30 questions they'd realistically ask. "What's our gross margin by product line this financial year?" "Which suppliers are late more than 10 per cent of the time?" Then work backwards to the fields needed to answer them. That list is your first-pass schema.

Pick one measure per concept. If you've got four revenue measures, decide which one Copilot should use and leave the others out. If people genuinely need more than one (say, revenue including and excluding GST), make sure the names and descriptions make the difference obvious.

Keep the dimensions people say out loud. Region, state, product category, customer segment, financial year. If a manager would say it in a meeting, it probably belongs in the schema.

Leave out keys and plumbing. Surrogate keys, sort columns, row-level security helper tables, bridge tables. Relationships still work when these are excluded from the schema, so Copilot can still join across tables. It just won't try to report on ProductKey.

Check date handling. If you have a proper date table, include the columns people use (date, month, quarter, financial year) and leave out the dozen helper columns. Australian financial years trip up AI constantly, so including a clearly named Financial Year column and putting a line about the July to June year in your AI instructions is well worth doing.

Testing the schema

Don't set the schema and assume it's working. Build a small test set:

1. Take your list of realistic questions.
2. Write down the expected answer for each, checked against an existing report.
3. Ask Copilot each question, with and without the schema applied if you can.
4. Record which answers are right, which are wrong, and which fields Copilot used.

The wrong answers tell you what to fix. Usually it's a missing field, a poorly named measure, or two fields that mean similar things where one needs to go. Sometimes it's not a schema problem at all and you need an AI instruction or a verified answer instead.

Rerun the test whenever the model changes. That's the bit organisations forget. Someone adds a new measure six months later, it's not in the schema, and users start getting "I can't find that" responses without anyone understanding why.

Things to watch out for

A few honest observations from projects so far.

Too narrow is also a problem. It's tempting to strip the schema right back. But if you remove a field people legitimately ask about, Copilot will either refuse or find something adjacent and wrong. Start a little broader than you think and trim based on test results.

Names and descriptions still matter. The schema decides which fields Copilot sees. It doesn't make a measure called Measure 27 understandable. Rename things to plain business language and add descriptions. Those two jobs together do far more than either alone.

Ownership gets fuzzy. Who decides what's in the schema? In most of our clients it's ended up with the semantic model owner, with sign-off from a business lead. If nobody owns it, it drifts.

It's model-wide. The schema applies to the semantic model, not to a particular report or audience. If the finance team and the operations team want very different things from the same model, you may need to think about separate models, or at least lean on AI instructions to guide context.

The tooling is still maturing. The Prep data for AI experience has changed a fair bit over the past year and I'd expect it to keep changing. Check the current documentation before you write internal guidelines, and expect to revisit them.

Where it fits in a bigger AI rollout

AI data schemas are a small feature, but they point at a bigger truth. Most "Copilot gave us a wrong answer" stories are really "our semantic model was built for report authors, not for conversation" stories. The model works for humans who know which fields to avoid. An AI doesn't have that tribal knowledge unless you give it.

So if you're planning a Copilot rollout across Power BI, budget for model preparation. In our projects it's often 30 to 50 per cent of the effort, and it's the part that decides whether people keep using the tool after the first fortnight. Training matters too. Users who know how to phrase questions and how to check an answer get far more out of it, which is why we build that into our Copilot training.

If you want a hand getting a model ready, our Power BI consultants do this regularly, and for organisations looking at conversational analytics more broadly, our AI for business intelligence work covers the bigger picture, including where custom AI agents make more sense than Copilot.

For the official walkthrough of the feature itself, see Microsoft's AI data schemas documentation.