Making Data AI-Ready, Part 1
(This is the first article in a three-part series on making data AI-ready. Part 1 explains what AI-ready data actually means, Part 2 looks at the Microsoft tools that help you get there, and Part 3 explains how Prep data for AI and Fabric Data Agent instructions work together.)
Suppose you ask an AI assistant, “How many customers did we acquire last month?” Your database contains the answer, but the relevant table is called People, its identifier is Person_ID, and the date you need is First_Purchase_Dt. Would you expect someone unfamiliar with that system to immediately know which fields to use? That is the challenge you are handing to AI when you provide access to data without explaining its meaning. Before discussing models, agents, or prompts, I would start with a simpler question: What would someone need to understand this data correctly?
This goes deeper than my earlier post, Getting Your Data GenAI-Ready: The Next Stage of Data Maturity. Here is the definition I would use: “AI-ready data is data that is accurate, well-described, semantically clear, governed, accessible, and enriched with enough business context for AI to interpret it correctly.” Notice that accuracy is only the beginning. A dataset can contain valid values and still leave important questions unanswered about what those values represent. Microsoft’s guidance on preparing data for AI makes the same broader point: reducing ambiguity requires context, not just access. For generative AI, preparation means helping the system find relevant information, interpret it appropriately, and use it within the right boundaries.
Start with the quality of the data
Data cleaning still matters, and I would not skip it because a tool now accepts natural-language questions. Start by looking for duplicate records, missing values, inconsistent spellings, invalid dates, outdated information, and contradictory records. For example, counting customer rows will give the wrong answer if the same customer appears three times and your query does not account for that duplication. Decide what identifies a unique customer before removing anything, because two people with the same name are not necessarily duplicates. This is also where Master Data Management (MDM) can play an important role by establishing trusted, consistent definitions and records for core business entities such as customers, products, suppliers, and locations across multiple systems. An MDM process can help determine which customer record is authoritative, reconcile conflicting values, and create a consistent identity that downstream AI systems can rely on. Tools such as Power Query’s data profiling capabilities can help expose errors, empty values, and unusual distributions before you build an AI experience on top of them.
Standardization also needs business judgment rather than a blanket cleanup rule. Suppose one system stores customer status as A, another uses Active, and a third uses Current; map those values only after confirming that they describe the same condition. A missing revenue amount should not automatically become zero, because “unknown” and “no revenue” are different statements. Document currencies, time zones, date formats, and whether an amount represents dollars or thousands of dollars. Likewise, explain whether a margin value of 0.25 represents 25 percent, and whether a date refers to an order, shipment, or invoice. These decisions belong in the preparation process, not in whatever interpretation the AI happens to choose.
Translate the language of the business
Expanding acronyms is a practical place to start. Instead of documenting only ARR, preserve both forms: ARR — Annual Recurring Revenue, so someone asking with either expression has a clear connection to the same concept. Apply the same approach to abbreviations such as NRR (Net Revenue Retention), ASP (Average Selling Price), ACV (Annual Contract Value), and NPS (Net Promoter Score), using your organization’s actual definitions. Be especially careful with overloaded abbreviations: GM might mean Gross Margin in one dataset and General Manager in another. Descriptive names help, too: cust_id becomes Customer ID, while netrev_qtd becomes Net Revenue Quarter-to-Date. The objective is not to eliminate every abbreviation; it is to make its meaning explicit in the context where it is used.
Now return to the People table. Suppose it contains only customers who have made a purchase, not employees, prospects, or suppliers; document that definition instead of expecting the table name to communicate it. You might describe it as, “One record per purchasing customer; the technical table name is People.” Add customer, client, and buyer as synonyms only where those words really are interchangeable in this system. If the table also contains prospects, then “People means Customers” is incorrect without an additional filtering rule. This is more than renaming: you are mapping system-specific language to an authoritative business concept, sometimes called semantic enrichment or business glossary mapping.
Business definitions need similar care even when the names look perfectly understandable. Consider Active Customer, Revenue, Region, and Churn: what would you calculate for each, and would someone in another department calculate the same thing? In a hypothetical sales system, Active Customer might mean a customer with at least one completed transaction during the previous 90 days. Revenue might mean net sales after returns, while Region might mean the customer’s assigned sales territory rather than their mailing address. Write down those choices, including exclusions and time boundaries. AI instructions in Power BI provide one place to express that context, but you first need agreement on what the definitions should be.
Explain more than the column names
Metadata is where much of this understanding becomes reusable. For each important table, column, measure, or document collection, I would describe its business purpose, source system, owner, refresh frequency, and relevant limitations. Explain the level of detail: does one row represent a customer, an order, an order line, or a monthly snapshot? Include lineage so someone can trace a result back to its origins, and distinguish the authoritative dataset from an experimental copy. Microsoft’s semantic-model optimization guidance emphasizes meaningful names, descriptions, and clear modeling. A label tells you what something is called; useful metadata explains how to interpret and use it.
Relationships deserve the same attention as individual fields. In a simple example, CustomerID in Orders relates to CustomerID in Customers, while Product belongs to Category, which belongs to Business Unit. Documenting those connections tells the consumer how the business fits together, not just where its pieces are stored. Also explain whether one customer can have many orders and whether a customer can belong to more than one segment. Otherwise, a seemingly reasonable join could multiply rows and overstate a total. I would treat relationships, hierarchies, and the meaning of a row as essential context rather than details that the AI should reconstruct from similar-looking names.
Governance belongs in this discussion because useful data must also be appropriate for the person asking the question. Identify sensitive information, clarify ownership, and decide which users should have access to which datasets and results. Microsoft Purview supports the cataloging, lineage, business context, and data-quality work behind those decisions. However, a description saying “confidential” is not a substitute for enforcing permissions in the systems that serve the data. I would make authorized access part of the design from the beginning, rather than adding a sentence to a prompt and assuming the security problem is solved.
Change the data, or explain the data?
There are several ways to supply this meaning, and physically changing the production database is only one of them. You could clean values, standardize codes, or rename fields in a curated dataset, but a legacy application might depend on the original names. In that situation, leave dbo.People alone and expose an AI-friendly view such as vw_Customers, with descriptive fields and the correct customer filtering logic. A semantic model can provide another layer of business-friendly names, relationships, and calculations without requiring a production-table rename. My preference is to fix shared meaning in a reusable layer when practical, so each consuming application does not need its own explanation of the same problem.
You can also leave the data unchanged and provide metadata, definitions, or AI-specific instructions. For example, a description could explain that People contains customers and Person_ID is their unique identifier, while an instruction could explain when to use that information. With Fabric Data Agents, the supported configuration depends on the source; a Power BI semantic model follows a different path from a SQL source. The important distinction is that instructions guide interpretation, whereas cleaning changes values and a semantic layer formalizes meaning. These approaches can complement each other, but an instruction cannot make an incorrect source value correct.
Documents need preparation, too
The same principles apply to policy manuals, contracts, support articles, and other unstructured content. Use meaningful titles and headings, identify owners and effective dates, and distinguish current documents from obsolete or duplicate versions. When splitting documents into smaller passages for retrieval, preserve enough context that a passage still makes sense outside its original page. Microsoft’s guidance on document chunking explains why document structure and chunk boundaries matter. I would retain the document title, section, source link, and applicable product or customer context alongside each passage, rather than handing the AI disconnected sentences and hoping it reconnects them correctly.
Where should you start? Pick a small set of real business questions, identify the data required to answer them, and list everything a knowledgeable employee would need to explain to someone new. Then decide whether each gap needs a quality fix, a business definition, a relationship, retrieval preparation, or an instruction in the appropriate product. Test the answers against an agreed result instead of judging them only by how convincing they sound. In the next article, I will map those needs to Microsoft tools. The goal is not simply cleaner data; it is less guessing about what the data means and how it should be used.
More info:
Microsoft Fabric: AI Needs Clean Data, But What Does That Actually Mean?
The post What Does It Mean to Make Data AI-Ready? first appeared on James Serra's Blog.