Every AI initiative inherits the data estate it lands in. The model does not care that the customer table has duplicates, that the knowledge base contains three versions of the travel policy, or that nobody knows which spreadsheet is authoritative. It will read all of it, treat it as truth, and answer accordingly. Most "the AI is wrong" complaints we investigate turn out to be "the data was wrong, and the AI repeated it fluently."
What readiness actually means
Data readiness for AI is narrower and more achievable than enterprise data governance. You do not need a pristine warehouse. You need the specific data your first use cases will touch to be findable, current, permissioned, and owned:
- Findable: the systems of record are identified, and there is exactly one authoritative source per fact. Where duplicates exist, one is declared the winner.
- Current: obsolete documents are archived or marked superseded. Retrieval systems are ruthless about surfacing whatever exists; expired content must be removed from their reach, not just forgotten.
- Permissioned: access rules exist in a form an application can enforce. An assistant that answers from documents must not become a bypass around the permissions on those documents, and salary data leaking through a chatbot is the canonical failure.
- Owned: a named person can answer "is this field reliable?" and "who fixes it when it is wrong?" for each source the use case touches.
Scope readiness to use cases, not the enterprise
The multi-year "fix all the data first" program is where AI ambitions go to die, and it is unnecessary. Invert it: pick the first two or three use cases, list the data each one actually needs, and make just that data ready. A support assistant needs the product docs and ticket history, not the ERP. Readiness scoped to a use case is weeks of work, it delivers something visible, and each project leaves the estate slightly better for the next one.
The unglamorous checklist
- Inventory the sources the use case touches and name an owner for each.
- Fix identity: agree on the keys that connect a customer or product across systems, because context assembly lives on those joins.
- Cull the knowledge base: delete or mark superseded content, add dates and owners to what remains. For retrieval, curation beats volume every time.
- Write down the sensitivity classes (public, internal, confidential, personal data) and what each is allowed to flow into, including which model providers.
- Wire freshness: decide how updates in the source reach the AI system, on what delay, and what stale looks like on a dashboard.
Privacy is part of readiness, not a veto at the end
If personal information will flow through prompts, logs, or an index, the privacy questions belong in the readiness work: what is the lawful basis and disclosed purpose, does the vendor agreement cover this processing, what gets redacted before it leaves your boundary, and how do retention rules apply to prompt logs. Answering these early is cheap. Discovering them from a regulator's letter or a customer's diligence questionnaire is not.
A useful first test
Ask three people in the relevant department where the authoritative version of a key document or customer fact lives. If you get three answers, that is the readiness gap, stated precisely, and it is fixable in weeks. Data readiness is not a platform purchase; it is a set of decisions, written down and enforced, about truth, ownership, and access, made for exactly the data your AI will touch first.