The data infrastructure gaps that surface when AI moves in
A churn model at a telecommunications company I worked with flagged a customer who had just renewed. The investigation took three days. The renewal was in the CRM, the feature pipeline read from the data warehouse, and the warehouse had not ingested the renewal yet. What the model saw was three days out of date, and it flagged the customer correctly, given what it knew.
The instinct is to investigate the model. The gap was in the data infrastructure. This is the pattern that surfaces when AI workloads land on top of a data platform built for BI: the model is fine; the layer beneath it was not designed for what the model needs.
The data access layer
A data warehouse is optimised for throughput: batch reads, aggregations, scheduled refreshes. BI tolerates staleness. AI inference does not.
A feature store serving a recommendation engine needs to return features in under 100ms. A fraud detection model needs a transaction history in under 50ms. A vector database handling embedding search is a different retrieval primitive entirely. None of these access patterns were in scope when the data warehouse was designed, and the data warehouse cannot serve them.
The practical consequence: every data source feeding an AI model needs its latency and freshness requirements defined before the model is built, not after it fails. A churn model can tolerate features computed yesterday. A real-time personalisation model cannot. When those requirements are not defined upfront, they are discovered in production, with a failing model as the forcing function.
The cold start
AI models need historical data to train on. How much depends on the use case — a recommendation model might need two years of interaction history; a fraud detection model might need every transaction for the past five years. That history has to be complete and consistent enough to train on.
It rarely is. Fields that were optional are sparse for the first year of collection. A schema change three years ago means column names differ across time periods. A data quality issue resolved last year left a defect in the two years before it.
At a healthcare company I worked with, the business had accumulated years of internal reports — PDFs, Excel files, Word documents, PowerPoint decks — stored on a shared drive without metadata, consistent naming, or access controls. When they tried to build a classification model and a chat interface over that data, the preprocessing took months before the first model could run. The data was there. The engineering to make it usable was not.
Every month of consistent, quality-checked data collection is a month of training data that cannot be bought back. The teams that treat data as a training asset from the start — documenting schema changes as they happen, backfilling gaps when they surface, defining what will be needed before the model is scoped — have a shorter path to the first result in production.
The governance layer
An AI agent does not consistently caveat. When it queries a data warehouse to compute a business metric, it returns what the data says, unaware of any contested definition or known inconsistency. A data analyst in the same position would flag the ambiguity. The agent might not, unless that context has been put into the data layer deliberately.
The data contracts and semantic layer that make this tractable I have covered in earlier posts — the relevant point here is that the governance work needs to happen before the agent is deployed, not after the first output is questioned by a stakeholder who knows the number is wrong.
Data observability
Three days to trace a feature pipeline back to a CRM sync gap. The reason it took three days: no data lineage. Without a map of which data sources feed which features, which features feed which models, and which models produce which outputs, debugging runs backwards through the chain manually.
Most data teams have partial lineage at best — they know which dashboards depend on which tables. End-to-end lineage from raw data source to model output is rarer, and expensive to build retroactively. The teams that instrument it from the start pay a one-time cost. The teams that do not pay it every time a model produces a result nobody can explain.
The leadership mandate
These are data infrastructure decisions, not ML decisions. A data engineer can implement a feature store. They cannot decide that the model's latency requirement is 50ms and that the existing data warehouse cannot meet it — that is a product decision, and it needs to be made before the model architecture is chosen.
The AI project almost always starts with the model. The data infrastructure gaps surface when the model fails. By then the team is behind the deadline, the model is already built, and the data infrastructure conversation happens under pressure. Starting it before the first model is scoped changes what that conversation costs.
The path forward
The three days spent tracing a feature pipeline back to a CRM sync gap is a cost that repeats every time a model produces a result nobody can explain — until the data observability layer exists. The cold start problem does not get cheaper the longer it waits. The governance gaps do not close themselves. The conversation worth having before the first model is scoped is not which model to build. It is whether the data layer beneath it is ready — and that is where I usually start.
