# Data readiness is a workflow question > AI data readiness is not a warehouse project. It is knowing which sources one piece of work depends on, who owns them, and what happens when they are wrong. Published: 2026-09-08 Updated: 2026-09-08 Category: Assessment “Is our data ready for AI?” is one of the first questions leaders ask, and one of the hardest to answer in the abstract. Framed that way, it tends to produce a long program: consolidate systems, clean every table, build a platform, then come back to the use case. That sequence delays the work without making it safer. Most organizations will never have uniformly clean data, and they do not need it. An AI system needs the right data for the specific work it is being asked to do—reliable enough for the consequence of getting it wrong, and owned by someone who can fix it. ## Readiness belongs to a workflow, not a company Data is not ready or unready in general. A product catalog can be perfectly adequate for search and dangerously incomplete for answering warranty questions. A CRM can hold enough history to summarize an account and still be too inconsistent to decide who qualifies for a discount. That is why readiness has to be assessed against a defined piece of work. Once [the work has decided where AI belongs](/journal/the-work-should-decide-where-ai-belongs), the data question becomes concrete: what does this workflow need to know, at what moment, and from where? ## Map the sources the work already depends on Start with the people who do the work today. Ask them what they look at before they act, and where they go when the first source is not enough. The answer is usually a mix of systems, shared documents, inbox history, and a colleague who “just knows.” For each source, record: - **What it is used for** in the workflow—answering, deciding, or acting; - **Who owns it** and can change it when it is wrong; - **How current it is** and how often it changes; - **How it is accessed**, and whether a system can reach it with appropriate permissions; and - **What people do when it is missing or contradictory.** The last item matters most. The workarounds people use when a source fails are the exceptions an AI system will meet on its first day. ## Separate authoritative from convenient Many workflows run on a convenient copy of the truth: an exported spreadsheet, a pinned message, a policy PDF from two revisions ago. People compensate because they know which copies to distrust. A system will not know unless you tell it. For every fact the system will rely on, name the authoritative source. If a price, policy, or availability window appears in three places, decide which one wins and retire or label the others. This is often the most valuable readiness work, and it is rarely technical. It is a decision about ownership. > A system cannot be more reliable than the source it is told to trust. ## Match the quality bar to the consequence Not every source needs the same standard. A system that drafts an internal summary can tolerate gaps a reviewer will catch. A system that confirms a booking, quotes a price, or updates a customer record needs a higher bar, because the error reaches someone before a person sees it. Grade each source against the action it supports: - **Inform:** used to help a person decide. Gaps are acceptable if they are visible. - **Recommend:** used to propose an action a person approves. Errors should be rare and easy to spot. - **Act:** used to complete work without review. The source must be authoritative, current, and monitored. This grading keeps a team from over-investing in data that only informs, and from under-investing in data that acts. ## Define what happens when the data is wrong Every source will eventually be missing, stale, or contradictory. Readiness includes deciding in advance what the system does then. It might ask a clarifying question, fall back to a safer answer, or stop and hand the work to a person with the context attached. These are the same stop conditions that make [escalation a product feature](/journal/escalation-is-a-product-feature) rather than an afterthought. A missing field is not only a data-quality problem; it is a designed reason to stop. Record who is told when a source fails, and how quickly they are expected to fix it. Without an owner and a response time, a known data gap becomes a permanent one. ## Readiness is proven after launch No assessment finds every gap. Real volume will surface sources nobody mentioned and edge cases nobody documented. That is expected, and it is why the first weeks of operation should be treated as part of the readiness work. Track which corrections trace back to data rather than to the system’s reasoning. Review them alongside the other [measures that matter after launch](/journal/what-to-measure-after-launch). A pattern of corrections from one source is a clear, fixable signal—far more useful than a general sense that “the data isn’t great.” ## Start narrow and make the data earn more scope The practical path is not to fix everything first. It is to choose one workflow, name its sources, fix the few that must be authoritative, design the failure path, and launch within those limits. As the evidence shows which sources hold up, the system can take on more. Data readiness then stops being a precondition that never quite arrives and becomes what it should be: an operating discipline attached to the work.