AI-Ready Semantic Models in Microsoft Fabric
Copilot and Fabric Data Agents answer from your semantic model's metadata, so preparing the model is the real AI work. A persona-mapped, flowchart-driven guide with brownfield and greenfield checklists.
TL;DR
In Microsoft Fabric, Copilot and Data Agents build their answers from your semantic model's metadata, the table and column names, descriptions, synonyms, relationships, and measures, not from the raw rows underneath. So the quality of an AI answer is capped by how well the model describes itself, and "AI-ready" is something you engineer into the model, not a switch you flip.
- The metadata is the interface. Descriptions are the highest-impact element. A model with business-friendly names and 90%+ description coverage beats a larger, cryptically-named one.
- Prep for AI is the control surface. Four features: AI Data Schema (pick what AI can see), AI Instructions (how to read it), Verified Answers (deterministic answers to top questions, up to 250 per model, 15 trigger phrases each), and Descriptions.
- Readiness is a team sport. Developers, architects, data engineers, stewards, and admins each own a slice. The persona map below shows who owns what.
- Validate before you trust. Test in the sandbox, then measure against a ground-truth set. AI-generated DAX is probabilistic, so accuracy is measured, not assumed.
Why the model is the AI surface
Every AI experience in Fabric that answers a business question routes through the semantic model. Copilot in Power BI turns a natural-language question into a DAX query using the model's metadata plus its Prep for AI configuration. A Fabric Data Agent does the same across more sources, translating questions into DAX, SQL, or KQL. Publish that agent into Microsoft 365 Copilot and the same model answers questions from Teams or Word. None of these read your data to decide what a question means. They read the description of your data and generate a query from it.
The practical consequence: the highest-leverage AI work in Fabric is making the model legible, well ahead of prompt engineering or agent orchestration. DIM_GEO_01 tells an agent nothing; Sales Region with a one-line description tells it what the column is, what it filters, and how a person would ask about it.
Who owns AI-readiness
Readiness is rarely one team's job, and treating it as "the BI developer's problem" is why so many models stall halfway. Each slice has a natural owner, and a model is ready only when every row below is satisfied.
| Persona | Owns in model prep | "Done" signal |
|---|---|---|
| Semantic model developer | Names, descriptions, measures, relationships, and the Prep for AI configuration | Schema trimmed, 90%+ descriptions, relationships complete |
| Analytics architect | Domain scoping, naming standards, endorsement and promotion gates | Models are domain-sized; standards documented and enforced |
| Data engineer | Upstream data quality, star schema, grain, and freshness | Clean grain, no unexpected nulls in filter columns |
| Data steward / business SME | Business term definitions, synonyms, and the questions Verified Answers must cover | Top questions verified and reviewed for business correctness |
| Governance / admin | Tenant settings (regions, cross-geo), RLS/CLS, Copilot enablement and capacity | Permissions enforced; Copilot enabled per policy and budget |
The pattern to notice: the developer owns the mechanics, but the steward owns the meaning. A model can be technically immaculate and still give confidently wrong answers if no one who understands the business validated what "revenue" means.
How to prep a model
The work is the same loop whether the model is new or existing. Only the entry point differs: a brownfield model starts with an honest inventory, a greenfield model starts with a domain-scoped design. From there the path converges, and the accuracy gate at the end is a loop, not a finish line.
Three stages carry most of the outcome. Enriching metadata is the highest return on effort: descriptions written for a business reader, cryptic names fixed or given synonyms, and relationships repaired, since a missing join is a leading cause of wrong DAX. Configuring Prep for AI is where you set the boundary: the AI Data Schema decides what AI can even see, and a smaller, sharper schema is both more accurate and faster than exposing the whole model. Validating is non-negotiable, because AI-generated DAX is probabilistic and complex time-intelligence questions are where it fails. Test questions in the sandbox first, then measure against a ground-truth set of known-good answers, weekly and on every model change; Microsoft's Data Agent evaluation SDK (preview) automates that measurement.
Warning
Region and compliance. The Azure OpenAI service behind Copilot runs only in US datacenters and the EU data boundary. If your capacity is elsewhere, Copilot is off by default until an admin enables the cross-geo processing tenant setting, which carries data-residency implications worth reviewing first. Copilot is also all-or-nothing per workload: you cannot enable it for one experience and disable it for another.
Checklists
Same destination, different starting work. Use whichever matches the model in front of you.
Brownfield: preparing existing models
- Inventory each model: storage mode (Import, DirectQuery, Direct Lake), table count, and description coverage
- Prioritize the models actually exposed to Copilot or agents; do not boil the ocean
- Rename cryptic tables and columns where safe; add synonyms where a rename would break reports
- Backfill descriptions to 90%+ of tables, columns, and measures, in a business reader's voice
- Repair missing or ambiguous relationships before anything else
- Configure Prep for AI: trim the AI Data Schema to the exposed subset, write AI Instructions, add Verified Answers for top questions
- Test questions in the Copilot chat pane before publishing
- Mark the model Approved for Copilot and endorse it (Promoted or Certified)
- Attach a Data Agent, align its source tables to the AI Data Schema, and confirm users have Read plus that RLS/CLS holds
- Validate against 50+ ground-truth pairs, then schedule weekly drift checks
Greenfield: designing for AI from day one
- Scope each model to one domain, 15 to 25 tables; compose multiple agents rather than build a monolith
- Set business-first naming standards before development starts (singular nouns, self-documenting measures)
- Make descriptions a definition-of-done, authored as objects are built; Copilot can draft measure descriptions from the DAX to speed it up
- Enforce a star schema with clear grain, and validate upstream data quality first
- Choose Direct Lake, and configure Prep for AI in the Power BI service, not in Desktop
- Build Verified Answers and AI Instructions into the model, not as an afterthought
- Version metadata as code with TMDL and Git; use the Power BI Modeling MCP server to bulk-generate descriptions and synonyms
- Add an AI-accuracy gate to the promotion path (dev to test to prod)
- Design for multi-surface consumption, report and natural-language Q&A, from the start
- Plan Copilot and AI-meter capacity from day one
Where this fits
Semantic-model prep is the foundation, and it sits inside a wider surface worth knowing. Copilot is embedded across Data Factory, Data Engineering, Data Warehouse, and Real-Time Intelligence, each grounded in item-level metadata. AI Functions (generally available) bring one-line LLM enrichments like ai.classify and ai.summarize to notebooks, with a preview set now in Data Warehouse via T-SQL. Fabric IQ (preview) is Microsoft's direction for shared business semantics, spanning ontology, the Power BI semantic model, Fabric Graph, Plan, Data Agents, and Operations Agents, with ontologies now exposable through a Model Context Protocol endpoint so outside agents can ground on them. Every layer rewards the same discipline: the better the model describes itself, the better everything above it performs.