Making Data AI-Ready, Part 2

(This is the second article in a three-part series on making data AI-ready. Part 1 covered the fundamentals of AI-ready data, this article looks at the Microsoft tools that support it, and Part 3 explains how Prep data for AI and Fabric Data Agent instructions divide their responsibilities.)

Making data AI-ready involves more than choosing an AI product. You need reliable values, understandable business concepts, appropriate access, and enough context for the system to answer the questions people actually ask. In Part 1, a People table containing customers illustrated the gap between storing data and explaining it. Now comes the practical question: Which Microsoft capabilities help close that gap? I would organize them by the problem they solve, rather than treating them as a shopping list where every solution requires every product.

Clean and curate the underlying data

For physical preparation, start with familiar data-engineering capabilities. Fabric Dataflow Gen2 uses Power Query to clean, shape, merge, and enrich data through a low-code experience. You could standardize customer-status codes, remove confirmed duplicates, add readable descriptions alongside abbreviated values, and write the results into curated lakehouse or warehouse tables. A useful output might be a Customers table with consistent identifiers and documented rules about which records qualify as customers. This is where you fix the actual data rather than instructing an agent to work around known problems every time someone asks a question.

Fabric notebooks provide a code-first option for transformations that need custom logic, while Data Factory pipelines can orchestrate preparation activities and their dependencies. For example, a pipeline could run ingestion, execute a notebook that reconciles customer identifiers, and then refresh the curated output. SQL views are another option when you need clearer names or filtering without changing the original production tables. I would keep the distinction clear: pipelines coordinate the work, while dataflows, notebooks, and SQL perform the relevant transformations. The value comes from the preparation you implement, not from the presence of a pipeline alone.

Give the data reusable business meaning

A Power BI semantic model is an important part of this preparation, even before adding AI-specific configuration. Business-friendly names, descriptions, relationships, hierarchies, and explicit measures turn technical storage structures into a model people can analyze consistently. In our example, the model could expose Customers even though the original table remains People, and provide a Net Sales Amount measure rather than asking each consumer to reconstruct revenue logic. I would put shared calculations in measures whenever practical. That gives reports and supported AI experiences a defined calculation to use instead of several independently written versions of the same business rule.

Microsoft Purview addresses a related question: Which data should the organization trust, and who is responsible for it? Its governance capabilities include business concepts, cataloging, ownership, lineage, and data-quality management. For our customer example, that could mean identifying the authoritative customer data product and linking it to the agreed definition of Customer. However, I would not assume that writing a glossary definition automatically inserts it into every agent’s prompt. Treat governance metadata as something your architecture must make available to the consuming experience, and distinguish catalog permissions from access to the underlying data.

Where Fabric Ontology helps

Fabric IQ Ontology, currently in preview, makes business concepts and their connections explicit. I think of it as a business meaning layer that sits above the physical data and describes the business in terms people and AI can understand. I covered Fabric Ontology in more depth in my earlier post, Understanding Fabric Ontology. Entity types describe Customer, Order, and Product; properties describe their facts, relationships connect them, and constraints clarify their meaning. You then bind those definitions to actual data instead of leaving them as a diagram disconnected from the systems people use. Its graph connects instances of those business concepts, providing a shared context layer that supported tools and agents can consume. I would consider it when several sources or teams need a consistent understanding of the same business concepts, not simply because one column has an inconvenient name.

For example, imagine a legacy table with Person_ID, Nm, Addr, and Rev_YTD. In an ontology, you could define Customer with properties such as CustomerID, CustomerName, Address, and YearToDateRevenue, then map the source fields through data bindings. Customer is the business concept; People is one physical representation of it. The mapping tells a consumer how the concept connects to the data without requiring a production-table rename. You still need correct identifiers, agreed definitions, and appropriate source preparation; an ontology does not discover the right business meaning merely because you gave it a clearer label.

The larger benefit appears when relationships span several concepts. Imagine People, SalesHdr, SalesDtl, and Prod represented as Customer places Order, Order contains Order Line, and Order Line references Product. A question such as “Which customers bought products in the Outdoor category?” now has an explicit business path to follow. Microsoft’s ontology and Data Agent tutorial demonstrates adding an ontology as a source so answers can use its definitions and bindings. This differs from repeatedly writing the same explanation in individual prompts: the business meaning layer becomes reusable across consumers that connect to the ontology, rather than each consumer having to rediscover what the underlying data means.

Add context specifically for AI

