CDO Playbook
for AI Readiness

The first mistake most CDOs make when preparing for AI is starting with the data environment rather than the AI program. They assess what they have before understanding what is required. The result is a readiness picture that is accurate but not actionable — because it measures the data against general standards rather than against the specific requirements of the AI programs the organization is committing to.

Before any data work begins, the CDO needs to understand three things about the AI program: what it does, what data it requires, and what the consequences of failure are. The first question shapes the readiness assessment scope. The second determines which data domains are in scope and what quality thresholds apply. The third determines how much governance is required before deployment is appropriate.

The Decision: Anchor Every Data Activity to a Specific AI Use Case

Every quality standard, governance control, architecture decision, and remediation priority should be traceable to a specific AI use case on the roadmap. If a data activity cannot be connected to an AI program outcome, it may be good data management work — but it is not AI readiness work. The distinction matters for budget justification, sequencing, and for maintaining organizational focus on the programs that have committed timelines.

• Document the two or three highest-priority AI use cases with enough specificity to derive data requirements from them
• Identify the data domains each use case depends on — not the full data estate, just the relevant domains
• Classify each use case by its governance sensitivity: consumer-facing, regulated, safety-critical, or operational
• Confirm with the AI program owner what the deployment timeline is and what data readiness milestone is required to meet it

The most expensive decision a CDO makes is committing the organization to an AI program on a timeline that assumes data readiness that has not been verified. When the program starts and the readiness gaps surface — and they will — the remediation happens under delivery pressure, with scope that could not be planned for, and at a cost that is four to six times what upfront assessment would have produced.

A readiness assessment scoped to the target AI use cases costs a fraction of one delayed program. It produces a scored gap register that either confirms the timeline is achievable or surfaces the remediation that needs to happen before it is. Either outcome is valuable. The only outcome that is not valuable is discovering the gaps after the program is already committed and funded.

The Decision: Make Readiness Assessment a Gate, Not an Option

The CDO who establishes a standing policy — no AI program goes to detailed design or procurement without a completed, scoped readiness assessment — changes the organization's relationship with data problems from reactive discovery to proactive design input. This is not a governance overhead. It is the cheapest form of AI program risk management available.

• Establish readiness assessment as a standard stage in the AI program initiation process — before detailed design, before vendor selection, before model development begins
• Scope every assessment to the specific AI use cases in scope — not the full data environment
• Ensure the assessment output is a scored gap register and remediation roadmap, not a narrative report
• Use the gap register to negotiate AI program timelines with the business — readiness gaps are schedule inputs, not obstacles to be minimized
• Separate deployment-blocking gaps from acceptable-risk gaps in every assessment output — leadership needs to understand the distinction

The governance conversation in most AI programs happens in one of two sequences. In the first sequence, governance is designed into the data foundation before AI deployment — classification implemented, lineage tracked, access controls enforced, training data provenance documented. In the second sequence, AI is deployed and governance is addressed when a regulator, an auditor, or an incident demands it.

The CDO who controls the sequencing controls the risk profile of the entire AI program. The decision is not whether to implement AI-specific governance — it is when. Before deployment, it is a program. After deployment, it is a crisis response with an adverse finding attached.

The Four Governance Extensions AI Requires

Standard data governance covers human data access. AI workloads require four extensions that most governance frameworks have not been designed to address:

• Training data provenance: versioned, immutable record of exactly which data trained each model version — not reconstructed on request, produced automatically at training time
• AI-specific access controls: classification labels enforced at the retrieval layer for AI inference, not just at the user access layer — a model with read access can surface data in generated outputs in ways human access controls were not designed to prevent
• Output auditability: every consequential AI output traceable to its input data and model version — required for consumer-facing explainability obligations and regulatory examination readiness
• Responsible AI data inputs: bias monitoring reference datasets and drift detection baselines governed as regulated assets — monitoring programs that run on ungoverned data produce unreliable signals

One of the most common data quality program failures is launching measurement before standards are defined. The result is a catalogue of data quality findings with no basis for prioritization — because without a threshold, every deviation is equally important and none of them is definitively a problem. The remediation program that follows is undirected, has no endpoint, and cannot be connected to AI program outcomes.

Quality standards for AI need to be defined at the domain level, against the specific requirements of the AI use cases that domain supports. The completeness threshold for a fraud detection model's transaction feature set is different from the threshold for a customer churn model's demographic features. Applying a single enterprise standard to both produces standards that are simultaneously too strict for some use cases and too permissive for others.

The Decision: Define Standards per Domain, per Use Case, Before Measuring

• Define quality standards per domain before any gap measurement begins — the standard is the baseline against which gaps are scored
• Set thresholds at the feature level for high-stakes AI use cases — not all fields in a domain carry equal criticality to model performance
• Address the ML-specific quality dimensions that general frameworks miss: representativeness, temporal consistency, and data leakage absence
• Implement data contracts for every material producer-consumer relationship in your AI data pipeline — standards without contracts degrade as soon as the remediation team leaves
• Instrument automated quality monitoring against the defined standards — quality that is checked periodically is not quality that is maintained continuously

The most common failure mode in data foundation programs is not technical — it is organizational. The foundation is built correctly. The governance framework is sound. The quality standards are defined and the monitoring is instrumented. And then the external team leaves, the internal team inherits a program they were not designed to run, and quality and governance degrade within months because the operating model was not designed for the team that has to sustain it.

The CDO's job is not just to commission a good foundation. It is to commission a foundation that the existing team can maintain without ongoing external support — which requires designing the operating model alongside the technical components, not after them.

Four Operating Model Questions the CDO Must Answer

• Who owns what? Named data stewards per domain with documented accountability for quality, classification accuracy, and contract compliance — not a governance committee that reviews reports without making decisions
• What does the team maintain vs. what does the platform automate? Everything that can be automated should be. Stewardship decisions that require human judgment should be defined, bounded, and time-boxed so they do not become open-ended responsibilities
• What triggers a review? Define the signals that prompt a governance or quality review — threshold breaches, contract violations, new AI use cases, regulatory changes — so reviews happen in response to evidence rather than on an arbitrary calendar
• What does the handoff actually include? Not a governance document. Operational runbooks. Monitoring dashboard access. Contract registry ownership. A documented escalation path. And a 90-day operating period with external support available before full internal ownership transfers