Data & Knowledge Platform Readiness Playbook

1. Scope of this playbook

This playbook is for architects and data leaders assessing whether their organization's data estate can actually support production AI — RAG systems, agents, and analytics alike. It sits underneath the rest of this series: the Enterprise RAG, MCP, and AI Memory Architecture playbooks all assume a baseline of data readiness that this playbook is about establishing. It does not cover model selection or agent orchestration; it covers whether the data those systems depend on is trustworthy, accessible, and well-described enough to use.

2. Data & knowledge platform maturity model

Self-assessment checklist

• Can you name, for your most business-critical data domain, who owns it and how current it is, right now?
• If an agent or RAG system needed to query that data, would it get an accurate, well-scoped answer, or would it need a human to interpret ambiguous or stale fields first?
• Is there a consistent access-control model across data sources, or does every new AI use case require custom permission work?
• Do your data domains have enough semantic metadata (definitions, relationships, business context) for an AI system to use them correctly without a human translating first?
• When a data quality issue causes an AI system to produce a wrong answer, can you trace it back to the source, or is the investigation close to starting from scratch?

3. Is dedicated readiness work worth it now?

If you're piloting a single, narrowly scoped AI use case against one well-understood data source, informal readiness (a manual review before the pilot starts) may be enough. The case for a dedicated readiness program strengthens once you have multiple AI initiatives competing for the same underlying data, or once a pilot's results are questioned because nobody can vouch for the data behind them.

Given that the gap between "running AI initiatives" (97%) and "having AI-ready data at scale" (5%) is this wide, most enterprises are already past the point where informal readiness is sufficient — the risk is discovering that the hard way, mid-scale-up, rather than addressing it deliberately now.

4. Readiness checklist

• A data catalog exists (or is being built) covering the domains your priority AI use cases depend on, with named owners per domain.
• Data quality is measured, not assumed — even a basic completeness/freshness/accuracy scorecard per domain is a meaningful start.
• Access controls can be enforced at a granularity that respects both human and AI/agent access patterns, not just broad role-based buckets built for human users.
• A semantic layer or glossary exists (or is planned) so AI systems can resolve business terms and relationships consistently, not per-application.
• There's an agreed process for onboarding new data sources that includes an AI-readiness check, not just a technical integration check.

5. Build vs. buy

6. Phased rollout playbook

Phase 0 — Assessment

Score your priority data domains against the maturity model above. Be honest about Level 0 territory — most organizations have more of it than they expect, and knowing where it is matters more than the overall average score.

Phase 1 — Pilot domain

Bring one business-critical domain to AI-ready status: catalog it, establish quality monitoring, add semantic metadata, and validate that a real AI use case (RAG or agent) can consume it correctly. This proves the pattern before scaling it.

Phase 2 — Production hardening

Extend the pattern to the domains behind your next wave of AI initiatives, and formalize the onboarding process so new data sources meet the bar by default rather than by exception.

Phase 3 — Scale-out

Move toward self-service onboarding against a template that enforces readiness standards automatically, so the data team isn't a manual bottleneck for every new AI use case.

7. Governance & risk checklist

• Every data domain feeding an AI system has a named owner accountable for its quality and currency.
• Data quality issues that cause AI system errors are logged and traced back to source, feeding a continuous improvement process rather than one-off fixes.
• There's a review cadence for the semantic layer/glossary so definitions don't silently drift out of sync with how the business actually uses the terms.
• Changes to source data schemas or definitions trigger review of downstream AI systems that depend on them, not just the systems that directly consume the change.
• Data lineage is auditable — for any AI-generated output, you can trace back to the source data that informed it.

8. Security checklist

• Access controls are enforced at the data layer, not just the application layer — an AI system's access should be scoped as tightly as the least-privileged human doing the equivalent job, not broader by default.
• Sensitive and regulated data is classified and separated from general-purpose data made available to broad AI/RAG consumption.
• Data used for AI training, fine-tuning, or retrieval is handled per your data-classification and retention policy — AI use doesn't exempt it from existing rules.
• Data quality monitoring includes checks for poisoned or manipulated data, not just accuracy and freshness — a data source that feeds a RAG or agent system is now part of its attack surface.
• Third-party data platforms and catalogs with access to enterprise data are vetted with the same rigor as any other vendor with broad data access.

9. Cost model & ROI

The ROI case is strongest when framed against pilots that failed or stalled for data reasons — readiness investment converts "we don't know why this didn't scale" into a fixable, visible problem.

10. Organizational playbook

A data platform or data governance team should own the catalog, quality monitoring, and semantic layer infrastructure. Domain teams (finance, product, operations) should own the quality and definitions of their own data, since only they know what "correct" actually means for their domain. AI/platform teams should be a demanding customer of this function, not a substitute for it — teams that try to solve data readiness inside each AI project individually are the clearest source of the fragmentation this playbook exists to prevent.

11. Common failure patterns

• Pilot-scale blindness: a successful pilot against clean, hand-picked data creates false confidence that the broader data estate is ready, when the pilot's data was actually an exception.
• Catalog without quality: cataloging data without measuring or improving its quality, so teams can now find data they still can't trust.
• Semantic gap: data that's technically accessible but lacks the business context an AI system needs to interpret it correctly, producing confidently wrong answers.
• Governance-as-paperwork: ownership and access policies that exist on paper but aren't enforced technically, so the same fragmentation persists in practice.
• One-and-done readiness: treating a domain as "done" after an initial readiness push, without a process to keep it current as the business and its data change.

12. Data & knowledge platform readiness scorecard

A domain that scores well on catalog coverage but poorly on quality and semantic context is discoverable, not usable — AI systems need both. Weight accordingly, and prioritize the domains behind your highest-value AI initiatives first.