Prepare a Power BI semantic model for AI in five passes: bound the business use case, repair model and metric ambiguity, configure the AI-facing schema and context, establish expected-answer tests, and only then approve and expand access. Begin with one model, one target user group, and a representative set of questions. AI configuration cannot compensate for an unsafe grain, competing metric definitions, or untested permissions. The output of the process should be evidence—a model contract, test results, owners, and known limitations—not simply a completed settings dialog.
Microsoft’s tutorial recommends sound model design, an AI data schema, verified answers, AI instructions, testing, and the Approved for Copilot setting. It also identifies these capabilities as preview and reminds authors that Copilot output is nondeterministic. Prepare a semantic model for AI
The build-and-test workflow
| Pass | Main question | Artifact produced | Exit test |
|---|---|---|---|
| 1. Bound | What must this user group be able to ask reliably? | Use-case and question inventory | Stakeholders agree on scope and consequence |
| 2. Repair | Is the semantic layer unambiguous enough to generate queries safely? | Metric/source/grain/calendar/filter/owner map | Benchmarks reconcile at sensitive cuts |
| 3. Configure | What context should the AI receive or prioritize? | AI schema, verified answers, instructions, descriptions | Each control resolves a named ambiguity |
| 4. Evaluate | Does the experience satisfy answer contracts across wording and roles? | Golden-question results and evidence register | Critical questions pass; blockers are documented |
| 5. Operate | Who approves, monitors, and retests changes? | Approval record and lifecycle control | An owner can show when and why the model was approved |
The workflow is a Refinity implementation recommendation. The product controls within it are Microsoft features.
Pass 1: bound a consequential use case
Avoid “make the enterprise model ready for AI” as a first scope. Instead, define:
- One business use case: for example, weekly revenue performance review.
- One semantic model: the model that should answer that use case.
- One target group: for example, regional commercial leaders.
- Representative questions: direct questions, synonyms, follow-ups, ambiguous versions, and questions the system should not answer.
For each question, capture the decision it supports and the consequence of a wrong answer. “Which regions missed plan last fiscal month?” deserves a tighter contract than “Show me a fun trend.”
Scope card
| Field | Example |
|---|---|
| Decision | Allocate recovery support to regions below plan |
| Approved metric | Net Revenue vs Plan % |
| Time basis | Corporate fiscal month |
| Grain | Region × fiscal month |
| User roles | Regional leader; finance partner |
| Exclusions | Internal transfers; provisional adjustments |
| Known source | Certified performance report and benchmark query |
| Unsafe question | “Why did revenue fall?” without causal evidence |
This card becomes the boundary for every later design choice.
Pass 2: repair the semantic foundation
Declare the grain
State what one row represents in every fact-like table exposed to the question set. Test the keys that should be unique. If weekly targets and daily sales are combined without explicit allocation or aggregation logic, no instruction can make an unsafe sum defensible.
Microsoft’s model guidance recommends separating facts used for summarization from dimensions used for filtering/grouping and keeping fact-table grain consistent. Understand star schema
Make measures explicit
Create named DAX measures for consequential calculations. Hide raw numeric columns that users should not aggregate, where appropriate for the authoring model. An explicit measure does more than shorten a query: it locates business logic, formatting, and ownership in an inspectable object.
Before:
| Exposed object | Problem |
|---|---|
Sales[Revenue] with default Sum | The aggregation is possible, but its business definition and exclusions are unknown |
Orders[Margin] with default Average | Average-of-row-percentages may not equal the required weighted margin |
After:
| Exposed object | Contract |
|---|---|
[Net Revenue] | Approved inclusions/exclusions, currency basis, owner, benchmark |
[Gross Margin %] | Defined numerator/denominator, aggregation behavior, format, owner |
Microsoft distinguishes explicit DAX measures from implicit summarizations and notes that explicit measures let modelers control how values should be summarized. Star-schema measures
Resolve calendars and date roles
Document fiscal versus calendar periods, week-ending conventions, partial periods, and the role of each date relationship. If “last quarter” should mean the corporate fiscal quarter based on invoice date, encode and test that definition rather than leaving both choices implicit.
Test relationships and security
Review cardinality, filter direction, inactive relationships, many-to-many bridges, and role filters. Test as each target user—not only as a workspace administrator. Microsoft’s RLS guidance emphasizes role design and validation, and clarifies that RLS filters rows rather than hiding model objects. Row-level security guidance
Pass 3: configure the AI-facing context
1. Define the AI data schema
Select the smallest useful set of tables, fields, and measures for the target questions. Exclude technical keys, deprecated measures, raw numeric columns with unsafe defaults, and near-duplicate fields that are not meaningful to users.
Microsoft says an AI data schema defines a focused subset that Copilot prioritizes for schema-based questions. It also documents important scope limits: the AI schema does not affect every Copilot capability, and some actions require the full model. AI data schemas
Use an inclusion register:
| Object | Include? | Question served | Reason / risk |
|---|---|---|---|
[Net Revenue] | Yes | Revenue trend, variance, ranking | Owned and benchmarked metric |
Sales[Revenue] | No | None | Raw column competes with the approved measure |
Date[Fiscal Month] | Yes | Fiscal-period questions | Approved calendar label |
Date[Calendar Month] | No for this use case | None | Creates avoidable ambiguity for target users |
2. Create verified answers
Use a verified answer when a maintained report visual already represents the approved response to a common or nuanced question. Choose trigger phrases from actual user language, test their variants, and assign an owner to the source visual.
Microsoft describes verified answers as author-configured responses that can return a selected visual for matching questions. Verified answers are saved to the semantic model. Prep data for AI
3. Add AI instructions
Add short instructions for business context the schema and measures cannot fully communicate: local terminology, an organization-specific season, or a defined analysis rule. Link every instruction to a question and a test.
Good instruction:
For this model, “fiscal month” refers to
Date[Fiscal Month]. Use[Net Revenue]when the target user group asks for “revenue.”
Weak instruction:
Always be accurate, use the right data, and provide useful business insights.
The second statement has no testable interpretation. Microsoft also documents that AI instructions are model-level, not persona-specific, and have capability-specific limitations. AI instructions
4. Improve descriptions
Write descriptions that clarify business meaning, population, time behavior, and exclusions. Avoid descriptions such as “Revenue column” for a field already named Revenue.
Microsoft says descriptions currently influence DAX-query and search capabilities, rather than every Copilot behavior. Prep data for AI FAQ
Pass 4: evaluate answer contracts
For each golden question, store:
- user wording and variants;
- expected intent;
- approved measure and dimensions;
- calendar, date role, and filters;
- security role;
- benchmark result and evidence source;
- acceptable numeric tolerance, if applicable;
- required clarification or refusal behavior;
- result across repeated runs.
Example evaluation record
| Field | Value |
|---|---|
| Question | Which regions missed plan last fiscal month? |
| Variants | “Below target last period”; “last month misses by region” |
| Expected query contract | [Net Revenue vs Plan %] by Region for closed fiscal month |
| Role | Regional leader |
| Security expectation | Only assigned regions appear |
| Benchmark | Certified performance report, same refresh timestamp |
| Pass rule | Correct period, metric, population, role-filtered regions, and values within agreed tolerance |
| Safe-failure rule | Ask for clarification if “last month” could mean an open fiscal period |
Microsoft recommends known-benchmark questions, comparison to trusted reports or analyses, and before/after comparisons when validating Copilot or AI-skill output. Validate Power BI content
Do not require identical prose across runs. Evaluate the answer contract: intent, fields, calculation, filters, security, evidence, and whether the wording stays within what the data supports.
Pass 5: approve and operate
Microsoft provides an Approved for Copilot setting on the semantic model. Marking the model changes how the standalone Copilot experience treats the model and associated reports; it is not proof that every question will be correct. Microsoft says changes can take time to propagate and there is no equivalent approval setting for an individual report, dashboard, or app. Approved for Copilot
Before approval, record:
- scope and target users;
- approver and technical owner;
- last evaluation date and model version;
- critical questions and results;
- security roles exercised;
- known failures and user guidance;
- events that require re-evaluation;
- rollback action.
Trigger re-evaluation when a measure, relationship, calendar, security role, AI schema, verified answer, or instruction changes.
Microsoft product facts vs. Refinity recommendations
Microsoft product facts
- Current Power BI preparation controls include AI data schemas, verified answers, AI instructions, descriptions, testing, and Approved for Copilot.
- Preparation settings are stored at the semantic-model level.
- AI data schemas and instructions have capability-specific limitations.
- Copilot output is nondeterministic.
- Microsoft recommends evaluating results against known benchmarks.
Refinity recommendations
- Start with one consequential use case rather than tenant-wide readiness.
- Repair semantic and security defects before AI configuration.
- Require each AI configuration element to resolve a named ambiguity and pass a test.
- Evaluate contracts rather than exact generated sentences.
- Treat approval as a scoped, time-bound governance decision.
Primary CTA: See what a Power BI Copilot Readiness assessment inspects and delivers.
Related reading: