Data Readiness for AI: Which Tests Must a Dataset Pass?
Quick Answer
Before an AI assistant accesses a dataset, it must pass four distinct tests: ownership, quality, access, and context. Ownership and access are gates; quality and context are conditions that narrow scope rather than halt it. An assistant pointed at the wrong table will answer fluently but incorrectly, leaving the meeting unable to identify which table caused the error or why.
Key Takeaways
Before an AI assistant accesses a dataset, it must pass four tests: ownership, quality, access, and context. Ownership and access are gates; quality and context are conditions that narrow scope rather than halt it.
A name on the register is not the owner’s recorded yes for this table being read this way. The authorization record has six fields: dataset, use case, stated purpose, accountable approver, approval date, and lapse condition.
A product-level data quality score can look healthy when the one column the model reads is the weak one. Read per-column scores. For AI, uniqueness, freshness, and completeness deserve special attention because their failures are invisible in generated text.
For multi-audience AI, prefer user identity mode: the boundary an auditor is shown is then the platform’s role list and not the code the team wrote. OneLake defaults to deny, and new roles must explicitly remove users from DefaultReader.
Definitions written for one use case are part of what the next use case inherits, which is why the context test scales even though the first pass is the expensive one.
Ownership and access are gates; quality and context are conditions that narrow scope rather than halt it.
Why Readiness Is a Per-Use-Case Decision
An AI assistant pointed at the wrong table will answer fluently and incorrectly, and the meeting after will not be able to say which table caused it or why. The four tests below are the checks that happen before that meeting exists: one dataset admitted to one AI use case, on whose authority, against what baseline, read by which identity, and with what meaning attached to its columns.
Ownership and access function as gates; a failure stops the use case. Quality and context function as conditions; a failure narrows scope rather than halting it. Reading the four in that order keeps the argument in the right place: at whether the use case is allowed to proceed, before it is at whether the numbers are close.
The Four Readiness Tests, at a Glance
Test
Question
Pass criteria
Evidence location
Ownership
Who authorized this dataset for this use case?
One accountable person recorded approval for this specific consumer and purpose
Ownership register plus data product fields in Microsoft Purview Unified Catalog
Quality
What must be accurate for this use case?
Written baseline at column level with floor threshold and stated consequences
Per-column data quality scan results in Purview Unified Catalog
Access
Which identity reads the data and how far does it reach?
Identity named with reach documented and dated from platform permission surface
OneLake security roles pane on Fabric item or admin permission surface
Context
Can a model interpret columns without human explanation?
Every column has definitions usable by newcomers; ambiguous columns mapped to single concepts
Glossary terms and critical data elements in Purview Unified Catalog
Ownership: A Name Is Not the Same as an Authorization
A name is who to email when it breaks. An authorization is what an auditor asks to see. Fewer people can produce a record of the accountable person agreeing that this table may be read by this assistant, for this purpose, on terms they set. That record is the readiness artifact.
The authorization record has six fields.
The authorization record has six fields: dataset, use case, stated purpose, accountable approver, approval date, and lapse condition. The lapse condition is the field most often skipped and the one that prevents assumptions about reuse. A pilot approval for twelve users is not a production approval for four hundred, and the record has to say so.
Quality: One Score Is Not Enough
Product-level data quality scores hide column-specific problems. A dataset scoring well overall can be weak in the exact column the AI model depends on, and a score that looks healthy on average is silent on that. For AI systems, three dimensions deserve renewed attention because their failures are invisible in generated text.
Uniqueness. Duplicates appear as two visible rows in a report but as competing answers in an AI response, and the assistant will pick one without telling anyone which.
Freshness. Stale data reads identically to current data in generated prose. A number from last quarter and a number from last week produce the same sentence.
Completeness. Missing values disappear from AI outputs entirely, unlike blank cells that an analyst notices.
Each column baseline runs to three lines: the dimension that matters, the floor threshold, and the breach consequences. That third line, often omitted, names who suspends or narrows the use case when the threshold fails. Purview alerts notify owners and stewards of quality misses, but that notification path excludes the assistant and its readers, and the baseline closes that gap.
Governance Skills Are Scarcer Than Prompt Skills
The market is full of people who can build an agent and short on people who can make one defensible. i3solutions’ senior specialists bring Microsoft platform depth and regulated-industry delivery to AI work that has to survive review.
Two architectural shapes exist, and the choice decides where the audit lives.
Two architectural shapes exist, and the choice decides where the audit lives.
User identity mode: the AI reads as the requestor, and answers are bounded by what that person could access themselves.
Delegated identity mode: the AI reads through a service identity against a curated set, and the boundaries live in custom code rather than in platform roles.
For regulated environments and multi-audience use cases, user identity mode is preferable, because the boundary an auditor is shown is then the platform’s role list and not the code the team wrote. Two habits make this hold. OneLake defaults to deny access; new roles must explicitly remove users from DefaultReader, and reviewing only the new narrow role misses that users remain in the wide default. Verify both the new role and the removal in the same access review.
Context: What the Model Cannot Ask About
Models need business meaning for columns they cannot ask about. A status column such as STAT_CD, holding A, I, and P, gets an answer composed around a guess, and the guess reads exactly like knowledge.
Two Microsoft Purview objects hold this work. Glossary terms carry business definitions with access and handling policies attached. Critical data elements group logical columns for stronger governance and hold the concept mappings that let a model reconcile CustID and CID as one Customer ID rather than two. A model asked to reconcile them without those mappings will do so silently.
Definitions require joint ownership. The domain owner supplies the meaning; the analyst supplies the columns; and that pairing is what makes the definition durable, because a definition owned by one side alone is a definition that stops being updated the first time the other side changes something.
Scaling Considerations
Four tests per use case scales initially. The eventual cost lands on context: building glossary terms, documenting allowed values, and mapping concepts is real work. This work scales because definitions written for one use case are part of what the next use case inherits, and by the third use case the marginal cost of context has dropped materially.
Prerequisites Before Running These Tests
Three situations require earlier work. If the use case has not identified which datasets it reads, the four tests have no targets. A wish is not a consumer; all four tests require a described AI application, one that names a user, a task, and an output. And where system-of-record disagreements predate AI, resolve them first, because a readiness verdict rendered against an unsettled source of truth is a verdict that will be overturned quietly.
Relationship to Data Pipeline Operations
Data readiness is different from pipeline operations. Pipeline operations covers continuous running of estates: who owns the number, what happens when the run fails, who is called at 2am. Readiness is a one-time decision per use case, asking whether one dataset is admitted to one AI use case, on whose authority, against what baseline, read by which identity, and with what meaning attached to its columns. The operating model feeds readiness decisions; readiness verdicts become stale if pipeline failures go unnoticed.
Michael Branson
Founder/COO
Michael Branson co-founded i3solutions 30 years ago and brings executive, operational, and technical perspective to organizations working in complex, secure, and mission-critical environments. His insights focus on business process consulting, automation, data analytics, collaboration, secure operating models, and the operational discipline required to turn technology investments into practical business systems with measurable value.
Run four tests per dataset per use case: ownership (yes in the register for this consumer and purpose), quality (per-column baseline with threshold and breach action), access (named identity with reach from platform permissions), and context (usable definitions with concept mappings). Settle ownership and access gates first. Begin with the datasets one described use case reads, because none of the four criteria can be scoped until the consumer is described.
A product-level score can look healthy when the one column the model reads is the weak one. Read per-column scores for relevant columns rather than product aggregates. Uniqueness, freshness, and completeness warrant special attention for models because their failures are invisible in generated text. Baseline runs to three lines per column: dimension weight, score threshold, and breach action naming who suspends the use case.
One named accountable person must authorize each consumer for a stated purpose on stated terms. A name on the register is not the owner's recorded yes for this table being read this way. Microsoft Purview supplies the authorization home through access policies on data products, and the record has six fields: dataset, use case, stated purpose, accountable approver, approval date, and lapse condition.
Models cannot ask colleagues what values mean. Context includes meaning (what a value represents), allowed values (explicitly spelled), and what the column excludes. A status column such as STAT_CD, holding A, I, and P, gets an answer composed around a guess, and the guess reads exactly like knowledge.
For multi-audience scenarios, use user identity mode so answers remain bounded by individual access rights. This keeps audit trails on the platform's role pane rather than in custom code the team wrote. Verify both new roles and removal from DefaultReader in the same access review, because OneLake defaults to deny and new roles must explicitly remove users from DefaultReader.
Data readiness decides one-time admission of a dataset to a use case per authority and baseline. Pipeline operations manage continuous estate running. The operating model is an input to that decision, because the ownership test reads the register that model keeps, and readiness verdicts become stale if pipeline failures go unnoticed.
An Ungoverned Agent Is an Unowned Risk
Every agent in the estate answers for what it can reach, what it can do, and who approved it. i3solutions' senior AI advisors work with IT leaders who need that record built and enforced before an auditor asks for it.
