TL;DR:
Microsoft's newest layer on Fabric that turns your data into a formal business model (ontology) that AI agents can understand and act upon. Still in preview with real limitations, but potentially game-changing for the right organizations.
Fabric IQ
At Microsoft Ignite 2025, Microsoft announced Fabric IQ, positioning it as the evolution from a unified data platform to a unified intelligence platform. For organizations already invested in Microsoft Fabric or considering their data platform strategy, understanding where Fabric IQ fits and when it becomes relevant is crucial for positioning and client readiness.
How did we get there
To understand Fabric IQ, we need to trace the evolution of Microsoft Fabric over the past two years. Microsoft began by addressing data silos through OneLake, creating a single, consolidated data estate. This solved the fundamental problem of fragmented data across multiple systems, giving organizations one source of truth.
However, unified data alone proved insufficient. Organizations needed to move from retrospective analysis to real-time action. Microsoft added Real-Time Intelligence, enabling streaming, analysis, and immediate response to live data.
The platform then expanded to handle spatial and relational complexity through Maps, Graph, and Digital Twin Builder. These capabilities allowed organizations to understand not just what happened, but where it happened and how disruptions cascade through connected systems. Finally, Fabric Databases enabled developers to build operational applications directly on the same platform powering analytics and AI.
At this stage, Fabric had become a comprehensive platform where data is centralized, analysable in real-time, relationally understood, and operationally actionable. Yet one critical piece remained missing.
The Semantic Gap
As data governance experts, we see the following problem constantly: data people and business people speak different languages. To put it in a slightly reductive way, data professionals think in tables, schemas, and queries. They will say things like: “Join the customers table to orders on customer_id and filter by order_date > 2025-01-01”. Business leaders think in business concepts like customers, orders, delays, and outcomes. They think about relationships and semantics, how things connect, which policies apply, what goals matter, and what actions change results. They would say things like: “which customers have not ordered recently and might churn?”. Same question, completely different vocabulary.
The real problem is that all of this business meaning traditionally lives in people's heads. Each team develops its own definitions, reports, and slice of truth. There is no shared model, no unified business language, and no way to see or optimize the business end-to-end.
This limitation extends to AI. Without semantic grounding, AI can read data but cannot truly understand your business. It cannot reason about cascading effects, constraints, or objectives. It cannot make trustworthy decisions because it lacks the context, policies, and meaning that human experts inherently possess.
Fabric IQ addresses this gap by creating a live, structured, connected model of how your business operates, expressed in the language your teams already use, but executable by AI.
Concretely, what is Fabric IQ and how to get started
At the heart of Fabric IQ is the “Ontology”, a formal model of your business that defines entity types (business concepts you want to track, like Customers or Orders), their properties, relationships, and rules, then binds them to real data in OneLake. This transforms business knowledge from people's heads into a structured, machine-readable definition that AI can understand and act upon. Once created, the ontology acts as the semantic foundation that powers other Fabric capabilities:
- Fabric data agents: Chatbots that use the ontology to answer questions in plain language. Ask "Which high-value customers have not ordered in 90 days and might churn?" and the agent consults the ontology to understand what " high-value customer" and "order" mean, finds the data, and returns results. No SQL is required.
- Graphs: Visualizes your ontology as a connected network. Navigate from Customer -> places -> Orders -> contains -> Products -> supplied by -> Suppliers. Query patterns like " show all customers who bought Product X but haven't reordered in 6 months”.
- Operations agents: Autonomous AI that monitors operations using ontology concepts. Instead of watching raw transaction streams, it understands "Customer status changed to 'at-risk' ", then alerts your sales team in Teams when high-value customers show churn signals.
- Power BI semantic models: Your existing BI layer can generate an ontology (as a starting point) or consume one (for consistent reporting). Creates a two-way bridge between traditional BI and AI-powered intelligence.
To get started, you should create an ontology, and you can do it in two ways:
- Generate from Power BI semantic models: For organizations with mature Power BI implementations, generating an ontology from existing semantic models offers the fastest path to value. In your Fabric workspace, navigate to the semantic model of your choice, click on the three dots, and select “Generate an Ontology”.
This approach automatically creates entity types for each table, establishes properties based on columns, binds static data, and replicates relationships defined in the semantic model structure.
However, this automated generation creates only the structure, not the complete working ontology. Several critical steps require manual completion. If you have time series data, you must configure those bindings separately because the generation process only handles static data from your semantic model. You need to verify that entity type keys (the unique identifiers) are correctly identified. The generation creates relationship types based on your semantic model structure, but you must still bind these relationships to the actual data by specifying which columns in your tables represent these connections. Finally, you should thoroughly review the entire ontology to ensure nothing was missed or incorrectly interpreted during the automated generation, checking that entity definitions match your business understanding, properties have the right data types, and relationships accurately reflect how things connect in your operations.
This path works best for organizations already invested in Fabric with well-constructed semantic models representing their core business domains. They can rapidly transform existing Power BI work into a richer ontology foundation while maintaining continuity with established reporting infrastructure.
- Build directly from OneLake: Organizations preferring clean-slate approaches or lacking mature semantic models should build ontologies directly from OneLake data sources. In your Fabric workspace, create a new Ontology item and start with a bounded business domain such as “customer order management” or “customer lifecycle management” with just two to three core entity types (Customer, Order, Product and Supplier).
The process involves manually defining each entity type by specifying its name, properties with their data types, and constraints. You then create bindings by pointing each entity type to specific lakehouse or warehouse tables and mapping which columns correspond to which properties.
Next you establish relationship types between your entity types, specifying how they connect and what cardinality rules apply. Finally, you validate the model by querying actual data to ensure entity types populate correctly before expanding to additional domains.
This approach suits organizations early in their Fabric adoption or those pursuing specific operational intelligence use cases not yet reflected in existing semantic models. While requiring more upfront work than generating from semantic models, it provides complete control and avoids cleanup of auto-generated content that may not match your business needs.
Regardless of starting point, organizations should adopt a pilot-first approach. Select a limited domain representing 2-3 core entity types with clear relationships. Validate that bindings work correctly, and data flows as expected. Create a simple data agent demonstrating natural language query capabilities over the ontology. Measure value delivery before expanding to additional domains.
With the ontology operational and bound to data, users gain new capabilities. They can visually navigate relationship graphs to explore connections between business entities, execute queries traversing multiple relationships (such as “show all high-value customers who haven't reordered in 90 days AND whose primary supplier has delivery delays”), and uncover cascading impacts across the business that traditional SQL queries or BI reports struggle to reveal.
Fabric data agents leverage the ontology as their semantic foundation. When users ask questions like "which customers are at risk due to supply chain disruptions in Asia" the agent consults the ontology to understand entity meanings, relationship structures, and data locations. This ontology-grounded approach ensures accurate, contextually relevant answers rather than generic responses disconnected from business reality.
What about Purview, then
A natural question arises for organizations already using Microsoft Purview. Both tools involve business concepts and metadata, so how do they differ?
Purview serves as your data governance foundation. It answers questions about documentation, accountability, and policies. Where is this data? Who owns it? What data products relate to this term?
Who has access? Purview provides a place to publish business concepts and help people discover related data products. It excels at cataloging, lineage tracking, sensitivity classification, and access control.
For example, Purview tells you: "The 'Customer' term is defined by Marketing, stored in the customers table in the sales_dw database, classified as PII, and accessible only to Sales and Support roles."
Fabric IQ operates at a different layer, focused on operational and semantic intelligence. It answers questions about how business entities relate and how tools and agents can reason over those relationships consistently across domains. Rather than documenting what exists, Fabric IQ organizes OneLake data in the language of your business and exposes it to analytics and AI with consistent semantic context.
Fabric IQ enables an AI agent to understand "Customer has relationship with Orders, Orders contain Products, analyze purchase patterns, identify Customer segments, predict churn risk, and trigger retention campaigns", then actually execute those analyses and actions.
The two are complementary, not competitive. However, while Fabric IQ handles operational intelligence, it cannot replace Purview's rich business context capabilities. Fabric IQ has technical limitations that prevent it from fully capturing business meaning (ontology names cannot contain spaces, attributes lack description fields, and the modelling is quite basic). For comprehensive business context, documentation, and governance, Purview remains essential. Think of Purview as your business dictionary and Fabric IQ as the execution engine. Both are complementary.
Who is this for then
Not every organization is ready for Fabric IQ, and understanding the signals that indicate readiness is essential for proper positioning.
Organizations asking about AI agents that make operational decisions automatically are prime candidates. If they want systems to autonomously reroute shipments, rebalance inventory, or trigger retention campaigns based on customer behavior, they need Fabric IQ's ontology to give AI business context.
Organizations asking complex cross-domain questions signal readiness. Questions like "If this supplier fails, which customers are impacted?" or "Show stores where equipment failures correlate with sales drops" require the relational reasoning that Fabric IQ enables. Traditional SQL and BI reports can't handle this easily.
Organizations with numerous Power BI semantic models in production can start fast. Fabric IQ generates ontologies from existing semantic models, so they capitalize on prior investment while unlocking AI agent capabilities.
Organization all-in on Fabric with data already in OneLake are natural fits. No migration needed, just the next step in their Fabric journey.
The Maturity Question
As Governance experts, we worry about the governance maturity prerequisites. Organizations with fundamentally disorganized data, scattered across systems with poor quality and no catalog, should address those foundational issues first. Building an ontology on unreliable data simply propagates problems at scale, and AI agents making decisions on incorrect information creates serious risk.
However, organizations already deep in Fabric with well-constructed Power BI semantic models can consider Fabric IQ even without perfect formal governance (as this is a natural continuity of their Fabric stack). Existing Power BI work demonstrates they have already done the intellectual modelling of their business. Fabric IQ can build on that foundation. Fabric IQ is the next step after basic data organization, not a replacement for it.
Limitations
All Fabric IQ capabilities remain in preview with notable limitations. The platform doesn't yet support certain advanced features, performance at scale requires validation, and organizations should expect iterative refinement as Microsoft matures the offering. Early adopters should plan for active engagement with product evolution rather than treating Fabric IQ as a finished solution.
Given the technical complexity and strategic importance of proper ontology design, we strongly recommend working with experienced practitioners when starting with Fabric IQ. Getting the semantic foundations right from the beginning significantly accelerates time to value and prevents costly rework. If you're interested in exploring Fabric IQ for your organization, reach out to discuss how we can support your implementation and make it a “first-time-right”.