Power BI’s Prep data for AI, also documented as preview, adds three complementary capabilities to a semantic model. AI data schemas focus attention on relevant model objects, AI instructions explain terminology and analytical rules, and Verified Answers connect common questions with approved visual responses. For example, you might clarify that Revenue means Net Sales Amount and that People represents Customers. These settings belong to the semantic model rather than an individual report. They complement good modeling; they do not replace correct relationships, accurate source values, or well-defined measures. Their role is to reduce ambiguity when supported AI experiences use the model.

Fabric Data Agent configuration addresses how a particular conversational agent should work with its sources. Agent instructions can guide source selection and response formatting, while supported data-source instructions supply local business and query context. Data-source descriptions help distinguish what each source contains, and example queries demonstrate how a business question maps to valid query logic. These are related capabilities inside agent configuration, not separate products. Crucially, support differs by source type: you should not assume that an instruction mechanism available for a warehouse is also available for a Power BI semantic model. That distinction is the focus of the third article.

For supported SQL sources, schema-object descriptions provide more targeted context about individual tables and columns. You could explain that People contains one record per customer and that Person_ID is the customer identifier. This capability requires the Data Agent preview runtime, and descriptions edited in the agent do not overwrite the source object’s description. That is useful when you cannot change a shared source, but it also introduces a maintenance decision. Prefer shared source metadata where appropriate, and use agent-specific descriptions intentionally rather than creating several slightly different definitions of Customer without realizing it.

A third-party tool for measuring AI readiness

BI Pixie’s AI Readiness capability adds another useful question: How do you know whether your Power BI semantic model is actually ready for AI? BI Pixie analyzes semantic models and produces an AI Readiness score, looking for areas such as missing descriptions, ambiguous names, AI data schema configuration, AI Instructions, and implicit measures. It can also recommend improvements for review and provide benchmarking capabilities that let you test Copilot or Fabric Data Agent answers against expected results. BI Pixie is a third-party product rather than a Microsoft-native capability, so I would view it as complementary to the Microsoft tools above. The interesting idea here is that AI readiness becomes something you can assess and repeatedly test, rather than simply configuring a few settings and assuming the job is finished.

Prepare documents for retrieval

Structured analytics is only part of the picture. With Azure AI Search integrated vectorization, an indexing pipeline can retrieve content, split documents into passages, apply enrichment, and generate embeddings for vector search. An embedding is a numerical representation used to find related content; it is not a replacement for the original text or its business definitions. Think of a policy manual becoming searchable passages with titles, dates, section information, and source links. I would describe this as retrieval preparation: making the right supporting material available to an AI system when it needs to answer a question.

Retrieval choices matter alongside document preparation. Full-text search finds matching terms, hybrid search combines text and vector retrieval, and semantic ranking reranks initial results for relevance. These capabilities serve different purposes; they are not substitutes for explaining what a business term means. Azure AI Search also supports synonym maps for equivalent terms in text queries, which can help with approved acronyms or alternate names. A Fabric Data Agent can use an existing Azure AI Search index as a source, currently in preview, but that connection does not remove the need to prepare and maintain the index.

Microsoft Foundry IQ builds on Azure AI Search with reusable, configurable knowledge bases that multiple agents can share. Think of a knowledge base as a managed retrieval layer between an AI agent and the organization’s information. You connect it to sources such as OneLake, SharePoint, Azure Blob Storage, or Azure AI Search, and agents call the knowledge base when they need information. When a user asks a question, Foundry IQ can determine which connected sources are relevant, plan searches, retrieve and rerank useful content, and return grounded information with citations for the agent to use in its response. Instead of connecting every agent separately to every information source, you can create a shared knowledge base once and let multiple agents use the same prepared knowledge. For indexed sources, Foundry IQ can also automate tasks such as chunking, generating embeddings, and extracting metadata. Availability varies by feature and API version, so I would check the current documentation rather than describe the whole offering as either preview or generally available. Foundry IQ manages knowledge retrieval; Fabric Ontology models business concepts and relationships. They address different needs and can be complementary.

Choose the layer that matches the problem

My recommendation is to work backward from a specific question and a specific failure. Incorrect values call for cleaning; unclear calculations call for modeling; ambiguous terminology calls for definitions; missing document evidence calls for retrieval preparation. Use an ontology when shared concepts and relationships justify it, and add agent configuration where the consuming experience needs guidance. You do not need every tool to make one dataset useful for AI. Next, I will explain how Prep data for AI and Fabric Data Agent instructions divide responsibilities—and why the distinction matters.