How to Audit Your Business Data for AI Readiness (A Practitioner's Guide)

The most common thing we find when we start an AI engagement is that the client’s data isn’t ready.

Not in a catastrophic, start-from-scratch way. In a “this will produce confident wrong answers if we don’t fix it first” way. Bad data doesn’t mean you can’t pursue AI — it means you need to fix the data before you build the AI. The order matters.

This guide covers what a real data audit looks like for AI readiness: what we check, what we’re looking for, and what the findings typically mean for your implementation timeline.

Why data readiness is the first thing we check

AI models — whether large language models or simpler classification systems — learn patterns from data and apply those patterns to new inputs. If the patterns in your data don’t reflect reality, the model will faithfully reproduce the unreality.

A concrete example: if your CRM’s “Lead Source” field is populated correctly only 60% of the time, and an AI model is trained to route leads based on lead source, it will route leads correctly 60% of the time and make confident random guesses the other 40%. The problem isn’t the AI. It’s the data.

Data readiness is not about having perfect data. It’s about having data that is consistent, accessible, and representative enough that a model can extract real signal from it. Here’s how to assess that.

Dimension 1: Completeness

What we measure: The percentage of records with values in the fields that matter for the intended AI use case.

How to check it: For each field critical to your AI use case, calculate the fill rate: records with a value ÷ total records. Do this for both active records and historical records.

What we’re looking for:

• Fill rates below 70% in critical fields are a red flag. Below 50% is a blocker for most AI use cases.
• Check whether completeness varies by source, rep, time period, or team. Inconsistent completeness (good data from some sources, bad from others) is sometimes fixable by fixing the source — better than fixing 50,000 individual records.

Common findings: Close date fields that are blank or set to the default value. Company size fields that are empty for 80% of contacts. Deal stages that are correct for the current stage but have no history of previous stages. Industry classifications that were never entered.

What to do: Identify the fields most critical to your use case. Prioritize getting those fields populated — even if it means a manual backfill effort or a cleanup import. Two weeks of data cleanup often unlocks a project that would otherwise take six months longer.

Dimension 2: Consistency

What we measure: Whether the same concept is recorded the same way across records.

How to check it: Pull distinct values for categorical fields (like Lead Source, Industry, Stage, Region) and look at how many variations exist. Also look at text fields — are names entered in the same format? Are company names standardized?

What we’re looking for:

• Picklist fields with dozens of near-duplicate values: “Inbound”, “inbound”, “INBOUND”, “Inbound Lead”, “Inbound - Web”. These are all the same thing and will be treated as different categories by any model.
• Free-text fields used where picklists should be. If “Industry” is a free-text field, you’ll have 400 variations of “Healthcare”.
• Date field formats that vary: some records with dates in MM/DD/YYYY, others with YYYY-MM-DD, others with text like “Q3 2025”.
• Inconsistent use of nulls vs. empty strings vs. placeholder values like “N/A” or “TBD”.

Common findings: CRM records where “Lead Source” has 40+ distinct values because nobody cleaned it up after a merge, a system migration, or a team expansion. Records where “Company Name” includes “Inc.”, “Inc”, “Incorporated”, and nothing for the same company.

What to do: Run a normalization pass on the fields most important to your use case. For picklist fields, create a canonical value list and remap existing records. This is usually a one-time effort that pays for itself immediately — both for AI readiness and for reporting accuracy.

Dimension 3: Accessibility

What we measure: Whether the data you need can be programmatically accessed when and where the AI needs it.

How to check it: Identify the systems that hold the data for your intended AI use case. For each system, answer:

• Does this system have an API?
• Is there a supported integration method (webhook, streaming, batch export)?
• Is authentication manageable (OAuth, API key, SAML)?
• Are there rate limits that would affect real-time use cases?

What we’re looking for: Data that exists but is only accessible via manual export (CSV download). Systems without documented APIs. Data that lives in legacy tools with no modern integration support. Critical context that lives in email or Slack rather than a system of record.

Common findings: Quote history in a legacy quoting tool that has no API and requires a CSV export every morning. Customer interaction history in a support platform that has an API but requires significant transformation before it’s usable. Product usage data that the engineering team can query but that isn’t exposed to any business-facing system.

What to do: For each data source required by your AI use case, build a connectivity map. If API access doesn’t exist, estimate the cost of building an integration before you price the AI project. The integration is often half the work — and should be priced and planned accordingly.

Dimension 4: Recency and Representativeness

What we measure: Whether your historical data is recent enough and varied enough to represent the patterns your AI will encounter in production.

How to check it: Look at the age distribution of your records. Look at whether the historical data covers the full range of cases you expect the AI to encounter.

What we’re looking for:

• Historical data that’s mostly more than 3 years old when your business or product has changed significantly since then. A model trained on pre-pandemic customer behavior may not generalize well.
• Training data that doesn’t include edge cases. If 95% of your historical records are routine cases and 5% are exceptions, a model trained on this data will handle routine cases well and fail on exceptions — which may be exactly the cases where AI assistance matters most.
• Seasonal or cyclical patterns that aren’t captured in the historical window. A model trained on 6 months of data may miss a pattern that occurs every 12 months.

Common findings: Lead scoring models trained on historical data where high-quality leads were manually curated — meaning the “good lead” examples are systematically different from what the model will see in production. Customer churn models trained on data from before a major pricing change that shifted which customers stay vs. leave.

What to do: Be realistic about what your historical data represents. If it doesn’t represent the current business reality, consider whether a smaller dataset from a more recent period is better than a larger dataset that reflects a different era.

Dimension 5: Governance and Ownership

What we measure: Whether data quality is maintained over time, or whether it degrades the moment the cleanup effort ends.

How to check it: Ask who is responsible for data quality in each system. Ask whether there are validation rules that enforce quality at the point of entry. Ask what happens when a new field is created — is there a process for populating historical records?

What we’re looking for: Systems where anybody can edit any field with no validation. Fields that were clean six months ago but have degraded because the cleanup was a one-time event rather than a process change. Data that is high-quality in the hands of one team and low-quality in the hands of another because the standards were never shared.

Common findings: CRM instances where field validation was turned off because it was “too annoying” for the sales team. Data that is clean for enterprise accounts (which get careful attention) and poor for SMB accounts (which don’t). Integration-created records that bypass validation rules and arrive with missing required fields.

What to do: For any AI project that depends on ongoing data quality, pair the AI implementation with a governance update: validation rules at the point of entry, ownership assignments for critical fields, and a periodic quality audit cadence. AI built on data that degrades over time will degrade with it.

When to fix it yourself vs. bring in help

Fix it yourself if:

• The completeness and consistency issues are in a small number of fields
• You have a tool like Salesforce or HubSpot that has built-in data management features
• The volume is manageable — a few thousand records rather than a few million
• You have someone on your team who knows the system well and can own the cleanup

Bring in help if:

• The issues span multiple systems and require integration work to fix
• The root cause is process — how data is entered — rather than just the existing records
• Volume makes manual cleanup impractical
• You’re not sure what “clean” looks like for your specific AI use case

A good data audit takes a day or two and produces a clear priority list. It’s almost always worth doing before you start a significant AI investment — and it’s part of what we do in every WLT assessment engagement.

The mini-checklist

Before you start an AI project, run through these eight questions:

1. What is the fill rate for the three fields most important to this use case? (Target: >80%)
2. Are your categorical fields using consistent, normalized values? (If not, do a normalization pass)
3. Can the AI access this data programmatically, or only via manual export?
4. Is your historical data recent enough to represent current business patterns?
5. Does your historical data include enough examples of edge cases and exceptions?
6. Who owns data quality in each system involved? (If nobody, assign someone before you build)
7. Do you have validation rules that prevent bad data from entering the system?
8. After you clean the data, what process will keep it clean?

Eight yeses doesn’t guarantee success. But eight noes almost guarantees failure.

Next steps

If you want a practitioner’s read on your data readiness — including which systems to prioritize, what a realistic cleanup timeline looks like, and how data readiness maps to your specific AI use cases — that’s a significant part of what we cover in a WLT assessment.

The free scorecard is also a useful starting point: three of the fifteen questions specifically address data readiness, and the scoring guidance will tell you whether your data foundations are a blocker or a strength.

Download the free AI Readiness Scorecard →

See how a WLT assessment works →