The Data Foundation for Enterprise AI

A consistent finding across enterprise AI post-mortems is that model quality accounts for a minority of project failures. The larger category is data readiness — the organisation's ability to supply the AI system with accurate, accessible, governed, and contextually appropriate information at the time of inference.

McKinsey's 2024 State of AI survey found that data-related challenges (quality, access, and governance) were cited as top barriers by more respondents than model cost or capability. Gartner has estimated — with the caveat that such figures are surveys, not audits — that roughly 80% of enterprise AI projects that fail cite data issues as a primary cause. The intuition is straightforward: a frontier model applied to garbage data produces confident garbage. The sophistication of the model amplifies whatever is in the data, including its errors.

Data quality for AI has four distinct dimensions, each of which can independently kill a deployment:

1. Accuracy. Is the data factually correct? A product catalogue with stale prices, a customer database with duplicate records, or a policy document that was superseded 18 months ago will all be reflected faithfully in model outputs — and attributed confidently to the organisation.
2. Completeness. Are the relevant records present? Retrieval-augmented systems can only surface what exists in the corpus. Missing contracts, undocumented decisions, and knowledge that lives only in email threads are invisible.
3. Consistency. Does the same entity have conflicting representations across systems? Three CRM records for the same customer with different account managers will produce three different AI answers to the same question.
4. Timeliness. Is the data current? For regulatory content, product information, and pricing, a 6-month-old embedding index is a liability. Freshness requires pipelines — not a one-time ingestion.

Most organisations have reasonable intuitions about accuracy. Completeness and timeliness are systematically underestimated in pilot planning.

Data governance means knowing what data exists, who owns it, who can access it, and under what conditions. Data lineage means being able to trace any AI output back to the source data that produced it.

Both become non-negotiable in three scenarios that are common in enterprise AI:

• Regulated industries. Financial services, healthcare, and insurance all have requirements to explain decisions. If an AI system recommends a credit limit or a treatment protocol, auditors need the lineage chain — which data, which model version, which retrieval step — to verify compliance.
• Hallucination remediation. When an AI system produces an incorrect output, the fastest diagnostic is lineage: did the wrong answer come from wrong source data, a retrieval failure, or a generation error? Without lineage, remediation is guesswork.
• EU AI Act scope. High-risk AI systems under the EU AI Act (effective August 2024 for many provisions) require documented data governance, including training data provenance and ongoing monitoring. Lineage is not optional for in-scope deployments.

Building governance retroactively — after a deployment is already in production — is expensive and often impossible without re-architecting the pipeline.

Two dominant architectures for grounding enterprise AI in proprietary knowledge are Retrieval-Augmented Generation (RAG) and fine-tuning. They are not substitutes — they solve different problems at different cost points.

The most common mistake: using fine-tuning to inject factual knowledge (e.g., teaching the model your product SKU list) when RAG is cheaper and more maintainable. Fine-tuning does not reliably store facts — it adjusts the model's generation style and patterns.

Scenario: A financial-services firm deploys a RAG-based assistant to help advisors answer client questions about product fees. The source corpus is the firm's PDF product disclosure statements (PDS), ingested once at launch.

Six months later, two fee structures were updated. The PDFs were not re-ingested. The assistant continues to quote the old fee tables — confidently, with citations to the (outdated) PDS documents.

An advisor uses the AI-generated fee quote in a client proposal. The client notices the discrepancy after signing. The compliance team investigates.

What went wrong:

• No data-freshness pipeline: the index was treated as a static asset.
• No lineage: the system didn't flag the document version or date to the advisor.
• No automated staleness detection: nothing triggered an alert when the source PDFs changed.

Cost of remediation: manual review of all proposals generated in the 6-month window, client remediation communications, compliance report. Easily 10–20x the cost of building a proper ingestion pipeline at launch. The model was blameless. The data infrastructure failed.

Before launching an AI project, score your data estate on each dimension. This is not a vendor checklist — it is a frank internal audit.

A single Red is typically sufficient to delay launch. Multiple Yellows without remediation plans are a predictable path to the pilot-to-production chasm.

Enterprise AI systems are bounded by what has been written down and made accessible. The vast category of tacit knowledge — how a senior underwriter actually evaluates a non-standard risk, how a sales engineer decides which configuration to recommend, the unwritten rules that govern exception handling — is invisible to any AI system until it is externalised.

This is simultaneously the greatest opportunity and the most underestimated cost in enterprise AI. Organisations that invest in knowledge externalisation — structured documentation, decision logs, annotated examples — build a data asset that compounds. Those that don't will find their AI systems confidently wrong in precisely the edge cases that matter most, because edge cases are where tacit knowledge is concentrated.

The practical implication: knowledge externalisation is not an IT project. It requires domain-expert time, incentive structures that reward documentation, and tooling that makes capture low-friction. Budget for it explicitly or plan to under-deliver.

The most costly sequencing error in enterprise AI programs is running AI deployment in parallel with data remediation, rather than making data readiness a gate.

The sequence that fails:

1. Launch pilot with available data.
2. Pilot produces mixed results — attributed to the model.
3. Swap model. Results still mixed.
4. 18 months later: discover the actual cause was incomplete, inconsistent source data.

The sequence that works:

1. Run the data-readiness scorecard before selecting the use case.
2. Choose the use case where the data estate already scores Green or Yellow-with-plan.
3. Build the ingestion, freshness, and lineage pipeline before the first user query.
4. Treat data quality KPIs as first-class metrics alongside AI output quality.

This sequencing constraint is why the best enterprise AI programs are run out of teams with data-engineering capability, not just data science or product capability. A brilliant model on a broken data pipeline is just a more confident way to be wrong.