AI & Data
Most AI projects fail because of bad data pipelines, not bad AI models
When AI projects fail in large organizations, it's almost never because the AI itself doesn't work. The problem is the data infrastructure feeding it — which was never built to support AI. Here's what you need to fix first.
The failure mode that the AI vendor ecosystem doesn't talk about
Enterprise AI has a problem that the model vendors, the cloud providers, and the consulting firms who run AI transformation programs have a collective incentive not to discuss: the majority of enterprise AI projects fail before a model is ever trained in a production environment. The failure is not at the model layer. It's at the data layer — the infrastructure that should produce training data, serve features to inference pipelines, and maintain the lineage records required for governance. That infrastructure doesn't exist in most enterprise environments, and building it takes longer than anyone's AI roadmap anticipates.
The four data requirements that determine AI production readiness
Requirement 1: Training data must be accessible, documented, and reproducible. This seems obvious, but most enterprise data estates have data that is accessible (you can query it) but not documented (no one knows what it means or whether it's been transformed) and not reproducible (the pipeline that produced it ran once, 18 months ago, on a server that no longer exists). Requirement 2: Feature values must be consistent between training and serving. The same feature computed by the training pipeline and the inference pipeline must produce the same result. When they don't — and they frequently don't, because the pipelines were built by different teams at different times — the model you trained and the model you deployed are not the same model from the data perspective. Requirement 3: Data lineage must be traceable at the column level. Not because it's good practice, but because it's increasingly a regulatory requirement. The EU AI Act, NIST AI RMF, and most financial services AI governance frameworks require that you can trace every feature back to its source. Requirement 4: Access controls on training data must be compatible with the access model of the ML training pipeline. Training pipelines often need to read across datasets that are normally siloed for compliance reasons. Resolving this without violating the compliance controls is an architectural problem, not a permissions problem.
Why the timeline estimate is almost always wrong
The most common failure in enterprise AI program planning is underestimating the data infrastructure work by a factor of 3–5x. A typical estimate allocates 2–3 months for data preparation and 6–9 months for model development and deployment. In practice, the data infrastructure work takes 12–18 months in environments where it wasn't designed for AI workloads — which describes most enterprise environments. The model development phase is genuinely fast with modern tooling. The data infrastructure phase is slow because it requires changes to operational systems that weren't designed to be changed, documentation of data that was never documented, and resolution of access control conflicts that were never anticipated.
What the right starting point looks like
The right starting point for an enterprise AI program is a data infrastructure audit, not a model selection process. The audit should answer: what data do we have that's relevant to the AI use case; what is the quality of that data and how is it measured; what is the latency from event occurrence to data availability; what access controls apply to the data and how will the ML pipeline satisfy them; and what lineage documentation exists. The answers to these questions determine whether the AI program can proceed on the proposed timeline or whether data infrastructure remediation is required first. Starting with model selection before answering these questions produces projects that stall 6 months in when the data infrastructure gaps become blocking issues.
Want early access to our thinking?
Subscribe to receive Aethon Core insights as they publish — practical, plain-language content on enterprise technology from people who build it.