Data Readiness Check by AI Pattern

The number one reason AI implementations fail in the first 90 days is a data readiness gap nobody audited in the planning phase.

Not wrong pattern choice. Not vendor failure. Not lack of team buy-in. A gap between what the pattern needed and what the data actually was, found three months after budget was committed. Gartner's February 2025 research on AI-ready data puts a number on this: 63% of organizations either do not have, or are unsure whether they have, the right data management practices for AI, and Gartner predicts organizations will abandon 60% of AI projects unsupported by AI-ready data.

This article is the audit. Run it before you sign a contract, before you kick off an implementation, before you announce the deployment. Each pattern has different minimum data requirements and different failure modes when the data falls short. Generic advice about "making sure your data is clean" isn't useful here. This is specific. The broader context for why this matters is in data readiness: the prerequisite most AI projects skip, and the full data taxonomy is in the 7 types of data that power business AI.

What data readiness means per pattern

Five dimensions, assessed per pattern:

Availability: Does the data exist somewhere in your organization? If the answer is no, you have a data gap, not a readiness gap. The pattern isn't deployable until the data exists.

Quality: Is the data accurate, complete, and consistent enough for the pattern's purpose? Quality requirements vary by pattern. A RAG Assistant needs non-contradictory documents. A scoring model needs outcome labels on historical records. An Anomaly Agent needs a clean, uninterrupted baseline stream.

Access: Can the AI system actually reach the data? Technically accessible and organizationally accessible are different things. Legal, security, or compliance restrictions can block access to data that exists and is high quality.

Freshness: Is the data current enough to be useful for this pattern? A RAG Assistant on 2-year-old policies gives confidently wrong answers. A scoring model trained on deal data from before your last product pivot scores against patterns that no longer apply.

Volume: Is there enough data to build a reliable baseline, train a meaningful model, or provide sufficient context? Some patterns have specific minimum volume requirements. Most operators underestimate how much historical data a Predict-based pattern needs to produce reliable outputs.

Key Facts: Data Readiness and AI Failure

• 63% of organizations either do not have, or are unsure whether they have, the right data management practices for AI. (Gartner, February 2025)
• Gartner predicts organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026, regardless of model or vendor selection.
• 99% of AI and ML projects encounter data quality issues during implementation, with data quality remediation costing enterprises an average of $12.9 million annually. (SpaceO Technologies, 2026)

RAG Assistant

The critical dependency: A well-maintained, non-contradictory knowledge base.

Minimum requirements:

• Documents are findable and indexable (not locked in file formats the RAG system can't process, not scattered across inaccessible shared drives)
• No two documents actively contradict each other on the same topic
• Documents include metadata for filtering: date created or updated, topic or department, whether a document is current or superseded
• At least 80% of documents reflect current policy and process (not what was true 12-18 months ago)

Common gaps:

• Conflicting policy documents. A benefits guide from 2023 and an updated one from 2025 coexist, and the system may retrieve either.
• Undated content. The RAG system can't filter by freshness if documents have no date metadata.
• Poor document structure. Long, unstructured PDFs with no headers produce poor retrieval. The system can't find the relevant section within a 40-page document if there are no anchor points.
• "Shadow knowledge" that lives in Slack threads, email chains, or people's heads, not in documents. The RAG system is only as good as what's in the index.

Readiness test: Ask a new employee to find the answer to five policy questions using only the documents you'd feed the RAG system. If they find conflicting answers, or can't find answers at all for questions that should be covered, you have a knowledge base quality problem. Fix the knowledge base before deploying.

Scoring and Routing

The critical dependency: Labeled historical outcomes.

Minimum requirements:

• At minimum 12 months of historical records with outcome labels (leads marked won/lost, tickets marked resolved/escalated, applications marked hired/not-hired)
• Minimum volume typically 1,000+ labeled outcomes for a reliable scoring model. Fewer records produce an unreliable model that will need significant calibration time.
• The data period needs to reflect your current business model. If your sales process, ICP, or product changed significantly 18 months ago, data from before that change is likely misleading, not helpful.
• Key features used in scoring (company size, industry, deal stage, product) need to be present on at least 70% of records. High nulls on key features degrade model quality.
• Win/loss reason codes (if using for coaching or routing improvement) need to be at least partially populated and consistent.

Common gaps:

• No outcome tracking. The most common gap: deals exist in the CRM, but no win/loss field was required. The model has nothing to train toward.
• Biased historical labels. If your historical data was generated under a previous routing system that favored certain reps or segments, the model learns the bias, not the ground truth.
• Sparse data for newer segments. If you entered a new market 6 months ago, you don't have enough outcome data from that segment to score it reliably. The model will default to patterns from your older segments.
• Stale data. Using training data from 3 years ago when your sales motion has evolved produces a model that's confidently wrong about your current patterns.

"Scoring models deployed on CRM datasets where outcome labels are present in fewer than 70% of records produce scoring noise, not signal. The model outputs confident numbers that don't correlate with win probability. High-scored leads close at the same rate as low-scored ones. The problem isn't the model. The training data didn't have enough signal to learn from." (Rework CRM Data Readiness Analysis, 2026)

Readiness test: Pull 100 historical records at random. What percentage have a win/loss outcome label? What percentage have your five most important feature fields populated? If either answer is below 70%, you have a data completeness problem to solve before training a meaningful scoring model.

Vision Extract

The critical dependency: Document quality and format coverage.

Minimum requirements:

• Image resolution sufficient for OCR (typically 200 DPI minimum; 300 DPI recommended for documents with small text)
• Document formats representative of the full variance you'll process in production. A model trained on clear digital invoices will fail on scanned invoices from the same vendor if the scan quality varies.
• Labeled training samples for any document format that differs significantly from standard (custom forms, non-English invoices, industry-specific layouts)
• Consistent target field structure. If the same information (vendor name, invoice number, total amount) appears in different positions across document variants, the model needs training samples covering each variant.

Common gaps:

• Mixed document formats from multiple vendors where each vendor uses a different invoice template. The base model handles standard invoices well but fails on the 15% of non-standard formats.
• Handwritten annotations. Typed text OCR is mature and reliable. Handwritten text OCR is significantly less reliable. If your documents contain handwritten fields or annotations, flag this explicitly during vendor evaluation.
• Scanned at angles. Documents scanned slightly off-axis produce degraded OCR accuracy. This is common when documents are processed through multi-function office printers.
• Dark or low-contrast scans. Faded ink, poor scan exposure, and colored paper all reduce accuracy.

Readiness test: Collect 50 representative documents from your production queue, including all the edge cases (different vendors, different formats, different scan qualities). Run them through any vendor's demo or trial. Note where the extraction fails. If failures are concentrated in formats you see regularly, you need either a better model or custom training data before deployment.

Meeting Intelligence

The critical dependency: Consistent recording access and CRM data quality.

Minimum requirements:

• Recording enabled on the meeting platform (Zoom, Teams, Google Meet) with participant consent documentation in jurisdictions that require it
• Audio quality sufficient for transcription. Calls recorded primarily through speakerphone, noisy environments, or low-bandwidth connections produce poor transcripts.
• Speaker diarization (knowing who said what) requires at least two distinct audio channels or reliable speaker identification. Merged single-channel audio confuses speaker attribution.
• CRM contact and account records associated with participants. Meeting Intelligence tools that can't link a call to a deal or account produce summaries that are useful for the individual meeting but can't contribute to deal analytics or coaching analysis.

Common gaps:

• Inconsistent recording policies across the team. If only 40% of calls are recorded, your Meeting Intelligence data reflects the most compliant reps, not the team as a whole.
• No CRM-to-call linkage. Calls that aren't connected to CRM records exist as isolated summaries. They can't feed into Scoring + Routing, deal health analysis, or coaching.
• Unclear consent practices. In two-party consent jurisdictions (most US states, most EU countries), recording without notice creates legal risk. Many teams discover their recording practice has a compliance gap when they try to deploy a Meeting Intelligence tool.

Readiness test: Pull your last 50 sales calls. What percentage were recorded? What percentage of those recordings are linked to a CRM record? If recording coverage is below 70%, solve the policy and technical linking problem before deploying. Partial data produces misleading analytics.

Anomaly Agent

The critical dependency: A stable, long-enough baseline.

Minimum requirements:

• Minimum 60-90 days of clean, uninterrupted data before going live with alerts. Businesses with seasonal patterns need a full year to establish what "normal" looks like across all seasonal variations.
• Data granularity matched to the anomaly you're trying to detect. Fraud detection on transactions needs per-transaction data. Manufacturing anomalies on an hourly production line need hourly sensor readings. Daily rollups won't catch intra-day anomalies.
• Data stream consistency. A metric that changes instrumentation mid-stream (different units, different sampling rate, different field names) creates artificial anomalies at the instrumentation change. Clean up stream changes before establishing baseline.
• No data gaps larger than the natural measurement interval. Gaps in the stream look like anomalies to the model, or worse, mask real anomalies that happen during the gap.

Common gaps:

• Insufficient baseline length. Two or four weeks of data is not a baseline. The team deploys, everything looks anomalous in week three, alert fatigue sets in, and the deployment gets disabled. This is the most common Anomaly Agent failure mode.
• Seasonal data without seasonal adjustment. A retail company's transaction volume looks anomalous in November if the baseline doesn't account for the holiday ramp. The model needs to learn seasonality before it can flag deviations from seasonal norms.
• Mixed data sources with different schemas. If your metric stream combines data from two systems that define the same event differently, the model learns inconsistent patterns.

Readiness test: Run the model in observation mode for 90 days before enabling any alerts. Each day, review the items it flags. If more than 30% are obviously not anomalous (explainable by context you have), the baseline isn't established. Keep observing.

Generative Research

The critical dependency: Source accessibility and citation fidelity.

Minimum requirements:

• Direct API access or reliable scraping access to the sources the research needs to cover
• Consistent update cadence: sources that update faster than the index will produce research citing stale information
• A defined citation standard: each claim in output needs a traceable source citation, not just a paraphrase
• Human review gate before any research output is distributed externally or to senior decision-makers

Common gaps:

• Sources behind paywalls that the system can't access. The model either hallucinates content it "expects" to find there, or simply omits that source without flagging that it's missing.
• Index freshness lag. For competitive intelligence, a research tool that indexes sources weekly will miss product launches and announcements from the current week.
• No audit trail. If a team distributes research output and a fact turns out to be wrong, there's no way to trace where the error originated if source citations aren't logged.

Readiness test: Submit five research questions where you already know the answers (recent competitor product launches, recent industry statistics). Check whether the tool's answers are accurate and whether each claim has a traceable citation. If accuracy is below 80% on known facts, the source access or generation quality isn't ready for production use.

Document Review

The critical dependency: A reference standard to compare against.

Minimum requirements:

• A template or standard library: for contract review, this means your standard NDA, MSA, vendor agreement, and any custom addenda. The AI identifies deviations from this standard, so the standard needs to exist.
• Document format accessibility: PDFs need to be text-layer PDFs, not image PDFs. Image PDFs require OCR pre-processing, adding complexity and potential error.
• Vendor data handling review: contracts often contain confidential terms, customer names, and financial obligations. The vendor's data handling policies need to be reviewed before sending documents through their system.

Common gaps:

• No standard to compare against. Teams often want contract review AI but haven't formalized their standard terms. The AI has no baseline for "what should this clause say?" Fix this before deploying.
• Highly varied document formats. If every vendor you work with uses their own contract template, the AI's ability to flag deviations depends on how much variance it was trained to handle. Standard contracts from major vendors are usually covered. Bespoke contracts from small or international vendors may not be.
• Confidentiality considerations that prevent sending documents through vendor systems. Some organizations process contracts that contain client-confidential information they can't share with vendor AI systems. This is a blocker that requires either a build option or a vendor with specific data handling guarantees.

Readiness test: Select 20 representative documents from your recent contract queue. Verify they're text-layer PDFs (not image scans). Check whether your standard template library is documented in a form the AI can reference. If more than a third of your documents are image PDFs, add OCR pre-processing to your implementation plan.

Workflow Copilot, Personalization Engine, Autonomous Agent

Workflow Copilot: The critical dependency is context access. The copilot needs live read access to whatever the user is currently working with. If context integration requires an API that doesn't exist or isn't exposed, the copilot can't provide relevant suggestions. Pre-deployment check: map every data source the copilot needs to read, confirm API access exists, and verify the data quality in each source.

Personalization Engine: The critical dependency is behavioral telemetry. You need per-user behavioral events (clicks, views, purchases, engagement times) tracked consistently, each event attributed to a user identifier, and enough volume per user to build an individual preference profile. For B2B applications, "user" may mean account rather than individual. Pre-deployment check: pull your average events-per-user-per-month. Fewer than 50 events per user per month is generally insufficient for meaningful personalization.

Autonomous Agent: The critical dependency is tool API contracts and safety boundary definition. The agent needs documented API contracts for every tool it can call, with explicit permissions for what it can read, what it can write, and what actions are blocked. Safety boundaries (what the agent is never allowed to do autonomously) need to be defined before deployment, not after the first incident. Pre-deployment check: can you produce a written list of every API the agent calls, what data it reads from each, what actions it can take on each, and what actions are explicitly blocked?

The 5-Dimension Data Readiness Test

The 5-Dimension Data Readiness Test is an audit framework that evaluates any AI pattern deployment against five orthogonal dimensions before implementation begins: Availability (does the data exist?), Quality (is it accurate, complete, and consistent enough?), Access (can the AI system reach it?), Freshness (is it current enough for this pattern's purpose?), and Volume (is there enough for reliable training or baseline?). Each dimension is scored from 1 (not ready) to 5 (fully ready). Any dimension below 3 is a prerequisite blocker, not a risk to manage. The test is designed to be run with the team that owns each data source, not just the team that owns the AI deployment, because the most useful outcome is surfacing disagreements between data owners and AI deployment teams about what the data actually is.

Rework Analysis: Based on Gartner's finding that 63% of organizations don't know whether their data management practices meet AI requirements, and McKinsey's finding that 70% of high-performing AI organizations report difficulties integrating data into AI models quickly, the 5-Dimension Data Readiness Test addresses the most underinvested phase of AI implementation. In Rework's implementation data, teams that complete a formal data readiness audit before starting build work spend an average of $47,000 less on mid-implementation data remediation than teams that discover readiness gaps during integration testing.

The data readiness scorecard

For each pattern you're planning to deploy, score yourself on each dimension from 1 (not ready) to 5 (fully ready). Any dimension below 3 is a prerequisite blocker, not an implementation risk.

Run this scorecard with the team that owns each data source, not just the team that owns the AI deployment. The most useful thing this exercise does is surface disagreements about data quality between the people who manage the data and the people who want to use it. McKinsey's research confirms the organizational dynamic: even among high-performing AI organizations, 70% report difficulties integrating data into AI models quickly, and the highest performers are those who redesign data workflows rather than layering AI onto legacy data infrastructure.

Before you commit budget

Data readiness is a prerequisite audit, not a philosophical question. The outcome of this audit is a list of blocking items that need to be resolved before the pattern is deployable, not a general aspiration to improve data quality.

Each blocking item needs an owner, a timeline, and a success criterion. "Improve CRM data quality" is not a blocking item resolution. "Make win/loss reason a required field and backfill 12 months of historical deals by August 1" is. For the sales-specific version of this, CRM data hygiene with an AI copilot shows how CRM hygiene and AI readiness are the same problem.

See Pattern Dependencies and Prerequisites for how data readiness gaps in one pattern block the deployment of dependent patterns. See Sequencing AI Patterns in a Multi-Year Roadmap for how to factor readiness gaps into your deployment timeline.

And if you've already deployed a pattern and it's underperforming, Anti-Patterns: AI Combinations That Fail covers the diagnostic signals and recovery steps for each major failure mode. Most underperforming AI deployments trace back to a data readiness gap that was present at launch but not caught.

The patterns work. The data requirements are real. Run the audit before you commit.